You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related discussion is here.
In short: game, called Labyrinth by Pack In Video, at its start sets stack to F380, and down its execution uses the RAM within F000-F380. After setting new stack, it performs calling of the MSX-Audio BIOS using EXTBIO and, as NYYRIKKI says, the stack grows to the extent being corrupt by Nextor during EXTBIO processing.
The only solution so far is to remove Nextor from the equation at all.
Right now I have only one case for this issue, thus it is exception rather than a rule. Nevertheless it would be a "right" action changing to not using these disk I/O-related areas for EXTBIO-related stuff, making environment to be a "little safer" :) I think if you need some space for temporary code or data, you can use stack for it, or use Nextor-allocated upper mapped RAM for longer-term storage.
I will refrain from any suggestion how it can be done as people say that it may bring other problems.
The text was updated successfully, but these errors were encountered:
As suggested in the MRC thread, turn this request down if you think it is inappropriate. Nevertheless, may I ask you, if you have time, please look into your EXTBIO processing code, maybe you can find something to improve. Thank you!
The EXTBIO handling code is somewhat complex indeed because of the added support for custom EXTBIO handlers in drivers. Probably it can be improved, indeed, but "please look into the code, maybe you can find something to improve" is somewhat of a too generic suggestion 🙂
About the Labyrinth game, since it's a ROM game it probably doesn't expect the disk system to be in place when it runs (which is usually the case for games running from ROM) and thus it places the stack at F380h, which is a legal thing to do in these cases if I'm not missing something.
I'll mark this issue as "enhancement" and leave it open in case you or someone else want to provide a more detailed suggestion for improvements in the future.
Related discussion is here.
In short: game, called Labyrinth by Pack In Video, at its start sets stack to F380, and down its execution uses the RAM within F000-F380. After setting new stack, it performs calling of the MSX-Audio BIOS using EXTBIO and, as NYYRIKKI says, the stack grows to the extent being corrupt by Nextor during EXTBIO processing.
The only solution so far is to remove Nextor from the equation at all.
Right now I have only one case for this issue, thus it is exception rather than a rule. Nevertheless it would be a "right" action changing to not using these disk I/O-related areas for EXTBIO-related stuff, making environment to be a "little safer" :)
I think if you need some space for temporary code or data, you can use stack for it, or use Nextor-allocated upper mapped RAM for longer-term storage.I will refrain from any suggestion how it can be done as people say that it may bring other problems.
The text was updated successfully, but these errors were encountered: