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