How Do You Deal With"Collection" Games?

[Dybbles]

Hi all. I dove back into Sonic Classic Collection, so I could fix all of my old bad codes and make new ones as well.
And I came across something I haven't come across before.

Every time I place a breakpoint for any Sonic game on any address, the debugger always snaps here:



The address is small, but I'll tell you the address. it's : 0202F3DC/E12FFF1E

It snaps at this address no matter what, for everything.
Has anyone ever come across this problem; and if so, how I do I overcome it and find the right address?

[Pyriel]

I think you confirmed before that this collection is running through an emulation framework. You're going to have to learn to deal with the fact that memory access is probably a layer in the framework. You're not going to be able to access game routines in the manner you're accustomed to because they all exist as machine code for a Motorola 68K target (or worse some sort of recompiled, object code that resembles nothing). They're being emulated on whatever system this collection is for (DS?), and that means the only machine instructions your debugger can detect reading from or writing to that address will the handful of instructions in the routines for memory access operations.

This is why I dislike commercial releases that run through emulation (aside from being a really cheap way to monetize old properties as if they're ports). In order to properly hack this thing, you need to be able to deal with both the Nintendo system it runs on now and the Sega system it ran on in ancient days.

[Dybbles]

So long story short, I need to know Arm and Thumb assembly, (DS) and 68000 assembly (Genesis)?

I was reading up on this game more and found this: Taken from: http://info.sonicretro.org/Sonic_Cla...tion#Emulation

Emulation Bug

The jEnesisDS emulator incorrectly emulates $Axxx and $Fxxx instructions as if they were $6xxx instructions. The $Axxx opcodes were typically used to implement system calls on 68000-based computers, and the $Fxxx opcodes were used for floating-point coprocessors. Since the Genesis doesn't run an operating system or have a floating-point unit, these opcodes are typically unused. (These opcodes trigger the Line 1010 and Line 1111 emulator traps in the Motorola 68000 CPU. If you've ever seen the "LINE 1010 EMULATOR" or "LINE 1111 EMULATOR" error in Sonic the Hedgehog or other games, that means one of these opcodes was executed, and the game doesn't have any function to handle it.)

For whatever reason, when jEnesisDS encounters an $Axxx or $Fxxx opcode, it handles it as if it's $6xxx. The 6-line opcodes are used as conditional branches; that is, if a certain condition is met, the CPU will branch to another part of the program. The Sonic Classic Collection developers decided to randomly change all of the $6xxx opcodes in the games to $Axxx or $Fxxx, resulting in a ROM image that functions normally on jEnesisDS, but breaks horribly on all other emulators.

In order to fix this bug, the $Axxx and $Fxxx opcodes need to be changed back to $6xxx in the ROM images, or an emulator needs to be hacked to handle these opcodes as if they were $6xxx opcodes. (Doing the latter option may break some obscure ROMs that depend on the A-line and F-line emulator traps.)

Is this bug going to be a big issue when trying to hack this game as well?

[Pyriel]

So long story short, I need to know Arm and Thumb assembly, (DS) and 68000 assembly (Genesis)?

Yep. That's about the size of it if you want to do more than poke data like the value of rings somewhere in memory, anyway.

Is this bug going to be a big issue when trying to hack this game as well?

I don't really know. Just instinctively I'd say no. It sounds like the issue is that otherwise useless op codes were used as a timer or to quickly coax the Genesis into some desirable state or something, rather than being used for their intended purposes. I'd hazard a guess that the occurrences of it are rare, and the operations probably won't appear in anything you're interested in.

[Dybbles]

Alright. it's abput time I started hacking the Genesis to, lol. Never even hacked a single Genesis code in my 4 years of hacking lol. Now's a good time to start I guess. Thanks, Pyriel!

[Helder]

There almost no ASM codes for this game for this reason which is why you see RAM codes with conditionals which indicate which game is loaded since they just about share the same RAM and can sometimes crash the game if certain codes are used. Stick with RAM codes since they're pretty much static. The only ASM code which I thought of doing but didn't have the ASM skills at the time was the press start to pause code which Normatt ended up making.

[Dybbles]

Ok then. I guess I'll stick with those.
I should learn how to use conditionals, I never use them, but I think it's time i started.
Actually, there is a legit way to pause them game, using the start button like you would on a Genesis.

At the end of Sonic 1, where, Sonic is releasing all of the animals on a part of Green HIll Zone, you can press the start button to pause the game normally. SEGA must have forgotten to take this out. Demonic and I tried to hack a code to use it, but neither of us could get it to work.

It only pauses the game, it doesn't unpause it. It worked for every game in the Collection too.

[Demonic722]

Demonic and I tried to hack a code to use it, but neither of us could get it to work.

It only pauses the game, it doesn't unpause it. It worked for every game in the Collection too.

I forgot that I attempted to hack that (it must have been briefly). I might take another look at it sometime.

[Dybbles]

It's ok, Demonic.
Anyway, back on topic. Do all Collection games work like this? Or is this game a special case?
I remember hacking Zelda Collector's Edition for the Gamecube and having a hell of a time hacking asm codes for that as well.
That Collection uses pointers out the ass, and literally everything slightly advanced requires them.

I took a look at the N64 versions of those games, and it's the same deal. Pointers out of the ass.
But wouldn't you think that an asm code would work anywhere?
I tried making asm codes for both Gamecube and N4 versions for some codes, but they only work in one area.

[Pyriel]

I'd have to say that nowadays most Collections titles will work like this. It's far easier and cheaper to license and modify an emulation framework than it is to fully port all the games.

As I recall, those Zelda games were fairly hefty for N64 titles, so they probably pushed beyond what most titles did in terms of memory and ROM bank management.

[lee4]

collection games titles always have emulator

doing breakpoint will snap to emulator data

close ASM code you get for these two games are my RAM and ROM pointer code

[travelsonic]

collection games titles always have emulator

* almost always, Sonic Jam for the Saturn being (one of?) the lone exception(s?) where they actually ported the games over to that platform (and added some changes too ).

[lee4]

nope, sonic jam also using an emulator with modified roms

[travelsonic]

nope, sonic jam also using an emulator with modified roms

Incorrect. 110% incorrect. The games were not emulated at all in that particular compilation. Are you sure you're not thinking of the Mega Collection for the XBOX, Gamecube, etc?

[Skiller]

the thing is when u get the ASM Spot of the emulator.. you can make a subroutine there. iv done this in the past Since the way the emulator works is in that section of code. its Reading Starting point of game then offsets to place your value to and this offset is normally same to that of old Par codes.

i did a setup like this on Wii Phantasy Star II and a few other Emulator games.
to use ASM section there is some things you will need > and most of the time this is why its simpler to just find a memory pointer

So
1. Need to find Game Selector that is set when you enter the game.
2. Need to find the Reg that's holding the Offset that's being Read/Written from.
3. Then you need to do to Condition checks . 1 for the game selector and 1 for the offset..
4. You have 2 Options Rip the Pointer and place it into memory so you can use it or just set write to offset inside ASM

My codes for Wii Phantasy Star II rips the Pointer and places it into a section of ram that i then just use Pointer Codes from.