Replace your #$%& console power switch!

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.

Posted in Horizon, TI-99/4A | Leave a comment

Well, it wasn’t the 32k card

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.

Posted in Horizon, TI-99/4A | Leave a comment

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

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 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.

Posted in Horizon, TI-99/4A | Leave a comment

Refurbishing a Horizon 4000 RAMdisk

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.

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.

Posted in Horizon, TI-99/4A | 1 Comment

No more AtariAge.

Well, there I was basking in the warmth that was the TI-99/4A AtariAge forum. I felt comfortable, I was among friends (some of whom I wouldn’t like in real life, I think, but at least civil people).

However, I forgot rule one for non-Americans: don’t point out the decline of the American civilization to Americans, even if you are or used to be one. It never ends well.

So, to avoid more bloodshed, I’ve withdrawn from AA. I’m pretty turned off on the whole TI-99/4A scene at the moment; if I do any more hardware work on this machine, I will post here rather than AA.

Sorry, Ksarul/IM/Tursi/ralphb. You guys are okay. I don’t much care for the country that two of you live in (three, if we count China), but that doesn’t (or, rather, shouldn’t) affect our friendship.

Your cohorts at AA, however … I don’t care to associate with people like that.

You guys can always reach me here, or via email.


Posted in TI-99/4A | 3 Comments

Internal power / disable switch for the Axiom Parallax printer interface

The Axiom Parallax sidecar Centronics printer interface has only nine chips inside, and they’re all small LS TTL glue.

The console +5VDC supply should be able to handle the additional (minimal) current draw, especially if the console has an F18A and the now-useless 4116s were removed. One less wall wart to get in the way, plus the Axiom runs cooler because the linear regulator isn’t dumping ~+4VDC as waste heat.

So I tried it. It works. Here’s what you have to do:

Ensure that you’ve actually got + 5VDC on pin 1 of the expansion bus (lower left as you’re looking at it). If you have a speech synthesizer, you don’t, because TI didn’t run the line. If that’s the case, crack the synthesizer open and run a wire between pin 1 on the socket and pin 1 on the card edge. Be careful not to oversolder the card edge — solder it to the very edge and clean up with desoldering braid.

Disassemble the Axiom. There are a lot of screws and standoffs. Keep track what goes where .

Desolder and remove the 7805 voltage regulator. Note the orientation of the 7805 — pin 3 is the pin on the right-hand side as you’re facing the regulator, and that’s the one we care about. The board quality is just a tad above crappy; if I had to do it over again, I’d snip the leads and pull what’s left out of the hole rather than do a full desolder, because I lost the through-plating on the (now unused) voltage supply pin.

On the bottom of the board, solder a wire between pin 1 on the socket and the solder pad of where pin 3 of the 7805 used to be. The pad may not have been run through to the bottom of the board ; if so, poke the wire through the hole and solder to the pad on the top of the board.

Remove the old power jack, because you’ll need that hole for the disable switch.

There’s another modification that the Axiom should have if you’re using an UberGROM.

As documented, the UberGROM uses spacebar-at-powerup to bring up the recovery code.

Well, the Axiom does the same thing — it goes into diagnostic mode when spacebar is held at powerup, and keeps outputting chr(0x01) through chr(0xff) until you release it. And the UberGROM never sees the spacebar held down, so it never invokes the recovery code.

And if you’re like me, you probably have your sidecar connectors wired down with something like double-sided tape to keep them from shifting and crashing the console. Thus, unplugging the Axiom is a PITA when building up UberGROMs on real hardware.

Luckily, disabling the Axiom at boot-time is simple. Do this:

  • locate pins 20 (!CE) and 18 (!OE) on the ROM/EPROM,
  • disconnect them. There’s a trace on the bottom of the PCB that wires them together — take a razor knife and break that connection.
  • prepare a single-pole dual-throw switch (i.e., two positions, three wire lugs). Solder a 4.7k resistor and a length of wire to the leftmost lug (which we’ll call 1), and regular wire to the middle and right lug (which we’ll call 2 and 3).
  • Wrap electrical tape or heat shrink tubing around all of the switch solder joins (both sides of the resistor especially). You don’t want anything shorting out inside.
  • feed the three wires in through the top of the PCB. There are a bunch of viable holes: pick one that feels suitable.
  • Connect 1 to +5VDC. There’s a nice big lug to the left of pin 24 on the ROM/EPROM; that’s a safe place to hook up.
  • Connect 2 to 18 (!OE).
  • Connect 3 to 20 (!CE).
  • Test before reassembly. If it all works, reassemble. Put the switch where the power input used to go.

What you’re doing is forcing the EPROM output-enable signal to be logic-high all the time when the switch is engaged, essentially disabling the EPROM. When the switch is disengaged, !OE gets the same signal as !CE (the chip-select line) and the EPROM is enabled when the decode glue kicks in. This method takes advantage of the old ROMs having separate chip-enable and output-enable, and makes it easy to turn off the EPROM without messing with the chip select logic.

(Also of interest: the Axiom can use either a 2716 or a 2732. Pin 21 (A11 on 2732) is grounded on the PCB, so both will work. Just put the firmware in the bottom half of the 2732 and you’re good to go — no need to fill the ROM by double-copying.)

Posted in Horizon, TI-99/4A | Leave a comment

Printing from a TI to a modern printer

So, obviously, the TI-99/4A doesn’t support printing to USB printers, nor can it print to network printers.

With a little help, though, it can print to modern printers via a helper device running UNIX/FreeBSD/etc. This leverages the BeagleBone Black-based cassette emulator I described in an earlier web log entry.

Here’s how it’s done:

  • Decide if you’re going to use the TI’s parallel port or the serial port. I recommend the parallel port for the sake of speed — the serial port lacks any sort of handshaking, so you will drop characters if you choose serial.
  • (parallel): obtain a parallel-to-serial converter. They’re about fifteen bucks on eBay. Pretty much any unit will do, so long as it has a Centronics port on the input and a DB25/DB9 on the output. Configure it to output as fast as it can (typically 38400, which we’ll refer to as ${SPEED} for the rest of this procedure), 8N1.
  • (serial): obtain a straight-through DB25 <-> DB9 cable. DB25 will be male, DB9 will be female.
  • obtain and connect a USB serial adapter to the BeagleBone Black. You will probably need a small USB hub if you’re also using it as a cassette deck emulator — passive hubs are fine. Run “dmesg” on the BBB’s console until you see it detect the serial adapter and assign a device name (typically “ttyUSB0”). Note the device name; we’ll refer to it as ${DEVICE} for the rest of this procedure.
  • connect the TI to the BBB. If you went with step 1a, verify that you can successfully send characters through your parallel converter — i.e., print a file while running minicom on ${DEVICE} at ${SPEED}. If you went with (serial), no further actions are necessary for this step.
  • download my TI utilities from GitHub here … you care about everything in the printer_listener subdirectory.
  • on the BBB, make an incoming printer spool directory wherever convenient. We will refer to it as ${SPOOL_DIRECTORY} for the rest of this procedure.
  • inside the printer_listener subdirectory is an “epsonps” directory. Enter it, and execute “make; sudo make install”. The Epson-to-PostScript converter (and its PostScript preamble) should be installed to /usr/local/bin.
  • on the BBB, as root, ensure that the python2-pyserial package is installed.
  • on the BBB, copy the script from the printer_listener subdirectory to someplace convenient in your path. You can also leave it in-place, but you’ll need to explicitly specify its location when started.
  • on the BBB, look at the sample filter scripts and optionally choose one to use. One will send the printed output to a networked printer as HP PCL, the other will leave a PDF in /tmp. If you choose to use a filter, copy it to someplace convenient in your path (hereafter referred to as ${PATH_TO_FILTER})
  • on the BBB, execute “ -d ${DEVICE} -s ${SPEED} -f ${PATH_TO_FILTER} -n ${SPOOL_DIRECTORY} (with the “-f” and “-n” options being, well, optional). You will see “printer listener listening” after the serial port is initialized.

At this point, anything you print will appear either in the directory that you ran from, or the ${SPOOL_DIRECTORY} if you specified that option. If you specified a filter with “-f”, the output will be processed per the directives in the filter file.

That’s about it. You’ll probably want to wire this into a startup script; I despise systemd, so I’m leaving that as an exercise for the student.


Posted in TI-99/4A | Leave a comment

Two UberGROM images: Logo/Logo-II/Multiplan/TurboForth and Plato/Return to Pirate’s Isle

Thanks to Tursi, Ksarul, and a few others, it’s now possible to create bankswitched GROM/ROM cartridges for the TI-99/4A.

Most of the game cartridges were converted long ago to disk-loadable EA/5 images (most needing the 32k RAM expansion). The languages, courseware, and things that wouldn’t fit into a RAM expansion have not been converted.

The aforementioned guys built a GROM simulator around an AVR, added a bank-switching 512k EEPROM for the ROM side of the cartridge, and released it as the UberGROM cartridge board.

Therefore, I went ahead and created two multicarts. The first one contains Logo, Logo II, and Microsoft Multiplan. The second contains Plato and Return to Pirate’s Isle. They can be found here.

Update: the first image now also contains TurboForth v1.2.2.

To convert these to cartridges, first obtain two UberGROM cartridge boards. The link above goes to ArcadeShopper’s web site, but you can also purchase them directly from Ksarul on AtariAge.

The AVR must be prepared as per Tursi’s instructions here. The instructions expect you to have a cheap eBay TL866 EPROM burner, but it’s also possible to program with avrdude via SPI. Contact me for details if you decide to go this route.

Next, extract the files from the archives you downloaded from the links above. If you’re building both cartridges, extract into separate directories.

Next, burn the “eprom.bin” that corresponds with which of the two multicarts you want to create onto the EEPROM that you should have received with your UberGROM and install it onto the board.

Next, copy “cart1.tifiles” or “cart2.tifiles” onto a TI-readable media. I use and recommend the HxC Floppy Emulator, which uses disk image files on a SD card to emulate a Shugart-compatible floppy drive. Note: these files are (obviously) in TIFILES format; do the needful when copying them onto the target media.

Next, copy “gromcfg” from Tursi’s website onto the same TI-readable media. Insert that media into the floppy drive. If HxC, be sure to mount it.

Next, insert the prepared UberGROM cartridge into the TI. Hold down the space bar and turn it on. After the rainbow screen, you should see a menu that includes “Run Program”. Choose it.

The file you run will be “DSKx.GROMCFG”, where “x” is the number of the drive that contains the prepared media. After several seconds, you will see the GROMCFG browser.

Hit control-L. Say yes, you really want to do this, then feed it the name of the cartridge file (“DSKx.CART1” or “DSKx.CART2”.

Now go get a beer, this takes about five minutes.

When it’s finished, powercycle the TI. After the rainbow screen, you’ll see an option for “Multicart”. Choose that, and you’ll see the selection menu for the multicart that you just created.


Posted in Horizon, TI-99/4A | Leave a comment

Building a TI-99/4A cassette deck emulator

Although many people use their PC (workstation-class) to transfer programs to their TI via playing a .wav into the cassette port, I went in a different direction.

I like small dedicated devices, and thus I built a tape recorder emulator out of a BeagleBone Black, a SparkFun display cape, a USB sound dongle, and a little bit of UNIX.

First, I installed Arch Linux on the BBB via the instructions here. Yes, I hate systemd as much as anyone else, but Arch Linux has it and it’s the least distasteful of the Linux distributions at the moment.

Second, and this is very important, I disabled HDMI. If you don’t do that, the display cape WILL NOT WORK. There seems to be a different method every kernel release (as is the norm for Linux — I really wish FreeBSD supported capes), but I guarantee this method will work on Arch Linux as of March 2015. Log into the BBB, push to root, and execute:

mv /boot/dtbs/am335x-boneblack.dtb /boot/dtbs/am335x-boneblack.dtb-old
cp /boot/am335x-boneblack-emmc-overlay.dtb /boot/dtbs/am335x-boneblack.dtb 

You need to do this because the capemgr (if present in the kernel) will not disable HDMI; u-boot has the dtb hardcoded into its environment, and on the BBBs that I have they cannot be overridden by uEnv.txt. You won’t find this documented anywhere; I found it while poking around a storage-blanked BBB via serial console.

pacman -S lynx alsa-utils

Next, install the necessary packages with pacman:

Next, turn off the BBB and attach the display shield and USB sound dongle. I like the 4D Cape 43, as it’s cheap and has movement buttons. Turn on the BBB and wait to see a login prompt on the display. If you’ve got a white screen, then HDMI is still enabled. Disable it with extreme prejudice per the instructions above.

Next, log in and create an account. You can continue using “alarmpi” if you want. Edit /etc/systemd/system/ and add “–autologin ${USER}” after “/sbin/agetty” in the line that starts with ExecStart.

Now go to that user’s home directory and edit .profile to look like this:

export PATH=$HOME/bin:$PATH
TAPE_HOST="(web server)"

if test -z "${SSH_CONNECTION}"; then
lynx -cfg=$PWD/lynx.cfg \ "${TAPE_PROTO}://${TAPE_HOST}:${TAPE_PORT}${TAPE_DIR}"

… editing the TAPE_* to match your environment. You can rework it to use the local filesystem by using “file:///path/to/files” if you so desire.

Now edit .mailcap thusly:

application/x-gzip; cat %s | aplay 1>/dev/null 2>&1

… so that gzip files will be autoplayed when selected. If you’re using local files, you will need to use this .mailcap instead:

application/x-gzip; cat %s | gzip -d -c | aplay 1>/dev/null 2>&1

(why gzipped .wavs? gzip -9 losslessly compresses the output of my TI-to-sine-wave generator the best, better than even flac, thus I highly recommend doing this)

Now reboot. If all went well, you’ll see a list of tape files. Select one with the buttons on the shield and press the enter button. The .wav file should be played through the USB sound dongle. Verify that it sounds okay via whatever method you desire (powered speakers, headphones, and so forth); ssh in and adjust the output volume with alsamixer if necessary.

That’s it. Standalone cassette tape player construction complete, for roughly the price of a decent tape deck back in the 80’s.

Posted in TI-99/4A | Leave a comment

HRD+ 74259 Daughterboard verified good

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.

Posted in Horizon, TI-99/4A | Leave a comment