Yesterday ended with the pizzazz of a wet newspaper when I couldn’t get the HD6309 computer working. Of course, I couldn’t just let this slide, so today I took another shot at bringing up the board.
With a fresh mind and a strong cup of coffee I examined the board that had thwarted me yesterday. The first thing I tried was to add 100pF capacitors tot the clock oscillators as the signals to the processor and UART were ringing like there’s no tomorrow. The divided down E and Q signals, which are generated by the CPU based on this clock, looked fine. However, it’s unclear if the undivided clock signal is used internally by the CPU, so better safe than sorry. That didn’t fix things either.
At this point I took a look at the programs for the memory and IO decoder GALs. I use WinCUPL to compile these into fuse maps that the TL866 programmer can read. WinCUPL generates quite a few files and one of them is a report that has a .doc extension. It contains the simplified/optimised logic equations for the GAL.
WinCUPL lets you write the logic equations in a high-level manner, such as:
io_cs_n = !(addr:'B'1110XXXXXXXXXXXX);
Here, addr is a 16-bit address, X means ‘don’t care’ and ‘!’ means negation, so IO_CS_N will go low if the top four bits of the address are 1110. At least, that’s the idea. It turns out that WinCUPL has a bug in it that will not apply the negation. You won’t see that in the waveform simulation of your design, but it will show up in the .doc file equations!
The .doc file will show:
io_cs_n => a15 & a14 & a13 & !a12
,which is wrong!
To work around this problem, I directly wrote the simplified equation, instead of relying on the compiler:
io_cs_n = !a15 # !a14 # !a13 # a12;
,where ‘#’ means OR in the WinCUPL language.
There were several other places in the memory and IO decoder programs that caused erroneous compiler output. It is even a documented bug, which they claim has been fixed. Not the case, so watch out if you’re using WinCUPL.
I also noticed an error on my part; I didn’t use the IO_CS_N signal in the IO decoder GAL, which means that IO devices were being selected at the same time as the RAM or ROM! Two devices were competing for the same bus, which won’t give the best outcome.
Fixing both GALs instantly turned the machine into something predictable. It no longer did random things when I pressed the reset button. Progress!
One more thing…
I could see the CPU executing the code I had written:
START: JMP START
It was reading only from ROM and the address lines were not toggling, except for a few least-significant ones.
It was time to try the bootloader I had developed and tested using the emulator. No luck, the UART wasn’t responding. The cause of the problem manifested itself when I probed the RESET line and I accidentally ‘shorted’ the RESET pin to OUT1, which was outputting a logic ‘1’. The UART spang to life! During my handling of the board, the bodge wire I had connected to the RESET of the UART must have come loose!
Resoldering the reset wire finally fixed the computer and I’m now greeted with the bootloader screen every time I press the reset button!
9600 baud — the world is my oyster!
Most of the system seems to be working, including the RAM, which the bootloader checks by reading and writing patterns.
During development I disabled the expansion port and memory mapper. I will have to update the GALs to get them working, but that’s something for another time…