Skip to content

Building the HxC command-line tool

TI-99/4A As previously noted, I've replaced the floppy drives in my TI gear with HxC floppy emulators.

There are both GUI and command-line tools to convert floppy disk image files to the HxC's native HFE format. I needed to implement proper 80-track DSSD support for my TI floppy images. The build framework for the CLI tool is sort of a mess; to make things easier, I cloned the git repos (four of them!) and refactored the code as follows:

  • Changed libraries from shared to static by default. There's no reason whatsoever to have shared libraries for a single command-line tool (and I'd also argue against the need for shared libraries when building both CLI and GUI versions)
  • Changed the framework to build out of the repository as cloned from git. The original author appears to still be using subversion on SourceForge; as such, the project cannot be built straight from the repo without Makefile modification
  • Removed a few Linux-isms to allow this to be built on FreeBSD (and, by extension, pretty much any POSIX platform)
  • Use my rewritten TI V9T9 image conversion logic. This derives the target disk format from the geometry embedded in sector 0 of the HFE image, rather than guess based on image size. This is much more reliable than the logic in the mainstream tool, and has not yet been merged into the original author's codebase
  • Here's how to build:

  • mkdir hxcfe
  • cd hxcfe
  • git clone https://github.com/christopherkobayashi/HxCFloppyEmulator_cmdline.git
  • git clone https://github.com/christopherkobayashi/libhxcadaptor
  • git clone https://github.com/christopherkobayashi/libhxcfe
  • git clone https://github.com/christopherkobayashi/libusbhxcfe
  • cd libhxcadaptor/build/
  • make
  • cd ../../libhxcfe/build/
  • make
  • cd ../../libusbhxcfe/build/
  • make
  • cd ../../HxCFloppyEmulator_cmdline/build/
  • make
  • Enjoy.

    Refurbishing a TI PEB power supply

    TI-99/4A I've seen a number of people recommending replacing the older forty-ish watt TI PEB power supply with AT(X) power supplies.

    As with most stopgaps/workarounds that the TI community has come up with, I'm not sure that's a good idea. The original PSU emitted +16VDC, +8VDC, -16VDC, and +5/12VDC for the stuff in the drive bay, and the PEB cards are expected to have on-board regulators to produce the desired voltage.

    An AT(X) PSU, on the other hand, emits +12/+5/-12VDC. The folks that have done the conversion recommend that the original +8 and +16 be wired into the +12 rail, and the -16 wired into the -12 rail. That will work if and only if the voltage regulator on each card will go into bypass/shunt mode when the input voltage is below the regulator's input voltage floor (typically about two and a half volts over the specified output voltage).

    If the card regulator goes into bypass mode, it might as well not be there at all. The entire point of the per-card regulator scheme has been negated -- you've lost the protection afforded by the onboard regulator, and are at the mercy of the PSU. The only case where this isn't an issue is on a +5VDC-only card, and if you haven't replaced the 7805s on the cards with switching equivalents, you'll see a dramatic increase in heat generated by the regulators.

    Therefore, if one has an ailing PSU in a PEB, I reckon it's better to refurbish the original PSU rather than replace it with under-specced voltages.

    The PEB PSU is pretty simple. It uses a gigantic multi-tapped transformer to step down the voltages to somewhere around nominal, simple full-wave bridge rectifiers and a few large electrolytic capacitors to smooth things into DC, and a couple of 78xx regulators to deliver the +5 and +12VDC. The schematic is here.

    First, replace the 7805 (in a TO-220 form factor) with a switching equivalent. I used CUI Inc's V7805-1000, which handles one amp without breaking a sweat. It's probably better to get the -1000R, which has longer leads for mounting flush against the PCB, but the non-R leads are long enough to fit as well.

    Second, replace the 7812 (in a TO-3 form factor) with a switching equivalent. These are harder to find ... I used the EzSBC PSU6, which is also good for one amp. Do not forget to put the screws back into the mounting holes; if you don't, the regulator won't be grounded and will go into bypass mode. That'll put an unregulated +16VDC onto the +12VDC rail, with bad consequences.

    Third, replace all of the electrolytic capacitors. All are axial-mount 35V polarized units; you'll need two 4700uF, two 3300uF, two 1000uF, and two 47uF. The replacement 35V caps are probably thinner than the originals (mine were), but if you go up one more size to 50V, the physical dimensions should match pretty closely.

    Fourth, replace D1 through D6 (i.e., all of the diodes) with 1N5401s. D3 and D4 are already 1N5401, but they're at least thirty years old and are near or past their service lifetime. The other diodes were 1N4002s, which are the less-beefy cousin of the 5401 (the 4002 can handle one amp, the 5401 is good for three amps). The 5401s are a bit bigger than the 4002s, but they'll fit into the mounting holes with a bit of elbow grease.

    While you're in there, you might consider replacing the original fan (running on 110VAC) with a normal PC fan (running on +12VDC). The size is standard. Wire that into the regulated +12VDC rail wherever convenient. Instructions can be found here.

    That's pretty much it. Plug the P1 cable from the transformer back into the regulator board, turn the PEB on, and verify the voltages at the P2 and P3 connectors against the schematic referenced above. If everything matches (the unregulated voltages will be high, because there's no load), then you're done.

    This should return your PEB PSU back to original strength.

    Replace your #$%& console power switch!

    TI-99/4A If "the solder joints are always bad" is rule #1 when repairing old gear, "the power switch is worn out and must be replaced" is rule #2.

    The TI-99/4A in-console power supply has a DPDT switch that handles +5VDC and +12VDC. The switch internals will wear grooves in the contacts over time. After nearly forty years, that power switch is going to be grumpy as hell. It will not reliably make nor keep contact when energized, and should be replaced. Desolder the sucker, take it down to your local parts house, and look for something that is close enough to work.

    The closest replacement I could find in Akihabara was a non-PCB-mount switch. The actuator is a bit taller than the original, and I had to bend the mounting lugs out ninety degrees to make contact with the PCB pads, but the console in question now powers on reliably. The only thing missing is the tactile "thunk" when switching it between "on" and "off" positions, but that's an aesthetic thing that can be ignored.

    The TI-99/4A console power switch is like a VW shift hanger -- if you haven't replaced it, or even looked at it, then it is bad and will cause problems. Just replace the (redacted) thing as soon as you open up the console, and you'll save yourself a lot of heartache down the road.

    Well, it wasn't the 32k card.

    TI-99/4A I spent an unreasonable amount of time trying to get an in-console expansion working. I'd previously modified my main console with the 16-bit mod, which worked fine, and I thought I'd give Tursi's scheme a test drive.

    I wasn't successful. I used the PCB that fellow (name forgotten) had put up on OSHPark, and I noticed the following:

  • One of the address lines is wrong. The address line on pin 21 is documented as going to pin 11 of a 74xx74, but it actually needs to go to the same pin on a 74xx00 right next to it. This is a typo in Tursi's instruction PDF; I'm surprised that it wasn't pointed out by anyone.
  • The board layout isn't smart about +5VDC or ground. It just slavishly replicates the instructions in the PDF, and omits decoupling capacitors. The guy that put this together had two layers to work with (because, well, OSHPark), but used only one.
  • The board layout isn't smart about mapping the RAM address pins to the CPU. If it were me, I'd replace the first eight wire pads with a header and solder that right onto the CPU, rather than run a bunch of wires.
  • Once I'd fixed the pin 21 issue, it still failed the Corcomp expansion test (whereas the 32k expansion in the PEB, perversely enough, passed before I started this project). The error address was random, and based on the diag results it looked like the 8->16 translation was glitching (expected FFFF, saw FF05, and the error was always in the low byte).

    I ripped it out and replaced it with the old 16-bit modification, and that killed the board completely.

    I have a (third) spare parts machine, and I swapped the main boards. Now everything works, modulo having to wait about thirty seconds after the PEB powers up before powering the console because I haven't fixed the new HRD+'s powerup reset bits yet.

    So the problem wasn't in the 32k card, it's somewhere in the console. I'll restore it back to non-expanded configuration and do the desoldering/replace routine when I have a day to kill.

    My suspicions are, in descending order of probability based on how things broke:

  • Either the '244 or '373 are slightly toast.
  • One of the 4116s on the mainboard is busted and is screwing with the address bus. The right thing to do is to pull them and try again (everything has F18s), but I was lazy. (pulling the 4116s saves an incredible amount of power; recommended for all F18 consoles)
  • The 9900 is glitching an address line.
  • What I really need to do is design a 16-bit RAM expansion piggyback board, along the lines of what I did for the HRD+. Stacking chips and running wires everywhere in a EF-noisy environment is never a good idea.

    Notes on reworking a low-serial-number HRD into a HRD+

    TI-99/4A Along with the Horizon 4000 (that I repaired and documented in the previous entry), IM also sent an original HRD. It uses the same board as the HRD+, but had a bit of extra glue logic and was missing the '259 and '138 stacks.

    It was populated with a number of stacked 6264s, and had chip-enable wires flying everywhere. I intend to use this board as a test bed for a one-megabyte daughter board (I'm awaiting delivery from the fab), but in order to do so I figured I should bring it up to HRD+ specs.

    That entailed removing U10 (and its socket), the socket from U1, and desoldering a stacked '138 from U19. After that, the 138/259/154 stack-replacement boards slotted right in. I fully-populated it with 62256s, reworked the power regulator as detailed for the Horizon 4000, connected the wires between U1, U10, and the various chips per the HRD+ construction manual, and fired it up for a test.

    Nothing. The ROS config utility didn't probe it. MEGTEST would test the DSR RAM chip (the sole 6264 left on the board), but would lock up halfway through the tests.

    It took about a day of dinking around with it, comparing the wiring against my other HRD+, and pulling chips for test in my TOP3000 (all chips passed) ... before I remembered rule #1 for repairing mid-eighties homebrew equipment: the original solder job is always going to be marginal.

    I touched up (and, in some cases, resoldered) all of the pads for the address glue logic. Suddenly, ROS config could see the card. The DSR test would still crash halfway through, so I replaced the original 6264 with a new CMOS workalike. Not only did that not fix the crash issue, but it also started throwing read errors during the bit verification test. My best guess is the weird germanium-diode-driven chip-select logic that turns on the 6264 is generating a signal that's marginally bad.

    It turns out that the 32k expansion card in the PEB has at least one bad chip. MEGTEST runs from expansion RAM. Removing the 32k expansion and swapping the console for a unit that has a known-good internal 32k expansion fixed the MEGTEST crash issue. All tests passed, the new HRD+ is happily chugging along at 384k, and all is well.

    Rather than troubleshoot the 32k card, I'm going to replace it with an in-console expansion. There's no point in replacing a slew of 4116s; they're weird (need +12V, +5V, and -5V), obsolete, and power-hungry. Tursi's two-chip expansion scheme costs less than ten bucks; I'm going to go that route.

    A side note: it's possible to rework the HRD+ to host the 32k expansion. There's a writeup on the mainbyte.com site; the author claims that it's for the HRD 2000, but the writeup and board pictures are obviously for the HRD+. There's a few discrepancies and/or errors on that site. I wrote about one in a previous entry here.

    I did send an email to the guy running the site about the flex card issue. No response, which didn't come as a surprise as the site hasn't been updated since 2010. Hence, I document the issues here.

    Anyway ... that's it for Horizon stuff until the one-meg board arrives from the fab. The design should be able to address four megs directly (with 512k x 8 SRAM) while eliminating the need for any '154s. I'll post the results here when everything is tested.