grom960 ROM Image Generator

grom960 extracts the text (executable code) and data sections from one or more object files, places them in specified locations in a binary image, and converts the binary image into one or more files in Intel hex format. The resulting files can be downloaded to a PROM programming device. grom960 also provides options that allow bytes from the binary image to be interleaved into multiple banks of PROMs.

The invocation command is:

grom960 [ -option ]... section_spec...

Each option must be preceded by a - character. (On DOS, you can also use a / character.) The options are listed below.

A section_spec specifies the placement of a text or data section into the binary image. Multiple specifications are allowed; they are processed in the order encountered. There are four types, listed below.

Section Specifications

• filename[,addr]
  Places the text section of the specified file at address addr, relative to the start of the image, and places the data section immediately following the text section.
• Bfilename[,addr]
  Also places both the text and data sections of the specified file at address addr, relative to the start of the image. However, the order of the text and data sections will be the same as in the input file (i.e., the one linked at the lower address will come first); and any gap between the sections will be preserved in the output image.
• Dfilename[,addr]
  Places the data section of the specified file at address addr.
• Tfilename[,addr]
  Places the text section of the specified file at address addr.

The addr argument is always optional. An omitted address causes the specified section(s) to be placed immediately after the one in the preceding specification (or at address 0 in the binary image, in the case of the first section specification).

Options

Numeric arguments are interpreted as decimal, unless preceded by 0x (hex).

• 20
  If the ROM is more than 64K long, generates extended address records in 20-bit format (e.g., as used by the 8086). The default is to generate 32-bit format records. This option is included primarily for compatibility with old ROM burner software that does not understand 32-bit format.
• An
  Sets checksum storage address to n. Default = 0x10000.
• bn
  Generates images for n banks of ROMs. Default = 1.
• c { 16 | 32 }
  Generates a 16-bit or 32-bit checksum.
• En
  Sets checksum end address to n. Default = 0xffff.
• f
  Dumps full image and does not skip all ones records.
• h
  Gives a help message and quits.
• i
  Suppresses generating hex output files. Instead, dump the raw binary image to output file image.
• ln
  Generates images for ROMs that are n bytes long. The default is 0x10000 (64K).
• m
  Writes a map of the binary image to stdout.
• oname
  Specifies the base name of the output file(s). If the i option is used, the output file name will contain the binary image. (Default filename is image.) If the i option is not used, a series of files name namexy.hex will contain the hex ROM images. (Default is a series of files named romxy.hex.)
• Sn
  Set checksum start address to n. Default is 0x0.
• V
  Print version and continue.
• v
  Produces a map, as with the m option, and summarizes the ROM configuration settings.
• v960
  Writes grom960 version information to stdout and quits.
• wn
  Generates ROMs that are n bytes "wide". (Default is 1.) n bytes at a time are written from the binary image to each bank of ROM, before moving on to the next ROM bank. The combination of the b and w options controls interleaving of ROMs.

Using grom960

Generating ROM images is a two-step process: creation of a binary image, and conversion of the image to ROM image (Intel hex) files.

Generating Binary Images

Regardless of the addresses where the code was linked, all bytes in a ROM image appear in a contiguous address space relative to the ROMs' base address. For instance, a 64K ROM based at address 0xffff0000 has a ROM address space of [0,0xffff], byte 0 of the ROM being the byte which will be addressed at 0xffff0000 at run time.

The binary image is generated by extracting the text and data sections of the input files and placing them at the specified locations in the ROM address space. Unused address space bytes are initialized to 0xff, the value of a byte in an erased PROM.

Hex File Generation

After a single binary image has been created, it is interleaved according to the ROM width and the number of banks requested. If the width is w, and the number of banks is b, the first w bytes in the image are written to the first bank of ROMs, then the second w bytes are written to the second bank, and so on. After bth bank has been written, output resumes at the first bank. For example, if the number of banks is four, the ROM width is two, and the first sixteen bytes of the image are:

0x00112233445566778899aabbccddeeff

then the four banks would begin with the following values:

bank 0: 0x00118899...

bank 1: 0x2233aabb...

bank 2: 0x4455ccdd...

bank 3: 0x6677eeff...

Each bank corresponds to at least one ROM. Every time the amount of data written to a bank exceeds the specified ROM length, a new ROM image file is started.

Each output file is in Intel hex format and corresponds to a single ROM device. The output files are named basenamexy.hex, where y is the bank number and x is the sequence number within the bank. Both x and y are numbered from 0. For example, if the number of banks is four, the ROM length is 64 K, and the total image size is 512K, then the following hex files would be output:

bank 0: rom00.hex, rom10.hex

bank 1: rom01.hex, rom11.hex

bank 2: rom02.hex, rom12.hex

bank 3: rom 03.hex, rom13.hex.

Return to the top of this page.

Go to the ic960 Interface Index.

Go to the gcc960 Interface Index.