VisitntX's Genesis PAR

[King Of Chaos]

I have to say something about Kega Fusion (probably all Kegas.). That emulator uses reversed bytes so in order to make all the codes to work there you have to add 1 in hex to the address.

Just randomly viewing topics on the forums, I saw this, and I had to reply informing you this is wrong. Kega Fusion does Pro Action Replay like the actual AR/PAR/PAR2 hardware, where it's Gens that does PAR wrong. Here's an example, most codes created in Gens don't work with the real hardware, as where Kega created PAR codes will.

If you're wondering why exactly Gens is wrong, it's because the 68k core used in Gens swaps the bytes internally to match x86's endianness. The intention of doing this is obviously a speed up. I've asked Stef in the past to correct this, but sadly I'm not sure this will happen.

P.S. ROM address codes will work on the real PAR hardware, not AR. =P

[VisitntX]

Just randomly viewing topics on the forums, I saw this, and I had to reply informing you this is wrong. Kega Fusion does Pro Action Replay like the actual AR/PAR/PAR2 hardware, where it's Gens that does PAR wrong. Here's an example, most codes created in Gens don't work with the real hardware, as where Kega created PAR codes will.

Actualy is awfuly wrong, more when you don't have to add one, it depends on the game. And then it cames the matter with the mod version of Gens with the cheat engine. So Kega then, yes, I remember some codes that I made wonder why if in Kega they were right (and like they must) I couldn't translate them correctly to Gens.

If you're wondering why exactly Gens is wrong, it's because the 68k core used in Gens swaps the bytes internally to match x86's endianness. The intention of doing this is obviously a speed up. I've asked Stef in the past to correct this, but sadly I'm not sure this will happen.

It's true that m68k is big-endian, but also that depends how the games work (at least I read about some games working as little-endian). I don't know how real hardware then interprete it. An example, my memory pokes (GG) are in big-endian and they work perfect in both emulators and in real hardware. Even debugging will show games working at big, so I was wondering if then the genesis swaps it at the memory writes if there are really "little" ones.

P.S. ROM address codes will work on the real PAR hardware, not AR. =P

Ah, this is something I wanted to hear. Much appreciated, really. Most cuz I can use it for invincibility codes that otherwise in PAR/AR aren't correctly (like I want) possible.

Thanks a lot KoC.

BTW, I edited this, it had terrible errors I made at writing. Dunno why I changed the concepts so badly, but after read it again I notice them.

[VisitntX]

This is a report after some tests with real hardware and a PAR cartridge.

Console: Mega Drive (European version)
Game: Castlevania (European version)
Cheat device: Pro Action Replay 2
Code: FFFB2E:0002 (Infinite Lives)

The code for lives that was tested worked perfectly in Gens (The mod version with the cheat engine built-in) and not worked in Kega in where graphics glitches were present at the lives counter and after losing all lives then the player always get a game over screen after one live is lost.
Now that same code was tested in the real hardware and worked perfectly as on Gens, and not any of the problems present in Kega were at the real hw.
Also was confirmed that the PAR can use ROM addresses to cheat.

Being the Genesis a motorola based console and being this one a bin-endian the correct way to use it should be as Gens.
But I thought then that Kega was working in little-endian, and maybe it's working that way. I took a look at that emu and maybe found what it does.

Now the code: FFFB2E:0002 will be write this way: FFFB2E:00 and FFFB2F:02. So the genesis and gens do this. And also the PAR should work as this for this code to work correctly.
As you see the 8 bits part that holds the number of lives is FFFBEF. So Kega takes that and do this FFFB2F:0002. Now we can think that two things are done there. One is that internally it made the code short to FFFB2F:02 losing the FFFB2E:00 part. Or that it works in little-endian. And so FFFB2F:0002 will be FFFB2F:02 and FFFB2E:00 or FFFB30:00 (with this one we get the little endian).
Doesn't matter, both seems to be wrong. And again, the motorola works in big endian, and so the genesis. And I doubt that the PAR works as Kega or ROM addresses will not work at all and crash the games. And they work as with any GG.

Now, a lot of games work with values at 16 bits. And so the addresses are even FFFB2E and not odd FFFB2F. And there are games that work at 8 bits and so FFFB2E will be 00 and FFFB2F will be 2, here we can use odd addresses.

That's all.