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?

But why then not just put the memory in a contiguous arrangement, where 
incrementation would get you the next line?

> 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.

> 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?
 
>   After those, the next 32x24 bytes had the color data.
> 
>   Anyways, both the fact that images contain regular patterns instead of
> random pixels *and* that weird ordering made an image saved on casette to
> have a rather distinctive sound which any Spectrum user would recognize
> immediately. The color data itself also made a relatively distinctive
> sound, especially coming immediately after the pixel data, which made it
> immediately recognizable when the color data begun.
> 
>   (One nice thing about all that data being mapped to RAM into consecutive
> memory locations is that you could load an image directly from a casette
> to the screen, and watch it form while loading, in real-time.)

You saw this on the Apple ][ as well - but then I guess it was just because 
it was so slow. (Even when loading from the Apple's floppydisk). 

-- 
Stefan Viljoen

Post a reply to this message