Skip to content

TI web/FTP site mirrors

TI-99/4A So the WHTech FTP site (the main major repository of all things TI) was down for a day or so. Reason given was "They had a catastrophic drive controller failure due to a power issue. They say we will be back within 24 hours."

I've seen sites go away permanently for various reasons (dead hardware and no backup, host provider went out of business and no backup, maintainer loses interest and no mirror). I don't want to see that happen with WHTech.

So, I'm mirroring the FTP site here. Mirror jobs will run daily, in the middle of the night in the US to minimize traffic.

I'm mirroring a few other sites as well. They are listed (and accessible) via the "Related Links" folder on the right-hand side of this blog.

Hopefully we won't need to have this mirror, but it's here in case Bad Things(tm) happen again.

Building a TI-99/4A cassette deck emulator

TI-99/4A 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.

Next, install the necessary packages with pacman:

pacman -S lynx alsa-utils

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.

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 :-)

Various TI python scripts on GitHub

TI-99/4A I should probably mention that I've put various TI scripts up on GitHub here.

Only two of the three are useful at this point: ti_bin_to_wav converts a TI binary file into a 48kHz stereo .wav file suitable for loading back into the TI via the cassette port, and pc99_to_dsk.py does just what it says on the tin: converts a PC99 disk file into a regular V9T9 disk file. The former generates the .wav file using sine waves of the proper frequency (guaranteeing that the TI will be able to read the file), and the latter uses Thierry's TI disk track documentation to extract and re-order the sector data.

Before various well-meaning people from AtariAge comment that "(random utility) already does that, and it runs great under wine!" ... I'd like to respond pre-emptively with this:

Any utility that a) expects to be run on Windows (even via an ABI translator) and b) doesn't have source code available should not be trusted. Yes, cs1er and tape99 convert TI binaries to .wav files. Yes, TIDir converts between various disk formats. What if I'm running on a Raspberry Pi and therefore don't have Windows ABI capability? What if I'm ssh'ed into a file server and need to do batch conversions quickly? What if the Windows program just plain doesn't work and I haven't the patience to watch a twenty-minute YouTube video to find that one setting that is breaking the process?

What if I just plain don't have a Windows box, have no desire to build one, and know how to program? (Rhetorical questions are fun)

Hell, tape99 didn't even work for most use cases for well over a decade. It wasn't until I nudged a guy that was in contact with the original author that a "fixed" version was released ... and it still emitted .wav files that neither of my consoles could read.

That's why I write this stuff -- prior art exists, but it's non-portable, non-future-proof, non-CLI-friendly, and impossible to troubleshoot when it's broken. And TI people, out of the entire computing community, should know better than anyone about depending on a single source and undocumented code to run their gear.

(nothing personal, AtariAge folks, but some of you just don't get it and probably never will -- users and engineers are fundamentally different creatures)