Today is the last day of the Retrochallenge 2017/04! Yesterday I tried to get the HD6309 computer up and running. The short version is that it still doesn’t run properly but it is “doing things”. By this I mean it behaves erratically.
When ordering the components, the AT28C64B I had planned to use was out of stock, so I ordered an AT28C256. They come in the same DIP28 package and use two additional pins (1 and 26) for addressing that are labeled not connected on the AT28C64B. So I wired those to ground on the back of the board.
To test the board, I wrote a program that lights up the LEDs connected to OUT1 and OUT2 pins of the SC16C550 UART and continuously sends 0xAA on the TX line. This seems like a small test but for this to work, the CPU, ROM, UART and two GALs must be fully working. Of course, it “didn’t work”.
Using an oscilloscope, I checked for clock signals. They were all there. Then I checked to see if the CPU was toggling its address lines: yes! The ROM_CS and IO_CS lines on the memory decoder GAL are next. Yes, they have activity too! So its very likely the program is actually running and trying to access the UART.
The SC16C550B UART
At this point, the main suspect is the UART. So I started looking at the schematic to see if I had made any mistakes in connecting up the data lines, address lines or the read/write lines. They all seemed fine. Then I spotted a potential mistake… Can you see it?
Anyone, anyone? Bueller? The reset pin on the component does not have a negation bar but the driving reset signal does. It is very uncommon to have an active high reset but I’m also quite meticulous when it comes to making schematic symbols. To be sure this is a problem, I checked the SC16C550B datasheet:
It is indeed an active high reset! So, I cut the reset trace going to the UART on the back of the board and connected it to ground. This way, the UART won’t be reset but I hope by writing to all the necessary registers I can put the UART in a defined state. This assumes that the UART doesn’t contain any internal/non-accessible flip-flops that need to be reset for it to function properly.
With the UART reset fix in place, I tried again. Something is happening on the UART TX line but the LEDs still won’t light up . At least the UART is doing something!
The first thing to check is the baud rate. Using my oscilloscope I measured the on time of the narrowest part of the bit pattern. Remember I’m sending 0xAA? I chose that because the bit pattern is ‘10101010’, which is ideal for measuring.
I expected to be close to 9600 baud, but it was way off! Hmm, that’s not a good sign. The registers of the UART aren’t receiving data correctly or correct data. This also explains why the LEDs aren’t lighting up. To make matters worse, the behaviour of the system changes every time I press the reset button.
The reset line has a 10uF timing capacitor on. This gives a long reset time but it also means that the voltage on the reset pin rises very slowly — too slowly perhaps. So I replaced the capacitor with a 100nF one. This didn’t fix the problem.
As an extra precaution, I inserted some NOP instructions between the UART accesses to increase the time between writes. That did seem to change the behaviour but everything is still unpredictable.
Unfortunately, this is one of those cases where a lot of things can cause this. Here’s a list of causes in order of hopefulness:
- The UART interface won’t work properly without a reset pulse.
- Bad solder joints.
- The data or address lines aren’t stable when data is written to UART.
- The CPU isn’t reading the ROM correctly.
- The CPU isn’t working properly.
I’ll first try and see if I can write data to the 8-bit expansion port. This will give me an idea if the bus timings are okay and that the CPU is behaving correctly.