Jump to content
  • entries
    36
  • comments
    32
  • views
    73,343

7800 Pac-man Construction Set- Viewing Graphics


jwierer

815 views

I don’t know much about 7800 graphics so I started reverse engineering them in Hack-o-Matic III and Tile 'M

 

So far this is what I’ve discovered. Jr. Pac-man has a couple banks of sprites starting at 0x0 and 0x6000 both of length 0xF00. Each sprite is read left to right and rows are separated by 0x100 (256) bytes. Each Pixel is 2 bits so the first 2 bytes represents the first row. The 2 bit value determines which color in the palette is used. (00 = color0, 01 = color 1, 10 = color 2, 11 = color 3). Here is how you would read the first sprite in the second bank of graphics.

 

Row 0 [0x6000 -0x6001]
Row 1 [0x6100 -0x6101]
Row 2 [0x6200 -0x6201]
Row 3 [0x6300 -0x6301]
Row 4 [0x6400 -0x6401]
Row 5 [0x6500 -0x6501]
Row 6 [0x6600 -0x6601]
Row 7 [0x6700 -0x6701]
Row 8 [0x6800 -0x6801]
Row 9 [0x6900 -0x6901]
Row 10 [0x6A00 -0x6A01]
Row 11 [0x6B00 -0x6B01]
Row 12 [0x6C00 -0x6C01]  - Always Blank
Row 13 [0x6D00 -0x6D01] - Always Blank
Row 14 [0x6E00 -0x6E01] - Always Blank
Row 15 [0x6F00 -0x6F01] - Always Blank

 

Since this will result in an image that is upside down it should be flipped for easy viewing.

blogentry-5778-1245162678_thumb.jpg

 

All the other games in the Pac-man series store sprite data differently. Data is also read left to right, with the exception that rows are sequential so you can read in a sequential set of 32 bytes. Colors work the same. The only problem with this is that graphics wrap so sometimes you need to edit 2 sprites to really edit the image.

 

Row 0 [0x6000 -0x6001]
Row 1 [0x6002 -0x6003]
Row 2 [0x6004 -0x6005]
Row 3 [0x6006 -0x6007]
Row 4 [0x6008 -0x6009]
Row 5 [0x600A -0x600B]
Row 6 [0x600C -0x600D]
Row 7 [0x600E -0x600F]
Row 8 [0x6010 -0x6011]
Row 9 [0x6012 -0x6013]
Row 10 [0x6014 -0x6015]
Row 11 [0x6016 -0x6017]
Row 12 [0x6018 -0x6019]  - Always Blank
Row 13 [0x601A -0x601B] - Always Blank
Row 14 [0x601C-0x601D] - Always Blank
Row 15 [0x601E -0x601F] - Always Blank

blogentry-5778-1245162519_thumb.jpg

3 Comments


Recommended Comments

Hey Jeff:

 

Looks cool :)

I apologize for not getting you the information sooner. Not only am I making carts for Jr., but I'm making Super & SI for GoodDealGames. Plus I have to learn Java to program the Blackberry (real fast). :ponder:

 

BTW, Super Pac-Man does graphics the same way as Jr. ;)

 

The graphics for PMC, however does them the same way as the original 7800 Ms. Pac-Man. As far as I know this is the only game that GCC stored the graphics this way. (It was a real pain figuring that out in the very beginning). It's done that way because the actual used graphics are held in RAM and are just copied from the ROM to save space.

 

I will get you the decode information for 320B (320A is the same as the way Jr. & Super Pac is set up, just with 1 'bit-per-pixel' instead of 2.)

160x4 is (as you may have guessed) 4 bits-per-pixel and 320B is just an *insane* way of holding graphic data. It's something like every odd bit is adjacent graphic data... and even is the other half... I'll try and look at it when I get home and get you an example.

 

Thanks - and great work!

Bob

Link to comment

I was wondering why the PMC graphics wouldn't be page separated - that's a characteristic of the way MARIA works.

 

Here's how to translate the sprite data to CLUT entries for the various graphics modes:

P2-P0 = palette bits from header
S7-S0 = sprite data from ROM

160A:  P2|P1|P0|S7|S6  P2|P1|P0|S5|S4  P2|P1|P0|S3|S2  P2|P1|P0|S1|S0
160B:  P2|S3|S2|S7|S6  P2|S3|S2|S7|S6
320A:  P2|P1|P0|S7|0   P2|P1|P0|S6|0   P2|P1|P0|S5|0   P2|P1|P0|S4|0   P2|P1|P0|S3|0   P2|P1|P0|S2|0   P2|P1|P0|S1|0   P2|P1|P0|S0|0
320B:  P2|0 |0 |S7|S3  P2|0 |0 |S6|S2  P2|0 |0 |S5|S1  P2|0 |0 |S4|S0
320C:  P2|S3|S2|S7|0   P2|S3|S2|S6|0   P2|S1|S0|S5|0   P2|S1|S0|S4|0
320D:  P2|0 |0 |S7|P1  P2|0 |0 |S6|P0  P2|0 |0 |S5|P1  P2|0 |0 |S4|P0  P2|0 |0 |S3|P1  P2|0 |0 |S2|P0  P2|0 |0 |S1|P1  P2|0 |0 |S0|P0

 

160A is 4 colors (well . . . 3+transparent/background) per pixel from 8 palettes, 160B is 12 colors per pixel from 2 palettes, 320A is 1 color+background/transparent from 8 palettes, 320B is 4 colors (different bit order than 160A) from 2 palettes. 320C and 320D are seriously warped as they mix the sprite and palette bits.

Link to comment

Here's another way of looking at it. MARIA has two internal 160x5 bit LineRAMs. The Write Mode bit controls how the palette & sprite bits are written to LineRAM. The Read Mode bits control how the LineRAM bits are changed into 320H pixels. (160H being two 320H pixels of the same color.)

 

write mode = palette+sprite bits to LineRAM entries:
WM=0:  P2|P1|P0|S7|S6  P2|P1|P0|S5|S4  P2|P1|P0|S3|S2  P2|P1|P0|S1|S0
WM=1:  P2|S3|S2|S7|S6  P2|S1|S0|S5|S4

read mode = LineRAM entries to CLUT indexes (pixels):
RM=00: X4|X3|X2|X1|X0  X4|X3|X2|X1|X0
RM=10: X4|0 |0 |X1|X3  X4|0 |0 |X0|X2
RM=11: X4|X3|X2|X1|0   X4|X3|X2|X0|0

 

(Note: there's an error in my previous entry for 160B. See WM=1 for the correct mapping.)

Link to comment
Guest
Add a comment...

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

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...