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.

Cheers.

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 printer_listener.py 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 “printer_listener.py -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 printer_listener.py 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.

Enjoy.

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.

Cheers.

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/getty.target.wants/getty@tty1.service 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_PROTO="http"
TAPE_HOST="(web server)"
TAPE_PORT="9640"
TAPE_DIR="/"

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

… 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

Daughterboard replacement for Horizon HRD+ chip stacks

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 🙂

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

Why I am against RAM-based DSRs

Right, so there’s a non-negligible number of TI users that use hardware with their DSRs (device-specific firmware) in battery-backed RAM.

This is a horrible, HORRIBLE idea … but I’m apparently having difficulty communicating to various users exactly why it’s a bad idea. “It’s worked for me for thirty years, all I need to do when the system gets weird is to pop the battery and reload the DSR”.

Well, that’s nice, sunshine, but just because it kinda sorta works for you most of the time
doesn’t mean that it’s a good idea to design hardware that way.

I understand the arguments for using RAM for firmware — rapid development cycle and easy upgrades. And that’s it. Let me enumerate the arguments against using RAM for firmware:

  • You’ve got to be able to bootstrap the system somehow. If the DSRs are involved in the boot process (whether simply initializing buffers, or actually being a boot device), and they’re corrupted, you’re screwed if you don’t have an alternate method to boot the device and restore the DSR.
  • It is way, WAY too easy to corrupt the DSR. The HDX DSR, in particular, appears to use buffers at the upper end of what would be ROM space. It’s RAM, though, so it doesn’t have to worry about the buffers being overwritten by other programs. It does have to worry about overrunning those buffers and thus corrupting code, though, and it doesn’t. The HDX has many flaws, but this is the killer — it doesn’t separate data from executable code, because (in the words of Raoul Duke) “the pension fund was just sitting there!”
  • Modified Harvard Architecture. Learn it, live it, love it. Keep your executable code separate from your data buffers and your system won’t be vulnerable to buffer overflows. We learned this in UNIX a long, long time ago, and that’s why NX pages exist.
  • Ready availability of cheap EPROM programmers. Back in the eighties, an EPROM burner was a valuable device. My Data-I/O burner cost nearly four digits. They’re USD$30.00 now on eBay and any fool can use the Windows point-and-drool interface to burn the DSR to EPROM.

In summary, using RAM for DSRs on the TI is (in my educated, non-humble opinion) a gigantic goddamned design error.

There. That’s off my chest 🙂

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

Refurbishing a Horizon HRD+ RAMdisk Card

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

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

Why won’t the TI-99/4A cassette port work with my PC sound-out port? Here’s why …

TL;DR: the OEM TI cassette cable tape-audio-1-input jack is wired incorrectly for equipment available now. Leave pin 9 floating and run pin 3 to CS1 plug sleeve and things magically work. You can cheat by amplifying the signal a lot (and expect it to have issues from time to time) or fix your wiring. Your choice.

Problem description:

Under most circumstances, when wired straight into either the headphone or line-in jack, the signal heard from the TI speaker is low. Really, really low. Much, much lower than I remember it being. And, thus, the TI doesn’t see the signal at all. Plugging the microphone jack in sometimes helps, but it’s still twitchy.

If you screw around with the cable (ground pin 4, plug the mike jack into headphone out and the audio-in jack into line out, pull the plug out about three millimeters, and so forth), suddenly the incoming signal volume dramatically increases and the TI sees it. That’s … not right, it’s very wrong, so I looked deeper.

I’ve spent two days poring over schematics (the official TI schematics, the SAMS schematics, with an eye towards Thierry’s cassette port description) … and I think I found the problem.

Let’s start with Thierry’s tape description. This description appears to be the same description that is reproduced throughout the net, but it’s slightly wrong (or, at least, cryptic). It looks like this (omitting the ASCII DB9 diagram):

1  >  Cass 1 motor control
2 > Ditto (negative)
3 > Output to tape 1 or 2 (neg)
4 > Audio gate
5 > Output to tape 1 or 2
6 > Cass 2 motor control
7 > Ditto (negative)
8 < Input from tape 1
9 < Ditto (neg)

According to the schematics, that’s mostly correct. There’s one thing that’s glaringly missing, though — a ground connection.

The way Thierry’s diagram should read is thus:

1  <  Cassette 1 motor control (switch input) 
2  >  Cassette 1 motor control (switch output)
3  x  Ground (connected to cassette 1 and 2 microphone sleeve)
4  >  Audio gate (unused, signal not present on cable)
5  >  Audio output to both cassette 1 and cassette 2
6  <  Cassette 2 motor control (switch input) 
7  >  Cassette 2 motor control (switch output)
8  <  Audio input from cassette 1
9  <  Audio input from cassette 1, grounded via RC filter

Note pins 8 and 9. 8 goes to the tip of the 3.5″ jack — that’s the signal. 9 should be grounded, according to the TRS convention where tip and ring carry signal, but sleeve is always grounded.

This would be why I was never seeing signal without the mike line connected to something; there is no ground continuity between the recorder and the console except through the microphone connector.

I say again: If the microphone connector isn’t connected, there is no ground connection. The TI depends on the microphone jack ground connection to ground the headphone/line-out jack.

I haven’t done the math to figure out what band that RC filter on pin 9 is passing, and the schematics have different opinions about what else is wired into that part of the circuit. Maybe cassette 2 was originally supposed to have output capability, and there was a last-minute cost-cutting measure

The fix is simple: connect the sleeve of the audio-in jack to pin 3, as it’s supposed to be grounded anyway.

That, however, is going to also ground the ring on the cable jack, and depending on how the audio source is wired, that may cause issues/damage the ring audio source. There are two possible fixes here: replace the male mono jack on the cable with a stereo mono jack (and leave the ring floating), or build a work-alike interface.

I chose the latter, mostly because my TI cable is extremely beat-up and therefore has questionable electronic reliability, but partially because it’s a cleaner solution.

I took a small project box and used a nibbler to cut a hole for a female DB9 connector. I then installed two female stereo 3.5-inch jacks. Pin 5 on the DB9 is connected to the tip of one of the 3.5-inch jacks (microphone), pin 8 to the tip of the other (audio-in), and pin 3 to the sleeve of both (ground)

You can wire in cassette 2 and/or motor control (I’m doing the latter, as the display shield on my BeagleBoneBlack has capability for this), but that’s the magic signal fix.

Electrical engineering bits that the uninterested can skip:

What IS going on with that circuit hanging off of pin 9? page 23 of this tech ref makes it clear that it’s an RC filter. The QI circuit on page 30 makes it look like it’s boosting the impedance (which might actually work, but I don’t have a QI). The SAMs looks very much like the RC filter variant, except it has another resister in series before the filter that’s probably boosting impedance.

Why hasn’t anyone noticed this problem before? I believe that it’s because the problem can be mitigated by throwing enough amplification at the problem. You’ll see recommendations on forums like AtariAge to run the signal through amplified speakers, thence through the speakers’ headphone jack. Others recommend using the line-out jack only, or the headphone jack only, at specific OS-side volume levels.

Each method succeeds to varying degrees, depending again on the hardware that’s being used. None address the root issue: the TI cable isn’t grounding both plugs, and worst-case is feeding audio backwards into the RC filter on pin 9.

It’s that simple. You don’t need to mess about with specific volume control settings or specific brands of USB audio dongles: it’s a TI design flaw that assumed that the cable would a) always be plugged into a mono source and b) always have the microphone plug connected.

So, in summary, here’s the behavior summary as I see it:

  • The TI cassette cable has mono plugs,
  • The audio-in plug therefore shorts the ring (right channel) and sleeve (ground),
  • The TI cassette cable connects the microphone sleeve to console ground,
  • The TI cassette cable connects the audio-in sleeve to ground via (at least) an RC bandpass filter,
  • If the TI cassette cable microphone plug is not plugged into the sound source, there will be a ground loop through the audio-in sleeve,
  • Behavior of the system beyond that point depends very highly on the quality of the sound source design,
  • Anecdotally, adding a large amount of amplification (and possibly equalization) to the signal overcomes the ground loop.

From an electrical engineering (and, thus, physics-derived) standpoint, here’s how I see it:

  • There are at least three different versions of the circuit schematic for the goop connected to the audio-in sleeve, which in turn means …
  • … there will be variance in what works for each user, depending on the goop in that particular console and the sound source design,
  • The incoming signal is amplified by a pair of op-amps to +5VDC in the console, so significant signal amplification should not be necessary,
  • In general, ground loops are bad and should be avoided if at all possible,
  • In general, significant signal amplification is wasteful and should be avoided if at all possible.

So, here are the possible fixes (in ascending order of desirability) as I see them:

  • Run the signal through a large amount of amplification to overcome the ground loop,
  • Plug in the microphone jack and use a mono-to-stereo plug converter to isolate the ring from the sleeve on the audio-in jack,
  • Replace the mono-intended cable with a stereo-intended cable wired per the first post in the thread.

The first one works for some people, but is electrically incorrect and will not work in all cases. The second and third are functionally equivalent.

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