Beggar Prince (first revision) hangs after SFT screen

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run the game)

What is the expected output? What do you see instead?
after SFT-logo screen fades and game hangs

What version of the emulator are you using (official, SVN revision,...)?
RetroArch win32 x86 + selfcompiled from current git libretro GenPlusGX port
the same issue with last "official" libretro-git-genplus-x86.dll (from 
17.02.2013)

Original issue reported on code.google.com by 0vet...@gmail.com on 26 Feb 2013 at 2:36

[GoogleCodeExporter]

rom used - size="4194304" crc="f3af46cd" 
sha1="f481b970756c482d8f408c4bab8902172837e7d8"

Original comment by 0vet...@gmail.com on 26 Feb 2013 at 2:39

[GoogleCodeExporter]

The emulator actually only supports the last revision of this game, which as 
far as i know, is not publically available.
The dump you are using, which was only dumped recently, is from the first 
revision and has a few hardware differences.
Since the internal name is the same, the emulator misdetects your rom as the 
later revision and try to emulate inappropriate cartridge hardware, which makes 
it crash.

Until this old revision hardware is emulated, you can make it somehow works 
like in other emus by hexediting your rom and replacing the first occurence of 
"SF-001" by something else. Note that since the hardware in the cartridge is 
not emulated for this one, it will still randomly crash later in the game and 
internal saves are not going to work (same would happen with any emulator not 
emulating the protection).

Original comment by ekeeke31@gmail.com on 26 Feb 2013 at 3:05

• Changed title: Beggar Prince (first revision) hangs after SFT screen
• Changed state: Accepted
• Added labels: Type-Defect, Priority-Low, CartridgeEmulation

[GoogleCodeExporter]

thanks for explanation, as quick fix I've made
/* 32K static RAM mirrored into $3C0000-$3FFFFF (odd bytes only) */
for (i=0x3c; i<0x40; i++)  <= i<0x3f
and game works without reboot (at magican house), but indeed saves not working, 
moreover I dont see any SRAM access attempts...

Original comment by 0vet...@gmail.com on 26 Feb 2013 at 3:37

[GoogleCodeExporter]

I know SRAM is mapped above ROM area in this first board revision (same as 
original chinese cartridge), at $400000-$4xxxxxx 

Original comment by ekeeke31@gmail.com on 26 Feb 2013 at 4:22

[GoogleCodeExporter]

thanks for info, this was weird decision to use 4xxxxx area and probaly couse 
problems with SegaCD

Original comment by 0vet...@gmail.com on 26 Feb 2013 at 6:26

[GoogleCodeExporter]

Indeed, that was the point of the later revisions.

Anyway, support for the early board revision has been added in r764

Original comment by ekeeke31@gmail.com on 26 Feb 2013 at 7:31

• Changed state: Verified