Project Logs

Collapse

• Graphics formats

  Julian • 08/11/2018 at 16:10 • 1 comment

  Due to constraints of what can be done with the hardware I'm planning to use, my display is pretty much required to be either 640x480 or 720x576 (or 320x240/360x288, the latter formats produced by doubling pixels).  But what format should I store the pixels in in memory?

  Historically, there have been a lot of options:

  • Monochrome text, each byte containing a character code that is used to look up pixels in a font table.
  • Colour text, alternating between character codes and colours (typically 16 background and 16 foreground colours)
  • Either mono or colour text with predefined graphical tiles (e.g. Commodore PET)
  • Mono or colour text with ability to redefined characters to new shapes (e.g. systems based on the TMS9918 display processor or its successors, such as the TI-99/4A or MSX).
  • Monochrome bitmap
  • Monochrome bitmap with colours applied to areas (e.g. the 8x8 character grid of the ZX Spectrum or C64 "HiRes" mode, or 8x1 grid achieved in some non-standard C64 modes)
  • 4-colour bitmap (typically with ability to select the palette, e.g. IBM PC CGA, CPC 464 Mode 1) although sometimes fixed (BBC Micro Mode 2)
  • 16-colour bitmap (most micros that support multiple modes, but frequently only at low resolution, e.g. 160 horizontal pixels)
  • 256-colour bitmap (e.g. VGA; this is probably not realistically achievable for an 8-bit system, other than at very low resolution)

  I was originally thinking of allowing modes up to 16-colours, but the memory bandwidth requirements for that are quite high (to process 320 pixels would require 160 bytes to be read for each line; a VGA scan line last 32us, or 64us if we can use a buffer to produce a single line and output it twice).  I'd still like to support it, but suspect it may only really be useful for showing small areas (perhaps as a format for sprites, or for small inset areas of the display).  But that's OK -- my plan for the display hardware supports using different formats for different parts of the screen (inspired by Atari's ANTIC, but improving on it so that we can partition sections horizontally as well as vertically).

  But: is there a stopgap between pure 4-colour and 16-colour that could be useful to support?  8-colour is interesting, but 3 bits per pixel makes it hard to work with -- the hardware would need to handle 8 different variations of where to pull pixels out, and only multiples of 8 pixel widths work without wasting memory.  Planar arrangements are possible, but require the hardware to fetch memory from much more random locations, which is less efficient.

  But there other possibilities.  What about, for example, using a 2-byte record with a selection of palette entries combined with a very small bitmap using those palette entries?  Something like this:

  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0|
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |COLOUR 0|COLOUR 1|C2 HI|PIX 4|PIX 3|PIX 2|PIX 1|
  +--------+--------+-----+-----+-----+-----+-----+
  

  This arrangement has a few interesting optimizations:

  • "COLOUR 0" and "COLOUR 1" are 3-bit indices into the current global palette, but "C2 HI" only provides 2 bits ... the third bit will come from elsewhere (see later)
  • Because we're free to pick any colour set we want for this small group of pixels, and can easily swap the indices around with little effort, we can have one pixel that is always a particular colour - say colour 0 - and just switch to using different encoding if that pixel needs to change to another colour.  So we only encode 4 pixels here, but produce 5.
  • There are three colours defined, but 2 bits for each pixel... the encodings are:
    00 - colour 0
    01 - colour 1
    10 - {c2 hi, 0}
    11 - {c2 hi, 1}
    We therefore get to select from 4 colours, with the constraint that two must be adjacent in the global palette.

  The fact that one of the pixels is implicitly coloured makes it difficult...

  Read more »

• A plan for an IO system

  Julian • 07/19/2018 at 09:30 • 1 comment

  Most 8 bit computers didn't have much in the way of organisation of their IO systems.  They just stuck all of the IO devices on a shared bus, and maybe if you were very lucky provided a DMA controller (although that was rare).

  The Apple II was somewhat of an exception - it was designed to make expansion easy by providing slots where addressing was already decoded, making add-in cards cheap and easy to design.

  In order to make a superior system, I have to improve on this state of affairs.  And by improving the organisation of the IO system, I can hopefully make the design of the most complex IO device in the system, the display adapter, both simpler and better.

  My first thought was simply to provide a DMA controller.  The display system could use a DMA channel to read a framebuffer.  Like the IBM PC I could use another DMA channel to make sure DRAM refresh happens correctly.  And having spare channels would be useful for other hardware, too.

  Unfortunately, standard DMA controller chips that were available off-the-shelf in 1981/1982 weren't ideally suited to what I want to do.  The logical choice for a Z80 system was Zilog's own offering the, Z8410.  Unfortunately, the speed grade I'd need for this system, the Z84C1006, is difficult to find advertised at the correct time (I'm not even sure if it was available yet, to be honest) ... but the pricing for the 2.5MHz to 4MHz variants ($29 to $37) scares me.  And even then it would need overclocking for the 6.25MHz I'm currently planning.  The most popular alternative was the Intel 8237A, and it was substantially cheaper than Zilog's chips, but as of 1982 it appears that the fastest speed available for that was 5MHz (it would later be used in the 8MHz IBM PC AT, but not until 1984).  Intel were pushing the 8259, and the 8MHz variant of that was definitely available, but I haven't found a price for it.  But it's telling that IBM chose to use the 8237A for the PC -- I presume the 8259 was noticeably more expensive.

  But at about this time, I realised that what I really want to do is actually quite a bit more complicated than a simple DMA controller will allow.  On most 8 bit systems from this time period, you had to compromise by choosing a screen mode.  You could get high resolution and full colour, but only if you could only display text with no graphics at all.  Or you could get high resolution with limited colour (either monochrome or, if you're lucky, a 4 colour palette), low resolution with full colour (but using up a lot of your precious RAM for the framebuffer), or low resolution with lower-still colour resolution (to save RAM for your actual program to run in).  These compromises were necessary due to the limited memory bandwidth of these systems, and due to the fact that memory was too expensive and limited just to throw it away on colour depth that might be nice but probably isn't necessary in many cases.

  But choosing which of these modes to use for your application often meant compromising in ways you really didn't want to.  What I really wanted was a solution where you could partition your screen into sections and use different modes in different sections.  There were systems that allowed this - the later Atari 8-bit systems supported something like this through their "ANTIC" custom IC.  ANTIC was basically a very simple processor that read a program called the "display list", which consisted of delays, mode changes, and pointers to blocks of data to display on the screen, and it fetched them and pushed them out to the display, changing how it interpreted them as necessary.  This is, in many ways, a lot like a DMA controller.  Why not combine these two functions?

  A somewhat more generic approach was taken by Intel in their 8089 IO Processor.  This combines a DMA controller with a coprocessor (connecting to an 8086 or 8088 via the...

  Read more »

View all 2 project logs