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