Jump to content
NHL'94 Forums

Quick Tech question


Recommended Posts

I'm no tech or code programmer myself but hopefully you can make better sense of what's posted in these links then I could Mikey.

http://atariage.com/forums/topic/183877-what-is-the-real-maximum-sega-genesis-can-address/

http://gendev.spritesmind.net/forum/viewforum.php?f=25&sid=c3993d16916a2b7414b59f14f1190b89

Edited by Fiddz
Link to comment
Share on other sites

There is a difference between megabyte and megabit: http://opensignal.com/knowledgebase/the-difference-between-megabyte-and-megabit.php

The original ROM (and most of other Genesis ROMs) is one megabyte but the code/game itself occupies less, have no idea how to figure out exact size but I am sure its possible with some ROM scanning utility.

Completely uncompressed size...its arguable, every game/rom uses different compressing routine and I doubt its possible to figure this out without asking the creator/owner of the code, imo it is not much more than the size of the ROM itself, the compression ratio of the code/text can be around 1:1 and the graphics ratio is higher but there is not much graphics compressed in the original ROM so the compressed:uncompressed NHL 94 rom size is more or less the same.

Edited by DominikJagr
Link to comment
Share on other sites

1 megabyte is 1024x1024 = 1,048,576 bytes.

A byte is 8 bits. A bit is a 0 or 1.

A byte can store 256 different values (which can be interpreted in many ways.. There are mappings from the numbers to text letters, digits, and other symbols, for example 65 if interpreted as text is the letter "A", 66 is "B"...).

The original ROM does pretty much use all 1 MB, although there is some space left at the end (where I added my checking and plus minus hacks) and the occasional gap in the middle of the ROM.

I have no idea about the uncompressed size though, or how many of the graphics are even compressed. I don't think the uncompressed graphics size is too important.

Wboy's 30 team uncompressed ROM easily fits in a 2MB ROM, and he added way more face pictures than were in the original game.

Link to comment
Share on other sites

Back in the day the co$t of production between a 1MB ROM inside a gaming cartridge vs a 2MB ROM was substantial. Kind of like buying 128GB vs 256GB embedded storage in your smart device of choice these days.

The original NHL94 would of probably been a little over the 1MB at best. That alone made it a no brainer that EA store most of all the graphics compressed in 3bpp linear format, and not the 4bpp linear format used by the original and more easily editable EA Hockey & NHL 92. 1 less bbp = 25% saving on all graphic bytes stored that way. The rest of the bytes (teams, rosters and the game engine) are not compressed.

When loaded into the memory during game play, the graphics are loaded uncompressed. That fact and understanding the header bytes for graphics is what allowed the editable rink versions of NHL93 and 94 to become a reality.

Edited by wboy
Link to comment
Share on other sites

I see it, too. Could be mass delusion, it happens sometimes.

For the images being stored in 3bpp (3 bit per pixel), is that actually considered compression? Seems more like an encoding choice, similar to recording audio at 11kHz instead of the standard 44 or 48kHz -- it's not compressed, it's just lower quality / less detailed. I always figured compressed meant there was some algorithm applied to the images to make them smaller, like a ZIP type of routine.

Link to comment
Share on other sites

Call it what you will, but it saved space and had no reduction in quality of the imagine being stored and then presented in game. A basic routine/algorithm that offered basic compression no?

Edited by wboy
Link to comment
Share on other sites

Hmm I'd say there was quality loss, because 3bpp limited you to just 7x7x7 = 343 valid colours, while 4bpp gives you more valid colours (not sure if it's 15x15x15 = 3375 or 16x16x16 = 4096). So I wouldn't say it's uncompressed when the game loads, but rather it's just up-converted to 4bpp -- colours were lost when the image was encoded to 3bpp but not restored when converting back to 4bpp. Basically like a BMP saved in 256 colours or 16 colours.

Edit 2: Looking into this more, it turns out 3bpp linear and 4bpp linear codecs basically correspond to the palette size (3bpp = 8 colours, vs 4bpp = 16 colours). It's just using a smaller palette, so you can't use as many colours in the image. Not to be confused with the palette format, "3bpp BGR" which is how the colours in the palette are specified.

Anyway, doesn't really matter. It's just that all this time I thought the compressed graphics were garbled in the ROM, with something like Run-Length Encoding :)

Edit 1: Ah, wikipedia has the method the game uses -- reduced colour space -- classified as lossy compression: http://en.wikipedia.org/wiki/Image_compression

Link to comment
Share on other sites

Good point, has been too many years and completely forgot 3bbp it was only it only had 8 color palette.

All I remember is back in day when I started to better understad the headers for images, I only then started to find the "hidden rink" graphic tiles etc, and from memory, they where flagged in the image header exactly like the player tiles (as in 03 for 3bbp & 00 for 4bbp as I assumed) forgetting that the rink tiles have a 16 color palette available to it.

As you have now highlighted the header byte simply flagged if the Run-Length Encoding was used (also why the occasional player card tiles where shared).

My way around that was exporting a Gens screenshot of the VDP(?) memory, cut out the tiles/sprites and then paste them into a new part of the ROM with with Tile Molester and create a header implying 4bpp.

Link to comment
Share on other sites

Oh yeah, I forgot that a few player cards had re-used tiles! I think you said in your player card tutorial that it probably actually used more bytes to store the tile indexes than if they'd simply stored the full images for each one and used a single index table?

But reusing the tiles is a compression type I'd say

Link to comment
Share on other sites

As for the original question!

SEGA GENESIS VERSION = 1,046,800 bytes (0.9983 MB)

There is a header that is 512 bytes. It contains the name of the game, etc.. but it's not actually code or data of the game.

The end of the ROM's data is at 0x0FFB10 (hex), which is 1,047,312.

I didn't find any particularly big/noticeable sections of unused ROM, so we can take those values as the start and end of the game and be pretty accurate.

So the game is 1,047,312 - 512 = 1,046,800 bytes (0.9983 MB)

As wboy said, the game is on a 1MB ROM (because going to 2MB would be more expensive), and they filled it almost 100%.

Had they been allowed to use a 2MB ROM, they probably would have had colour pictures for the players, like the SNES version. Although somehow they managed to do that in 1MB on the SNES.

SNES VERSION = 1,023,146 (0.9757 MB)

The SNES version is roughly

(end: 1,047,844) - (start: 512) - (other empty: 24186) = 1,023,146 (0.9757 MB)

The "other empty space" is chunks of unused space found throughout the ROM. The way SNES ROMs are organized lends them to spreading unused bytes throughout the ROM.

  • Like 1
Link to comment
Share on other sites

SNES has colour pictures but more graphic compression (ice logos, menu logos), has no banners graphics (its text only) and no animated glass-banging fan :lol: Colour pictures are maybe the reason for logos compression, damn it.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...