SEGA GENESIS VGM PLAYER

[mic_]

ROM builder could convert VGM data to any other format, more optimized for playback.

Well, you're free to write such a program if you want to. But I'm talking about something that I've already written and which is working - not something that could be done.

I did get another idea for a compression scheme though, but I haven't tried it out yet..

[MIKE-STAMP]

I only have one MD, (va6) and it works on that. I am also very sure that I clear down all the vram on start up. I have no idea whats up with that.

lea $ff0000,a0
lea $c00000,a1
move.l #$8f028f02,4(a1)
move.l #$40000000,4(a1)
move.w #16383,d0
clr.w d1

GEN_INITL1
move.l d1,(a0)+
move.l d1,(a1)
dbra d0,GEN_INITL1

move.l #$40000010,4(a1)
move.w #0,(a1)
move.l #$40020010,4(a1)
move.w #0,(a1)

move.l #$c0000000,4(a1)
move.w #63,d0

GEN_INITL2
move.w #$0000,(a1)
dbra d0,GEN_INITL2

I clear down the ram using this code.

Your vgm sample compression works really well, I did not think it would yield results quite that good. Compressor using 7MB of ram Euphoria seems to have quite abit of overhead?

[mic_]

Compressor using 7MB of ram Euphoria seems to have quite abit of overhead?

Even though it's a an .exe my program isn't compiled. Instead, the .exe is the interpreter and my source code bundled together. So my program gets interpreted every time you run it, which I suppose has some overhead. And then there's the fact that I read the entire uncompressed VGM into a sequence (array) and also store the compressed VGM data in another sequence. Each sequence element will use 4 bytes regardless of whether the data you store in them fits in a single byte.

But I use it a lot for prototyping purposes, and then if I really need better performance (usually I don't) I sometimes rewrite the program in C++.

[TascoDLX]

I am also very sure that I clear down all the vram on start up. I have no idea whats up with that.

<snip>

clr.w d1

GEN_INITL1
move.l d1,(a0)+
move.l d1,(a1)

That could be a problem.

EDIT: It looks like the MegaCart BIOS fudges the VDP mode registers (it unintentionally sets Mode 4!) before exiting. I recommend you set the VDP registers -- at least the first two -- *before* doing anything else with the VDP. Hopefully that will fix it.

[LocalH]

Rule of thumb for coding - never take the power-on values for granted, lest your method of booting software not give you the values you expected. First thing I always did in my code was clear VRAM and set up the VDP as I need it, all registers.

[MIKE-STAMP]

To fix the problem with the MegaCart bios I have made a small binary patch which will modify the vgm player image in Vgm_Play.exe

http://mjsstuf.x10hosting.com/SEGA%20DEV/VgmPatch.zip

[TascoDLX]

Sorry, Mike, but you're gonna have to redo that patch. You need to set the security register ($A14000) before accessing the VDP. It should work on systems without TMSS, though.

And you should probably change that clr.w d1 to clr.l d1. Something like that may not cause a problem until the reset button is used.

[MIKE-STAMP]

Well I have reuploaded the patch and it goes through the security register now, I had forgotton about the security register. I have not really done any MD stuff since january.

http://mjsstuf.x10hosting.com/SEGA%20DEV/VgmPatch.zip

[mic_]

I've implemented a dictionary-based compression scheme now that usually works better than the run-length compression (sometimes much better). The dictionary doesn't change during decoding so it doesn't cause any problems with looping.

The dictionary itself is stored in the VGM file as a data block:

0x67 0x66 0x01 0x00 0x01 0x00 0x00 (the length is always fixed to 256 bytes) followed by 256 PCM write commands, i.e. 0x8n 0x8n 0x8n ....

And any encoded strings of PCM write commands are stored as:

0x4D ss nn where ss is the starting position in the dictionary and nn is the length of the string (the dictionary is cyclic so you can wrap around the end). So it's a very easy format do decode.

The encoder and its source code (C++) is here: http://jiggawatt.org/badc0de/vgmpack2.zip

The new compression scheme is used by executing:

vgmpack -2 input output

and the old run-length compression:

vgmpack -1 input output

[Graz]

I've implemented a dictionary-based compression scheme now that usually works better than the run-length compression (sometimes much better).

Nice work. What kind of compression ratios are you getting from your new dictionary based approach?

[mic_]

I've made some further improvements that I haven't yet released.. but I've tried it with a few different songs from Gods, Ys III, Contra Hard Corps, Toy Story and Micro machines 2, and I've seen compression ratios ranging from around 30% to around 80%. So it depends on the song and how it uses the DAC.

[MIKE-STAMP]

And now a release none of you were waiting for VGM_PLAY V3.00
http://mjsstuf.x10hosting.com/SEGA%20DE ... elease.zip

Re-encodes vgm files into an MD optimised format,
More compact,
Dac sample compression,
Optional YM2612 duplicate write removal,
Better timing than V2.00 (I think)

[mic_]

Nice. It seems to compress even better than the codecs I put together a couple of months ago, and timing is still better.

One minor issue is that when I run the player on my Megadrive with the MD Myth cart there's some garbage on the screen:



Did you forget to clear plane B maybe? If i press the reset button it looks ok.

As far as using std::vector goes.. yeah, it may not beat the world record for speed. But it's always a balance of execution efficiency vs programming efficiency. And doing VGM compression on a modern PC isn't a very time-consuming task even if you don't use the most efficient data structures and algorithms, so I just went with stuff that I was familiar with so that I could get the job done quickly.

[TmEE co.(TM)]

The Myth seems to be having some issues in some unknown conditions... it runs flawlessly on my own flashcart and Megacart.

[TascoDLX]

I already pointed this bug out but Mike probably just missed it. In the init code (clearing work RAM and VRAM), clr.w d1 should be clr.l d1.