Yes, I've looked at this in detail, but I'm really not convinced about the automatic bank switching on function calls.
A bank switch is a critical impact mechanism and I think it's important to keep these changes visible to the user.
Think about a really big code base that needs to be split across many ROM banks. Doing the switch by hand just doesn't scale when things get complicated. That's the point of automatic bank switching.
Think about a really big code base that needs to be split across many ROM banks. Doing the switch by hand just doesn't scale when things get complicated. That's the point of automatic bank switching.
I don't say that it can't be interesting in some cases, but for a game (what MSXgl is made for), I think that it doesn't bring enough compared to the risk of losing control and the performance cost.
The main use of segments in game is to put data in them. But if we are on an 8K mapper, we can easily manually use 2 banks to put code on one (decompression program or replayer) and data to parse in the other.
Anyway, I don't plan to support auto-switching in MSXgl for the moment. But as we say: « never say never ». ^^
@Bengalack Here is how I handle mapped ROM in MSXgl.
Thanks for clearing up.
My current solution is, as mentioned, of the manual kind (just like yours). There are a few advantages atm. I have lots of code (5-6 code segments), so I need code calling **other** code-segments **in the same page**. Another flexibility: I sometimes put a (non-code-)segment in page 1, and, later, in page 2.
The overhead is there of course, but kept to a minimum.
I will probably stick to the current way of doing things in Lilly's Saga, but for future projects, what samsaga2 and geijoenr is talking about, looks super elegant!
@Bengalack Here is how I handle mapped ROM in MSXgl.
Thanks for clearing up.
My current solution is, as mentioned, of the manual kind (just like yours). There are a few advantages atm. I have lots of code (5-6 code segments), so I need code calling **other** code-segments **in the same page**. Another flexibility: I sometimes put a (non-code-)segment in page 1, and, later, in page 2.
The overhead is there of course, but kept to a minimum.
I will probably stick to the current way of doing things in Lilly's Saga, but for future projects, what samsaga2 and geijoenr is talking about, looks super elegant!
I see the crt0_48k.s from you and I'll be a little harsh but I found almost all of the content not necesary or even counterproductive because, for example, no need to select ROM on page 2 by default (besides this routine is really weird, why not use the common routine?) or initialize mapper pages until the user needs them. No need to manipulate SP either. On the other hand, what is necessary is not being done. That is to say the routines which give the necessary information to manipulate the slots (Main-RAM and current ROM). It also lacks the routines to manipulate the slots.
crt0_48k.s is the boot code of 48K plain ROM, not mapped ROM one.
Personally I prefer to select all the pages of my cartridge from the start (at least for pages 1 and 2). The user can then modify them if he wants, but it seems to me personally a better starting point.
For the stack, I just followed the advice of a (long) discussion on MRC.
The initialization of the mapper pages is there to help the emulators to automatically recognize the type of the ROM. And again, I think it's a cleaner starting point.
The functionality to manage the mapper is available in the library as a macro: SET_BANK_SEGMENT(bank, segment). That's all we need because I chose not to support automatic bank switching via function calls, so I don't need all the trampoline stuff.
Creating a library means making choices. I don't think my choices are "bad"; they just fit my vision of how to create games and I think they can help to make good games. But there are obviously many other visions and I respect them.
After SCC, MSXgl now supports the MSX-Music (YM2413)!
You can access YM2413 directly and the VGM replayer now supports this sound chip.
I updated the VGM sample with a music from Undeadline which uses only MSX-Music (no PSG).
This is the 6th music: https://webmsx.org/?MACHINE=MSXTR&ROM=https://github.com/aoi...
After SCC, MSXgl now supports the MSX-Music (YM2413)!
Cool!
I did a quick peek at the code of the vgm-player (https://github.com/aoineko-fr/MSXgl/blob/main/engine/src/ayv...). It seems to need wait-commands like
0x62 wait 735 samples (60th of a second), a shortcut for 0x61 0xdf 0x02 0x63 wait 882 samples (50th of a second), a shortcut for 0x61 0x72 0x03
does it?
from my experience, music recorded via vgmrec in openmsx does not use those, but this:
0x61 nn nn Wait n samples, n can range from 0 to 65535 (approx 1.49 seconds). Longer pauses than this are represented by multiple wait commands.
I've often seen that recorded music does not reflect that music has been played from a player that plays precisely "once per frame and at the same 'place' in the frame" (sometimes at the start of a frame and then suddenly 3/4 into another frame). I guess the recorder in openmsx records the fact that processing code takes time too :)
I'm just pointing out a vgm isn't always straight forward to convert to something (like a game) which should play back once per frame (only).
(or maybe it is just straight forward, but in that case, I have bugs in my code - bugs that has survived many iterations)
The MSXgl's VGM replayer handle:
- 0x7n: 4-bits +1 waits
- 0x61: 16-bits waits
- 0x62 : 60 Hz frame waits
- 0x63 : 50 Hz frame waits
I don't know if the VGM files I use for test, have been made using OpenMSX or MAME (both exists on https://vgmrips.net).
Analysing data, I found all those wait codes are used.
In theory, these numbers should be accurate if the emulation is well done since they correspond to the moment when the sound chip is accessed.
But I didn't look at the details of the VGM exporters implementation to make sure that this was the case.
For the VGM SCC music I analyzed, I had plenty of micro-waits between the modification of the waveform bytes that correspond, I guess, to the time the code takes to update the data in the original game.
For an MSX replayer, it's almost impossible to recreate the exact timing, but from what I could test (cf. the sample ROM), it still works very well with 1 update per frame.
The only real problem is the music made for a 60 Hz machine that you try to play with the timing of a 50 Hz machine. In this case, some effects can disappear because the registers are overwritten twice in the same frame.
This is very audible on the music of Dragon Slayer 4 on a 50 Hz machine.
In theory, these numbers should be accurate if the emulation is well done since they correspond to the moment when the sound chip is accessed.
Agree. Still I found some special cases when recording from MoonBlaster. I might bake up a case of this, at a later stage. Will focus on finishing Lilly's Saga first.
But all-in-all, sounds like your vgm-replayer should handle the most important things. Thumbs up!