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

On 27/10/2015 11:28 AM, clipka wrote:
> Am 27.10.2015 um 09:29 schrieb Orchid Win7 v1:
>> 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.

Yeah, I can't count.

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

That... is some interesting theorising, actually! Makes the most sense 
out of anything I've heard.

>> I was shocked an horrified when I realised that RAM doesn't work this
>> way any more.
>
> It does help with bulk memory access though.

Only if your RAM bus is drastically slower than everything else in the 
system...

I always wondered why nobody puts, say, 1GB of RAM onto the same die as 
the CPU, so bus speed becomes a total non-issue. And then I read the 
specs of the Raspberry Pi and thought "OK, NM..."

Post a reply to this message

On 26/10/2015 11:31 PM, Jim Henderson wrote:
> On Mon, 26 Oct 2015 22:38:03 +0000, Orchid Win7 v1 wrote:
>> 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.

At that point, doesn't it kinda make it look like *the screen* is all 
the smarts? Not the inconspicuous little box in the corner?

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

Oh, I *totally* agree with what you're saying. My question is how you 
keep the kids from just glancing at it and going "this is lame!" and 
going back to playing Angry Birds or something.

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

Thanks to backwards compatibility, every IBM PC-compatible starts up in 
8080 emulation mode, and has a BIOS that lets you do stuff without even 
knowing what model of video card you have. Even then, it surely has 100% 
VGA register compatibility, so you can program it that way.

On the Pi, until you poke the GPU, the CPU isn't even *turned on*...

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

Oh, really?

[That maybe sounded sarcastic. It wasn't meant to.]

Clearly you've got different ideas to me... What kinda thing are you 
thinking?

[Genuinely interested here.]

Post a reply to this message

On 10/27/2015 6:58 PM, Orchid Win7 v1 wrote:
>> I think there's a lot you can do that's interesting without any video at
>> all.
>
> Oh, really?
>
> [That maybe sounded sarcastic. It wasn't meant to.]
>
> Clearly you've got different ideas to me... What kinda thing are you
> thinking?
>
> [Genuinely interested here.]

Break codes, calculate ballistic trajectories, solve engineering 
problems. Run the finances for Lyons tea house. Text processing and games.
And this:
https://plus.google.com/photos/+KenShirriff/albums/6116650756716708097/6116650759320217970?pid=6116650759320217970&oid=106338564628446721517



-- 

Regards
     Stephen

Post a reply to this message

On 10/27/2015 7:50 PM, Stephen wrote:
>
https://plus.google.com/photos/+KenShirriff/albums/6116650756716708097/6116650759320217970?pid=6116650759320217970&oid=106338564628446721517
>
>
Source:
http://www.righto.com/2015/03/12-minute-mandelbrot-fractals-on-50.htmlhttp://www.righto.com/2015/03/12-minute-mandelbrot-fractals-on-50.html


-- 

Regards
     Stephen

Post a reply to this message

On 10/27/2015 7:52 PM, Stephen wrote:
> Source:
>
http://www.righto.com/2015/03/12-minute-mandelbrot-fractals-on-50.htmlhttp://www.righto.com/2015/03/12-minute-mandelbrot-fractals-on-50.html
>
>
Bugrit!

http://www.righto.com/2015/03/12-minute-mandelbrot-fractals-on-50.html

-- 

Regards
     Stephen

Post a reply to this message