This is the first of a series of posts describing a personal computer system based on the 68HC000 processor. There are a number of reasons for selecting this processor, as I had previously described, but allow me to explain further why this particular choice within the 68k family.

The 68000 series was originally fabricated with NMOS, and only later (by Hitachi initially) converted to CMOS, which consumes only a fraction of a Watt so passive cooling is fine, and can be clocked faster. The later 68SEC000 is appealing but it is fundamentally not the same chip, and is also only available in SMT. The 68010 is a marked improvement upon the 68000, but was never upgraded to CMOS, and tops out at a 12 MHz speed grade. The 68020 and 68030 already add substantial complexity while still lacking an FPU. To me, the real runner up to the original 68k would be the 68040: a chip that can plausibly be run with passive cooling, has an FPU, and is also CMOS. The problem is this is even more complex and straying quite far from legibility. The original 68k is substantially more commonplace and simple enough to comprehend.

To me a computer is not a computer if it's not graphical. Originally, I was considering basic VGA at 640x480. However, a critical analysis shows we can actually do substantially better. The main issue is that the video RAM needs to essentially be dual ported: the CPU must be able to access it, while simultaneously it must be streamed out to the display. Old school VRAM chips were physically dual ported (with some minor limitations), but those are obsolete and would not support high resolution graphics. The main question then is how to simulate a dual ported VRAM. The Minimal 64x4 Home Computer mentioned previously does so by adding a shadow RAM: a separate VRAM chip exists that is constantly read to produce scanlines, and, most importantly, has enough idle time that CPU write requests can be inserted. In that particular case, the shadow RAM is a copy of main system memory; the framebuffer data is duplicated.

The original Macintosh proved out the concept that if the video subsystem is tightly coupled to the CPU bus timing, you can achieve substantial simplifications by time division multiplexing the VRAM bus. This suggests an overarching principle of this kind of tightly coupled architecture: the CPU bus memory bandwidth should be at parity with the video data bandwidth (or approximately so). The reasoning for this is that if the video bandwidth dominates, you are starving the CPU of the bus, while if the CPU bandwidth dominates, you're leaving video bandwidth on the table that could be used for higher resolution or bit depth. In this case I'm going to aim for near 1:1 parity, which we will see is a somewhat serendipitous condition.

Now to look at the numbers. Assuming we are going with a 68HC000 that can be clocked up to 16.67 MHz, the memory bus bandwidth is 16e6 * 2 bytes = ~32 MB/s (actually, the 68k requires 4 clock cycles to perform a memory access, but we are considering the full bus bandwidth to work out bus arbitration). Monochrome VGA bandwidth requires 800 * 525 / 8 * 60 = ~3 MB/s; an order of magnitude lower. Without going too crazy, let's increase the resolution to XGA 1024x768, a nice common native resolution for many old LCD screens. If we again assume monochrome, then the raster scan sets a peak bandwidth of 1344 * 806 / 8 * 60 = ~8MB/s; still low by a factor of 4. XGA already has a dot clock of 65 MHz, and going any higher seems unwise for a DIY project. What this tells me is that what is being left on the table is bit depth: we can do substantially better than monochrome. Going by our rule of thumb, it suggests we should go with 4 bit color. However this puts us in a rather uncomfortable position of having to deal with smaller-than-a-byte pixels, meaning requiring a shift register, but since there are 4 bits, it needs to be a 4 bit-wide shift register. The software complication of having to think in terms of chunks smaller than a byte is also worth keeping in mind. Therefore, let's make the full leap to 8 bits of color. At XGA resolution, this is 65 MB/s of video bandwidth.

Now, we have gone a bit too far the other way, but the conventional way of dealing with this problem is widening the pipeline: let's access a wider memory just as often to fetch more data per access. In this case, we need to double our data width on the VRAM side compared to the CPU side, which is 16 bits wide. This means that the VRAM should be accessed 32 bits at a time.

At this point, we must pause and look at what is required of the VRAM. The original Mac 128k put the framebuffer in the main CPU memory (DRAM), and reserved (approximately) every other cycle for the video system. With a 7.8 MHz CPU clock and a 4 clock access time, this meant each cycle was about 510 ns. Its video bandwidth was a mere 1.3 MB/s, so it was possible to perform a full DRAM access (RAS and CAS strobes) in each alternating cycle. Each video line was 32 16-bit words in 33 us, or 1 word per 1000 ns, meaning a video fetch was only needed every other cycle. The CPU cycle was the natural unit to interleave, and the video took every other one.

In our case, we need one 32-bit fetch every 4 dot clocks (61.5 ns), whereas a 4 clock CPU cycle is 246 ns. Thus, we need 4 fetches every CPU cycle, or 1 fetch per CPU clock period. The interleaving must happen within a CPU clock period. Trying to do this with DRAM is both too fast and too complicated for something that can be DIY'd. A DRAM controller that could do this would require a CPLD, and that is not a place I would like to go right now (primarily because the development toolchains are all proprietary). Since we clock the CPU using the dot clock divided by 4, we can consider every two periods of the 65 MHz clock as one 30.7 ns slot, and interleave slots. Getting a memory access to complete within a 30.7 ns window requires a fast SRAM (like < 25 ns access time), and arbitration requires some careful glue logic, but within the realm of feasibility of GALs rather than CPLDs.

The preceding thought experiment is the basis of the system architecture; the DRAM controller that rounds out the rest of the system memory is quite ordinary by comparison. With this, we can feel somewhat confident in formulating the final high level system specifications.

Specifications

  1. 1024x768x8bpp graphics (65 MHz pixel clock)
  2. MC68HC000 CPU running at 16.25 MHz (pixel clock divided by 4), tightly coupled to the video system
  3. Almost all of the 16 MB address space is usable RAM; the 1 MB VRAM sits within
  4. 512 KB boot ROM with low level OS routines
  5. PS/2 keyboard and mouse ports
  6. Dual RS-232 serial ports
  7. Dual SD card slots (SPI), with bridge mode to facilitate fast copy
  8. Real time clock module (SPI)
  9. Ethernet port using an SPI module
  10. Sound system piggybacking off video raster scan (~48 kHz)

Most of these features are relatively self-explanatory, but some bear explaining. PS/2 is the natural input device choice; plenty of devices are available at thrift stores and surplus stores and will be plentiful for quite some time. The need for dual RS-232 ports (rather than single) is that one is likely going to be used for debugging or monitoring, leaving the other for peripheral driving (such as a TTY, printer, etc.). Dual SD card slots are needed since for the system to be self-sufficient and self-bootstrapping, it must be able to duplicate its non-volatile file store (not to mention making backups). A real time clock is kind of crucial for any time keeping, so this should be self-explanatory. An ethernet port is starting to get into the nice-to-have territory. As it stands, the only way for this computer to communicate with other devices is through RS-232 otherwise, so ethernet enables a literal world of communication possibilities. Finally, I mentioned previously that I did not care about multimedia, but having at least basic sound capabilities is nice, and in the spirit of the original Mac, piggybacking it off the video system provides certain conveniences.