Author: Josh

Letting out the magic smoke

So I finally got around to using my last set of parts to build on my pre-castellated PCB, and I killed it. Seconds after applying power to the REX, a faint trail of smoke was visible rising up from the board. Dang!

A little background

The Tandy 100, like most machines of its day, ran all its logic circuits at 5 volts. Some parts in these older machines may have required additional supply voltages (12 volts was common, though some early RAMs needed -12 as well, and things like SID needed 9 sometimes… it was messy) but all the bus signals were 5 volts. Since then, 5 volts has become rather uncommon in logic parts, with 3.3 volts now being the most common voltage seen in both logic and power supply levels. The creates a bit of a problem when you want to integrate these older machines with modern upgrades built from newer components.

The REX deals with the 5-volt problem in several ways. The flash chip is actually a 5-volt part. Like the CPLD, it is old, obsolete, and no longer made, though you can still find supplies of them if you look a bit. The CPLD, while obsolete, is actually a 3.3-volt part but it’s I/O lines are 5-volt tolerant. This means you can connect it to the 5-volt data/address bus, but you must supply it with 3.3 volts in order for it to function properly. To get this voltage, there is a small linear regulator on the REX which creates 3.3 from the 5-volts supplied by the OPTROM socket on the Tandy.

Letting out the Magic Smoke

In testing my power socket, I was sure that had measured the proper 3.3 volts at the reference voltage point (one of the JTAG connections), but after my programming attempt, I got nothing. Switching to my ohmmeter, I measured a measly 2 ohms between the 3.3v pin and ground. This meant that the CPLD was attempting to pull 1.6 amps on the 3.3-volt line! (Ohm’s law) There was no way that puny 50mA regulator was going to handle that current, and thus, it gave up its ghost, slightly early for Halloween.

To try to figure out what went wrong, I broke out the hot air station and started de-populating the board, checking the resistance each time. None of the passives caused any change, nor did the regulator. Removing the CPLD, however, caused the resistance to go back to open-circuit. Just to be sure, I soldered the CPLD onto my remaining PCB from the original batch, and, sure enough, I measured 3 ohms this time. So, the new PCB wasn’t the problem. Somehow, I must have managed to kill the CPLD — either that or I got a dud. No way to tell.

So, from now on, I’m going to remember to check the resistance across the 3.3v line. I asked on the M100 mailing list, and another person measured ~11000 ohms across his, which seems reasonable given the datasheet’s power draw specs on the CPLD (~100 uA to ~1 mA, depending on activity).

So, I ordered a new set of parts. Hopefully the flash chip is okay since it’s not involved in the 3.3-volt rail. They should arrive today. In fact, I think I hear the mail truck!

The programming process

After the physical construction of the REX, the final step is to program it. Programming the REX is done in two stages: The CPLD and the flash.

CPLD

Programming the CPLD is done with a special programmer from Xilinx. The programmer uses the JTAG interface to program the CPLD. JTAG specifies a common standard for on-chip hardware that is used for programming and debugging IC-level stuff. More info can be found on Wikipedia, of course. The connection to the CPLD is six pins that are usually connected via a male pin header. The REX connection, though, is simply unpopulated vias, so a pin set is needed to connect the female header on the Xilinx cable. I used square wire-wrap pins cut from a connector that I had lying around.

Flash

The flash memory on the REX must be programmed by a program running on the Tandy itself, since the REX doesn’t make any connections available for directly programming the flash. I could use a TSOP-48 adapter to program the flash in an external chip programmer (I have access to an older Xeltek) but I’m not sure I would trust the code in the chip after the soldering process.

The flash programming is done my a machine-language executable (.CO) on the Tandy. Of course, getting the .CO file onto a cold-booted Tandy 100 requires us to first have a DOS loaded. Since the REX flasher application needs DOS anyway in order to load the ROM files that we’ll be flashing, this isn’t wasted effort. But it was something I’d never actually managed to do before.

I’m starting to see a pattern with this project: almost as soon as I realize I need something, someone on the M100 list posts and offers exactly what I need. In this case, it was Kurt McCullum who added an awesome feature into the Android version of mComm: the ability to send DOS.

mComm is one of several programs available that emulate some version of the Tandy Portable Disk Drive. This was a device sold by Tandy that connected to the serial port on the M100 and gave you access to 100K of disk storage on a 3.5-inch diskette. It, too, had it’s own bootstrapping procedure where it copied a small disk driver onto the M100. Later, Traveling Software would vastly improve on Tandy’s driver and release their product called “TS-DOS” in both ROM and RAM versions. It is this RAM version that I need to load onto my M102 so that I can get the REX flash utility.

By using a USB on-the-go cable, I can connect a USB-to-serial cable to my Android phone. This connects to my M102 using a null-modem adapter and a 9-to-25 pin adapter. Then, in BASIC on the M102, you type

RUN "COM:98N1E"

and tap “send” on the phone. The BASIC interpreter will execute the bootstrap loader, which basically POKEs TS-DOS into RAM in the right place. It provides handy instructions on the screen and little progress dots as it’s loading DOS. Then, after CLEARing space in high memory (CLEAR 0,55000) you can run TS-DOS from the menu, and you’ve got DOS! Amazing!

I had issues at first that I imagine came down to flow control. The serial UART on the M100/102 have a tiny, tiny little buffer, so it’s easy to drop bits if the CPU can’t keep up. Flow control is used to allow the M100 to tell the sending device to stop for a moment to allow the CPU to catch up. Some (many, actually) cheap USB-serial devices don’t implement flow control properly, and some (again, many) null-modem adapters don’t cross the flow control lines properly. I finally found a combo that worked: an FTDI-based cable and my roughly 30-year-old Radio Shack brand 25-pin null modem adapter. How fitting.

With TS-DOS installed in RAM, I can then load the REX flash program, ‘RF149.CO’. This program, when executed, will make the magic address calls to the REX which will:

  • Erase the flash chip
  • Program the REXMGR software into blocks 0 and 1
  • Program TS-DOS into block 8
  • Create an initial RAM backup image on the flash

RF149.CO pulls these files from the TPDD device (or emulator in my case) which is the other reason we need DOS in RAM in order to flash the REX, since the Tandy doesn’t have anywhere near the RAM capacity to hold all the data that needs to be programmed into the flash chip.

After this, you can cold-start the M100, run CALL 63012 from BASIC and the REXMGR will be loaded. After this, it functions transparently as an option ROM to the Tandy OS.

The REX is a really great little gadget and I see what all the fuss is about. For more information on it’s design check out the Bitchin 100 wiki at

http://bitchin100.com/wiki/index.php?title=REX_Overview

 

Castellated PCBs are here!

The pre-castellated PC boards arrived from OSH Park yesterday. The router paths that Stephen added look to be spot-on, and the router actually seems to have cut them darn near perfectly. The path went right outside the silk-screened grinding guides (that show how far the non-castellated boards should be sanded/ground) and left just a tiny bit of excess to be sanded. OSH Park’s milling tolerance is 5mil so there’s a but of variance across the three boards that I received, but all of them look usable. And they’ve got a special Halloween sticker, too.

I broke out my USB microscope to get a few pictures of the edges as they came from the factory. The first one shows a tab of fiberglass that didn’t get trimmed or cut, as well as a small copper tab inside the via. These get folded over into the castellation in just about every hole.

And some are larger than others.

After cleaning up one of them with a pocket knife, the result is pretty good, even with no grinding or sanding yet.

Overall I’m really pleased with how these boards came out from the factory. Here’s the underside. You can see a bit of tab as well as lots more copper to clean up. Hopefully I’ll get a chance to assemble and test these boards in the next couple days.

The option ROM socket

In they early 1980s, computers were hard. They were, on the whole, large, expensive, clunky, and difficult to operate. Graphical user interfaces were not yet a thing, and manufacturers really didn’t have a good handle on how to make computers easy to use and understand yet.

Tandy’s general approach to marketing computers had been to leverage their massive network of Radio Shack stores as both sales channel and service/support facilities. The pitch was simple: If you ever have any problems with your Tandy/Radio Shack computer, bring it to your local store (they had thousands, so a large portion of the U.S. population was easy driving distance to one), and a friendly technician would help you with it. Sure, this kind of support load would be a losing proposition today, but back when making computer hardware was actually profitable, companies viewed support as essential to making the hardware sale.

One of the ways that its designers tried to simplify the Model 100 family, was by shipping all software in the form of ROM modules. This had a couple of clear advantages over other systems of the time:

  • Software loaded instantly
  • No disks to lose or fail
  • Copy protection

But it had one fairly big drawback: The user had to actually install hardware to install software. Clearly, this would have been intimidating to a lot of potential users, so Tandy attacked this problem in two ways. First, software that you bought from Radio Shack would be installed by the sales tech at no charge. And, second, the machine used a special snap-in module socket instead of a chip with pins. This allowed the module to be installed without risk of bending or breaking the fragile pins on a traditional ROM IC.

This module socket is the Molex 50-39-5288. Like everything in this project, it’s obsolete and not manufactured anymore.

Of course, these special modules didn’t share the normal JEDEC pinout of the common DIP-28 IC ROMs, oh, no. There were a couple of key differences, just to shake things up, I guess. But the only thing I care about at this stage is power and ground, and they’re still located in the usual places. So, if I can get my hands on one of these Molex sockets, I can easily supply 5 volts to the REX while flashing the CPLD. I powered the first 2 boards in the Tandy itself while flashing, and that’s a bit clunky and slightly nerve-wracking. This will be better.

Again, a kind member on the M100 list had a good stash of these sockets and sold me a few really cheap (thanks Brian!) so all I need to do is wire power and ground to it as indicated above and Bob’s my uncle! Luckily, USB is a cheap and easy 5 volt source and I have a ton of cables lying around ready to be hacked.

 

The community

By far, the biggest and most important part of being a vintage computer enthusiast is the joy of being part of a community of other vintage/retro computer enthusiasts. Despite being what feels like a relatively obscure hobby, there are many hundreds of other old computer geeks that cluster around web sites, forums, social media, podcasts, and computer shows.

One of (if not the) biggest communities of Tandy 100 enthusiasts is the M100 mailing list, hosted at bitchin100.com. In order to gauge possible interest in a new run of REXes, I set up a Google form with a basic “sign-up” sheet. Less than a week after posting this form to the mailing list with a quick explanation of my goal, I had interests in over 60 REX units!

I allowed respondents to enter the number of units they were interested in. The majority just wanted a single unit, but clearly there are some who need a REX for a larger fleet, or maybe just wanted a spare. I should have probably restricted the number of requests in an effort to make sure that people only request enough for their own personal use and not for re-selling. When I open up an actual (pre)order I’ll have to remember to do that.

So, clearly there’s still a big interest. This is part of what’s driving me to want to actually do a production run. I’m going to take it as an omen that I saw this quote on Twitter recently: