It seems like the player can crash sometimes if the VGM file does not end with a 0x66 command. (This includes all files generated with MIDI-to-VGM translator.) It didn't happen in dosbox, but happened on my 286. The problem went away when I added the 0x66 byte.

Attaching VGM test file...

Thanks for the test file. It makes sense, since 0x66 is the "end of sound data" command and any properly formed VGM should have it, but I don't want it unceremoniously crashing either. One mitigation I could do at least is better bounds checking to see if the player overruns the end of a file. However if the file has a GD3 tag but no 0x66 before that, it is going to try reading the GD3 tag as a command and either send garbage to the OPL3 or quit due to encountering an unknown VGM command.

Great to see another VGM player for MS-DOS! Nice!

SBVGM is still the gold standard, though! Time-tested and versatile. I just wanted something flashier and OPL centric 😀

@bakemono - I committed a fix for VGMs missing the 0x66 command, and it will be incorporated into the next release.

MrKsoft wrote on 2024-05-08, 21:20:

SBVGM is still the gold standard, though! Time-tested and versatile. I just wanted something flashier and OPL centric 😀

Thanks! 😀 I think the more new MS-DOS software the better. So jealous of how many new things are released for the other older platforms in comparison.

With a DIVIDER setting of 1, VGMs play very slowly on my Pentium III - 450 MHz machine. I guess something is skipping updates?
[Edit]
It might be because I was running within WinME ... will have to check when I have time later.

Yeah, I should have put that in the readme - it is probably not going to work in Windows because it sets up an ISR8 handler and changes the PIT frequency to 44100hz/DIVIDER. IIRC Windows in protected mode prevents this from working as expected. There are probably more friendly ways to do timing but this one made sense to me as a learner and was able to trivially get me the 44100hz precision VGMs ask for.

MrKsoft wrote on 2024-05-11, 16:00:

Yeah, I should have put that in the readme - it is probably not going to work in Windows because it sets up an ISR8 handler and changes the PIT frequency to 44100hz/DIVIDER. IIRC Windows in protected mode prevents this from working as expected. There are probably more friendly ways to do timing but this one made sense to me as a learner and was able to trivially get me the 44100hz precision VGMs ask for.

No problem! It works in a pure DOS environment. Thanks for the update.

R2 is now available, with lots of fixes: https://github.com/MrKsoft/vgmslap/releases/tag/r2

• Rewrote screen update code to only write screen areas when the actual chip data changes instead of refreshing the whole thing. Performance is only marginally better overall, but it is much more responsive on under-specced systems.
• OPL2 detection now actually works outside of emulation.
• Disabled interrupt timer mistakenly left on while decompressing VGZs, now it completes a lot faster.
• Improved handling of VGMs that are missing "end of song data" command (0x66).
• Fixed a mistake in sample position calculation; all commands advanced the position counter even if there were multiple commands in one sample. This may have been a contributing factor to the DIVIDER configuration setting making complicated VGMs sound weird, so setting a higher DIVIDER should be less of a problem now!
• Fixed issue where playlist entries would fail to load on some systems.
• Fixed OPL register/data write delays being reversed.
• Error messages related to file loading are more descriptive.

R3 has just been released: https://github.com/MrKsoft/vgmslap/releases/tag/r3

• Added some bars at the bottom of the screen showing channel output levels by simulating the ADSR rates. There are a few edge cases where it isn't accurate but overall it provides a good approximation.
• Slightly better representation of percussion mode - the note-on indicators light up now, and change to a ! symbol to show they are percussion. This will likely be expanded later to a dedicated percussion mode display of some kind.
• Fixed 4-op channel display - all 6 channels that were capable of 4-op were shown combined, even if only a single channel had the 4-op flag enabled.
• Channels display in numerical order if 4-op mode is off.
• Struggle bus mode fixed to not leave an empty channel table on screen - this was a mistake introduced when reworking the drawing code. It also now leaves the system in 80x25 text mode instead of unnecessarily switching to 80x50.
• Under the hood, the source code has been restructured. It has been split out from a single gigantic file, and now has a proper build system! Rejoice!

Hi. Thanks for the nice tool. I was trying VGMSlap the other day to capture instruments from actual game music and replicate them inside of Adlib Tracker 2.
However, several parameters are shown "interpreted" in VGMSlap rather than actual register values. AdTrack2 takes the register numbers without much fumbling AFAICT.
Is it possible to have a mode where you show actual register values instead of converting them to more "human understandable" display?
Things like wave form shape, feedback, volume (I think this is reversed) and so on.

Another nice to have feature is if you can consume .DRO files directly. Not very important, but more of a convenience feature, since DRO->VGM conversion tools exist.

Otherwise, very cool! Thanks, and keep it up!

wbahnassi wrote on 2024-07-24, 12:45:

Hi. Thanks for the nice tool. I was trying VGMSlap the other day to capture instruments from actual game music and replicate the […]
Show full quote

Hi. Thanks for the nice tool. I was trying VGMSlap the other day to capture instruments from actual game music and replicate them inside of Adlib Tracker 2.
However, several parameters are shown "interpreted" in VGMSlap rather than actual register values. AdTrack2 takes the register numbers without much fumbling AFAICT.
Is it possible to have a mode where you show actual register values instead of converting them to more "human understandable" display?
Things like wave form shape, feedback, volume (I think this is reversed) and so on.

Another nice to have feature is if you can consume .DRO files directly. Not very important, but more of a convenience feature, since DRO->VGM conversion tools exist.

Otherwise, very cool! Thanks, and keep it up!

I can't guarantee it, but I could look into having it as an alternate display mode in the future alongside some others I'm thinking of (need some code shuffling to untie some of the interpretation/drawing code first). The register values are stored as-is and the only change is what's being put on screen as a result of those numbers, so the capability is there. That said the goal of the program is mostly to look nice and make it more human understandable.

If you're looking to do instrument rips, have you tried importing VGMs using OPL3BankEditor? I've used that in the past and additionally worked with it to help verify results for what VGMSlap is putting on screen. It may not be 100% ideal for importing into AT2 if you're doing 4-op, though - I don't think it exports any 4-op capable formats that AT2 understands. (It does for Furnace, though)

Regarding chip values, VGMSlap stays pretty close to what's actually being put into the chip. Even the "interpreted" values are tied directly to the values in the register. You can cross reference with this mirror of the well-known OPL3 Programmer's Guide. For example, if VGMSlap shows the feedback value "/4" it aligns to the same "/4" value as written in the guide, which is register value 3. Heck, I've been doing this so much now that I've started to memorize the mapping between them. 😀
In comparing to tracker programs, the most common differences seem to be in how the volume is interpreted. The OPL internally uses "volume attenuation" so 0 really is the loudest value and 3F really is the quietest (or highest attenuation). I believe AT2 inverts this intentionally because that is more like what a musician would expect, that the highest value equals the highest volume. Just doing a cursory look at AT2, which I haven't used in a few years, I think everything else lines up as expected. (I think OPL3BankEditor mentioned above also inverts volume, and Sustain as well)

Lastly, DRO support, while simple, not a priority. It used to be more popular, but is poorly suited to casual listening, and seems to mostly be used now as an intermediary format on the way to VGM anyway. Heck, all the VGM work that I do bypasses DRO completely with a patched DOSBox. I have done some preparatory work to decouple the VGM reading from the rest of the program, though, so who knows what the future will hold?

Thank you. I will give OPL3BankEditor a try. Last time I used it gave me some difficulties to make it even output sound. And yes, DRO is just for convenience.. perhaps it would be even better if DOSBox actually writes out VGM instead of DRO from the get go.

Gave OPL3BankEditor another go. Indeed it can import instruments from VGM files, but it's quite well hidden.. plus the UI controls to select the instruments to import is broken. The list control for selecting instruments is supposed to support multi-select but actually it is set to single-select. Thus, even the Select All button cannot do its function. So you have to click each instrument one-by-one and import them like that.

Once in, the program indeed shows a very good representation of all the register values, and moving them to AdTrak2 is straightforward.

Thanks again for both your suggestion and VGMSlap 🙂

Published R4 today, basically a hotfix release: https://github.com/MrKsoft/vgmslap/releases/tag/r4
Turns out there was a sizable memory leak on long playlists due to the GD3 tag handling. Whoops!