Stefan Viljoen wrote:
> I consider THAT hardcore.

Hardcore would be still remembering which instruction loops made which 
tones. :-)

Someone else did a program that played the opening of the Fifth Symphony by 
controlling the hammer timing on the line printer while it printed out a 
2-page ascii-art picture of beethoven.  That's was pretty cool. :-)

Or playing taps with a program that fit in the 16 registers of the machine 
after you'd told it to power down and the memory was no longer online. :-)

-- 
   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:
> Warp wrote:
> > which I could instantly recognize even today.

> That's hardcore. :-)

  Well, not really. Images are far from being as random as eg. machine
code or other game data. After all, images are not just noise, but have
tons of patterns in them.

  As someone commented, Spectrum used a rather weird ordering for the screen
pixels (for some reason I never understood; maybe they thought they were being
smart or something, but it really backfired; after all, I'm sure that when
they first designed the architecture they didn't even think that it would
actually be used to play full-fledged full-screen games):

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

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

-- 
                                                          - Warp

Post a reply to this message

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