05-01-2012, 04:20 AM
I suspected the last one, but I would have never guessed the reason behind the size limit. Haha. Nice one.
Native VGM player for the NGP(C)
|
05-01-2012, 04:20 AM
I suspected the last one, but I would have never guessed the reason behind the size limit. Haha. Nice one.
05-02-2012, 04:00 PM
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: wppppppp 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
04-17-2013, 01:06 AM
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).
04-17-2013, 01:22 AM
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.
|
« Next Oldest | Next Newest »
|