SofaROM bug report thread | MSX Resource Center (Página 9/21)

Enlighted (6449)

06-09-2017, 09:12

I forgot to put Firebird on the list and to say that USAS is a lot slower on Rurbo R in z80 mode than on MSX2.

Firebird:
without option = Works
/d1 = Works
/z1 = Graphic bug in enemy sprites
/z1 /d1 = Graphic bug in enemy sprites
/z1 /d0 = Works (a few slowdowns sometime)
/d0 = Works

Louthrax wrote:

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?

I tried. Usas & MoG work fine. No change.

I wonder if some Turbo R have hardware or software differences (bug in bios or others). Maybe we should do something to compare them.

Por Manuel

Ascended (19691)

06-09-2017, 10:27

Louthrax wrote:

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

FYI (besides Louthrax who already knows this): there was indeed a bug in openMSX, which got fixed now, thanks to your report: https://github.com/openMSX/openMSX/commit/6a538705fe14bf8a7b...
So, for testing this specific stuff in openMSX, please use the latest development build.

Por gdx

Enlighted (6449)

06-09-2017, 11:33

I launched Usas & MoG with Megamu and /z option (Z80 mode). Both work fine.
Megamu use the Turbo R mapper.

Por Louthrax

Prophet (2497)

06-09-2017, 11:40

Manuel wrote:

Louthrax wrote:

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

FYI (besides Louthrax who already knows this): there was indeed a bug in openMSX, which got fixed now, thanks to your report: https://github.com/openMSX/openMSX/commit/6a538705fe14bf8a7b...
So, for testing this specific stuff in openMSX, please use the latest development build.

That fix does not change anything about this problem, everything still works fine on turboR / openMSX.

There's also still another bug in openMSX: the value that you write to select pages in turboR mapper should also be written in the destination memory location after page has been selected (hence the need for saving / restoring those values on real turboR, that's the main source for slowdowns in games with this mode). Fix should just be to remove an "else" statement, I'll send more details to Wouter.

Por Louthrax

Prophet (2497)

06-09-2017, 17:34

I think I've found the reason for the differences between openMSX / my turboR ST and GDX & Grauw's machines:

When you switch the turboR mapper page at #6000-#7FFF, you poke the new page number at #6C00 (which is in the same location as the page you are changing!).

On openMSX, that value has no effect on the RAM content, it's just switching the page.
On my turboR ST, it changes the value only in the existing page.
On GDX and Grauw's machines, it changes the value in BOTH in existing page and the new page!

The cause of it on my machine is probably a different RAM latency, that causes the new page not to be written. MEGAMU is indeed getting and restoring both the existing and taget page, when SofaROM does it only for the target page.

The weird thing is that RAM at #EC00 seems to be corrupted on Grauw and GDX machines (when it should be ROM at #6C00). Maybe because the address bus is in a weird state at that time. Could also explain why this is happening only in Z80 mode. I've not been able to reproduce exactly that behavior in openMSX yet, but it should not be too hard to have a fix for SofaROM.

EDIT: I had a quick look at TRLOAD.COM, it's also only getting / restoring the existing page, so it might have the same problem in Z80 mode (but of course it works here...). Symptoms might be different as the code is not the same, but I would be very interested if someone could try that.

Por Jipe

Paragon (1625)

06-09-2017, 17:36

Turbo-R ST mod with 60ns RAM works but 70ns is better
for GT 80ns is required

Por Louthrax

Prophet (2497)

06-09-2017, 18:08

Jipe wrote:

Turbo-R ST mod with 60ns RAM works but 70ns is better
for GT 80ns is required

Hey Jipe !

By any chance, do your remember which model you installed on my ST 20 years ago ??

Por Louthrax

Prophet (2497)

06-09-2017, 18:09

Louthrax wrote:

EDIT: I had a quick look at TRLOAD.COM, it's also only getting / restoring the existing page, so it might have the same problem in Z80 mode (but of course it works here...).

In fact TRLOAD.COM switches automatically to R800 mode (even after a CPU 0 command), so no way to test that!

Por Jipe

Paragon (1625)

06-09-2017, 18:14

i make only one with 60ns for XAK
you have 70 or 80ns inside don't remember exactly

Por Louthrax

Prophet (2497)

06-09-2017, 18:17

Jipe wrote:

i make only one with 60ns for XAK
you have 70 or 80ns inside don't remember exactly

Do you remember any visual differences (that can be seen in games??) between the different versions? Or was that causing crashes or issues?