0x4000-0xffff (48 KB) ROMs do not work #99
Comments
|
Interesting... But how does your ROM work with NO RAM at the top of the
address space (around 0xffff)?
Doesn't it need RAM for the CPU Stack, or doesn't it mess with the system
variables and so?
…On Wed, May 17, 2023 at 12:20 AM Qiqitori ***@***.***> wrote:
Hi, there are two reasonable ways to organize a normal (mapper-less) 48 KB
ROM, 0x0000-0xbfff (this seems to work), and 0x4000-0xffff (this doesn't
work). The current code assumes the former whenever it encounters a ROM
larger than 32 KB.
The following patch seems to fix the issue with the particular ROM file I
was trying to load, which works in openMSX and on a real MSX1; you can
download it from
https://blog.qiqitori.com/wp-content/uploads/2023/05/msx1_popsa_2.rom.
This ROM loads in WebMSX, but it sees the ROM contents at 0xc000-0xffff as
0xff bytes. These 0xff bytes cause playback to appear to freeze, though it
actually is just executing very long breaks. After a while playback may
start from the beginning again because the counter loops to 0000 and
eventually may get to the correct song start address.
It also doesn't break the only other normal mapper-less 48 KB ROM (Uchusen
Gamma, which has the header at 0x4000) that I have on hand, but before
applying it the patch should be tested for regressions with other 48 KB and
64 KB ROMs (e.g., 48 KB with header at 0x8000, 64 KB with headers at
0x4000, 0x8000).
diff --git a/src/main/msx/slots/SlotFormats.js b/src/main/msx/slots/SlotFormats.js
index c87d2d97..7cb4516f 100644
--- a/src/main/msx/slots/SlotFormats.js
+++ b/src/main/msx/slots/SlotFormats.js
@@ -389,7 +389,8 @@ wmsx.SlotFormats = {
|| (rom.content[0x4000] === 65 && rom.content[0x4001] === 66))) return this.priority;
// Any > 32K and <= 64K content, with the Cartridge identifier "AB" at 0x4000 or 0x8000
if ((rom.content.length > 32768 && rom.content.length <= 65536)
- && ((rom.content[0x4000] === 65 && rom.content[0x4001] === 66)
+ && ((rom.content[0] === 65 && rom.content[1] === 66)
+ || (rom.content[0x4000] === 65 && rom.content[0x4001] === 66)
|| (rom.content[0x8000] === 65 && rom.content[0x8001] === 66))) return this.priority;
return null;
},
diff --git a/src/main/msx/slots/SlotNormal.js b/src/main/msx/slots/SlotNormal.js
index a2401bdb..4ce35d31 100644
--- a/src/main/msx/slots/SlotNormal.js
+++ b/src/main/msx/slots/SlotNormal.js
@@ -19,8 +19,8 @@ wmsx.SlotNormal = function(rom, format) {
var startingPage = 0;
mirrored = format === wmsx.SlotFormats.Mirrored ? true : format === wmsx.SlotFormats.NotMirrored ? false : null; // Force mirroring?
- // If > 32K (64K, 48K), force startingPage to 0
- if (size > 0x8000)
+ // If > 48K (64K), force startingPage to 0
+ if (size > 0xc000)
startingPage = 0;
else {
// <= 32K. Use position from info if present and mirror by default
—
Reply to this email directly, view it on GitHub
<#99>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFOLIDZTKEX4DSALMP4NCLXGQ7YBANCNFSM6AAAAAAYEPCK64>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
In order to use the stack, my program first copies 0xc000 to 0xefff from the ROM to RAM at init time. (It inefficiently switches pages for every byte.) It doesn't use the 0xc000-0xffff page of the ROM anymore after copying is finished. |
|
I see... Why not just place the ROM at 0x0000?
I will include your suggested modification on the next release.
Paulo
…On Wed, May 17, 2023 at 7:29 PM Qiqitori ***@***.***> wrote:
In order to use the stack, my program first copies 0xc000 to 0xefff from
the ROM to RAM at init time. (It inefficiently switches pages for every
byte.) It doesn't use the 0xc000-0xffff page of the ROM anymore after
copying is finished.
—
Reply to this email directly, view it on GitHub
<#99 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFOLIBWHMGGRMVL4T4S3WTXGVGLPANCNFSM6AAAAAAYEPCK64>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I must admit that I wasn't aware that it's more common practice to make 48 KB ROMs start at 0x0000. I'll consider adjusting my 48 KB programs to start at 0x0000. Thank you for considering the patch! Feel free to close this issue when you no longer need it. |
|
Shall we close the issue ? |
|
Let me investigate a little further...
Paulo
…On Mon, Dec 16, 2024 at 7:46 AM JOM ***@***.***> wrote:
Shall we close the issue ?
—
Reply to this email directly, view it on GitHub
<#99 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFOLIAMN66VU2XSOU3BW2D2F2VQLAVCNFSM6AAAAABTV3AEMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBVGIZTKMJXGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, there are two reasonable ways to organize a normal (mapper-less) 48 KB ROM, 0x0000-0xbfff (this seems to work), and 0x4000-0xffff (this doesn't work). The current code assumes the former whenever it encounters a ROM larger than 32 KB.
The following patch seems to fix the issue with the particular ROM file I was trying to load, which works in openMSX and on a real MSX1; you can download it from https://blog.qiqitori.com/wp-content/uploads/2023/05/msx1_popsa_2.rom. This ROM loads in WebMSX, but it sees the ROM contents at 0xc000-0xffff as 0xff bytes. These 0xff bytes cause playback to appear to freeze, though it actually is just executing very long breaks. After a while playback may start from the beginning again because the counter loops to 0000 and eventually may get to the correct song start address.
It also doesn't break the only other normal mapper-less 48 KB ROM (Uchusen Gamma, which has the header at 0x4000) that I have on hand, but before applying it the patch should be tested for regressions with other 48 KB and 64 KB ROMs (e.g., 48 KB with header at 0x8000, 64 KB with headers at 0x4000, 0x8000).
The text was updated successfully, but these errors were encountered: