Pro Action Replay and Donkey Kong Country

[CZroe]

I'd like to record/stream some gameplay videos from an actual SNES without using an emulator, but all I have are three model 2 SNES consoles and a Super Famicom. The problem with the three model 2 SNES consoles is that they only have composite video out... no RF and no S-Video, so I can't, say, capture from high-quality S-Video while playing on a TV unless I split it off. The SFC's only problem is that it requires a way to adapt the cartridge connector.

I used the Pro Action Replay to fit DKC2 in the SFC and did streaming and recording using a 3rd party cable with S-Video + composite, so I didn't even need the RF output or splitters, but this same method won't work with the original DKC. When you select a game save file, it gives you the message about not supporting unauthorized backup devices. It's strange that the PAR doesn't trigger this with DKC2, but it does it on the US consoles too.

I can't find a PAR cheat to circumvent the message unless I could trigger it in ZSNES. I can't find any information on the 'net regarding past PAR users and their work-arounds for specific games, though I know that there were many.

A little help?

[CZroe]

BUMP

[Starman Ghost]

According to this, none of the versions of it work with pro action replay.

[CZroe]

According to this, none of the versions of it work with pro action replay.

Actually, that's my Wikipedia edit.

I tested v1.0 and v1.1 and found them incompatible. Therefore, clearly, the 1.2 update was not made to counter them. Rather than remove this information (considering that I don't know where it came from), I made sure it referenced the older versions not working with the PAR. I also called the information into question with the information about the sequel (if they really cared about the PAR, why would they just "stop caring?").

As it stands, their conjecture regarding v1.2 is the only information confirming any type of PAR incompatibility and it was clearly flawed... the source was clearly unaware of the incompatibilities involving the previous versions. They likely came to this conclusion because they could not find corroborating information about DKC incompatibilities and assumed that this is because it was unique to v1.2.

[PHoNyMiKe]

these four codes will bypass the sram check on dkc u.s. version 1.0 in zsnes:

C0E9C0EA
C0E9C1EA
C0E9D4EA
C0E9D5EA

for u.s. 1.1 you gotta add 1 to the addresses:

C0E9C1EA
C0E9C2EA
C0E9D5EA
C0E9D6EA

however I don't think the par can address this on a real snes, but zsnes will decode it. to see them in action edit the sram size byte in the cartridge header (location 0x101D8 in a rom with a 512 byte copier header). make it a 02 instead of 01. the game will detect the extra sram zsnes is giving and give that blue error screen. enter the 4 codes, reset, and it goes on no problem. again, I don't think these par codes work on hardware, but it's worth a try. otherwise get a real snes, or a backup unit and it'll play fine.

the screen says: "this product will not operate when connected to a device which makes unauthorized copies." the par cannot copy a snes game. this is an sram check, used to detect backup units which have more sram than a normal cartridge (to store multiple games' sram). I don't know why the par triggers it, but the code can be disabled using ucon64 with the -k switch, which 'cracks' this snes rom.

[CZroe]

these four codes will bypass the sram check on dkc u.s. version 1.0 in zsnes:

C0E9C0EA
C0E9C1EA
C0E9D4EA
C0E9D5EA

for u.s. 1.1 you gotta add 1 to the addresses:

C0E9C1EA
C0E9C2EA
C0E9D5EA
C0E9D6EA

however I don't think the par can address this on a real snes, but zsnes will decode it. to see them in action edit the sram size byte in the cartridge header (location 0x101D8 in a rom with a 512 byte copier header). make it a 02 instead of 01. the game will detect the extra sram zsnes is giving and give that blue error screen. enter the 4 codes, reset, and it goes on no problem. again, I don't think these par codes work on hardware, but it's worth a try. otherwise get a real snes, or a backup unit and it'll play fine.

the screen says: "this product will not operate when connected to a device which makes unauthorized copies." the par cannot copy a snes game. this is an sram check, used to detect backup units which have more sram than a normal cartridge (to store multiple games' sram). I don't know why the par triggers it, but the code can be disabled using ucon64 with the -k switch, which 'cracks' this snes rom.

Thanks for going through all the effort. I've used UCON64 for my N64 backup units, but I didn't realize that it had generic SNES SRAM check patching. I tried them both with both versions of the cartridge and I still can't get past the game type selection without triggering this. The PAR must have SRAM to store its own code without using system memory, but it darn sure doesn't use it for storage! There is no battery and they figure that you may as well write it down if it supports a maximum of four lines at once. I wonder if a newer version of the PAR does things differently and therefore doesn't trigger this (hence the lack of information online).

It seems as if the act of creating a save file is what triggers the SRAM check, even though the save file does not get stored until a save point is reached/used, so I will try creating a save on another SNES and then swapping the console to see if that'll do it.

It probably doesn't work because the PAR must not truly intercept reads to those addresses (ROM) so it can only edit addresses in RAM/SRAM. However, now that we can trigger this in ZSNES, perhaps I can find a "SRAM check passed/failed" address. Thanks for your help!

[PHoNyMiKe]

no such luck, looking at the code it does this:

Code: Select all

LDA $306057 [$30:6057]
INC A
STA $306057 [$30:6057]
CMP $306057 [$30:6057]
BNE $5E [$EA20] (show copier screen)
DEC A
STA $306057 [$30:6057]

loads a value from sram. changes it and puts the value back, then makes sure the changed value is updated. if the value isn't doing what the code expects, then a copier or something must be interfering. afterwards it puts the original value back into sram.

Code: Select all

LDA $306059 [$30:6059]
INC A
STA $306859 [$30:6859]
CMP $306059 [$30:6059]
BNE $4A [$EA20] (show copier screen)
DEC A
STA $306059 [$30:6059]

now that the sram is functioning as expected (at least 1 word is functioning as expected) then it checks to make sure there's only 2KB of sram (copiers have like 32KB.) it loads a value from sram, changes it, then writes it to an address that should be mirrored. the sram should only go to 0x7FF. so a write to 0x859 should mirror and show up in 0x059. they should be equal. if there's more ram than the cart should have then it fails. afterward it puts the original value back.

so after looking at that, I say it's impossible to use a par to get past this check. only way around is to alter the code such as in an emulator or copier. since par can only edit ram, this will not work.

I got a 32mbit GDSF3 I'll sell ya for $40 shipped. then you can play all the games you want on your SF.

[CZroe]

YGPM