SofaROM bug report thread

Page 8/20
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13

Par Grauw

Ascended (10604)

Portrait de Grauw

03-09-2017, 21:55

I was about to say, did you try the emulator Smile. But MoG goes haywire there! Big smile

Par Louthrax

Prophet (2419)

Portrait de Louthrax

04-09-2017, 01:16

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 oO !!

"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??

Par Louthrax

Prophet (2419)

Portrait de Louthrax

04-09-2017, 01:23

Guillian wrote:
Grauw wrote:

I see corruption in the same spot, what it looks like may depend on how long I linger in the intro demo because I’ve also seen it have blue sky tiles there, but not the clouds that are supposed to be there:

It seems something is writting to #EC00. That byte encodes that metatile.

And guess what... if I poke something at #EC00 in MoG with openMSX, I get the same graphic corruption as described by GDX!!

Par Guillian

Prophet (3504)

Portrait de Guillian

04-09-2017, 09:36

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

Par Grauw

Ascended (10604)

Portrait de Grauw

04-09-2017, 10:22

Possibly in Z80 mode the tR mapper register has write-through, whereas in R800 it blocks writes.

The way the Z80 and R800 interface to memory on the turboR is quite complex, it wouldn’t surprise me if there was such a difference between the two CPU modes.

Par gdx

Enlighted (5594)

Portrait de gdx

04-09-2017, 11:25

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.

Par Guillian

Prophet (3504)

Portrait de Guillian

04-09-2017, 11:35

Grauw wrote:

Possibly in Z80 mode the tR mapper register has write-through, whereas in R800 it blocks writes.

The way the Z80 and R800 interface to memory on the turboR is quite complex, it wouldn’t surprise me if there was such a difference between the two CPU modes.

IIRC, when I made TRLOAD I had to restore the RAM value that was changed after writing to the mapper register.
So I had to figure out which RAM bank and address would be overwritten, save it, change the mapper register, and then restore the RAM content.

Par Louthrax

Prophet (2419)

Portrait de Louthrax

04-09-2017, 12:52

Guillian wrote:

IIRC, when I made TRLOAD I had to restore the RAM value that was changed after writing to the mapper register.
So I had to figure out which RAM bank and address would be overwritten, save it, change the mapper register, and then restore the RAM content.

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?

Par gdx

Enlighted (5594)

Portrait de gdx

04-09-2017, 13:00

Maybe your RAM is slower or faster than ours.

Par Louthrax

Prophet (2419)

Portrait de Louthrax

04-09-2017, 13:52

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).

Page 8/20
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13