SofaROM bug report thread

So I managed to "fix" openMSX so that the ROMs are correctly launched by SofaROM (and sent an email to Manuel about that)... and it works on openMSX, same as on my turboR, no graphic glitches in MoG or USAS. Daaarn !!

"Fix" is the following, not sure at all if this is the right thing (it probably isn't):

const byte* RomPanasonic::getReadCacheLine(word address) const
{
	if ((0x7FF0 & CacheLine::HIGH) == address) {
		// TODO check mirrored
		return nullptr;
	} else {
		return Rom8kBBlocks::getReadCacheLine(address);
	}
}

But at least the ROMs can be launched, just ignoring this "CacheLine" thing... Could that be related to the problem we have here??

Are you writing to #6C00 or #7C00 turbo R mapper?
Perhaps the value is not restored correctly.

I did a few more tests detailed with my A1ST + CF interface and I make a list:

MOG:
without option = Works (Very fast)
/d1 = Works (Very fast)
/z1 = graphic bugs -> unplayable
/z1 /d1 = graphic bugs -> unplayable
/z1 /d0 = Works (a few slowdowns sometime)
/d0 = Works (Very fast)

Usas:
without option = Works
/d1 = Works
/z1 = graphic bugs
/z1 /d1 = graphic bugs
/z1 /d0 = Works (a few slowdowns sometime)
/d0 = Works

MetalGear EUR:
without option = Works (fast)
/d1 = Works (fast)
/z1 = Works (a few slowdowns sometime)
/z1 /d1 = Works (a few slowdowns sometime)
/z1 /d0 = Works (a few slowdowns sometime)
/d0 = Works (fast)

MetalGear JP and remix:
without option = Works (fast)
/d1 = Works (fast)
/z1 = Graphic bugs just after the first message from transciver -> unplayable
/z1 /d1 = Graphic bugs just after the first message from transciver -> unplayable
/z1 /d0 = Works (a few slowdowns sometime)
/d0 = Works (fast)

Graduis:
without option = Works (Too fast)
/d1 = Works (Too fast)
/z1 = Works
/z1 /d1 = Works
/z1 /d0 = Works
/d0 = Works (Too fast)

Graduis enhanced by V. Martinez]:
without option = Freezes on the screen “Loading…”
/d1 = Freezes on the screen “Loading…”
/z1 = Freezes on the screen “Loading…”
/z1 /d1 = Freezes on the screen “Loading…”
/z1 /d0 = Freezes on the screen “Loading…”
/d0 = Freezes on the screen “Loading…”

Akumajou Dracula and Castlevania (Akumajou Dracula modified by M. Pazos & IMANOK):
without option = Works (Too fast)
/d1 = Works (Too fast)
/z1 = Works
/z1 /d1 = Works
/z1 /d0 = Works
/d0 = Works (Too fast)

Akumajou Dracula (Dynamic vsync patched by FRS):
without option = Works (Not too fast!)
/d1 = Works (Not too fast!)
/z1 = Works
/z1 /d1 = Works
/z1 /d0 = Works
/d0 = Works (Not too fast!)

King Kong 2:
without option = Works
/d1 = Works
/z1 = Works
/z1 /d1 = Works
/z1 /d0 = Severe slowdown at start but seems to work
/d0 = Severe slowdown at start but seems to work

King Kong 2 translated by Imanok:
without option = Works
/d1 = Works
/z1 = Works
/z1 /d1 = Works
/z1 /d0 = Severe slowdown at start then crash
/d0 = Severe slowdown at start then crash

MetalGear 2 (A1ST + CF interface + a Megasram SCC in slot-2) :
/d1 /t = Works (Fast but a few slowdowns remain, freezes sometime when Solid snake comes out of his hole at begining)
/z1 /d1 /t = Doesn’t work (Freezes at first screen of fox)
/z1 /d0 /t = Works (slowdowns sometimes)
/d0 /t = Works (Fast but a few slowdowns remain)

I think this is interruptions problem.
All of these games works normally on my Megasram SCC which is detected automatically. Only the /z1 option is required for games that are too fast in R800 mode.

Yes, that's also what I do: first get the byte value at #6C00 for example, then write the page at #6C00, then restore the saved byte using the memory mapper at #2C00 (that can't be restored directly using the turboR mapper). It looks like the memory mapper page selected is not the right one (if it's page 0, that would result in changing the byte at#EC00).

Checking my code right now... Still do not understand why it works on my ST and openMSX!! I was thinking about some Uninitialized Memory Read (RAM having different values at boot time depending on the RAM chipset or something). Have checked that with the latest openMSX UMR tool (which is great!), seems it's OK. And why does it work in R800 if it's an UMR?

I've created a little test version of SofaROM that should freeze on problem and light the CAPS led ON or OFF depending of the problem.

You can get it here: SROMTEST

Launch it with the usual parameters (/Z1 /D5) on the Usas or MoG ROMs (you can do it from SD cards, the problem does not come from the mass storage driver). Let me know if the MSX freezes when playing the game. If it freezes, is the CAPS led ON or OFF?

While you're at it, it would be interesting to try this: do not use the /Z1 option to switch to Z80, but use Nextor's CPU command:

• Boot on SD Card / Nextor
• Type "CPU 0"
• Launch the game without /Z1 (SROM MOG.ROM /D5)

Thanks to all for the reports here or by mail. GDX, thanks for your detailed report. The other things your are mentionning are expected (patched games often use same memory area as SofaROM, causing crashes, slowdowns in Z80 mode are expected too).