Self-inflicted Upgrades: Part I
All TEMPEST GRiDCase computers that I've seen share certain basic characteristics.
- No ISA bus.1
- The only expansion options were peripherals.2
- No "extra room" inside the case.3
So, without space for added hardware and no bus to which to connect it, these computers (at least the ones I've come across) had few boot options. It was either the floppy drive, external floppy drive, or the user-accessible4 ROM sockets above the keyboard.
Given that the drives in these machines were manufactured the same year Invisible Touch was released, it seemed prudent to get MS-DOS and some assorted programs onto EPROMs.
Fortunately, GRiD offered a program,
ROMBUILD.EXE, to facilitate that. One could select a number of files, (however many would fit onto the EPROMs to be burned), and it would create the Intel hex files needed. Conveniently, it would also send the files to a serial PROM programmer, if one had a "Sailor-8" hanging around.
This user-installed ROM functionality was available in both the Compass and GRiDCase models.
- The ROM sockets, of which there are four accessible to the user, are 28-pin DIL. While the sizes and order of the ROMs used may vary, the pin count of the sockets limits the capacity of any socket to 64KB, if it's an EPROM.
- However, if a masked ROM is used, such as those professionally produced and sold by GRiD, the capacity for any one socket increases to 128KB. (There are possible workarounds for this.)5
- Working within the limit of 64KB means that certain programs/files will not fit on a single EPROM.
ROMBUILD.EXEwill split these across multiple EPROMs.6
- If the ROMs being created will be used under MS-DOS, there's no RAM benefit. The program will still be "dragged" into RAM before being executed.7
There's really not that much to the operation. You choose how many ROMs will be burned and at what capacity, as well as the number of files to be included. There are fields to add names and part numbers and the option to mark the ROM(s) as bootable.
ROMBUILD.EXE will automatically increment the file extension if multiple files are being created.
The hex files generated are significantly larger than the eventual EPROM size. Had I more fully read the manual, I would have seen its warning that a 64KB EPROM will require a 157KB hex file while a 128KB ROM would require a 315KB file. In any case, one might want to run
ROMBUILD.EXE on a more fully equipped system than the one which will be receiving the finished EPROMs.
If the EPROMs need to be bootable, as in the case of MS-DOS 3.2, the program will present some options and warnings.
There are two systems available, as mentioned before, Compass and GRiDCase. If including the system files,
ROMBUILD.EXE will need to know where these reside. A benefit of running this program on a machine which already has the system files in ROM is that they will be automatically loaded.
The "Boot Prompt Key" setting allows different ROMs to contain bootable code. This means that if a program which contained its own operating system is in ROM (which must have been more prevalent in the age of floppy-based systems), it can be loaded by pressing the corresponding number key during startup.
Once the files have been added, (
ROMBUILD.EXE will keep cycling through the available files in the directory, asking if each should be added to the queue, until the maximum file count and/or capacity has been reached), the last step is to create the hex files.
With files on disk and label maker in hand, the EPROMs can be burned and dropped in sockets (They don't need to be in order, but it does look nicer).
I've read that aftermarket peripherals were available which would plug into the 8087 socket and use the data lines to directly access the CPU. After some searching, it seems these are rare as hen's teeth. ↩
Whether third-party or the collection of GRiD-branded devices like their oft-mentioned (in GRiD's technical documents) Pocket Floppy Drive. The collection of ports on the back the TEMPEST GRiDCase seems to be consistent from at least 1986 to 1991, which is to say that there were two types of serial port, a parallel port, and a GPIB port. ↩
The ad-hoc Faraday cage which surrounds the motherboard makes for a tight fit all around. ↩
To be clear, I'm not complaining. I mean, I've got a screwdriver, (heck, more than one), but the "slight case of over-engineering" with this computer is really exemplified by the metal shell which covers the ROM sockets. It is secured by pressure tabs running the length of the cavity, top and bottom, with screw holes on both ends. The tabs ensure good contact with the motherboard cage and the screws then ensure that it appears difficult to remove the cover. Once it's secured, it's flush with the rest of the body and allows the plastic cover above the keyboard to sit flat on top. Unfortunately, once the cover has been snapped into the pressure tabs, there doesn't seem to be any obvious way to remove it. Well, actually there is an obvious way, as evidenced by the damage I've seen on all but one of these metal covers: Stick a screwdriver (or two) into the screw holes, then bear down until you pry the thing off. Just as obvious is the fact that the metal cover was neither designed nor manufactured with this removal method in mind. (The one I've seen without damage had been reinforced with an extra layer of sheet metal over both screw holes). ↩
Such as wiring up an adapter to use a 32-pin EPROM in the 28-pin socket. ↩
I ran into this when working with the MS-DOS 3.2 system files, which the instruction manual helpfully points out are 66kb and ROMBUILD.EXE further clarifies, are 68377 bytes. ↩
GRiD-OS, on the other hand, allows "executable" ROMs, which effectively increase the available RAM as the programs are not "dragged" into RAM before execution. ↩