Retrochallenge 2016

Gracana's 68k Retrocomputer


Well, that was a rocky month! I reeled in my ColdFire ambitions entirely. I did try designing a board for the parts I mentioned in the last update, but I had similar troubles there. I ranted a bit on Twitter, and Micah Scott pointed me towards the Dragonball MC68SZ328, which is an early integrated 68k device for handheld computer applications. It was used in early Palm devices, for example. Cool! However, at that point I figured I'd go the simple route and pick up a 68SEC000. It has a 16 bit bus much like the original 68k, but with a static core, so it can be paused entirely and single-stepped. Awesome for debugging.

I made a big order on digikey, expanding my IC inventory quite a bit. I also bought an eeprom programmer, which I got working after struggling with Windows 7 parallel port driver issues. Note that I wasn't able to obtain a parallel cable in time. D'oh! I brought my work laptop home, along with its dock, just so I could have a working parallel port:

eeprom programmer

I also obtained an MC68230 (parallel interface/timer) and an MC68HC231 (dual UART). Along with the glue logic, SRAM, and EEPROMs I bought from digikey, that should give me the start of a computer.

That's as far as I've gotten, unfortunately.

Just for fun though, let me show you something cool... My debug tool is an HP 16700A logic analyzer with state/timing card, dual oscope card, and pattern generator card. It's a PA-RISC machine running HP-UX, which is pretty darn retro in itself. Earlier, before my eeprom programmer arrived, I had it hooked up to read from the (empty (full of FFFFFF)) eeprom:

I told you it was full of FFFFF...

eeprom on a breadboard, connected to logic 

I also downloaded the latest vim source package, and amazingly, it compiled just fine on this strange machine. Props to the vim developers for making that so painless!

vim on the logic analyzer


Not a happy-sounding title, huh? Well, I have actually accomplished a lot, but I keep getting to a certain point in the PCB layout only to find I can't go much further. That MAPBGA-196 IC is a big part, and with a 4-layer PCB and 5/5 mil trace/space, I'm having trouble routing everything. I can get all the data lines hooked up, but then I move on to the address bus and it starts to become a mess. Take a look:

sdram circuit

a pcb with too many traces

I'm starting to use the power layer to route signals (yellow), but I'm worried that will cause problems later on (like, I won't be able to get power to the pads that need it.) Plus, some of those traces are reaaallly long compared to the others. Will it even work? I'm worried about that, too.

Let's forget about that for a moment and look at the video circuit:

vga DAC circuit

Hooray! It's all there, I've got an isolated analog ground, and I left room for termination resistors if it turns out I need them, but I think it's within spec the way it is. Cool stuff. Problem, though: I was reading through the MCF52277 datasheet, and I realized the LCD controller doesn't have a whole lot of clock flexibility. You get the bus clock, which is 83.33MHz, and you can divide it. That's it. How do you get a 23.75MHz pixel clock for VGA output? Change the system clock. Argh.

So, in light of these recent frustrations, I'm announcing a change of course: I'm going to scale back a little and worry about the absolutely-necessary bits first. If I switch to the MCF5207, I'll have a very similar device (ColdFire v2, 166MHz, 32 bit data bus), but no LCD controller (I'll implement an external one later), and I can get it in a MAPBGA-144 or LQFP-144 package. Easier to route, and I can do just SDRAM + slots, and video output can come later. A project isn't any fun if you can't finish the damn thing, right?


I had a few false starts, but I think I'm on the last iteration of the power supply design. The key points are a highish-current I/O power (@3.3V) and a 1.5V core that needs to turn on only when 3.3V is steady, and turn off before 3.3V is removed. I'm using linear regulators with a "power good" signal from the 3.3V regulator to enable the 1.5V regulator. I also added a reset controller to produce a nice reset signal whenever core power is low and when a reset pushbutton is pressed.

In other news, I did some research on VGA DACs, read about VGA timings, and consulted the SoC datasheet to figure out if I could get the LCD controller to produce the signals and timings I need. There's some bad data out there, but the most trustworthy looking documents and calculators seem to confirm that it will work. I was worried that I couldn't produce an HSYNC pulse that matched the spec; it's limited to 64 pixels long, which is too short according to some of the data I found, but from what I found on the Coordinate Video Timing specification, that's actually just what I need.

The video DAC I picked out is a 48-TQFP packaged CDK3405ATQ48 from Exar Corporation. It's built to drive a video cable directly, so it should work well. I'll connect the HSYNC and VSYNC wires directly to the LCDC, which will only give 3.3V, but that's within spec (TTL levels.)

power circuit


Spent some time today figuring out the main crystal oscillator circuit. Figured out how to load it properly and I think it's sorted. I've also been working on the two power supplies (3.3 for IO/bus and 1.5V core), which is a little tricky because the core needs to switch on last and off first. Turns out there are simple linear regulators with monitor outputs and enable inputs, so I can chain the 3.3V monitor right into the 1.5V enable and everything will work out fine.


This one took a bit more than just drawing the symbols. I spent a long time reading about the MCF52277's FlexBus/SDRAM interface, learning about SDRAM in general, and learning about routing high speed data signals. I'm still a littl e worried about how this is going to work on a four layer board, but I think it's doable. I'll use termination resistors at the end of the bus and lots of decoupling caps and hope for the best.

I want to put the maximum amount of RAM possible on the board, for no other reason than "because (maybe) I can." To do that with individual chips on four layers is a definite "no." I figured I'd either find a memory module that work ed, or compromise and use fewer chips. Going the module route first, I tried to find information on 100-pin DIMMs, which are the only SDR SDRAM modules with a 32 bit interface. Unfortunately I didn't find much, and I was a little worried about availability. What I did find was a lot of datasheets for 144-pin SO-DIMMs, which seemed great except for the 64-bit interface.

That was a bit of a roadblock. I guess I could ignore half of the data bits, but that's no fun. How do other processors do it? As usual, the datasheet had the answer: Chip selects! A 144-pin SO-DIMM has two chip selects, so you can wire half of the data lines and data mask lines to the other half, and then just select which half you want to access. And rhw MCF52277 has two chip selects. It's like somebody already thought of this! :P

So with that settled, I picked out an SO-DIMM connector from digi-key and went on to draw a schematic symbol for it. I had some trouble with KiCad this time around, because I made a multi-unit symbol without checking the "All units are not interchangeable" checkbox, and that caused KiCad to make a huge mess of things as I tried to draw the Power and IO units. Once I figured out what was going on, things went pretty well, and I was able to speed up the process of naming and numbering the pins using a text editor.

Here's what I ended up with:

SDRAM slot symbol in KiCad


I spent today making symbols for the various functions of the MCF52277. I wanted to use Eagle, and I thought I was prepared to buy it, but the versions that support larger boards are just too expensive. Instead, I'm learning KiCad. It's not so bad!

MCF52277 symbols in KiCad


My plan is to build a home computer using the ColdFire MCF52277.


Why the MCF52277?

68k is a familiar old architecture, and this SoC has an external bus, LCD controller, onboard cache, no MMU, and comes in a reasonable package. Nothing else really fits the bill. ARM options are either Cortex-M (THUMB-only, which is only fun if you're a compiler) or enormously complex, with MMUs and FPUs and SIMD and complex memory layouts and multiple modes, etc. Renesas sells some cool stuff like Super-H and RX600, but again, I couldn't find something that had the combination of features I wanted.

Valid HTML 4.01 Strict