Unlike most Midway/Atari N64 titles, only .z compression is used.  Others also use a flimsy LZO scheme.  There will be roughly three z archives prior to the ROMDisk header.

  ROM offsets are relative to the ROMDisk header offset, internally names $ROMDisk.
  To find this you could look for some of the initialization tables, roundabout 0x12E0 (PAL, others differ but close).  The entries have a descriptive string, ROM offset to data, size, TLB range it will be allocated to, etc.
 
  It can be found easiest by searching directly for this string:
  "-==ROMDISK Header - HERE I AM==-"
 
  That "header" is 0x30 long and reveals the location of the main ROM index.  That lists most (but not all) of the files in the game.
  0x0\t20\t"-==ROMDISK Header - HERE I AM==-"
  0x20\t4\tsize of index in bytes
  0x24\t4\tROM offset to index (relative to this header)
  0x28\t4\t# entries
  0x2C\t4\tRESERVED
 
The ROM index is formatted like so:
The first segment are pointers to resources.  Number of entries are given in ROMDisk header.
Following the pointers are the resource table entries they point at.
\t0x0\t4\tusually 20000000.  List continues to -1
\t0x4\t4\tcompressed size
\t0x8\t4\tdecompressed size
\t0xC\t4\tROM offset
\t0x10\t4\tcompressed file CRC
\t0x14\tvar\tfilename

+_+

  All Midway/Atari z archives are headerless without crc.  Set the options Z_BEST_COMPRESSION, DEFLATED, and -MAX_WBITS to make identical archives.  In particular, -wbits suppresses the header on read/write.

+_+

  Oh, and one incidental remark.  In case you were wondering why Nemu doesn't like this game, it has to do with it using the loadlinked/storelinked opcodes, mostly to atomicly update controller input.  If you alter those to simple loadword/storeword that should inhibit the errors.
  Also, in case you were wondering why Nemu doesn't like to display addresses, remember they used a weird TLB range.  Just type an 'E' at the beginning of the address.
 
-Zoinkity