Estpolis Denki II NTSC-JAP Prototype

[trevormacro]

Hi,


Today I have received Estpolis Denki II Jap prototype on SFC.

I am busy at work now.Tonight or tomorrow, I will post an update.

I just removed the 3 eproms (8 Mo, 8 Mo and 4 Mo).

I will use LPC-32 device to dump all eproms like I did with my two first prototypes games.

If you have any helps, feel free to post them here.


Thanks in advance


Best Regards,

Trevormacro

[geluda]

Good luck! I was really interested in this prototype it's a shame to see it on its last legs.

[trevormacro]

Good luck! I was really interested in this prototype it's a shame to see it on its last legs.

Thank you Geluda.

I use smartchip 1.4a.

I dump the first eprom with MX27C8000.
I dump the second eprom with MX27C8000.
I dump the third eprom with MX27C4000.

I have 3 files:

- estopolis.001 (1024 KB)
- estopolis.002 (1024 KB)
- estopolis.003 (512 KB)

I join them.

When i run the estopolis.sfc ROM on Snes9x or Zsnes I have a bad checksum and black screen why?

Who have a solution?

[Bad_Ad84]

Because the contents of the chips are damaged, like you have been told a number of times.

Reading a chip with damaged contents still results in a damaged rom file

[Zoinkity]

Well, it's at least worth looking into how damaged each one is. Have you looked at any of the binary files with a hex editor? Even though a full dump will never work and the contents are permanently damaged, resources can still be extracted, and you could probably slide what intact resources still exist into a retail image to at least have a semi-beta playable demo.

[trevormacro]

I dump all 3 eproms in bin and hex format.
If I read one eprom with hex editor what can i do?
any solution to repair these 3 files?
thanks

Here the Rom Informations of Snes9x:

Well, it's at least worth looking into how damaged each one is. Have you looked at any of the binary files with a hex editor? Even though a full dump will never work and the contents are permanently damaged, resources can still be extracted, and you could probably slide what intact resources still exist into a retail image to at least have a semi-beta playable demo.

How can i extract ressources?

I try to redump the 3 eproms again. Old dump and new dump have the same checksum.


First dump : D8CC3BDF62E42B3EE95326DEE3E910BE
Second dump: D8CC3BDF62E42B3EE95326DEE3E910BE

With Snes9x 1.51 Gary H.

I've got this error:



Hex:

[JLukas]

From the screenshots, the internal header starting at SNES address $FFC0 has a lot of incorrect values. For example, the game is supposed to be LoROM with 8KB SRAM. It's hard to say if the incorrect bytes are due to corruption or not. Prototypes sometimes have missing or invalid header data. It's not an issue when running games on the SNES console, however, older emulators depend on the header being correct. The debugger screenshot above is an example - the hex editor window is showing the wrong mapping (C00000 instead of 808000) i.e, HiROM instead of LoROM. Setting the correct header bytes (using the retail version for comparison) would help rule out emulator related problems.

The important thing is that the entry point $8000 is correct (same as retail version), which is a good sign.

The very first opcode would explain the crash, it's $00 BRK instead of $78 SEI.

[derekb]

running the game in a decent emulator (bsnes) instead of a crap emulator (snes9x, zsnes) would probably help

[badinsults]

Really, the only hope is for you to release the ROM and let people who actually know what they are doing have a look. You really should do some research into how the SNES works before attempting anything.

For instance, if you are investigating dumps, you should be using NSRT. It tells you the header information and checksum.

You should learn how to use a tile viewer, like YY-CHR, to investigate the graphics.

You should learn the basics of the setup of the internal header, which can be found on the official dev docs that are on romhacking.net. If you read them, you will learn why the emulator is likely to say a game has a "bad" checksum when it is a prototype (hint: the checksum in the internal header was generally not set until the game was ready for production).

[JLukas]

Looking at the Info box screenshot above again, it's worth noting the two stored checksums agree (FFFF-6235 = 9DCA) Maybe the prototype did have a good checksum before the corruption, or it's possible they're numbers from an earlier build. Even if the actual checksum values aren't useful anymore, the fact that they agree means at least some of the header data is valid. The reset vector is also valid, which is critical. Hopefully corruption isn't the reason why the other values are incorrect.

[trevormacro]

Here is the Translhextion: estopolis.sfc (not changed)



Here is the Translhextion 00 value to 78:



The game doesn't work in zsnes 1.51 and Snes9x 1.51 debug.



$00007FB0 doesn't exist:

Picture:



With bsnes_v091-32bit:

When I want to load the game it's impossible because it doesn't appear and my rom is : estopolis.sfc

Why?

NSRT: (estopolis.sfc value 78 at the start)

Really, the only hope is for you to release the ROM and let people who actually know what they are doing have a look. You really should do some research into how the SNES works before attempting anything.

For instance, if you are investigating dumps, you should be using NSRT. It tells you the header information and checksum.

You should learn how to use a tile viewer, like YY-CHR, to investigate the graphics.

You should learn the basics of the setup of the internal header, which can be found on the official dev docs that are on romhacking.net. If you read them, you will learn why the emulator is likely to say a game has a "bad" checksum when it is a prototype (hint: the checksum in the internal header was generally not set until the game was ready for production).

Hi,

Where can I find the doc file for internal header please? do you have a complete link?

Some Hex comparaisons between prototype and commercial game:







Why so different?

[Borman]

Some Hex comparaisons between prototype and commercial game:
Why so different?

You have no idea what you bought, do you? Look at what Jackhead posted, the game looks entirely different, that is why things will be different.

[trevormacro]

You have no idea what you bought, do you? Look at what Jackhead posted, the game looks entirely different, that is why things will be different.

I have an idea about this game yes.

Anyone know good forum with expert? can help me or a Gold man.

[arnoldlayne]

You're surrounded by experts here - Someone should try and contact trevormarco via messenger or Skype and talk him through it. (just a thought!)

[trevormacro]

You're surrounded by experts here - Someone should try and contact trevormarco via messenger or Skype and talk him through it. (just a thought!)

Yes, I have msn messenger.
PM me.

[JLukas]

The good news from the screenshots is the data seems to be intact when compared to the final Japanese version. You also correctly fixed that first corrupt byte. If it's still crashing it must mean there's additional corrupt bytes somewhere else. To continue to fix it requires reviewing the log files in the debugger each time it crashes to find where the problem byte(s) are.

[N00ByBo0]

Hi,

I am a long lurker here and Lufia 2 is one of my most favourite SNES games of all time. I was pretty sad when the prototype when it was on last guy got somehow "corrupted" so I hope it isn't too much of that and you can save it.

But you're asking for professionals so why not upload the rom or whatever so everyone can look at it? Unless you want keep the dump yourself and the game once it has been fixed but I don't know really.

All I can really say is good luck and I hope this prototype of IMO best RPG of SNES can be fixed up.

-Long lurker.

[trevormacro]

21 E5 0B 05 00 33 F0

Change it to the following:

32 02 0C 03 00 33 00



The intro works without music :) now...

[JLukas]

That's definately a good start :)

[trevormacro]

That's definately a good start :)

estopolis.srm --> 8 KB created by Zsnes 1.51