Stefan Viljoen <pov### [at] polardcom> wrote:
> Warp wrote:

> >   The first 32 bytes in the screen memory represented the first line of
> > pixels (256 of them). The next 32 bytes represented the *eigth* line of
> > pixels. The next 32 bytes represented the *sixteenth* line of pixels,
> > and so on, until you get to one third of the screen, ie. 8 such groups
> > of 32 bytes, after which the next 32 bytes represented the second line

> Hmm didn't this have to do with it being quicker to multiply by powers of 
> two to get the next address by shifting right instead of "actually" 
> multiplying?

  No. That doesn't explain why the screen is divided into 3 sections and
the horizontal lines jump around. It makes eg. drawing a sprite a whole lot
more complicated (and slower) than if all the pixels were just contiguous.

> > of pixels, the next 32 bytes the ninth line, and so on. Then it went to
> > the second third of the screen, and then the third third, in the same way.
> > (Besides those being nice "round" numbers, otherwise that ordering makes

> I seem to remember that this same technique (shifting right instead of 
> multiplying) was in the Turbo Assembler Bible by Gary Syck as a quick way to 
> get the offset of an x and y location in 320x200 VGA.

  It has nothing to do with shifting or multiplying.

> > absolutely no sense, and I don't think there's a single person in
> > existence who understands why they chose such a weird ordering. It only
> > made coding games a lot harder than it had to be. Well, programmers
> > learned to cope.)

> From the far distant past... isn't this something that is vaguely similar to 
> "mode-x" used for 320x200 VGA displays, especially by demo coders of the 
> late 80's?

  The pixel arrangment in the Spectrum was not to save memory or address
space, nor is it at all similar to that in geometry.

-- 
                                                          - Warp

Post a reply to this message