#breadboard computer

On Using the Right Tool for the Job

I've been working on bringing up the video card for my PikaPC project. It has had me quite confused. No attempt to communicate with the device had any effect.

Everything I was sending it looked right. Address decoding asserted the chip enable, the state machine on the video card recognized it was being addressed, the emulated VLB cycle started. There only thing that was missing was some acknowledgement from the video chip itself.

I added debug headers and attached fine wires to even finer chip leads. I did manage to catch a few errors — I was asserting the VLB address strobe on the wrong clock edge, and I had omitted a couple pull-up resistors. My fixes did not change the result.

Recently a good friend sent me an HP 1670E logic analyzer. It is a 136-channel beast of a machine that is currently consuming over a third of my available desk space. I must admit some hesitance in attempting to use it. Frankly, I was intimidated. But I had a problem that surpassed what my 16-channel USB analyzer could easily tell me. To solve this problem, I needed to be able to see all of my 32-bit address/data bus plus another 8 bus control signals.

I attached the first 40 probes to my protoboard card, stumbled through the menus to learn how to enable and label each channel & configure the trigger event, and pressed Run. The machine waited. I hit enter on the PikaPC terminal to start a bus cycle addressing the video card.

… and immediately saw the problem.

The first step in initializing VGA is to set an Enable bit on I/O address 0x3c3. But the analyzer captured 0x1c3.

Either I had a short, or a missing address signal. I had already confirmed there were no solder bridges or missing signals on the video card, and I was using my protoboard card anyway. So the problem had to be on my main board.

I captured a few more tests —

0xfc0 captured as 0xfc0 ✅

0x7c0 captured as 0x7c0 ✅

0x5c0 captured as 0x7c0 ❌

0xcc0 captured as 0xec0 ❌

Address bits 9 and 10 were identical in all test results, regardless of input. Probing those address pins on the expansion bus buffer indicated a direct short. The problem did not affect normal operation of the machine, so it was not likely that CPU address pins 9 and 10 were shorted together. I traced the two wires from the buffer back to the CPU and found … both wired to the same CPU pin.

I had finally found my problem. It was a quick fix. Once it was in place, I ran the VGA initialization sequence and my monitor immediately sprang to life.

My video card appears to be working. I still haven't figured out the correct incantation to actually draw anything on screen using these S3 chips. That will be the next hurdle.

An Update I Can Count On

I have the first signs of life from the new bus on my PikaPC prototype!

The logic ended up being quite a bit less complex than I expected, using only 32 macrocells. It's just simple state machine written in verilog.

I did have to rework my plan for bus cycle timing & handshaking to work around more quirks of the PPC403's weird bus interface, but it does work. This took me even further away from NuBus, which I originally started from. But if it works, it works …

I decided what I really needed to make sure things were working was a dead-simple test card. Nothing so complex as my DRAM card (which is what I want to tackle next) or even needing custom logic like my keyboard/mouse controller card.

So I threw together a card with a 74'574 register, a 74'139 decoder, and some LEDs. (So glad I decided to spin up some custom prototyping boards!) The idea being I can write a value to the register and it will show up on the LEDs.

This was a good idea. I was able to find I had miswired one signal and swapped a few more in my CPLD pin assignments. I also got to watch my logic run with a logic analyzer to see that the timing mostly worked as expected, but with still more weird quirks of the PPC403 I hadn't accounted for.

Scattered Progress Is Still Progress

I've been bouncing around a lot. After confirming my new bus interface was working on my wire-wrap prototype, I built out the DRAM card. It … mostly works. It will work just fine for a few thousand back-to-back transactions and then it just randomly locks up. The CPLD running its timing sequence will freeze on one state and stop responding to any further input.

I managed to chase down a few bugs that helped, but did not resolve the problem. DRAM can use a lot of instantaneous current that may not have been well supported with how the bus connector is wired on my prototype. I spent quite a while reinforcing the power supply to the DRAM card and adding more bulk capacitance. This helped the card run much longer, but did not resolve the issue.

At this point I thought that maybe it was just my prototype, because I've already run into plenty of problems with the hand-wired board. Perhaps it would work more reliably with the new host card. So I spent a few hours assembling one.

I got everything put together and plugged into the backplane before stopping to think about what would be required to follow this process. I'm not currently set up for low-level debugging a PowerPC board that may or may not have working main memory. I got very lucky with my prototype that it pretty much worked and ran Forth on my first try. To bring up the new host card I'll need some lower-level code I can throw into ROM that will initialize the CPU & serial, then print out some debugging information while testing RAM. I still don't have a great grasp of PowerPC assembly so that will take quite a bit of effort.

… so I pivoted to building the video card instead.

My thinking here is I am trying to get this project into some kind of state that I can demonstrate at VCF Southwest in May. The known working prototype with video card would be a minimum viable hardware configuration for what I want to do for the show. It would make sense to get the video card working now, and then circle back to getting the new modular system working together later if I have time.

It, of course, does not work. Yet. I'm stepping through the logic for the video card to see what I've missed. So far I've found a bug in the host logic relating to how the lowest address bits are handled. This required a little rework on both the prototype and the new host card.

I've also identified a problem with the state machine for the video card and a possible timing issue with the VLB address strobe generated by that state machine. The result being so far the video chip does not acknowledge it is being addressed.

RS232 and Reading from Compact Flash

I decided that instead of adding a MAX232 level shifter for RS232 serial directly to the board, I would be better off building a separate board. This would allow me to use the existing header with either the MAX232 or a TTL-USB adapter.

I got to use an interesting unique part on the MAX232 board — a quad capacitor network in DIP8 package. I couldn't find any similar parts still in production, and couldn't find any data sheets either. I got the part from a local electronics surplus shop, and it's perfect for use with a MAX232 because it's four 0.1μF capacitors in a convenient package.

I don't actually have a computer running right now with a proper RS232 serial port, so I used a USB-RS232 adapter to test with. I did have the Receive lines wired backwards at first, but other than that the breakout works. There is a weird quirk though that I have to connect it and turn on my 68000 computer before plugging it in to the other computer's USB port or else Receive doesn't work. Strange, but not really a show stopper.

So then I moved on to trying to read from the Compact Flash card. It's a no-name 64MB card that I've formatted FAT16. I've been looking at it by running:

$ sudo xxd /dev/disk4 | less

on my iMac to read the actual raw data from the card (especially the boot block and FAT). There is something immensely satisfying to see the exact same data come through my 68000 computer when reading the card as I got from the Mac with a proper card reader.

Here we see a visualization of the top 32 bytes of RAM (which hold the bottom 32 bytes of the system stack) as the system dumps the contents of memory over serial. You can see the top 8 bits of the address counting up in the upper right quadrant.

My apologies for the shakycam; due to the instability of running this system on a breadboard, I was only able to get this to work once. I've verified the DMA is working, so I'm guessing I have a loose power connection to the display card.

I'm nearly finished with my monitor program too. I replaced the SDCC library atoi() function that was giving me so much trouble with my own hexToI(). It's less efficient, but at least it's working.

With that in place, the monitor commands for jump execution to specific address, and dump memory contents over serial in Intel Hex format are working. I still have some major bugs with my code to decode Hex data from serial and write it to memory.

I also got in an ebay package today with a cheap China Special logic analyzer and some more female pin headers. The logic analyzer has already proved itself useful in looking into how the DMA is operating. The pin headers will allow me to start building cards for the CPU & DMA, RAM & ROM, SCC, etc. I've got a board laid out for a backplane for the cards, I just need to place the order.

I finished the serial monitor on for my Z80 computer. It has three basic functions: PEEK - dump contents of memory; POKE - write to memory; and RUN - jump execution to any location in memory.

On startup, it uses the DMA to output the top 32 bytes of ram to the LED display. Since the system stack is at the top of RAM, this is useful for debugging. 

In this video, I’m testing all the functions of the monitor by copying a function and its corresponding data into RAM, dumping that section of RAM to verify its contents, and then jumping execution to that function. In this case, the test function reprograms the DMA to copy from address 0x3100 instead of the stack. I’ve loaded address 0x3100 with raw data for a Kirby sprite. 

Using the RUN command to jump to address 0 warm reboots the computer, which resets the DMA to output the stack. Since the memory contents haven’t been cleared, I can jump again to address 0x3000 to run the DMA reprogram function. 

The newest addition to my Z80 experiment, back in the back of that forest of wires, is the Zilog Z85C30 Serial Communications Controller. I added it to ease writing and debugging software, since right now even minor code changes require pulling, erasing, and rewriting my aging flash ROMs. To get to that point though, I’m going to need a monitor program to handle setup of the hardware and copying program data into RAM.