DKC Atlas Forum

Hello,

Here is my Super Donkey Kong (JAP) Prototype cart:



On Large sticker i can translate Super Donkey Kong Beta version don't remove the tape.

I have dumped the each eeprom and joined them.

When i run the game with Zsnes i obtain this screen.



Comparing Final Donkey and Proto:



Need some help to boot the game.

Thank you.

Regards,

Use a JP emulator.

CarpTheFish wrote:Use a JP emulator.

I use Higan 0.99 emu and i have black screen.
Need to change some Hex value i think to boot game.

Even if the ROM is different the size should be the same. "Donkey.smc" is only 3,670,016 bytes compared to the correct size of 4,194,304 (4MB), so it seems like you're missing some data. If the ROM tries to load code or data from a high region and can't find what it needs it would almost definitely end up not working.

You could start by verifying the contents of each EEPROM. They should all have sizes that are powers of two. The sticker hides things, but it looks like it has eight EEPROMs? So that would be 4,194,304 / 8 = 524,288 (512KB) per EEPROM? If it has four EEPROMs that would be 4x 1MB. Anyway, they should all add up to 4MB regardless. It might be easier for you to compare if you split up a known good ROM and compared each segment to your own segments. I think the smallest chip is SRAM so don't worry about that one (the one on the same side as the battery, next to the DIP switches).

EEPROMs can lose data as they age which could have happened here. If a working dump cannot be obtained by any means that might be the case. Does the board function properly in a real Super Famicom?

It's interesting that a development board would contain a Japanese version. I thought the final USA version was completed after the final Japanese release, but perhaps there is some other explanation. It's perhaps odd that an early version would be leaked given how secretive Rare was known to be. I wonder...

Kingizor wrote:Even if the ROM is different the size should be the same. "Donkey.smc" is only 3,670,016 bytes compared to the correct size of 4,194,304 (4MB), so it seems like you're missing some data. If the ROM tries to load code or data from a high region and can't find what it needs it would almost definitely end up not working.

You could start by verifying the contents of each EEPROM. They should all have sizes that are powers of two. The sticker hides things, but it looks like it has eight EEPROMs? So that would be 4,194,304 / 8 = 524,288 (512KB) per EEPROM? If it has four EEPROMs that would be 4x 1MB. Anyway, they should all add up to 4MB regardless. It might be easier for you to compare if you split up a known good ROM and compared each segment to your own segments. I think the smallest chip is SRAM so don't worry about that one (the one on the same side as the battery, next to the DIP switches).

EEPROMs can lose data as they age which could have happened here. If a working dump cannot be obtained by any means that might be the case. Does the board function properly in a real Super Famicom?

It's interesting that a development board would contain a Japanese version. I thought the final USA version was completed after the final Japanese release, but perhaps there is some other explanation. It's perhaps odd that an early version would be leaked given how secretive Rare was known to be. I wonder...

Hello,

There are 7 eeproms on dev cart. Not 8... perhaps because it's a beta version.



Here is the dumped files (Bin and Hex).

There is no sram on cart.
The board doesn't boot on a real super famicom system.

Here is Translhextion edit:

I have splitted in 8 files the Super Donkey Kong (V1.0) (J).smc
I take the 8th files and join with my 7 proto files.

Comparaison with final version:



Now the rom boot

Another problem:

I can see the intro.
I can see title screen and i can on map but when i enter in level 1 black screen...

If there are only seven EEPROMs it seems there is one missing from the board. (7x 512KB = 3,670,016, I should have realised that earlier)

The unusual ROM size might be the reason it didn't boot in emulators before. Most emulators will try to detect the mapper type by the ROM size and internal header. I wonder if it would still boot if you used 512KB of null data instead of that 8th segment? Maybe not.

Maybe there is something different about that eighth segment in the final release and the one the your board expects. If data were slightly offset within that bank it could explain why it would crash. I think the game executes code often from the final 512KB and regularly jumps between that area and the beginning of ROM, so that segment might be crucially important. If there are even small changes to code within the missing bank it could affect the other banks greatly as well.

If it is just a small code change, then perhaps it could be circumvented by swapping the first 512KB with a good ROM as well? It might be worth a try.

I can't really think of much else to do. Some deeper probing would be required for definitive answers, unless other people have some ideas.

Even if the ROM won't work it should still be possible to examine the data for interesting changes. It could be interesting to see how similar each segment is to the corresponding segment in the final release. That would be a good way to notice changes without having to play the game.

Have you done a debug during your tests, SDKJAP?

For instance, you said that you can see the intro, the title screen, and the map. The game goes black only when you try to enter a level. What codes does the game call when you enter a level in a fully working ROM, and what code do you get when you enter the one in the prototype?

When a level is inaccessible, it means that a code to access the level is missing, or the items used to draw up the levels (sprites, tiles, scripts) are missing.

Do you think you could share the EPROM shards with us via Dropbox or something? This seems like extremely important and valuable data.

Lastly, the fine folks at Assemblergames know a lot about ROM dumping and related topics, maybe they can help better than us.

In the final version, very crucial code and data exist in that last 512KB (PC addresses 380000-3FFFFF) including, but not limited, to the following:

1. Object animation data
2. Object graphic pointers
3. Object hitbox data
4. Level function code and pointers (code executed at the start of a level which load graphics/palettes/music, etc.)
5. Level banana placement maps
6. Level scrolling (a.k.a. camera) data
7. Level object placement maps and pointers
8. Palette data
9. Most of the code for the player objects (D.K./Diddy/Animal Buddies) as well as several baddies
10. Pointers to behavior code for all objects

If any of these are absent or misplaced, then that is likely what is causing the game to crash.

So the 512KB you speak of is the place where the actual level setup is stored. Everything else is just media files.

I wonder how this differs from IPS files made in DKCRE. If the game uses that last 512KB for what you said, then is the IPS file just an override script?

An IPS is only overwriting the bytes in the ROM, it has nothing to do directly with any of the games' substructure.

SNEScentral is implying you're a scammer - do you think you can provide any proof that your cart is legit? I'm interested in the EPROMs but I'm not holding my breath.

Interesting... however, I doubt that they are saying that sdkjap is the scammer