Running MSX AUDIO supported cartridge with NMS1205 Music Module

Page 4/6
1 | 2 | 3 | | 5 | 6

By Eugeny_Brychkov

Paragon (1166)

Eugeny_Brychkov's picture

16-09-2020, 21:39

Decided to see if the Labyrinth will run on exactly my machine in emulation (maybe it does not like -R machine?). Downloaded some package with ROMs for YIS503-3R, but they appeared to be defective! Had to unpack my programmer and read my machine's ROM chips. Result: game works in my openMSX-emulated machine... But does not on real one...

By Eugeny_Brychkov

Paragon (1166)

Eugeny_Brychkov's picture

16-09-2020, 23:28

I found the cause (not the root cause yet) - it is Nextor. It also hooks to the EXTBIO, and when MSX-Audio BIOS calls EXTBIO with DE=2, the call ends in some wrong place. As soon as I put FF at the beginning of Nextor ROM (disabling its initialization), Labyrinth works, even with GR8NET's TCP/IP UNAPI (which also hooks EXTBIO) in effect. Interesting that in emulation MSXDOS2 returns properly. Note that it is not a root cause yet, will perform RCA tomorrow.

By Manuel

Ascended (16864)

Manuel's picture

17-09-2020, 00:50

NYYRIKKI: the boosted audio extension has the audio BIOS by frs, as far as I know. I guess the same happens with real hardware using that BIOS? I don't have a way to test that.

By NYYRIKKI

Enlighted (5590)

NYYRIKKI's picture

17-09-2020, 01:52

Ah, I just realized this has nothing to do with the MSX-AUDIO... ie. in tR the game will hang even without MSX-AUDIO connected at all in case Nextor kernel is in subslot instead of primary slot and the game sends EXTBIO function 1 is as broadcast.... Reason seems to be that when EXTBIO hooks are copied and chained the stack usage increases quite a lot and that finally overwrites SECBUF pointer (#F34D) that is used by Nextor internally as pointer to temporary data storage in EXTBIO handler. Subslot handling seems to be enough to push the stack too far in this example case.

Let's say, this game is just not Nextor compatible as it inits SP to #F380

By Takamichi

Champion (368)

Takamichi's picture

17-09-2020, 05:28

@nyyrikki: Is Labyrinth cartridge a common rom or has additional ram? Is internal PCB pic necessary?

By Eugeny_Brychkov

Paragon (1166)

Eugeny_Brychkov's picture

17-09-2020, 10:00

NYYRIKKI wrote:

Reason seems to be that when EXTBIO hooks are copied and chained the stack usage increases quite a lot and that finally overwrites SECBUF pointer (#F34D) that is used by Nextor internally as pointer to temporary data storage in EXTBIO handler. Subslot handling seems to be enough to push the stack too far in this example case.

Let's say, this game is just not Nextor compatible as it inits SP to #F380

Did short research in openMSX emulator and must say you must be 99.99% correct (not because you may be 0.01% incorrect, but because I decided not to dig deeper Smile ). Tried to move stack lower, but then game reboots. I suspect it uses RAM just below its F380 stack and Nextor does the simiar harm.
I suspect it must be possible to modify Nextor keeping its EXTBIO related data in its upper mapped RAM (as I guess none else will need this data in c000-fffe working memory), and perform far jump to the next EXTBIO handler from its ROM.

I will implement the mechanism to turn Nextor off in GR8NET anyway.

By NYYRIKKI

Enlighted (5590)

NYYRIKKI's picture

17-09-2020, 10:36

Eugeny_Brychkov wrote:

Did short research in openMSX emulator and must say you must be 99.99% correct (not because you may be 0.01% incorrect, but because I decided not to dig deeper Smile ). Tried to move stack lower, but then game reboots. I suspect it uses RAM just below its F380 stack and Nextor does the simiar harm.

I tried to move stack to #FAF0 and it worked fine for me.

Quote:

I suspect it must be possible to modify Nextor keeping its EXTBIO related data in its upper mapped RAM (as I guess none else will need this data in c000-fffe working memory), and perform far jump to the next EXTBIO handler from its ROM.

I would start by adding check to Nextor so that if there is not #C9 in H.STKE (#FEDA) then Nextor would skip EXTBIO installation... I think DOS2 already checks this hook and goes to DOS1 when this hook is populated, but it seems to me Nextor installs the EXTBIO handler anyway... This would need some investigation.

By NYYRIKKI

Enlighted (5590)

NYYRIKKI's picture

17-09-2020, 11:00

Takamichi wrote:

@nyyrikki: Is Labyrinth cartridge a common rom or has additional ram? Is internal PCB pic necessary?

It is a common MegaROM AFAIK... I don't think you can find anything unusual from inside.

By Eugeny_Brychkov

Paragon (1166)

Eugeny_Brychkov's picture

17-09-2020, 11:00

NYYRIKKI wrote:

I tried to move stack to #FAF0 and it worked fine for me.

Confirmed! I did not try higher F380 not to corrupt main system variables.

NYYRIKKI wrote:

I would start by adding check to Nextor so that if there is not #C9 in H.STKE (#FEDA) then Nextor would skip EXTBIO installation... I think DOS2 already checks this hook and goes to DOS1 when this hook is populated, but it seems to me Nextor installs the EXTBIO handler anyway... This would need some investigation.

I created the issue, if you have ideas you can also write there.

By NYYRIKKI

Enlighted (5590)

NYYRIKKI's picture

17-09-2020, 12:43

Your suggestion to use upper mapped RAM does not sound very good to me. The number one reason why disk cracks don't usually work under DOS2/Nextor is exactly because DOS2 alters mapper registers... Although this would probably work on this particular case where game is on cartridge, in general this would just bring those same "DOS2 compatibility problems" to EXTBIO handling under DOS1.

BTW Do you know if there is some DOS1 kernel compatible functionality in Nextor EXTBIO routines? I just wonder, is there a real reason why Nextor EXTBIO handler should be active when DOS2 kernel is not?

Page 4/6
1 | 2 | 3 | | 5 | 6