If anyone hasnt already got it yet, get my NGPC rom viewer at:
www.

Its fairly basic, runs slow etc etc, my first c++ prog, etc etc.

I've been looking at the Metal Slug cart, I've worked out the system
that the game uses for its maps.  

Not knowing how the hardware operates yet, and having a look at the
map data, it may be the case that the NGPC reads its mapdata (for the
background and forgroud planes) directly from the rom chip on the cart.
(And not the way the the gameboy does it - having VRAM)..  I maybe wrong,
this mapdata may be internal to the game program, not the NGPC
hardware..  But SNKs coin-op hardware I think runs by reading its tiles
and mapdata direct from rom, just using vram for sprites and palettes.

Anyway, this is what I found using my rom viewer (it also helped
owning a real NGPC + games):

Mission 0:
Graphics bank for this level are at $a69c6
Forground map at $a81c8, with a modulo of 180 bytes (used as 90 words)
Background map at $a9fe2, with a modulo of 100 bytes (used as 50 words)
Map data height is 20 lines for both.
Both maps use the same GFX bank.

Mission 1:
Graphics bank for this level are at $a9c2c
Forground map at $ab42e, with a modulo of 180 bytes
Background map at $ac248, with a modulo of 100 bytes? (unsure this one)
Map data height is 20 lines for both.
Both maps use the same GFX bank.

*******************
8*8 Tile Format:

The tiles are 8*8, but use a different encoding to the gameboys tiles,
Tile uses two bytes in chunky pixel format, not bitplane, each byte =
4 pixels:

1st byte bits: 76543210,  2nd byte bits: fedcba98

    | 10 32 54 76 | 98 ba dc fe |

Each 2 bits = colours 0 to 3
*******************
Graphics Bank data:

Bank size is 32 tiles wide, by 12 down.
This bank is basically a graphics picture, as a graphics artist would
design.
*******************
Map data:
This is the same for Forground & Back, but the map width changes
between the two.

The data is in a 2 byte format, there seems to be 9 bits for tile
number, 3 (or more for palette) and 1 for Horizontal flip.

It seems like the bytes are swapped in the word, eg 1st byte (even) is
the Low byte (8 bit tile number), 2nd byte in the mapdata (ODD) is the
high byte (attribute data).

In memory as: 76543210 fedcba98
   But I use: fedcba98 76543210
              HxxxPPPT TTTTTTTT

x=unknown (but I would suggest theres a V Flip in there somewhere)
H=Horiz Flip
P=Palette
T=9 bit Start Tile number

Now the actual maps when displayed use panels 16*16 pixels in size,
basically 4 tiles, but the map data doesn't contain the tile numbers
for each 4 tiles. Each mapdata word refers to the top left tile in
the block of four. 

tiles in each 16*16 panel: 00 01
                           32 33

- since the graphics bank is a picture with a width of 32 tiles.

The forground map uses 90 words for the width, 90 panels of 16*16
pixels. The background uses only 50 for width. The height seems to
be 20 lines for the both.

 Forground Mapdata size = 180 bytes * 20 lines = 3600 bytes
Background Mapdata size = 100 bytes * 20 lines = 2000 bytes

These are unstandard sizes for maps, Usually 64, 128, or 256
are used (binary limits), so If the hardware is outputting this
data directly to screen, then the hardware must have some form
of modulo control for variable width maps, (back to Amiga days)
but thats just a guess so far.


I have added code to my RovViewer to show this mapdata, but it needs
work on it to make it for public use.


What I would like to do now is to disassemble the code to this game,
and check the references to these memory addresses, to see how this
data is used.

*SJ*