Notes on building a 32k RAM expansion for the TI PEB

I finally gave up on the OEM TI 32k RAM PEB card. It just wasn’t reliable … it passed all diagnostics that I could find, but it wouldn’t pass the acid test — function-6 GROM verification in Gazoo’s excellent Extended BASIC Suite v2.7.

I’ve previously detailed attempts to build a working in-console 32k expansion. The 8-bit expansion, although popular, is too invasive for my tastes; the 16-bit expansion killed my main board for reasons as yet undetermined and has even more wires than the 8-bit version.

Since I was resigned to an 8-bit design, and I had a spare PEB proto board from Ksarul, I decided to build an in-PEB replacement using a static RAM that used +5VDC only (instead of the OEM dynamic 4116s that need +12, +5, and -5).

Luckily, Thierry had already done the design work which can be found here. There are a few things that need changed or clarified to make this go, though.

First, the address connections to the RAM chip are A1/3/4/…/15 (circuit side) to A13-A0 (RAM chip). Note that A2 is not connected, because it’s used with A0 to derive A14. This is not explicitly stated in the instructions.

Second, it’s easier to connect A0 and A2 twice to the four-input AND gate rather than wire two of the inputs to +5VDC. Those signals are buffered; even if you’re using TTL parts instead of CMOS, you’re still not going to have a problem with fanout.

Third, Ksarul’s PEB board expects a non-inverted input to drive the board activity LED. Thierry’s design uses an inverted input (the RAM chip select) to drive the LED. There’s three ways to work around this: rework the board to put the LED in parallel to the 2N3904 rather than in series between Vcc and the transistor collector, or add a transistor to invert the input along the lines of the first option, or add a 74xx04 to invert. I had a spare 74HCT04, so I opted for the third option. Connect RDBENA* to pin 1, connect “LED DRVR” to pin 2, and you’re good to go. Ignore the gunk from RAM !CS through a ‘125 to the LED.

(note: on Ksarul’s PEB board, RDBENA* is isolated from the common PEB RDBENA* by the 74xx125 buffer. It’s safe to tap the signal from this location; you won’t be picking up signals from anything else in the PEB)

(further note: the PEB board handles all of the ‘125 bits for RDBENA* and the ‘245 !CS. The connection that would have been !CS from the RAM chip to CS* should now be from RAM !CS to the board’s RDBENA* pad; the board’s ‘125 will handle the rest. You can ignore the bottom part of the schematic that involves OE*, the ‘125, and RDBENA*)

Fourth, Ksarul’s PEB board has a slight error. The direction pin for the 74xx245 data buffer is connected to MEMEN*, but it should be connected to DBIN. Fixing this requires cutting the trace and running a jumper wire, but it’s not difficult. The LED polarity as silkscreened on the PCB is reversed, too … the flat side should be on the bottom, not the top.

Fifth, there should be a 4.7k ohm resistor between G1 (pin 6) of the 74xx138 and Vcc. You can also opt to connect G2B (pin 5) directly to ground (I did).

Don’t forget to put a 0.1uF decoupling cap between the Vcc and ground pins on every chip.

Anyway, that’s it. It’s trivial to build a PEB-based replacement for the 32k RAM expansion if you have a Ksarul PEB proto board. I highly recommend doing this if you have a few free hours; the power savings alone are worth it.

I may make Eagle schematics and a board file available for download in the near future.

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

Refurbishing a TI PEB power supply

I’ve seen a number of people recommending replacing the older forty-ish watt TI PEB power supply with AT(X) power supplies.

As with most stopgaps/workarounds that the TI community has come up with, I’m not sure that’s a good idea. The original PSU emitted +16VDC, +8VDC, -16VDC, and +5/12VDC for the stuff in the drive bay, and the PEB cards are expected to have on-board regulators to produce the desired voltage.

An AT(X) PSU, on the other hand, emits +12/+5/-12VDC. The folks that have done the conversion recommend that the original +8 and +16 be wired into the +12 rail, and the -16 wired into the -12 rail. That will work if and only if the voltage regulator on each card will go into bypass/shunt mode when the input voltage is below the regulator’s input voltage floor (typically about two and a half volts over the specified output voltage).

If the card regulator goes into bypass mode, it might as well not be there at all. The entire point of the per-card regulator scheme has been negated — you’ve lost the protection afforded by the onboard regulator, and are at the mercy of the PSU. The only case where this isn’t an issue is on a +5VDC-only card, and if you haven’t replaced the 7805s on the cards with switching equivalents, you’ll see a dramatic increase in heat generated by the regulators.

Therefore, if one has an ailing PSU in a PEB, I reckon it’s better to refurbish the original PSU rather than replace it with under-specced voltages.

The PEB PSU is pretty simple. It uses a gigantic multi-tapped transformer to step down the voltages to somewhere around nominal, simple full-wave bridge rectifiers and a few large electrolytic capacitors to smooth things into DC, and a couple of 78xx regulators to deliver the +5 and +12VDC. The schematic is here.

First, replace the 7805 (in a TO-220 form factor) with a switching equivalent. I used CUI Inc’s V7805-1000, which handles one amp without breaking a sweat. It’s probably better to get the -1000R, which has longer leads for mounting flush against the PCB, but the non-R leads are long enough to fit as well.

Second, replace the 7812 (in a TO-3 form factor) with a switching equivalent. These are harder to find … I used the EzSBC PSU6, which is also good for one amp. Do not forget to put the screws back into the mounting holes; if you don’t, the regulator won’t be grounded and will go into bypass mode. That’ll put an unregulated +16VDC onto the +12VDC rail, with bad consequences.

Third, replace all of the electrolytic capacitors. All are axial-mount 35V polarized units; you’ll need two 4700uF, two 3300uF, two 1000uF, and two 47uF. The replacement 35V caps are probably thinner than the originals (mine were), but if you go up one more size to 50V, the physical dimensions should match pretty closely.

Fourth, replace D1 through D6 (i.e., all of the diodes) with 1N5401s. D3 and D4 are already 1N5401, but they’re at least thirty years old and are near or past their service lifetime. The other diodes were 1N4002s, which are the less-beefy cousin of the 5401 (the 4002 can handle one amp, the 5401 is good for three amps). The 5401s are a bit bigger than the 4002s, but they’ll fit into the mounting holes with a bit of elbow grease.

While you’re in there, you might consider replacing the original fan (running on 110VAC) with a normal PC fan (running on +12VDC). The size is standard. Wire that into the regulated +12VDC rail wherever convenient. Instructions can be found here.

That’s pretty much it. Plug the P1 cable from the transformer back into the regulator board, turn the PEB on, and verify the voltages at the P2 and P3 connectors against the schematic referenced above. If everything matches (the unregulated voltages will be high, because there’s no load), then you’re done.

This should return your PEB PSU back to original strength.

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

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