12

The screen memory layout on the Commodore 64 in bitmap mode was nonlinear - which incurred a penalty in development time, code size and speed for games using it - because when designing the VIC-II, they ran out of chip area, couldn't quite afford the small extra area for a separate pointer increment circuit, had to reuse the one from character mode.

According to http://www.cpcmania.com/Docs/Programming/Painting_pixels_introduction_to_video_memory.htm the Amstrad CPC also had a nonlinear layout.

What was the reason for it in the Amstrad case?

Improve this question
3
  • 6
    In many home computers, the specific layout has to do with DRAM refresh requirements being fulfilled as a side effect of video scanner access to RAM. No idea if this is the case on the CPC, though.
    – TeaRex
    Feb 7, 2020 at 13:25
  • 1
    Because the Venetian blind effect when loading a screen off tape or disc is really cool!
    – CJ Dennis
    Feb 7, 2020 at 21:54
  • 2
    FWIW, Apple ][ also had non-linear graphics. COMX-35 had linear graphics but you could only read/write at specific time points (H/V retrace, I think, controlled by an interrupt). That made it very difficult to figure out fast screen I/O. Bottom line, old computers were weird but only if you think like a human :-)
    – paxdiablo
    Feb 10, 2020 at 5:18

1 Answer 1

Reset to default
17

Amstrad used an off-the-shelf component, and did the best they could.

For generating video addresses, sync timing, etc, Amstrad used the 6845 CRTC, which was originally designed for text displays. In particular it is designed for a linear text area, looking up character graphics from a font ROM, so e.g. if you’ve set up a 40-column display with 8px characters then an address counter will go through the same 40 character positions eight times, while a row counter goes up once after every 40 characters has been scanned, then after eight lines of that the address goes up by 40. In a typical implementation external hardware would use the character address to look up a character, then use the fetched character plus the row counter to look up a slice of character graphics from a ROM, and output those.

Acorn used the same chip for pixel graphics in the BBC Micro, and just wired up three bits of the row number as the three lowest address bits, and the character address as the rest. That produces a very non-linear display where every graphics byte is located 8 bytes after the one to its left, each line starts one byte after the one before within each 8-line group, and there’s a (40 or 80) * 8 leap in start addresses every eighth line.

Amstrad wanted to do better than that so, they wired the outputs up as:

  • top two bits: bits 13 and 12 of the character address;
  • next three bits: row number;
  • 10 further bits: bits 0 to 9 of the character address;
  • least significant bit: an internally generated left/right bit, as Amstrad fetches two bytes per CRTC address.

So it’s linear across a line, for all supported line lengths (and then some).

With a 6845 it is impossible to have a fully linear display unless you can fit the entire buffer with 14 bits of address space. On a machine which guarantees a particular power-of-two line length you could incorporate the row number into the character address seamlessly, but a design goal of the CPC was industry-standard 80-column output, which is not a power of two.

Improve this answer
6
  • 4
    Drats. Perfect description. Had to delete what I wrote so far :) Maybe add a short 'Table' how Memory address and Row address are interleaved? Also the 6845 supports a 14 bit address, not 12. It can address 16 Ki. The CPC uses 0..9 and 12/13.
    – Raffzahn
    Feb 7, 2020 at 13:41
  • 2
    Then most definitely not perfect; I’m just heading out for a commute but will correct later.
    – Tommy
    Feb 7, 2020 at 13:52
  • 2
    It can always be straightened. But what I meant it goes almost direct to the point which is the use of a standard device for address generation and its implications.
    – Raffzahn
    Feb 7, 2020 at 13:57
  • 1
    A bigger issue is that the 6485 is limited to 127 "text" rows per display. I'm not sure if it could accommodate enough blank rows to reach 262 or 312 lines/frame with a character height of 1, and 127 active rows, but straight linear mapping won't work on any screen with more than 127 scan lines. As to whether it's better to have each group of 8 pixels be eight consecutive bytes, or four pairs, that would depend upon the application.
    – supercat
    Feb 7, 2020 at 22:24
  • 2
    The Amstrad had a huge border all around the screen. Could they have faked 128 columns by extending the 80 columns into the border with blanks?
    – CJ Dennis
    Feb 8, 2020 at 2:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .