Skip to content

The HRD+ upgrade design is validated.

TI-99/4A The final piggyback board arrived today; this one eliminates the open-collector 74xx156 with a 74xx155 and a 74xx08 to handle what the pullup resistor used to do.

Everything works well, with one caveat: I never could get reliable operation out of the low-power CMOS 6264 handling the DSR. The old [HN]MOS 6264 that came with the card did fine, but the new Alliance CMOS part kept throwing errors up towards the top of the memory space.

It could be due to the HRD+ build instructions telling us to wire A14 into pin 1 shared by all of the memory chips. This is a non-connected pin on the 6264, but it's possible that Alliance's part doesn't like a fluctuating input.

It could also be due to the funky pullup/pulldown scheme on one of the two chip selects on the 6264. The chip turns on when one is high and the other is low, and turns off when the logic levels are reversed. The HRD+ does that by feeding Vcc through an LED to the non-inverted CS pin, and then grounding it through a resistor. I replaced that with all sorts of schemes (feeding that CS through the signal that handles the actual RAM disk, going to a two-resistor approach, etc) but nothing was stable ... and I didn't have a spare CMOS 6264 to test. My TL866 swears that this 6264 is okay, so fine ...

... I have a bunch of low-power Alliance 62256 chips. Standby current draw is roughly the same as the Alliance 6264, the package and pinout is mostly the same, and most importantly it has only one chip select pin. Ground pin 1 (A14) and pin 26 (A13), attach pin 20 (!CS) to Vcc via a pullup resistor to kick it into power-saving mode when the switch is flipped, and suddenly everything worked fine.

I'll post the piggyback boards (schematics, PCBs, and instructions) when I get a moment over the next few days. The design is validated, so I don't see any reason not to do a full layout and release that as well. This layout will require a 62256, because I won't release a variant that I couldn't get to work myself.

So ... we now have a vetted multi-megabyte RAM disk for the TI-99/4A that can be built by regular humans using currently-available parts. Total cost for the chips should be under thirty bucks; the PCB costs however much the fab charges you. You can choose to upgrade an existing HRD+ or build a new one, your choice.

(I'll also throw in a 32k expansion daughterboard PCB that plugs into the DSR chip socket. That's totally untested, of course, but it should work ... )

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.

Refurbishing a Horizon 4000 RAMdisk

TI-99/4A Ksarul and IM sent over a Horizon 4000 that wasn't working right. To wit, it wouldn't be detected at all by what passes for an OS on the TI-99/4A.

I got it working, and it didn't take too long. Along the way, I noticed some odd things about the design. My notes are below, in case someone else ends up working on a similarly broken board.

It turns out that U9, which was specced as a 6264 on the schematics, was a 62256. Although the 62256 passed a quick test with the TL866, it wasn't working with the 32/8 jumper in either position (and, per the documentation, that jumper was the selector between a 6264 (8) and a 62256 (32)).

There's bad weirdness going on with the 32/8 switch. It's on the schematic right next to R3, and if the schematic can be trusted, that jumper merely switches the power source for one of the chip selects on the CSR RAM from mains to battery. You don't want that. That doesn't switch pin 26 from a chip-enable (6264) to an address line (62256). Leave the jumper at the 8 position to keep it wired to the main voltage rail and avoid unnecessary battery drain ...

... the other CS (or A13 if you're using a 62256, which is what the aforementioned 32/8 switch should be frobbing) is more or less held high by the power LED, a diode, and a resistor before it hits the base of Q2. That's not a reliable way to do this. I think it works on a 6264 because TTL is voltage-tolerant, and chip-select is really tolerant. I can see a 62256 address line having issues with this. If I were redesigning it, I'd wire it high to the main voltage rail through a dedicated 4.7k resistor and depend on the !CS2 mentioned in bullet point one. No need for a 32/8 switch if that is done.

The '156 that is ultimately handling the !CS2 signal is open-collector, so it needs to stay connected to the main voltage rail. That bit I wouldn't change.

The power circuit needs to have R9 removed, and both CR10 and CR11 replaced with wires. This achieves several things: makes the circuit compatible with modern switching 7805 replacements, removes the voltage drop from the main power rail, and eliminates the need to add the same amount of voltage to the regulator's ground connection to compensate for the previous diode. CR12 handles any direct backwash from the battery power circuit (+5B), so CR10 and CR11 are both unnecessary and harmful.

After replacing U9 with a 6264 and moving the jumper to the 8 position, the RAMdisk fired up fine. Everything past that was either cosmetic (fixing the power circuit so that it didn't shed scads of waste heat) or investigative. These are weird boards, designed weirdly, and there's room for improvement. For example, the 74HC154s should not be HC, they should be HCT and they should not be on the battery-backup circuit.

I'm sure there's more weirdness in the design, but that's good enough for one post. Hope this helps someone else trying to fix one of these boards.

Finished and verified: SMD replacement boards for Horizon HRD+

TI-99/4A As previously mentioned, I've been working on an old Horizon HRD+ RAMdisk card for the TI-99/4A.

Three of the chips (a 74LS138, a 74LS154, and a 74LS259) had other chips stacked and soldered on top of them, with leads bent out and wires connecting to various places on the board. One chip (the 154) is no longer available in .600 DIP form.

For obvious reasons, I decided to replace these chip stacks with plug-in boards. Each board is electrically equivalent to the chip stack that it replaced, with the exception of the 138 replacement board incorporating errata wiring later published by Horizon. All chips are SMD, and are currently available as HCT.

The Eagle schematic and board files are available here.

All three of these boards designs have been tested and are currently in use in my HRD+.

Enjoy. Hopefully this will help someone out there that's trying to get one of these working, but is stymied by the stacked chips and/or can't find a package-exact replacement for the 74LS154.

HRD+ 74259 Daughterboard verified good

TI-99/4A The subject says it all, really. I got ahold of a couple of 74LS259D SMD chips, soldered them into the adapter board, and replaced the '259 stack in the HRD+ with the daughterboard.

Since nothing ever works correctly the first time, I botched a solder joint on one of the chips and spent an hour with a microscope, a schematic, and a continuity tester to track down the problem.

Anyway, it works. Eagle .sch and .brd are here. Enjoy.

Daughterboard replacement for Horizon HRD+ chip stacks

TI-99/4A Earlier, in my article about refurbishing an old Bud Mills Horizon HRD+, I asked why TI gear (both official and homebrew) tended to stack similar chips on top of each other, straightening pins out, and using flying wire to connect to other stacked chips.

The question was mostly rhetorical because it was pre-electronic-CAD ... so it saves real estate on the board, saves time laying out interconnects on the board, and so forth, because a human was doing the layout. It doesn't make much sense now, especially that nearly every 74xx chip ever made is available in a form factor that's 25% the size and consumes 10% of the power of the original chip.

The Horizon HRD+ has three chip stacks -- one stack of three 74LS138s, one stack of two 74LS259s, and one stack of (obsolete in PDIP) 74LS154s.

I have designed replacements for all three that fit into the original socket, with small solder pads at the edge of the board to handle the flying wires that were originally attached to the chips.

The '138 replacement has been tested and seems okay. It incorporates the "hide" function as described in the HRD+ errata, so you'll need a 4.7k resistor and a small two-position switch to superglue up by the positive end of the batteries, with the switch actuator facing towards the rear of the PEB. Connect the middle switch contact to "HIDE" on the PCB, and either of the other two switch contacts to ground (but not both!), and you're good to go.

You may have clearance problems between the daughterboard and the surrounding socketed chips. Add an extra 16-pin socket between the HRD+ and the board, and again you're good to go.

A zipfile containing the Eagle .sch and .brd files for the '138 replacement are here.

The '259 replacement board will be forthcoming. I accidentally ordered N-suffix (DIP) parts rather than D-suffix (SMD) from Mouser, so it'll be a few weeks before I can have that ready and tested. After that, the '154 ...

... and maybe, just maybe, a daughterboard that uses two 512kx8 SRAM chips to bring the HRD+ up to one megabyte. No promises, but the hardware can certainly handle it. This would entail pulling all of the 62256 SRAM chips, plugging into one socket, removing a resistor on the board underside and running a couple of CS/address lines to the '154 daughterboard.

Better than stack-and-solder, anyway. I hope that someone else finds the Eagle files useful when refurbishing the Bud Mills Horizon HRD+.

(Repetition of the full product name for search engines :-)

Refurbishing a Horizon HRD+ RAMdisk Card

TI-99/4A I recently came into possession of an ancient Horizon HRD+ RAMdisk card for the TI-99/4A PEB. Not the 2000, 3000, or 4000 -- the original model, designed by Bud Mills and Ron Gries circa 1986.

It's a variable-size RAM disk with battery-backed RAM. There's a rudimentary charging circuit onboard, so that NiCad batteries can be used and charged while the PEB is on. This particular card hadn't been turned on since 1989, based on the calendar taped to the front of the PEB that it was in ... so, needless to say, the batteries were not only dead but had leaked into the chips below.

First order of business was to replace the corroded AAA battery holders at the top of the card and assess the damage. Lucky for me, the original owner decided to put gigantic ceramic 0.1uF decoupling capacitors directly beneath the batteries, and they blocked most of the battery goop from the chips below ...

... which was a good thing, because this was a) fully-populated with 62256s (which are getting hard to find) and b) using a couple of 74LS154s soldered together to do the address decode, and .600 '154s aren't made anymore as far as I can tell.

I pulled the top row of chips (including the '154s) and scrubbed everything with isopropyl alcohol anyway. Good thing that I did, too, as the top right (power) pin on the '154 stack came off as I pulled the chip. The stub was okay, but the bit that went into the socket had corroded away. Easy enough to fix with a bit of extra stiff wire left from an LED from another project.

For some reason, mid-80's TI gear used a lot of stacked chips. There were wires flying from pins bent up on the stack, and some of those wires weren't connected anymore. So I needed a schematic ...

... and the go-to place for TI documentation (the whtech.com Horizon subdirectory) didn't have a manual for the plain HRD+.

A few days of searching led me to a post on AtariAge, where a person with the handle "schmitzi" posted a low-quality scanned version of the construction manual, including schematic (source here).

I fixed the wiring to match the schematic, powered it up, and it appeared to be okay. All memory tests passed, it could be formatted as a 384k RAM disk, and all was well ...

... until I replaced the (ancient, power-wasteful, hot-to-the-touch) linear 7805 with a Minmax switching 7805. Now, suddenly, it didn't work. I could see only a few volts across the power rails. That was not right.

It turns out that the 7805 ground connection isn't really connected to ground. It has to go through a diode first (which isn't usually a problem) and is fed back into the supply voltage via resistor R10 (which is a problem). The fix is to remove R10 and connect pin 2 of the 7805 directly to ground. Problem solved.

It also turns out that Bud Mills published errata for the HRD+ that fixed a data-corrupting reset-on-powerup bug, and added a switch to lobotomize the card in case the DSR somehow became corrupted. That document was found (in PDF form) in the TI-99/4A Yahoo! mailing list archives.

(Side rant: what is it with TI people and DSR-in-RAM? I've seen three projects now that put the DSR in battery-backed RAM, with predictable results. Did they all sleep through the electrical engineering class where they were taught that critical code needs to be in non-volatile memory unless you have a damned good reason for not doing so?)

Digression aside ... I have OCR'ed and cleaned up both the construction document and the errata and placed them here and here.

I have taken the liberty of correcting typos in the former; the latter didn't appear to need correction.

As far as I can tell, there was only one source each for these documents on the net (schmitzi's post on AtariAge for the construction manual -- and that place is sort of a walled garden regarding web spiders), and I've therefore posted cleaned-up versions of both here with the intention that the various search engines can find them easier.

I hope these documents help the next poor fellow that finds one of these cards and decides to make it go.