I had a ZX Spectrum 48KB, whose display was a 256*192 monochrome bitmap (plus separate per-block color attributes). I remember the display bitmaps scan lines were laid out in memory in a weird way - This was evident when trying to render to the screen via poke, and also when loading games splash screens from tapes.

Why was this layout chosen?

Layout:

  1. Screen was divided into 3 parts - top/middle/bottom
  2. In each part, the memory would render the first lines in every 8-line "text line", then the second lines etc.

For example, the layout of the top third would be:

Memory line  0 - Scan line  0
Memory line  1 - Scan line  8
...
Memory line  7 - Scan line 56
Memory line  8 - Scan line  1
Memory line  9 - Scan line  9
...
Memory line 15 - Scan line 57
(skip...)
Memory line 56 - Scan line  7
Memory line 57 - Scan line 15
...
Memory line 63 - Scan line 63
up vote 17 down vote accepted

This is a (for the moment) a short answer:

  • The Spectrum was engineered with a character oriented display, as Sinclair wanted people to use it for business, not for games, so the screen is arranged so displaying a character (8x8 pixel character) is fast. Given a character position, each scan is separated 256 bytes from the previous one, so to draw a character you will use a 16 bit register as pointer to the display memory and increment the most significant byte to advance one scan. 8 bit increments are fast (4 clocks). A linear display address would have forced each scan to be separated 32 bytes from the previous one, thus making the display of a character a bit slower (the ADD instruction only works with A register, and with an inmediate operand it takes 7 clocks). To get 256 bytes from one scan to the next one, the display must be divided into three thirds, each one using 8 character rows. At 32 characters per row, and being each character a grid of 8x8 pixels, this allows the desired 256 byte separation.

  • The ULA uses DRAM page read so it reads two bytes faster than two separate reads of one byte each. The ULA needs for each scan of 8 pixels, one byte of bitmap and one byte of attributes. To be able to use page read, addresses must share either the most significant 7 bits, or the least significant 7 bits. If the ULA would were engineered so the addresses share the most significant 7 bits, that would mean that page reads would read consecutive addresses, and that would mean that the display would have to be arranged so bitmap and attributes would have to be interleaved, making impossible to have 256 bytes between two adjacent scans in the same char. So page mode read addresses share the 7 least significant bits and change the 7 most significant ones, thus allowing the attribute zone to be completely separated from the bitmap zone.

  • Ula MUST share LSB 7 bits (that must be RAS addresses on DRAM chips) since Z80 refresh circuitry is based on the same principle: during Z80 refresh cycles, the contents of R register is put on A6..A0 address pins. – lvd Aug 14 at 16:56
  • Another view on the requirements to have such a puzzled screen: retrocomputing.stackexchange.com/a/4858/4692 In short, without page-mode access, Z80 would have been stopped for the complete duration of line fetch. Due to ingenious page-mode access that ULA makes to video DRAM, Z80 access to video memory on ZX is still possible, with the famous 6-5-4-3-2-1-0-0 pattern. – lvd Aug 14 at 17:00
  • ADD HL, [BC/DE/HL/SP] slightly disagree with the reasoning in your first bullet point, but not the conclusion. There's no immediate 16-bit add, so you'd lose a register pair to store the 32 constant, and at 11 cycles it's still slower than a simple INC H. – Tommy Aug 14 at 17:49
  • @lvd - even with a linear layout, the ULA could have used page mode to optimize accesses, but it would have needed to read 16 pixels ahead rather than just 8 each time, which would have made the required circuitry larger and the ULA potentially more expensive. Alternatively, the RAM chips could have been organised with their address lines mapped into a different order than the one the processor expects; this would have worked (and, I believe, was the solution used in the Apple II for refresh, which is a similar problem). – Jules Aug 14 at 18:37
  • @Jules -- could you please give more info on how linear or another different layouts would be possible within the given DRAM restrictions? – lvd Aug 14 at 20:02

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.