After my previous efforts to clean up the board were successful and the floppy controller started working again, I thought I’d solved the problem. What a simple fix I thought. (it wasn’t a simple fix) A week later, I sat down to test out my new gen 2 GoTek floppy emulator and was having all sorts of trouble in the form of hangs and parity errors. I hadn’t seen this before, so at first I assumed I had a broken or misconfigured GoTek. I did some detailed troubleshooting and couldn’t find anything that helped, so I took out the GoTek and put a real 1.44M drive in its place. To my surprise, I was getting the same behavior. Great, the controller went bad again.

I re-checked everything on the controller, from the individual traces, to inspecting each chip and socket and making sure everything was making good contact. Stumped, I started looking around for anything that didn’t seem quite right and noticed the Ti logo on the 2 74LS138 encoder/decoder ICs didn’t look quite right. It was also super obvious because there was a legit Ti chip right next to them with a logo that wasn’t warped. Great, these must be counterfeit chips I thought. Off to ebay I went and ordered some vintage Motorola chips for a few bucks. What I really should have done was just test the chips.

Long story short, the replacement 74LS138 chips didn’t solve the issue either. Strange I thought, what else connects to the ISA bus that could be causing this?

Then it finally hit me… This controller also has a serial UART with an external connection. It also has a multiple driver/receiver IC that sits inline. I don’t really use the serial port right now, so I just pulled those 2 chips and amazingly everything worked perfectly.

I’m guessing that the UART went bad, or there’s an internal fault in the driver IC. (which my tester doesn’t support of course) I’m just glad that it works, because now I can get back to playing with the XT clone board I’ve been restoring! (**update: it was the 16550 UART that was to blame. Ordered a replacement chip from TI that will hopefully be more reliable.)

After some extensive repairs and restoration of my old DTK 286, I wanted to revive the motherboard of my first home computer, a Taiwanese PC XT clone: the VIP TXM-8. This board is essentially a reverse engineered copy of the IBM PC XT (5160), but with additional ROM sockets like the earlier IBM PC (5150). Thankfully the original PC and PC-XT did not have an onboard clock requiring a battery, (and thus no board damaging leakage!) but were instead configured entirely with DIP switches. Any additional/advanced features often required an expansion ROM to add that functionality.

The TXM-8 came with only a single 8k BIOS ROM leaving the other 5 sockets unpopulated. While watching one of Adrian Black’s videos about a similar board, I noticed he had populated most of the rest of his ROM sockets which allowed him to have ROM basic as startup option. I’d never seen this in my childhood as most of the IBMs (including the clone I built from spare parts) were business machines and had no use for basic. This led me to search for the source of these ROMs which you can find on github and are part of a distribution that includes a more or less universal PC XT BIOS.

I ordered up some old 8k and 16k EPROMs, of which I used only the 8k for this project. I removed the old labels and dropped a handful of the chips into my UV eraser and then built the binaries for the Super PC/Turbo XT BIOS and the accompanying basic ROM images while I waited. (if you haven’t worked with EPROMs before, they take some time to be completely wiped by the UV light)

I burned all of the images, labeled the chips and amazingly it worked perfectly. (well, once I referenced Adrian’s video to figure out the correct order in which to install them anyway! close-up shot at 1:31 in the video) So now I had a PC XT with a full 640k of RAM that booted directly into ROM basic. Cool, but utterly ridiculous.

I’d also been working in parallel on a separate issue with a DiY floppy controller I’d built and wanted to have the option of either booting into ROM basic, or into DOS with the new BIOS. Unfortunately, I ran into a problem. While the PC XT could now talk to the repaired controller card, the XT only ever supported low density 360k 5.25″ floppy disks. The DiY controller card has an open source BIOS extension that provides support for other types of disks, but I couldn’t get it to work with the universal BIOS I’d installed. I tested the controller at various memory addresses and even removed the 4 ROM basic chips in case there wasn’t enough space, but that didn’t solve the issue. I could only ever get the BIOS extension to work with the OEM Phoenix BIOS chip that came with the board.

I searched around and eventually found a forum post on Vogons that linked to a ROM image from an old generic controller card that supported high density drives. This turned out to be the solution as not only did it support high density floppies, it was an 8k image I could install in the last remaining socket on the board. I configured the DiY controller to disable the onboard BIOS extension ROM, burned this new image to another 8k EPROM and installed it in the board. To my amazement, not only did it work, but it automatically detected the drive type that was connected. (this is pretty great because it means I can use EPROMs since I don’t need to store the configuration anywhere)

I like this new configuration for several reasons. 1) This is something that would have been entirely possible in that time period (albeit with pirated ROMs at that time) with a generic floppy controller capable of working with HD media. 2) Having the ability to boot from floppy or ROM basic gives me more interesting options to play with and potentially use in testing. 3) The more advanced BIOS is also more useful and capable than the old Phoenix code and should help with testing.

A while back, I built a couple of DiY interface cards to help with restoration and testing of old XT/AT machines. One of those, the XT_IDE card worked perfectly and is now permanently installed in the DTK 286. The other, while it worked initially, developed a mysterious issue that would cause it to glitch and no longer work. At first I thought this might just be a bad controller IC as it was a used vintage part with unknown history. I bought a pair of replacements from different sellers in China, but neither one solved the issue.

I went down a rabbit hole testing and probing on the board, eventually finding a strange issue that, oddly enough was the clue to the real problem. (only I didn’t realize it at the time) The bottom of the board has 2 identical 74LS logic ICs in neighboring sockets that are hooked up to some of the data & interrupt lines of the ISA bus. When probing with a multimeter, I discovered one of the chips wasn’t connected to ground. I checked the board and at the time didn’t see any damage, so I assumed one of the sockets had a bad contact. As a temporary fix, I added a bodge wire to link the ground pin on the affected chip to the functioning ground of the other chip. Sadly, this didn’t improve the situation at all.

I had thought for sure the bus interface was the issue, so when that didn’t pan out, I decided to see what I could learn by tapping the various signals between the floppy drive and the controller and seeing if I saw anything weird on the oscilloscope. At the time, the controller would sort-of work for a few minutes on cold start, but would then degrade and eventually stop reading disks all together. After several sessions and still not seeing anything definitive on the scope I gave up for a bit. Nothing I’d tried had worked.

Recently, I sat back down at the workbench and decided to go over the board in detail and see if there was something simple I’d missed. I brought my reading glasses and used my craft light with its big magnifying glass to go over the PCB in detail. (sadly my eyes aren’t what they used to be) The first thing I noticed was the flux residue on the board. This hasn’t been a problem with previous projects, so I’d left it in place previously, but I decided to remove it just in case. I cleaned all of the flux residue off the board with 90% IPA and a toothbrush and then absorbed the mixture into a paper towel to remove it.

Once the residue was removed, I found the cause of the original issue. The chip with the ground problem had a cold solder joint that had broken loose. That was an easy fix, but not believing it to be the only issue I kept searching. The more I looked the more problems I found, mostly with bad solder joints, excessive solder, or spatter in some of the small gaps between connections that could have caused a short. I’m pretty sure a lot of this is due to the Ryobi soldering iron I use that enters a power saving mode periodically. It’s an annoying feature that only serves to cause poor soldering. I probably spent 30-45 minutes inspecting every connection and trace and touching up/cleaning anything that looked off. In the end, I’m not sure if it was just the floating ground on the 3-to-8 decoder/demultiplexer, or something else I fixed, but when I hooked up a floppy drive to the controller it appeared that it might be working. A few tweaks to the ROMs and controller configuration and I was able to confirm that it was indeed fixed. In the end, I probably could have saved myself the trouble if I’d been more patient and checked my work when building the board in the first place, however it was a good opportunity to practice some low-level troubleshooting.