Close
0%
0%

Ultimate retrocomputer

Collecting ideas for building a computer to be the best an early 80s 8-bit home computer could have been.

Similar projects worth following
The year is 1981. The competition: the Apple II, TRS80, the Commodore VIC-20, or the Sinclair ZX81. You need to build something that can beat not just these, but also knock the socks off the competition that's coming next year: first the Sinclair Spectrum, but not too soon after that the Commodore 64. What do you do, hotshot?

This is a collection of ideas of what could have been done then ... and what we can do to make a realistic system today that would replicate what could have been (plus be able to interface reasonably with the modern world, which is unfortunately a problem for real systems of the era).

Choosing the processor

I'm strongly in favour of the Z80.  

A lot of people working with retro builds gravitate towards the CPU of their first computer. My first computer wasn't a Z80 machine - it was a TI-99/4A, based on the rather obscure TMS9900 processor - a reimplementation of an old TTL minicomputer processor in NMOS microprocessor format, an idea that really didn't work very well... the processor needed very fast RAM to make it work (because, like many minicomputer processors, it stored its registers in external RAM), but that made actually attaching a reasonable amount of RAM to the processor too expensive for a home computer.  In order to be able to compete with computers using commodity DRAM, the TI-99/4A had to limit the memory attached to its processor to just 256 bytes: the rest of its 16KB of RAM was attached to the display processor and only indirectly accessible to the CPU.  I'm not going to build a TMS9900 based machine.

My second computer was a Sinclair ZX Spectrum, and it was on the Spectrum that I first learned assembly programming (assembly programming for the TI required an expensive RAM expansion pack -- otherwise there wouldn't be any free RAM to load your program in -- and an external disk drive, neither of which I could afford).  It was only later that I learned 6502 programming, and ever since I have held a sincere belief that the Z80 is a much more programmer-friendly processor.

In the 1981-1982 time period, the Z80 was available in 3 speed grades: the original 2.5MHz version, the Z80A (4MHz), and the Z80B (6MHz). The faster Z80H (8MHz) didn't show up until later, and in any case would have been expensive to use in 1982 as DRAM fast enough to keep up with it wasn't yet available, so more expensive static RAM would be necessary (or you could use WAIT states to reduce its memory access rate, but that slows it down far enough that you see almost no benefit for having the faster and much more expensive chip anyway).  So the Z80B it is.  Z80s are notoriously easy to overclock (Grant Searle asserts that every Z80A or B he has tested is able to manage at least 10MHz) so I have some flexibility to increase beyond 6MHz - I plan to do this in order to run at an integer divisor of my pixel clock (see video hardware below).

At 6MHz, a bus cycle lasts about 160ns -- it's exactly 160ns for 6.25MHz.  In order to do this with no WAIT states (which would be ideal - WAIT states can really slow a machine down) I'll need to memory that responds within 240ns to each request (because the Z80 requires 1.5 cycle response time when fetching instruction data).  This can be achieved with 4164-120 DRAM chips, which have a cycle time of 230ns, or a page mode cycle time of 120ns, plus 90ns RAS precharge + 20ns RAS-to-CAS delay when changing page.  4164-100 cost a bit more, but may help with implementing video hardware (see below); this has a page mode cycle time of 105ns, plus 95ns overhead on page changes.

 (I originally planned to use 41256 chips to get a reasonably large memory capacity without making the board too big, but it seems those weren't available until 1983)

Memory design

How much of it should the system have, and how should it be organized?

Because of the speed constraints above, no commonly available 16Kb DRAM chip would be fast enough.  And seriously, why bother?  64KB RAM is the minimum specification an 8 bit machine should ship with.  Catering for smaller capacities will end up with a more expensive design so you can handle different installed amounts that within a couple of years nobody will ever want.  The existence of the 16KB spectrum made the 48KB model harder to design, and more expensive, because they needed to share a board design.

It's tempting to just say 64KB and be done with it.  It simplifies everything.  But -- I want to design a machine that's superior to its competitors.  And in very...

Read more »

  • Graphics formats

    Julian08/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

    Julian07/19/2018 at 09:30 0 comments

    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

Enjoy this project?

Share

Discussions

Samuel A. Falvo II wrote 05/29/2018 at 05:16 point

Can you go into more detail about your HDMI video generation idea?  Right now, I'm designing my FPGA logic to put out gun signals intended for an R-2R DAC network to drive an analog VGA.  Although I've read the specs on DVI, I'm not up to speed on HDMI.  I know HDMI is backward compatible with DVI 1.0, though, and what you're describing is a DVI video mode (baseline VGA was the lowest spec possible on DVI).  However, I'm not putting my knowledge of DVI and your thoughts together; something seems missing.  Is it possible to create a project log that goes into more details on this idea?  Thanks!

  Are you sure? yes | no

Julian wrote 05/29/2018 at 15:07 point

I need to do a lot more research into how it would work, and I'm not sure if it's even viable.  I suspect I'm most likely going to end up with a VGA output similar to yours, especially as I've never worked with a frequency as high as 125MHz before (outside of purely internal FPGA signals at least), so it would likely test the limits of my ability to make it work.  But definitely think I should put a few design ideas together at least.

  Are you sure? yes | no

Samuel A. Falvo II wrote 05/29/2018 at 05:13 point

Fun fact: a very similar idea popped into my head back in early 2000s which lead me to create my Kestrel Computer Project.  That was, specifically, everyone saw the writing on the wall, and you wanted to make the very best send-off home computer you could before the 16-bit computers came along.  Apple IIgs, C64, et. al. engineers would get into a room and cooperate.  What is the machine that they'd produce?

Of course, over the years, Kestrel has not lived up to this vision (although it's conceivable the Kestrel-3 *might*, if I get things to play nicely with each other and the hardware doesn't put up a huge fight).  However, it's taken on a life of its own, and I cannot complain at all.  The Kestrel-2DX looks and feels very retro, despite having a fairly powerful CPU under the hood.  I'm quite happy with the results I've achieved, and will continue to evolve the design going forward.  My next "stop" in its evolution is a kind of C64/Atari ST-like machine.

I think this is a really neat project, and I wish you the best.  I look forward to seeing the results and its evolution!

  Are you sure? yes | no

Ed S wrote 05/28/2018 at 10:37 point

How about not seeking 256kbit DRAM, but using 16kbit instead? The 1981 BBC Micro used MK4516N-11 parts with a 250ns cycle time - not sure whether that meets your timing for a Z80. But if you have multiple banks of 8 bit wide memory, you can overlap video accesses in one bank with CPU accesses in another.  Indeed you can give the video system a 16bit path to memory which helps even more.

  Are you sure? yes | no

Julian wrote 05/28/2018 at 14:33 point

I have 240ns cycle time available, if I want to run at 6.25MHz, which is convenient due to being a quarter of the pixel clock.  Fujitsu's data book for 1982 (part of the bitsavers collection on archive.org, which is an amazing resource)  lists the 8264A-12 with a 230ns full cycle time, which would do the job. If I really wanted to push it, the 8264A-10 managed 200ns, which would be good enough to manage a 7.4MHz Z80.  41256 is listed in Toshiba's 83 data book as preliminary, so I guess it must have launched during 1983.  

I've considered a 16 bit path... it complicates the control logic a bit, but not hugely, and it more than doubles the throughput available to the display hardware, because obviously the processor usage remains the same, so a set of 16x4164s could do the job nicely.  I'd need to carefully plot out how everything would work with the RAM cycle time being longer than the time the processor actually uses it for, but it should be possible to figure out an interleaving that makes sense.

  Are you sure? yes | no

Ed S wrote 05/28/2018 at 15:49 point

One advantage of choosing the Z80 is wait states: could be worth considering, either to cope with (slightly) slow RAM or to allow video/CPU sharing of RAM.

  Are you sure? yes | no

Ed S wrote 05/28/2018 at 09:39 point

Like the half-speed HDMI idea! Certainly 125MHz is a lot more achievable than 250MHz...

  Are you sure? yes | no

Julian wrote 05/28/2018 at 14:35 point

Yeah.  To get 250MHz in 1980s era components you basically needed to work in ECL.  And I don't fancy the cost or the cooling requirements of that ... sure, Cray could afford to spend a huge chunk of cash on logic chips and a big vat of fluorinert, but I don't think the home market would have stood for it. :)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates