In 2022, I documented my ancient SWTPc 6800 Computer System, which I had upgraded with several home-brew cards. It had been 25 years since I had last used the computer, but this ancient machine fascinated me. I wanted to record what I had done, as I'd forgotten a lot.
During this process, I plugged in one of the I/O cards incorrectly -- off by one pin. Normally, there's an index pin that prevents this, but some of my cards don't have the plug that blocks the pin.
Sadly, when I powered it on, smoke was immediately released from one of the chips. After correcting that board, I found the system completely inoperable. This computer was 45 years old at the time, and I had many other projects that needed more attention. I decided that fixing it would be something I could do in my retirement.
And, it remained broken until this year. You see, I've retired, so it was time debug this monstrosity.
When I originally built the CPU boards for this machine, I borrowed a 32-channel HP Logic analyzer. That allowed me to fix the bugs in the hardware and the software alike. But I long-ago lost access to such equipment. I had little more than the original kit manuals, schematics and notes, plus a digital voltmeter and an oscilloscope.
Symptoms
After the smoke let out, the machine crashed on reset. I could see from the front-panel LEDs that the CPU had gotten completely lost -- with every 4KB block LED illuminating dimly. This is characteristic of a crash.
Debugging
Initial step established what was working on the machine. I removed all the cards from the motherboard. I checked the power supply voltages on the motherboard:
- +8v: +8.3v
- +12v: +14.15v
- -12v: -14.06
These unregulated voltages were nominally good. I verified that several of the bus signals were pulled high on the motherboard, such as RESET*. Everything seemed good.
I added the Bit Rate Generator board. It supplies all the serial bit rates on the SS-30 bus. I couldn't find any clock rates using the oscilloscope. Looking at the original schematic and the MC14411 data sheet, I found one thing missing. The data sheet recommends a 15 M Ω feedback resistor across the crystal. My circuit had none. Other designs used a 1 M Ω resistor. So I added one. Now I found all of the bit rate clocks present. Funny that it worked before.
Next was the 6809 V2 CPU board. The LEDs would light up on reset, then go into the characteristic crash. Examining the important signals on the bus:
- RESET* - goes low for 0.1-0.3s, then high
- HALT*, BREQ*, MRDY, NMI*, IRQ*, FIRQ* -- all staying high.
- BA, BS - both low -- this means that the CPU is actively controlling the bus
- E* and Q* - these clocks running at 2 MHz, as expected, this mean the CPU was alive at least
- VMA* - cycling, meaning the CPU was attempting to access the bus
- R/W* - cycling as expected
- D0*-D7* - each data bus pin showed signs of normal activity
- A0-A15 - the Address bus had problems on two pins
- A3 - activity limited to 0v to 1v
- A14 - activity stuck around 0v
This was good news. The CPU was working and attempting to process instructions, as evidence by the clocks, the BA/BS status pins, and the data bus activity.
The address bus seemed to be the source of difficulty. When the I/O board was plugged in incorrectly, one of the chips received -12v, and that same chip was also connected to A3. As there are no buffers on A2 or A3 between the SS-30 and SS-50 bus, it is possible the 74LS244 address bus buffers could have been damaged. That didn't explain A14, but it made sense.
I swapped out both 74LS244 chips, and the CPU board now acted correctly -- polling the E block of memory, where the I/O resides. The E LED was brightly lit.
An MP-S board was added next. Since it was not connected to the A3 line, it was unlikely to be damaged. I needed something to function as a terminal to connect to the MP-S. I fashioned a DB-25 to DB-9 cable and hooked it to a USB serial port on my MacBook Pro. Pressing RESET brought up the "BBUG v1.91" prompt. YES! After nearly four years of being non-functional, my old computer was able to run the ROM monitor.
Using the capabilities of the BBUG monitor, I set about diagnosing the other parts of the system. Since the last time it was operation, I expanded the CPU board memory from 64 KB (really 56-60 KB) to 256 KB (really 248-252 KB). I set about testing to make sure all of this additional RAM was functional. Because the MC6809 processor can't access more than 64 KB of memory at once, I had to do this in steps. I manually re-programmed the DAT to use different blocks, leaving the D, E and F blocks alone. The additional memory worked great.
With the CPU card functional, I set about to determine what else was working.
Working on the I/O slots, something was amiss with the MC6840 on the bit rate generator board. A 74LS04 inverter connected to the A3 bus line had apparently been damaged. Swapping it out restored operation to the MC6840.
The 5 1/4" Floppy Disk Controller (FDC) board was the one that had been plugged in wrong. A 74LS139 that let the smoke out had been replaced, and everything seemed to be working. Similarly for the 8" FDC board. Both boards would respond properly to basic commands, even with no disk drives connected.
The Tanner/Digital Research 64KB RAM board was next. It took some experimentation to discover how to address its extended memory address. I found that the BBUG "Q" command, which does a memory test, can be fooled by bus capacitance. That's a bug that needs to be fixed. While the memory appears to be present, at least some of the time, there appear to be some address or data convergence problems. I haven't quite sorted that out yet.
Next Steps
There are still issues that need resolution. I've attempted to boot FLEX/09, but it fails rather quickly. It appears to be properly loading the boot loader off the first sector of the disk, but for some reason does not appear to be able to load FLEX.SYS. I think my problem is that I don't have 5 1/4" boot disks set up for these 80-track drives. Most of my use of FLEX was limited to 8" disks, and those drives aren't yet connected.
An attempt to boot into OS-9 Level I also failed, even though I have several 5 1/4" boot disks. That's going to take more time to diagnose. It could be there's other damage to the 5 1/4" FDC board that I haven't isolated yet.
No comments:
Post a Comment