1

Programming / Re: Why would you do this? (SCD 68k)

« on: April 12, 2012, 11:52:03 am »

Yes, that block of code just reads a little-endian long from a0 to d7.

Out of curiosity, what game is this and what is the context?

2

ROM Hacking Discussion / Re: IDA Question: Special Handling of 68000 A-line opcodes

« on: May 02, 2011, 12:52:19 am »

Bah, figured it out: the list is at C:\Program Files\IDA\cfg\atrap.cfg; the file says what format it is in comments (hooray plain text config files!).

3

ROM Hacking Discussion / IDA Question: Special Handling of 68000 A-line opcodes

« on: April 14, 2011, 11:38:52 am »

Hi. I've been trying for a while now to at least begin to reverse-engineer a MD game that uses A-line opcodes, generally used on the 68000 for syscalls (the game in this case is Star Cruiser, though I might see more in the future — I've seen Twinkle Tale use F-line). The only issue is that IDA 5.5 loads some default syscalls (I believe classic Mac syscalls) unless it detects another binary type (such as Amiga, Palm Pilot, etc.) and will stop analyzing if it sees an invalid syscall opcode. Is there a way I can have IDA just not process A-line opcodes and leave them as word definitions while continuing code analysis? Thanks.

4

Newcomer's Board / Re: Question about compressed graphics

« on: March 25, 2011, 01:46:31 am »

I understand his second question (he wants to know if the savestate format is big endian or little endian), unfortunately the answer is a bit iffy. What emulator are you using to make the savestate?

(On a side note, if I was approaching this problem I would just disassemble Enchanted Castle...)

EDIT How are you determining the format for the level layouts — from the VRAM area or from the RAM area or from the ROM?

5

Newcomer's Board / Re: Question about compressed graphics

« on: March 24, 2011, 09:58:29 pm »

If a game has compressed and uncompressed graphics and instead of findind a way to decompress, I just repoint it to a location with uncompressed graphics in the same order, what will happen?

If the game isn't smart enough to detect literal data, it will simply crash and die shortly after.

Only in extreme cases — the least that could happen is bad data where the good data should be but nowhere else, with some data corruption being the median case due to the decompressor running longer finding that magic terminator. This all depends on the format of the compressed data and the algorithm used by the decompressor.

What do you intend to accomplish by this — figuring out how the compression works? Replacing graphics?

You'll need to hack the game to read the straight data - "break the compression's kneecaps", as Gideon Zhi once put it. It's not that hard; at worst, you'll have to replace the compression routine with a straight copy into the same RAM address.

The only problem with this method is that it'll break all decompression, not just the one you want to have happen. The only way is to locate where the particular data you want is decompressed and change the particular routine call to a copy.

6

Newcomer's Board / Re: Searching through ROM data

« on: March 24, 2011, 12:19:19 am »

Or just learn how the hardware works and use that knowledge to figure out how the game works using a disassembler to produce ASM like Ryusui said above.

Example — Mega Drive/Genesis ROMs are raw 68000 boot ROMs loaded at memory space $0, so the longword at $4 is the pointer to the entry point. Longword at $70 is the pointer to horizontal interrupt; $78 is pointer to vertical interrupt. At that point, all I really need to figure out how a game does what is a memory map and hardware documentation. I've done a lot of disassembling so at this point I have quite a bit of all these parts down...

7

ROM Hacking Discussion / Re: Something weird! Flashback and/or JVC X'Eye Related

« on: March 20, 2011, 12:48:43 pm »

This was discussed on the SpritesMind forum already, but I'll say it here too for those who are curious:

This is a 68000 exception (not Genesis-specific) that occurs when the CPU runs an opcode whose uppermost nibble is $F (%1111; these first nibbles are called "lines," hence LINE %1111 or F-line). The entire range of these opcodes are reserved by Motorola for future use (and indeed, some are used by later members of the 68000 family — for example, for coprocessor instructions (such as FPU instructions) and the 68040's move16 instruction). This usually happens for one of two reasons — either the program somehow jumped into data or there's something corrupting the bits the 68000 reads (bitrot? dirty connectors on the cart or hardware?).

Line 1010/A-Line is similar — the $Axxx range is reserved for system calls, and indeed some systems use them. I know the Japanese Mega Drive game Star Cruiser does — but since that's a port of a X68000 game, I'm thinking that's the case with the X68000 too?

8

Programming / Re: Can somebody make me a little tool for window or dos??

« on: March 10, 2011, 08:01:25 pm »

If you don't mind me asking: what exactly are you intending on doing with this?

9

Programming / Re: Can somebody make me a little tool for window or dos??

« on: March 09, 2011, 11:05:58 am »

For a splitter, I'm sure many hacking communities have had this tool, but here's the one the Sonic hacking scene uses; I've used it myself for Mega Drive/Genesis research. The general format of each line is "#split" followed by a tab (NOT SPACES) followed by three comma-separated fields. The first field is the start address as a C hex number. The second field is the end address (that is, the address of the first byte AFTER the data) as a C hex number. The third field is the output filename. You can also create directories with lines beginning "#dir" followed by a tab and then the directory name.

Here's an example, from the Sonic 2 disassembly on Sonic Retro's subversion:

Code: [Select]

/***********************Directories***************************/
#dir    art
#dir    art/palettes
#dir    art/nemesis
#dir    art/kosinski
#dir    art/uncompressed
#dir    mappings
#dir    mappings/16x16
#dir    mappings/128x128
...
/***********************Palettes***************************/
#split  0x001E5A,0x001E7A,art/palettes/Title Water.bin
#split  0x001E7A,0x001E9A,art/palettes/EHZ ARZ Water.bin
#split  0x001E9A,0x001F1A,art/palettes/Hill Top Lava.bin
#split  0x001F1A,0x001F2A,art/palettes/Wood Conveyor.bin
#split  0x001F2A,0x001F36,art/palettes/MTZ Cycle 1.bin
#split  0x001F36,0x001F42,art/palettes/MTZ Cycle 2.bin
#split  0x001F42,0x001F56,art/palettes/MTZ Cycle 3.bin
#split  0x001F56,0x001F66,art/palettes/HPZ Water Cycle.bin
#split  0x001F66,0x001F76,art/palettes/HPZ Underwater Cycle.bin
#split  0x001F76,0x001F86,art/palettes/OOZ Oil.bin
#split  0x001F86,0x001F8E,art/palettes/MCZ Lantern.bin
Usage is

Code: [Select]

splitrom.exe ROM.bin split_list.txt
For combining, if you just want to merge files together, most command-line copy or concatenate command:

Code: [Select]

(windows) copy /b file1+file2+file3 bigfile
(unix) cat file1 file2 file3 > bigFor padding with zeroes, if your assembler can import raw binaries (a directive like incbin or binclude), you should be able to use it...