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