Thread Rating:
  • 3 Vote(s) - 4.67 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Native VGM player for the NGP(C)
I suspected the last one, but I would have never guessed the reason behind the size limit. Haha. Nice one.
I've been working on an improved version of a VGM packer that I originally wrote for use with the SNES. The original packing scheme has been changed to the following:

Each group of 7 VGM commands are preceded by one byte worth of flags:


p: if 1, the corresponding VGM command is a "PSG write" command (0x50 0xnn) and only the argument (0xnn) will be stored in the compressed stream. if 0, the corresponding command is something other than a "PSG write" command and is stored verbatim.

w: if 0, all commands in the group for which the corresponding p-bit is 0 are "wait one frame" commands (0x62 or 0x63), and those command bytes will not be stored in the compressed stream.

This compression technique will fail if a song uses both command 0x62 (wait 1/60 s) and 0x63 (wait 1/50 s), but I see no good reason for why any song would do that.

According to my tests this gives a compression ratio of about 1.85:1 for most songs, and in some cases over 2:1 (for SMS/GG songs that is, it doesn't pack NGP songs nearly as good).
For example, this:

50 83 50 15 50 A9 50 0A 62 50 F4 62

would be compressed into this:

2F 83 15 A9 0A F4

If I also bumped up the maximum ROM size to 4 MB you'd be able to fit something like 3.5 hours worth of VGMs Tongue
Question: is it possible for you to update your driver to use the z80 interrupt ?
Instead of letting the tlcs code check if data is needed, the z80 could ask for new data using this interrupt (writing something at #c000 with the z80 code will generate the signal).
I think the easiest solution would be to put the check in your VBlank handler. See my minimal VGM playback example where I do just that.

Forum Jump:

Users browsing this thread: 2 Guest(s)