The VGM replayer is mostly a way for me to easily test the new sound chips I want to support for MSXgl. ^^
It can hardly be used as is in a game because of the size of the music data.
BTW, I am really looking forward to Lilly's Saga \o/
Keep up the great work!
To replace high resolution waits by 0x62 and 0x63 you can use the vgm_facc tool.
This is what I do in the ayVGM format.
BTW, after studying the operation of the YM2413 and generated VGM data, I think it is a good candidate for addition to the light VGM format. I'll see if I can find a format compact enough to get a reasonable size for a game.
In Tile² I use 00H-0FH for PSG register writes, 40H-7FH for OPLL register writes, 80H for jumps and 81H-FFH for waits. A jump has a target bank and address. If the data spills out of an 8K bank the generator inserts a jump to the next bank. Other than that the jump is used for loops, and if the song doesn’t loop it generates a 1-cycle wait + a jump at the end.
The resulting replayer is very fast (5% CPU time max), data size is acceptable to me (36604 bytes for Xak - Town of Nemnu). A path for further data reduction that I’ve explored (but not completed) is to introduce “call” and “ret” commands to extract repetitive command sequences.
I’m curious to see what you will end up with, since the above encoding is more compact than VGM, but still simple compared to what you did for the PSG. The upside of the simplicity is that the player does not need a big switch so the code stays compact and fast.
crt0_48k.s is the boot code of 48K plain ROM, not mapped ROM one.
That's one of the reasons there's a lot of useless stuff in there.
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.
If you are doing a general library for everyone, you should avoid "personally I prefer". It becomes more complicated to find the RAM on page 2 if you automatically remove it at startup.
For the stack, I just followed the advice of a (long) discussion on MRC.
This is bad advice because if you make a ROM that installs things but returns control to system (to use disks for example), it can cause problems.
I chose not to support automatic bank switching via function calls
Why not leave the choice?
Creating a library means making choices.
Yes but not personal. A library is for general use. And normally, this serves to simplify things.
Don't take my criticisms the wrong way, I'm glad to see this project. For once someone tries to make something accessible, I wish it was done well.
To replace high resolution waits by 0x62 and 0x63 you can use the vgm_facc tool.
Oooh, it sounds like something that would have saved me hours and hours. From the docs it's stated
Even then, make sure the left/right errors aren't too high, else you will introduce jitter.
Sounds familiar! And this:
The 3rd line is included, because initialisation can take many commands and takes more time than the rest of a song.
Right, from my findings, it seems like MoonBlaster starts preparing instruments (i.e. sending commands to the ports) as "pre-step", and not something that is part of the tune, timingwise these milliseconds seems outside the original tune.
Anyways, thanks for the tip - even if my custom vgm_facc-tool works, I'm curious to test this one out. Just need to get that build-env for PC set up correctly...
Hi,
I'm adding MSX-Audio (Y8950 chip) support for MSXgl but I run into a problem.
I hesitated to create a separate thread, but it's probably a trivial issue.
To check Y8950 support I added to my VGM replayer sample 2 MSX-Audio musics, and if everything works fine on BlueMSX, I have no sound on OpenMSX with -ext audio or -ext Philips_NMS_1205 extensions.
I checked the sound options of OpenMSX (I use version 1.16) but everything is normal (volume 75 and no mute).
For the moment, I use the basic way of detecting MSX-Audio (just checking in(C0h) == 06h) but it's work fine on OpenMSX with both extension, and on BlueMSX.
Anyway, even if the MSX-Audio is not found, my VGM replayer still sends data to the MSX-Audio I/O (C0h/C1h) so the problem should not come from there.
Any idea?
In my VGM replayer sample the MSX-Audio musics are number #8 and #9
For the moment, I use the basic way of detecting MSX-Audio (just checking in(C0h) == 06h) but it's work fine on OpenMSX with both extension, and on BlueMSX.
The bits 1 and 2 of the MSX-AUDIO status register are floating. Because of that, this way of detecting only works on MSX computers with pull-ups on the machine’s internal bus, which makes those bits go high. So you should mask these two bits out before checking the value: in(C0h) & 06h == 0.
In VGMPlay MSX I detect it like this: first a quick status register check with bits 1-2 masked out, and then I check if starting ADPCM raises the PCM BUSY status flag. The latter check not only improves the robustness of the simple first check, but also confirms it is an MSX-AUDIO and not e.g. an OPL or OPL4.
In VGMPlay MSX I mask out various writes to control registers:
- FLAG CONTROL (04H) writes are completely ignored
- MISC CONTROL (08H) writes ignore bits 0-1 and 3-5
- IO CONTROL (18H) writes are completely ignored
I bet the IO Control register write is the culprit. I believe the Philips NMS-1205 has a sound output enable on one of the GPIOs, where on the Panasonic FS-CA1 it has a different function. OpenMSX matches the real hardware in this regard. BlueMSX is no longer maintained for more than 10 years.
