The Builder of ROMs

Self-inflicted Upgrades: Part I

All TEMPEST GRiDCase computers that I've seen share certain basic characteristics.

  • Floppy-based.
  • No ISA bus.[1]
  • The only expansion options were peripherals.[1:1]
  • No "extra room" inside the case.[1:2]

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-accessible[1:3] 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.

Some caveats:

  • 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.)[1:4]
  • Working within the limit of 64KB means that certain programs/files will not fit on a single EPROM. ROMBUILD.EXE will split these across multiple EPROMs.[1:5]
  • 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.[1:6]


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

  1. 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. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎