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.

About Chris Kobayashi

I'm a security systems engineer, specializing in UNIX, network, and physical security. I'm in Tokyo, and I'm mostly retired now. I'm well-versed in both electrical and software engineering, with a particular interest in old computers and game consoles. You can contact me here.
This entry was posted in Horizon, TI-99/4A. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.