Subject: Q: Complete list of GROM/ROM Sizes

From: Jon Guidry <[email-masked]>
Date: Sat, 20 Feb 2010 08:25:21 -0600

Does anyone have a complete list of every single cart, and the sizes/number of GROMs/ROMs used in each?

This is why I'm asking... the sizes between the different emulators don't match up:

PC99: 
-rwxrwx---@ 1 Jon  staff   6150 Apr 23  1994 PHM3034.GRM
MESS RPK:
-r-xr-xr-x@ 1 Jon  wheel    8192 Dec 13  2006 phm3034g.bin

6,144 byte GROM = 8,192 byte GROM?  (Extra padding?)

PC99: 
-rwxrwx---@ 1 Jon  staff   8198 Apr 24  1994 PHM3035.GRM
-rwxrwx---@ 1 Jon  staff   6150 Apr 24  1994 PHM30351.GRM
-rwxrwx---@ 1 Jon  staff   6150 Apr 24  1994 PHM30352.GRM
-rwxrwx---@ 1 Jon  staff   6150 Apr 24  1994 PHM30353.GRM
-rwxrwx---@ 1 Jon  staff   6150 Apr 24  1994 PHM30354.GRM
MESS RPK:
-r-xr-xr-x@ 1 Jon  wheel    8192 Dec 13  2006 phm3035c.bin
-r-xr-xr-x@ 1 Jon  wheel   40960 Dec 13  2006 phm3035g.bin

Even if they're padding the four GROM files to 8K, shouldn't the phm30356G file for MESS only be 32K, not 40K?

PC99: 
-rwxrwx---@ 1 Jon  staff   6150 Apr 23  1994 PHM3036.GRM
MESS RPK:
-r-xr-xr-x@ 1 Jon  wheel   40960 Dec 13  2006 phm3036g.bin

I can't even begin to explain this one....

PC99: 
-rwxrwx---@ 1 Jon  staff   6150 Apr 23  1994 PHM3037.GRM
MESS RPK:
-r-xr-xr-x@ 1 Jon  wheel    8192 Dec 13  2006 phm3037c.bin
-r-xr-xr-x@ 1 Jon  wheel   40960 Dec 13  2006 phm3037g.bin

The same here.  Where did the extra ROM file come from, and why is the GROM file so large?

PC99: 
-rwxrwx---@ 1 Jon  staff   6150 Apr 23  1994 PHM3038.GRM
MESS RPK:
-r-xr-xr-x@ 1 Jon  wheel   16384 Dec 13  2006 phm3038g.bin

OK, this is only double the size (including "padding").

PC99: 
-rwxrwx---@ 1 Jon  staff   6150 Apr 23  1994 PHM3039.GRM
MESS RPK:
-r-xr-xr-x@ 1 Jon  wheel   40960 Dec 13  2006 phm3039g.bin

Another huge large one that shouldn't be that large...

PC99: 
-rwxrwx---@ 1 Jon  staff   6150 Dec 23  1994 PHM3040.GRM
-rwxrwx---@ 1 Jon  staff   6150 Dec 23  1994 PHM30401.GRM
-rwxrwx---@ 1 Jon  staff   6150 Dec 23  1994 PHM30402.GRM
-rwxrwx---@ 1 Jon  staff   6150 Dec 23  1994 PHM30403.GRM
MESS RPK:
-r-xr-xr-x@ 1 Jon  wheel   32768 Dec 13  2006 phm3040g.bin
 
This one is actually correct.

Thoughts?  If I have to make a database, I'll do one... (I'd like one for quick reference), but if one already exists, why do the work? :-)

Thanks!!
Jon

---

From: "kabldb" <[email-masked]>
Date: Sat, 20 Feb 2010 14:55:20 -0000

/quote
PC99:

/unquote

Yes, extra padding. My experiments with GROM and MESS shows that it will accept and work with both lengths.

/quote
PC99:

Even if they're padding the four GROM files to 8K, shouldn't the phm30356G file
for MESS only be 32K, not 40K?
/unquote

You're listing only GROMs there (GRM) and there's 5.
5 times 8 = 40. A size of 38 (leaving out the last padding) would work too with MESS.

:-)

---

From: "kabldb" <[email-masked]>
Date: Sat, 20 Feb 2010 15:06:42 -0000

/quote
PC99:

That's Zero-Zap. I guess someone was lazy and just copied all 5 banks with the "if it works, don't touch it" attitude !? 

:-)

---

From: Owen Brand <[email-masked]>
Date: Sat, 20 Feb 2010 10:17:19 -0500

I tend to have that attitude often times with my game coding.  :). If  
it works, leave it the heck alone!  :). Sorry, Jon. Didn't mean to  
hijack your thread.  :)

Owen Brand
Opry99er.com

On Feb 20, 2010, at 10:06 AM, "kabldb" <[email-masked]> wrote:

> That's Zero-Zap. I guess someone was lazy and just copied all 5  
> banks with the "if it works, don't touch it" attitude !?
>
> :-)
>
> > Even if they're padding the four GROM files to 8K, shouldn't the  
> phm30356G file for MESS only be 32K, not 40K?
> >
> >
> > PC99:
> > Thoughts? If I have to make a database, I'll do one... (I'd like  
> one for quick reference), but if one already exists, why do the  
> work? :-)
> >
> > Thanks!!
> > Jon
> >
>
>

---

From: "Michael Zapf" <[email-masked]>
Date: Sat, 20 Feb 2010 21:11:54 -0000

Hello Jon,

in general, MESS stores the GROMs in a single byte array; therefore, dumps should always have a multiple of 8 KiB length - how else should one map the GROM address to an offset in the byte array? It is acceptable to truncate the last GROM to 6 KiB, so you should have sizes like

6144
n*8192
(n-1)*8192 + 6144

The 8 KiB dumps are produced by reading 8 KiB from a GROM; the last 2 KiB may be a mirror of previous locations, but I also read something about a strange combination of prior values, so that could also be the case.

The maximum file size for GROMs is 40 KiB, since you have 3 GROMs in the console (24 KiB). If you find cartridges with 40 KiB GROM, the complete GROM space was dumped, probably too much, which is also called "overdump" and considered to be redone.

> The same here.  Where did the extra ROM file come from, and why is the GROM file so large?

As above. Obviously overdumped. As for the ROM file, the same. 

> OK, this is only double the size (including "padding").

Overdump. There was no second GROM, probably.

> Another huge large one that shouldn't be that large...

See above.

> This one is actually correct.

Yes, 4 GROMs with 8 KiB dumped each.

It is actually reasonable for MESS to stay with 8 KiB sizes, since there could be "advanced" GROMs or GROM simulators which make use of 8 KiB. Otherwise I would have to put in voodoo to find out the kind of GROM (6 or 8 KiB).

We could split the file to separate files as PC99 did, but there are so many dumps with multiple-8 KiB sizes that I don't see much sense in that. Moreover, I think the dumpers also produced hash files which would be wasted if that was changed.

Michael

---

From: Tony Knerr <[email-masked]>
Date: Sat, 20 Feb 2010 17:50:30 -0500

Michael Zapf wrote:
>  
>
> <snip>
>
>
> It is actually reasonable for MESS to stay with 8 KiB sizes, since 
> there could be "advanced" GROMs or GROM simulators which make use of 8 
> KiB. Otherwise I would have to put in voodoo to find out the kind of 
> GROM (6 or 8 KiB).
>
> We could split the file to separate files as PC99 did, but there are 
> so many dumps with multiple-8 KiB sizes that I don't see much sense in 
> that. Moreover, I think the dumpers also produced hash files which 
> would be wasted if that was changed.
>
> Michael
>
There are "Groms" that use the last 2k of the 8k per grom.
An example is XB 2.5 (& 2.6 & 2.7). If you cut off the last
2k of the 40k, then CALL XXB won't work, since part of it
is stored in that last 2k.

I would suggest keeping the full 40k dumps unless you're sure
the last 2k isn't used.

Tony

---

From: "hexbus" <[email-masked]>
Date: Sun, 21 Feb 2010 02:05:41 -0000

No worries everyone - I don't want any changed standards.

However, here is a spreadsheet I just compiled.  I went by the PC99 ROMs, as I figure Mike Wright probably dumped them correctly.  I've noted which GROMs were dumped as >1800 and which ones were >2000.  There's also other ROMs that I have in this spreadsheet as well.  Please look at it everyone, and let me know there's any corrections, etc.  (I do have a couple missing.)

https://spreadsheets.google.com/ccc?key=0AmwB5QkfV7DbdEE5SmdDV09tdG1FNzJnUGNSOTdtbHc&hl=en

I do have questions, though, about these GROMs.  Are these native format GROMs that manufacturers released but never distributed?  How do I find the GROM bases out?

I'd love for someone like Bill Gaskill to give a history behind these...

Angler Dangler (Deco)
Astro Fighter (Deco)
Mission X (Data East)
Berlin (?)
Cannonball Blitz (?)
Nature's Way (?)
Super Disk Manager (99/4 UG)
U-Boat (German)
Cave Creatures (FW)
Lobster Bay (FW)
Lasso (TI)
Paddleball (TI)
Submarine Battle (TI)
River Rescue (Thorn Emi)
Submarine Commander (Thorn Emi)
Springer (Tigervision)

How did the below two get out as GROM format?  The sidecars were GROM AFAIK.
Espial (Tigervision)
Miner 2049er (Tigervision)

Jon

---

From: "hexbus" <[email-masked]>
Date: Sun, 21 Feb 2010 02:10:22 -0000

The sidecars were ROM, not GROM. :)