#breadboard computer

[techav]

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.

I might have eventually found this issue using my small analyzer. I would have had to capture the address bus no more than 8 bits at a time, carefully stepping through multiple captures with different test parameters. It would have taken quite a long time, and there's no guarantee I would have noticed the error no matter how carefully I reviewed at the captures. There just isn't any substitute for using the right tool for the job.

[techav]

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.

For the video at the top of this post I'm running a simple Forth program to count up from 0 to 15 and display the binary equivalent on the LEDs. It's a simple test representing another big milestone for this project. Now that I know my new bus controller works, I can start building more complex peripheral cards to go with it.

[techav]

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.

I've made a lot of progress over the past week or so, here and there. I don't necessarily have anything flashy to show for it, but it's still progress; it's still things I have now that I didn't have a week ago. And progress is progress.

[techav]

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.

Now I need to figure out just how to interpret the FAT16 structures so I can add commands to the monitor for reading a file into memory.

[techav]

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 was supposed to be getting a compact flash to IDE adapter with the other stuff, but no sign of it yet (yay eBay). I'm thinking I'll be able to use it to follow Grant Searle's design for booting CP/M off of a CF card. I've always wanted to build a Z80 computer capable of running CP/M ... It's what originally got me playing with the Z80 breadboard computers to begin with.

[techav]

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. 

Being able to load test code directly into RAM greatly speeds development. Without some way of getting code into RAM, the only option is to power down, pull the ROM, erase and reflash the ROM, reinstall, and reboot. Erasing and reflashing takes a little while, and eventually will destroy the ROM.

It turns out I was very close to having the monitor working earlier in the week. There was just one glaring error I had made in the POKE function: I had declared a pointer as unsigned int* instead of unsigned char*. Always double check variable types. Since the pointer was declared for an int, it would insert empty bytes between each byte I was trying to insert into memory. I never claimed to be a good programmer.

Now that I have the monitor finished, it’s time to move on to doing something with it. Before I get to that though, there’s a lot of hardware work that needs to be done. I do want to move the computer from the breadboard mess onto cards, and for that I’ll need to build a backplane for the cards to sit in. 

I also noticed while working on the Kirby sprite that the ordering of the four LED matrixes is not optimal - numbered 0,1 on top and 2,3 on bottom, with the least significant bit of each matrix on the bottom left. This makes it a bit awkward to address them. I need to shift around the decode logic so that the matrixes are interleaved where byte 0 would go to the bottom left, byte 1 to the top left, byte 2 to the bottom left, etc.

[techav]

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.

The SCC is a 2-channel USART perhaps most commonly known for its use in early Macintosh computers for serial and LocalTalk. It’s not exactly the easiest chip to use though, with sixteen registers per channel which have to be programmed in the right order to get the thing operational. The manual calls attention to this, but then fails to specify what order they should be initialized. I had a heck of a time trying to get it to work the first time I used it, so I just copied what worked that time, and changed the appropriate registers for baud rate and clock settings. 

The hard part this time was just getting a stable enough clock. The SCC can generate a clock with a crystal between its sync and clock in pins, but on a breadboard it can be hard to get a stable clock that way. With modern hardware, I could receive whatever the SCC sent with no problems, but the SCC is not as flexible in its timing. It had about 1 in 20 odds of mangling a byte it was receiving. In the end, I replaced the crystal with a 1.8432MHz oscillator, and receiving data has been much more reliable. That particular clock frequency was chosen because it’s one of the standard clocks that can generate common baud rates without jitter.

As for the monitor program, I want something that can accept data from serial in Intel Hex format and copy it to RAM, then jump execution to any point in memory. I also want to be able to dump the contents of memory back out the serial port in Hex format. I’m sure I could find a monitor program and modify it to work with my setup, but where’s the fun in that?

Instead, I’m modifying the sketch I wrote to program my flash chips using an Arduino Mega, since it already has the ability to input/output Hex format over serial. That was certainly an interesting exercise—porting C++ code heavily dependent upon specialized libraries for a modern embedded microcontroller to C code for for a 1970s microprocessor. I’ve finished with porting it, and at the very least my menu structure is working, but I’ve got a lot of debugging to do.

Most notably, the system reboots nearly every time I call atoi() (but of course, not every time). I’m going to have to either dig deep into the standard libraries for SDCC or just write my own atoi() function. 

Still though, this is further than I’ve gotten down this road before. Software is not my strong suit. I’m getting better though, and I feel like the more I learn about the hardware itself, the better I understand how to write software to use it. I’m even making decent progress with Assembly.