>> (Now I'm curious to know what the original retail price was...)
>
> https://en.wikipedia.org/wiki/ZX_Spectrum
>
> Lists some original retail price.  Don't thank me, thank Google. ;)

Hmm. So, at £99, this recreation is *almost* the same price as the 
original, 30+ years later. Nice.

>> Isn't that what the Raspberry Pi was supposed to do?
>
> Depends a lot on what you want to teach.

I guess the Pi by itself doesn't do a lot; it's great for building crazy 
robots, if *electronics* is what you're trying to teach. But you need 
more components to make a usable computer out of it. And then there's so 
many other bits plugged in, you lose sight of the fact that the little 
circuit board in the middle is the part that's actually "doing" stuff.

>> Don't get me wrong, I think it's *way* easier to learn system-level
>> programming on obsolete hardware. (It's how *I* did it!) But I doubt
>> many kids these days would get out of bed to see some blocky 8-bit
>> graphics.
>
> Also depends on what you want to teach.

When I was a kid, 8-bit graphics were all you could ask for. I can 
actually recall spending *multiple hours* playing Space Invaders. I 
can't imagine why; today it seems like the most boring game imaginable! 
It wouldn't hold my attention for ten seconds. And that's kinda my 
point; kids these days have smartphones in their pockets. Why would they 
bother with this obsolete thing? (Unless you manage to convince them 
that its arcane-ness makes it "special" rather than just dumb.)

>> Which is why they invented the Pi, with it's full-HD video and audio
>> capabilities and 3D rendering support... Which thus makes it impossible
>> to do system-level programming, kinda negating the point.
>
> You certainly can do system-level programming on the RPi.  How do you
> think you get a kernel developed to run on it? ;)

You're aware that to this day, the OS includes a closed-source binary 
blob that only people who sign an NDA are allowed to look inside, right? 
Literally, you cannot operate the GPU without signing an NDA or using 
closed-source code. And since this is a mobile phone SoC, the GPU 
controls the CPU, not the other way around...

But sure, once you've started the CPU, you can do system-level 
programming. Good luck getting anything interesting done; it's not like 
you can just poke 53280 to change the overscan colour... ;-)

>> And besides, for £0 you can probably just *download* a Spectrum emulator
>> onto your PC or indeed phone or tablet... You don't actually need a
>> physical box.
>
> Not the same, and as I said, it depends on what you want to teach.

I will admit, particularly for a younger audience, there's a certain 
something to having it be a hardware box.

Post a reply to this message

>> Huh. I did not know that. Come to mention it, I don't remember
>> there being an expansion port!
>
> You remember the pcb at the back, that is the expansion bus... At
> least for the original 16k and 48k model. I do not remember if there
> was a default plug/cache on it or if it was all time open.

Huh. I forgot about that. Yeah, I think we had the 16K model. Not 100% 
sure...

> The 128k wasted all: the keyboard and rear was different. (and the
> 128k were via bank switching of 16k... otherwise, it was like a 32k +
> 16k switched... and the double size rom (16k x 2) was also switched.
> Well, it's only a 16 bits Z80, what did you expect !

So there *was* a system with bank-switching! I'm so glad I invented that 
idea when I was only 11 years old... I *knew* somebody must have thought 
of it before!

>> Ah, the hours I wasted with our Spectrum hooked up to a portable 4"
>> CRT monitor. Do you know what 8x8 characters look like on a 4"
>> screen with manually-tuned RF? I do...
>
> Mine was hooked on TV. oh the battles vs the TV shows.
> Only 2 colours per 8x8 pixels was the main drawback of the display.
> (and the fancy flash mode bit... hardly documented, surprising to use)
> That, and only 8 colours.

Oh yeah, this was a TV too. A portable TV for camping. Which, if you 
know anything about CRT, "portable" doesn't really come into it. The TV 
was 4" at the front, but about 9" long to accommodate the huge tube and 
transformer at the back. Bloody heavy too! And with manual tuning, for 
some reason... I'm guessing it was cheap?

For those that don't know, mis-tuned RF signals result in a weird kind 
of zig-zag ghosting pattern that's very distracting...

Post a reply to this message

On 26/10/2015 09:06 PM, Le_Forgeron wrote:
> Only 2 colours per 8x8 pixels was the main drawback of the display.

Oh yeah... I forgot about that! One time I wrote a program to draw 
randomly positioned circles in random colours. After a few minutes of 
drawing, most of the pixels were in the "on" state, but there were weird 
squares of colour that changed every time a new circle was started.

I also remember saving several test patterns to tape, and eventually 
discovering which colour provoked which tone from the speaker... Jesus, 
I was bored as a child!

I've always wanted to know... why is the framebuffer arranged so 
weirdly? Like, as you load a picture file, rather than filling from top 
to bottom, it seems to fill every Nth line...

Post a reply to this message

On Mon, 26 Oct 2015 22:38:03 +0000, Orchid Win7 v1 wrote:

>> Depends a lot on what you want to teach.
> 
> I guess the Pi by itself doesn't do a lot; it's great for building crazy
> robots, if *electronics* is what you're trying to teach. But you need
> more components to make a usable computer out of it. And then there's so
> many other bits plugged in, you lose sight of the fact that the little
> circuit board in the middle is the part that's actually "doing" stuff.

I've got OpenELEC running on one; it makes a reasonable media server.

Nothing else really plugged in, either.  HDMI, external hard drive, 
power.  Wireless keyboard/mouse combo that I generally don't use.

>>> Don't get me wrong, I think it's *way* easier to learn system-level
>>> programming on obsolete hardware. (It's how *I* did it!) But I doubt
>>> many kids these days would get out of bed to see some blocky 8-bit
>>> graphics.
>>
>> Also depends on what you want to teach.
> 
> When I was a kid, 8-bit graphics were all you could ask for. I can
> actually recall spending *multiple hours* playing Space Invaders. I
> can't imagine why; today it seems like the most boring game imaginable!
> It wouldn't hold my attention for ten seconds. And that's kinda my
> point; kids these days have smartphones in their pockets. Why would they
> bother with this obsolete thing? (Unless you manage to convince them
> that its arcane-ness makes it "special" rather than just dumb.)

Lower end equipment can help kids and students understand where the 
technology comes from and how it developed over time.  Understanding the 
past is useful to seeing ways in which things can be done in the future.

>>> Which is why they invented the Pi, with it's full-HD video and audio
>>> capabilities and 3D rendering support... Which thus makes it
>>> impossible to do system-level programming, kinda negating the point.
>>
>> You certainly can do system-level programming on the RPi.  How do you
>> think you get a kernel developed to run on it? ;)
> 
> You're aware that to this day, the OS includes a closed-source binary
> blob that only people who sign an NDA are allowed to look inside, right?
> Literally, you cannot operate the GPU without signing an NDA or using
> closed-source code. And since this is a mobile phone SoC, the GPU
> controls the CPU, not the other way around...

Yes, but that's true on a lot of PCs that run Linux as well.  That 
doesn't mean you can't do system-level programming on it.

> But sure, once you've started the CPU, you can do system-level
> programming. Good luck getting anything interesting done; it's not like
> you can just poke 53280 to change the overscan colour... ;-)

I think there's a lot you can do that's interesting without any video at 
all.

>>> And besides, for £0 you can probably just *download* a Spectrum
>>> emulator onto your PC or indeed phone or tablet... You don't actually
>>> need a physical box.
>>
>> Not the same, and as I said, it depends on what you want to teach.
> 
> I will admit, particularly for a younger audience, there's a certain
> something to having it be a hardware box.

Absolutely.

Jim



-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

Le 26/10/2015 23:43, Orchid Win7 v1 a écrit :
> I've always wanted to know... why is the framebuffer arranged so
> weirdly? Like, as you load a picture file, rather than filling from top
> to bottom, it seems to fill every Nth line...

Probably because Pal is an interleaved image: there is odd and even 
frames. It was probably easier for the electronic in charge of 
generating the lines in that order instead of obvious linear order.

IIRC the memory was not a dual access memory (that's expensive), so for 
the chip to generate the signal, it might have been easier to read 
consecutive address (an hardware counter is cheap).

Oh, it was a time in which accessing memory was easy: presents an 
address on the address bus, read the data on the data bus. No column & 
no row selection, no wasted cycles to wait for the data (no CAS Latency !)

Post a reply to this message

On 27/10/2015 07:23 AM, Le_Forgeron wrote:
> Le 26/10/2015 23:43, Orchid Win7 v1 a écrit :
>> I've always wanted to know... why is the framebuffer arranged so
>> weirdly? Like, as you load a picture file, rather than filling from top
>> to bottom, it seems to fill every Nth line...
>
> Probably because Pal is an interleaved image: there is odd and even
> frames. It was probably easier for the electronic in charge of
> generating the lines in that order instead of obvious linear order.
>
> IIRC the memory was not a dual access memory (that's expensive), so for
> the chip to generate the signal, it might have been easier to read
> consecutive address (an hardware counter is cheap).

See, for example, this image:

https://i.ytimg.com/vi/O6uwfM8F5uU/hqdefault.jpg

It seems to load every 8th line, for the top 6 groups, and then load 
every 8th line for the next 6 groups, and so on... That's a really weird 
order. I could understand if it was loading all the odd lines and then 
all the even lines, but it's much more complicated than that.

(Also, recall that the Spectrum doesn't go to high enough resolutions 
for the odd/even scans to make sense; every pixel is at least two 
scanlines high!)

> Oh, it was a time in which accessing memory was easy: presents an
> address on the address bus, read the data on the data bus. No column &
> no row selection, no wasted cycles to wait for the data (no CAS Latency !)

I was shocked an horrified when I realised that RAM doesn't work this 
way any more. It seems today, the difference between DDR3-1333 and 
DDR3-1600 is merely the speed of the complex bus protocol connecting the 
processor chip to the RAM chips; the actual memory cells themselves are 
exactly the same speed. It's like the difference between a USB2 HD and a 
USB3 HD; it's the same physical harddisk in there, just connected to a 
faster bus. But it won't access your files any quicker!

But then, I remember being horrified when I realise that even since 
waaaay back in the 80386, the processor isn't actually *executing* your 
instructions any more. It's compiling them into an intermediate RISC 
language and doing dependency analysis and branch prediction and cache 
management and... man, just EXECUTE THE CODE ALREADY! Sheesh...

The problem with x86, of course, is the forty years of backwards 
compatibility. :-P

Post a reply to this message

Am 26.10.2015 um 19:12 schrieb Orchid Win7 v1:
> http://www.ebuyer.com/708786-recreated-zx-spectrum-kyb-zxspectrumbt
> 
> 1. Why would anybody want this?

Because their original has worn out?

> 2. THE PRICE!!

Yeah, especially once you factor in inflation. We really should have had
the price back then!

Post a reply to this message

Am 27.10.2015 um 09:29 schrieb Orchid Win7 v1:
> On 27/10/2015 07:23 AM, Le_Forgeron wrote:
>> Le 26/10/2015 23:43, Orchid Win7 v1 a écrit :
>>> I've always wanted to know... why is the framebuffer arranged so
>>> weirdly? Like, as you load a picture file, rather than filling from top
>>> to bottom, it seems to fill every Nth line...
>>
>> Probably because Pal is an interleaved image: there is odd and even
>> frames. It was probably easier for the electronic in charge of
>> generating the lines in that order instead of obvious linear order.
>>
>> IIRC the memory was not a dual access memory (that's expensive), so for
>> the chip to generate the signal, it might have been easier to read
>> consecutive address (an hardware counter is cheap).
> 
> See, for example, this image:
> 
> https://i.ytimg.com/vi/O6uwfM8F5uU/hqdefault.jpg
> 
> It seems to load every 8th line, for the top 6 groups, and then load
> every 8th line for the next 6 groups, and so on... That's a really weird
> order. I could understand if it was loading all the odd lines and then
> all the even lines, but it's much more complicated than that.

Actually judging from the image that seems to be 8 groups, not 6.

The Amstrad CPC had a similar frame buffer arrangement, though a little
simpler.

In the case of the Amstrad CPC, this was easily explained:

The CRT controllers used back in those days were originally designed for
text-only display, such as in text terminals: In sync with the cathode
ray, the CRTC would generate an address into a text buffer, plus a
separate pixel row address; in normal operation, the former would be
used to fetch a character code from the text framebuffer; the character
code combined with the pixel row address would then be used as an index
into a character ROM, to fetch the bit pattern of a single pixel row of
the character in question. The CRTC would then fetch that bit pattern
into a shift register, to control the cathode ray brightness for
(typically) 8 pixels.

Such controller chips were already widely available back then, while
dedicated graphics CRTCs were not.

To use such a text CRTC for graphics display with a minimum of
circuitry, a clean framebuffer layout would have required to make the
image width a power of 2; in that case you could splice the text buffer
address into a lower and higher portion (being equivalent to a column
and super-row address, respectively), and insert the pixel row address
between the two (as the row address) to generate a framebuffer address.
But with any non-power of 2 image width, this scheme would either
utterly break down, or require you to sacrifice precious memory.

Therefore, typically the text buffer address would simply be used as the
lower portion of the framebuffer address, and the pixel row address
would be used as the higher portion, resulting in the 8-line interleave
pattern.


In the case of the ZX Spectrum, the framebuffer layout is less easily
explained: First of all, it doesn't seem to use a dedicated CRTC, but
has this functionality integrated into a custom chip - which sounds like
an expensive solution to me. But I guess it is safe to assume that the
custom chip wasn't designed from scratch, but just combined
miscellaneous 3rd party integrated circuitry on a single chunk of
silicon, so in a sense it may have had a text CRTC after all.

However, the display width is 256 pixels, so it would have been easy to
splice the text buffer address as explained above, and thus get a simple
frame buffer layout.

One potential reason could be that the framebuffer address
double-featured as a dynamic refresh address for the DRAM cells. Or the
designer was so preoccupied with this way of doing it that he didn't
realize it could be done easier. Or he wanted to keep the design
flexible to support different screen resolutions.

This still doesn't explain the additional grouping of the image into
bocks of 64 pixel rows. I must confess I have no idea why anyone would
want to do that, unless it's /some/ artifact of the CRTC used.


> I was shocked an horrified when I realised that RAM doesn't work this
> way any more. It seems today, the difference between DDR3-1333 and
> DDR3-1600 is merely the speed of the complex bus protocol connecting the
> processor chip to the RAM chips; the actual memory cells themselves are
> exactly the same speed. It's like the difference between a USB2 HD and a
> USB3 HD; it's the same physical harddisk in there, just connected to a
> faster bus. But it won't access your files any quicker!

It does help with bulk memory access though.

Post a reply to this message

Le 2015-10-27 03:23, Le_Forgeron a écrit :
> Le 26/10/2015 23:43, Orchid Win7 v1 a écrit :
>> I've always wanted to know... why is the framebuffer arranged so
>> weirdly? Like, as you load a picture file, rather than filling from top
>> to bottom, it seems to fill every Nth line...
>
> Probably because Pal is an interleaved image: there is odd and even
> frames. It was probably easier for the electronic in charge of
> generating the lines in that order instead of obvious linear order.

It's because the phosphorescent particles on the CRT face would dim too 
much by the time the scanning electron beam came back to tickle them 
back to life.  By having an interleaved image, the flicker was less 
apparent.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 27/10/2015 01:56 PM, Francois Labreque wrote:
> Le 2015-10-27 03:23, Le_Forgeron a écrit :
>> Probably because Pal is an interleaved image: there is odd and even
>> frames. It was probably easier for the electronic in charge of
>> generating the lines in that order instead of obvious linear order.
>
> It's because the phosphorescent particles on the CRT face would dim too
> much by the time the scanning electron beam came back to tickle them
> back to life. By having an interleaved image, the flicker was less
> apparent.

I have personally used an ancient Grundig CRT TV with an Amiga 1200 set 
to a high enough resolution that pixels are 1 scanline high.

The flicker is *crazy*!

Post a reply to this message