Hacking the SMC file

[mnorton8bit]

Forgive me if this question has already been beaten to death on this forum. I tried searching the forum for SMC file parsing information.
Does such information exist?

I am writing a python program on my raspberry pi to open and examine SMC files. I have a hex dump working but I have no clue what it is I am looking at in this dump.
Can someone point me in the right direction of technical docs or code?

Thank you

Mike

[koitsu]

http://wiki.superfamicom.org/snes/show/Super+Wild+Card in section "File Header". The extension abbreviation comes from the name of the original Super Magicom copier; the Super Wild Card uses the same file format.

Depending on what information you want, you're probably going to want to read the actual ROM header ("Cartridge Header") information (where that lies in the file, offset-wise, depends on ROM size and several other factors, but it's mapped to $FFB0-FFDF in actual memory space (bank $00 in all modes, except mode 25, where it's in bank $40). Those bytes are documented fully/completely per official documentation.

P.S. -- Tepples, could you please move this to the SNESdev section; has nothing to do with NES/Famicom.

[tepples]

Here's what I gathered from that wiki page:

0x0000-0x0001 (16 bits little endian): Size of image in 8192-byte units
0x0002: Emulation mode
0x0008: Constant 0xAA
0x0009: Constant 0xBB
0x000A: 0x04 for ROM, 0x05 for WRAM
All other bytes are constant 0x00

Code: Select all

7654 3210  Emulation mode bit meanings
|||| |||+- 1: Enable cartridge at banks $20-$5F and $A0-$DF during play
|||| ||+-- 0: run in "mode 3"; 1: run in "mode 2" (JMP Reset)
|||| ++--- WRAM size. 0: none; 1: 16 Kbit; 2: 64 Kbit; 3: 256 Kbit
|||+------ ROM uses A15. 0: LoROM (mode $20/$30); 1: HiROM (mode $21/$31)
||+------- WRAM mapping. 0: $7x8000-$7xFFFF; 1: $3x6000-$3x7FFF
||         (Usually matches Hi/LoROM bit)
|+-------- 0: Single or last file of the split game; 1: more files follow
+--------- 0: normal; 1: run in "mode 1" (JMP $8000)

A tool for adding the copier header can fill out bits 5 (WRAM mapping), 4 (ROM mapping), and 3-2 (WRAM size) from the internal header, and bit 6 is 0 unless you're actually using multiple floppies. But I'm so sure about what bits 7, 1, and 0 are meant for. Perhaps 0 is meant for ROM hacks that use assets from the original game?

[Revenant]

A tool for adding the copier header can fill out bits 5 (WRAM mapping), 4 (ROM mapping), and 3-2 (WRAM size) from the internal header, and bit 6 is 0 unless you're actually using multiple floppies. But I'm so sure about what bits 7, 1, and 0 are meant for. Perhaps 0 is meant for ROM hacks that use assets from the original game?

Bits 7 and 1 are for the memory mapping modes described in this section. The bit 0 setting is described as being for modes 2 and 3 only, but the actual function is not really clear (perhaps it maps certain banks to an actual cartridge inserted in the unit instead of the image loaded from disk? The way the documentation uses the words "cartridge" and "DRAM" to describe memory mapping gives me that impression, anyway)

[koitsu]

Bits 7 and 1 are intended for behavioural definition within the Super Magicom / Super Wildcard itself. The use of the word "mode" refers to actual behavioural modes of the SWC copier, not SNES graphical modes or memory modes/models.

In other words: what Revenant says is pretty much spot on.

As for code, you can go try to reverse-engineer the UCON64 source code.

What you haven't stated is really what you're overall goal is with regards to the header and/or format. "Examine SMC files" doesn't really give anyone any information (and before your edit, you said something about using a Raspberry Pi, so it's hard to determine what exactly you're up to). Knowing what you're trying to do may help us point you in the right direction of how to go about accomplishing your goal and/or caveats/complexities you may encounter on the way (and how to avoid/solve those).

If you're trying to do an emulator, this is pretty simple: if the file is an SMC file (use the identifier bits in the header to detect that, possibly combined with use of .SMC or .SWC extension -- but for multi-file SMC images, yeah, you'd need to parse/understand the header), you can simply ignore the first 512 bytes (SMC header). The rest is a standard ROM dump. You don't need the SMC header to do proper emulation -- you can safely lseek() past the header and go from there.