Dungeon Master Forum

recently, i started to retry to extract the images from snes version.
currently, new images seem to be exposed: inventory icon images, hero portraits.

a problem. more than one palette are used in a large image.
a image has many icons. each has separate palette... it is unexpected trap in myself. i'm almost giving up because i was sure that the goal was very near.

http://homepage3.nifty.com/kkdf/snes.ne ... .0913..rar

Inv0, 1, 2, 3, 4.bmp --- item icon images
New480.bmp --- hero portraits
palette.bmp --- known 34 sets of 4-bpp palette.



snes version has 2 pixel formats. 4 bit packed pixel forrmat, and 4 bit bit-plane format.

packed pixel forrmat is very familiar to recent hardware. so it is easily expected in unknown image format.


but their new exposed ones were in bit-plane format.

i knew about snes specific bit-plane format, when i was researching DSP2 chip information.

convert from packed pixel to bit-plane format. why?
atari st hardware uses packed pixel format. (IMHO)
snes hardware uses bit-plane format.

BUT in snes version, packed pixel is still used to render viewport. Command 01H in DSP2 chip converts packed pixel viewport image to bit-plane format.

which part? conversion process is required?
if you render any images to viewport. e.g. creature images, chests, weapons, and so on...

if you have no reason to render some images into viewport, they are just stored in ROM as bit-plane format.


how to know the way of extraction from snes DM graphics?

i selected very ordinal way.
i tried zsnes. it is a open sourced snes emulator. you can modify the zsnes's behavior by editing its source code. this is one of my answer.
if i talk everything about "how to ..." it tooks very long time. i'll enumerate main points.

1. know snes's CPU type (65C816).
check the sites to know snes hardware spec, capacity.

2. study the 65C816's assembler.
in many situations, you'll guess the "result" or respective "cause" from unreadable disassembled source code.

3. study the memory mapping of snes.
65C816 has 16MB address space. in the large space, ROM, RAM and other peripherals(devices) are mapped into the address space.

4. code disassembler, and get disassembled source code.
anyway i wanted disassembled source code.
i made my private version to generate disassembled source code.

5. perform "corruption"!
i think there are 2 ways to grab the images from ROM.
A) corrupt the ROM partially, and watch the difference by running emulator with corrupted ROM. if image is broken, it is sure that you "hit" the compressed/uncompressed image data in ROM.
B) hack with disassembled soure code

usually i tried A). and it benefitted me and us.
however i couldn't know what i need about snes version. so i tried B) with zsnes.

6. add the breakpoint. if "hit", then try more breakpoints.
if image is compressed, there must be decompression program in ROM.
i succeeded to locate the decompressor by adding breakpoint (breakpoint against read memory from ROM).
then, read the disassembled source code around decompressor.

7. know about image palette.
if snes program is willing to do something, it tends to write a byte/word value to memory.
nothing occurrs if ROM program doesn't write to memory.

it is same against palette.
ROM program writes color information to memory (palette memory part is called as CG-RAM).

what's important? it is memory address. i wrote many devices are mapped into 16MB address space.
if you write a value to memory, a device will perform something.
e.g. if you write a value to CG-RAM, colors in your zsnes console image will be altered.

i located the memory addresses ($00:2121 and $00:2122).
then, i added breakpoint to locate the "palette initialization routine".
or you can use disassembled source code to locate the routine. it is very eaasy to find the string "2121" or "2122" with teext editor.

8. write extraction tool.
if you know what to do, it is much easier to write extraction tool. at least, it is easier than hacking ROM program.

it is all what i have performed to create grabsnesdm and dm_snes_pcat_exchange tools.

thanks.

A friend and me have been working on extracting data from the SNES ROM for months. We have worked on both the US and JP versions, but mostly on the US version recently.
Our work was of course based on your own extraction tools. Thank you again for this foundation work on the SNES version.

My friend has developed an extraction tool that works with extended .map files. A new .map file format was required to accomodate the various needs that we had.

Some facts about SNES graphics:
There are two types of images: backgrounds and sprites.
Both are made of tiles. A tile is a small image of 8x8 pixels. By assembling several tiles together, you create full images and sprites.
The color palette on the SNES contains 16 palettes of 16 colors each.
Each tile can specify which palette to use. The first 8 palettes can be used by backgrounds, the last 8 palettes can be used by sprites.
A background image is defined by a tilemap. A tilemap is a structure defining the list of tiles to use to create an image and the palette to use for each tile.
So, to render a background image, you need a color palette, a tileset (a set of individual tiles) and a tilemap.
A sprite image is defined by a spritemap. A spritemap defines the list of tiles that make each sprite (the SNES can manage up to 128 sprites) and the palette to use for each tile.
To render sprites, you need a palette, a tile set, and a spritemap.

Currently, our tool can extract:
- All the color palettes used in the game
- All the "usual" DM images (everything that appears in the dungeon view: walls, creatures, etc...). These images are not stored as tiles, they are converted to tiles for display, as you explained.
- All the tilesets available for other ingame images (introduction, end of game, game over, the dungeon entrance, portraits, items, maps, fonts, user interface parts, etc...)
- Most tilemaps and spritemaps (several formats are used in the ROM)
- A lot of information from the equivalent of item 558 in Atari ST version (and other). This item contains the size of lots of images, useful for decoding.
- All the text strings (item names, champion names, messages, etc...)
- The dungeon.dat file
- All champion statistics
- All sound samples


We still have some work to do and we hope we can join our efforts to decode what remains to be decoded without doing duplicate work. I will send you a pre-version of the tool so you can see for yourself what has been done.