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

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

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> which I could instantly recognize even today.
> 
>> That's hardcore. :-)
> 
>   Well, not really.

That you think you could still recognise it? *That* is the hardcore part. :-)

> (Besides those being nice "round" numbers, otherwise that ordering makes
> absolutely no sense, 

The only reason I could think of would be memory bandwidth issues. DMA was 
quite expensive at the time.

-- 
   Darren New, San Diego CA, USA (PST)
     Is God willing to prevent phrogams, but not able?
       Then he is not omnipotent.
     Is he able, but not willing, to prevent phrogams?
       Then he is malevolent.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > (Besides those being nice "round" numbers, otherwise that ordering makes
> > absolutely no sense, 

> The only reason I could think of would be memory bandwidth issues. DMA was 
> quite expensive at the time.

  There might have been some technical reason for that odd pixel ordering,
but I have the gut feeling that they decided on that ordering for some
subjective (and ultimately stupid) reasons, like "it looks cool when an
image being loaded appears in sparse scanlines which get slowly filled"
or something along those lines.

  It might perhaps had even made some sense if the 8-pixel jumps from one
pixel row to the next would have been continuous from top to bottom, but
instead, as said, the screen was divided into three parts so that the upper
third of the screen would fill up first, and when it was completely full,
then the middle third, and then the lower third.

  (With a vertical resolution of 192 pixels one third makes a round amount
of 64 pixels, ie. 8 rows of 8x8 blocks. While all that sounds all round and
nice in binary, it's a real pain in the ass to draw anything, and you have
to waste precious clock cycles into jumping properly around inside the
screen buffer to draw something. In the Spectrum everything had to be done
with the CPU, as there were no auxiliary graphic chips of any kind.)

-- 
                                                          - Warp

Post a reply to this message

Bill Pragnell wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> which I could instantly recognize even today.
>> That's hardcore. :-)
> 
> Puts me in mind of the blind character in 'Sneakers' who could tell what sort of
> wiring they were snooping by the buzz it made over his speaker.

Yep, his name was Whistler.  They never stated why he was called that, 
but I always assumed he could whistle a perfect 2600 :)

...Chambers

Post a reply to this message

Darren New wrote:

> I wrote a program once that you could set a radio on the console and it 
> would play music with the interference from the bus lines.  You know, 
> back in the days when instructions ran at roughly the speed of AM radio 
> wavelengths. :-)

Dude, I thought this was just an urban legend! O_O

Post a reply to this message

On Tue, 17 Nov 2009 17:02:43 +0100, Darren New <dne### [at] sanrrcom> wrote:
>
> I wrote a program once that you could set a radio on the console and it  
> would play music with the interference from the bus lines.

http://hackedgadgets.com/2006/07/17/music-via-monitor-interference/



-- 
FE

Post a reply to this message

Warp wrote:

> 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

Which ZX Spectrum video mode was this?

'pedia says there are / were lots and lots of them - what mode does this 
arrangement refer to? The lowest res one?

Or were all the modes arranged similarly to this way, only with longer lines 
and "quicker" jumps?
-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen wrote:

> Warp wrote:
> 
>> 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
> 
> Which ZX Spectrum video mode was this?
> 
> 'pedia says there are / were lots and lots of them - what mode does this
> arrangement refer to? The lowest res one?
> 
> Or were all the modes arranged similarly to this way, only with longer
> lines and "quicker" jumps?

From http://www.worldofspectrum.org/faq/reference/sereference.htm:

---
Memory is paged in 8K banks from either the DOCK or the EX bank, but these 
banks are mutually exclusive - you cannot page in a bank from both 
simultaneously. Bit 7 of port 0xff determines which bank to use (0=DOCK, 
1=EX-ROM). Port 0xf4 determines which banks are to be paged in with each bit 
referring to the relevant bank (0-7 or 0'-7'). When memory is being paged, 
interrupts should be disabled and the stack should be in an area which is 
not going to change.

On a TC2048, BASIC is contained in the 16K ROM area and banks 0-7 and 0'-7' 
are not normally available, while on a TS2068 part of the BASIC is stored in 
an 8K ROM in bank 0' and cartridges plugged into the dock use banks 0-7. On 
the SE each of these banks is connected to 64K of RAM, providing an 
additional 128K in addition to the base RAM.

The contended memory timings for the SE are unknown but should be similar to 
that for the 48K machine, except that the pattern starts at a different 
number of T-states after the interrupt, than the usual 14335. Odd banks in 
the 128 scheme are contended.
---

"Memory is paged in 8K banks from either the DOCK or the EX bank, but these 
banks are mutually exclusive - you cannot page in a bank from both 
simultaneously."

and

"The contended memory timings for the SE are unknown but should be similar 
to that for the 48K machine, except that the pattern starts at a different 
number of T-states after the interrupt, than the usual 14335. Odd banks in 
the 128 scheme are contended."

What does that imply? It seems as if the reason for the knit-one-slip-one 
video RAM approach was the way the Speccy handled interrupts, and / or the 
hardware being incapable of paging more than 8K at a time? (8192 bytes / 256 
bytes per line = 32 ?)

I. e. on one interrupt tick you can get the first 32 columns of line one, on 
the next tick the first 32 columns of line sixteen, etch. - due to the 
limitations of the architecture's memory handling paradigm of "max 8k 
blocks" only?
-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen <pov### [at] polardcom> wrote:
> Which ZX Spectrum video mode was this?

  The ZX Spectrum has exactly one video mode.

> 'pedia says there are / were lots and lots of them - what mode does this 
> arrangement refer to? The lowest res one?

  I don't know which article you are reading, but it's definitely not about
the ZX Spectrum.

-- 
                                                          - Warp

Post a reply to this message