SpritesMind.Net

I'm not sure how it would work in emulation since a good number of official SRAM-enabled carts did place it at $200000 AFAIK, but theoretically you can place the RAM anywhere you want, as long as the cart hardware is designed around that. I'm not even sure if you absolutely have to denote it in the header, although it may be necessary for emulation. How much cart RAM are you using? You could try putting it at the top of ROM space, leaving the space in-between for the VGM. Alternately, you could try placing it inbetween your code and the VGM data. Once again, I don't know how this would pan out for emulation, nor with cart copiers or flash carts, but with a suitably-designed PCB I'm certain that it would work at least on real hardware.

MIKE-STAMP wrote:on a different subject, does anyone have any information about how to access the cd hardware in the sega cd. I am now trying to write a new version of my vgm player for the sega cd.

Fonzie has the biggest selection of docs. You'll find the SEGA CD docs there.

http://www.genny4ever.net/index.php?page=docs

I had downloaded all of your demos.
Good job guy !

For the moment, i prefer this : "Z80MUS.BIN", lot of zics in the same rom, great idea !

Very funny and good stuff !

A+

Emulators only emulate SRAM in $200000 to $20FFFF range (64KB)... Genecyst is the only one that emulates full 2MB of SRAM.

@Shiru ,Mike-Stamp...
I have this little idea...
Is possible in future version display author and song name ,total time and current possition in song on MD screen (into BIN or SMD)???
Simple TXT menu player (for more songs...)????
Something like this one 8bit player for Atari... but with more features.

I supose it would be possible, vgm files though are usually very consuming on space, so there is only a limited number of games in which you could get more that a couple of tracks on. Could probaly get away with the increased cpu usage but, adding things does increase the likelyhood of the buffer becomnig empty. I could easylt though read the gd3 tag, and support for multiple tracks.

MIKE-STAMP wrote:I supose it would be possible, vgm files though are usually very consuming on space, so there is only a limited number of games in which you could get more that a couple of tracks on.

That's why you want to make a player for Mega CD? It would be really cool having the entire library on one or a few discs, to play on real hardware.

Yes, iv'e been working quite hard on the mega cd version. Running up against quite a few problems. The mega cd is an horible machine. The lack of any shared memory is causing me problems. And also, the megacd docs say that the z80 should not access the word ram. If the real hardware has issues with this i'm screwed.

Wow

Btw, you might be able to cleverly mix 1M and 2M ram modes (so you can always keep 128KB for z80 and the other 128KB alternatively on megacd or megadrive side for the undécoded VGM file... That's just an idea.

I would not suggest to bus request the megacd pgrm ram... I do it for tavern rpg and it cause a lot more issues than expected ^^

About the z80 reading the Word ram... I suspect it is possible because many ports (with just intro FMV) ran from the word ram, z80 included (probably).
Just get sure to halt the Z80 for few cycles when switching word ram modes/sides (sometimes, the hardware take some time to react, f***** hardware).

Good luck!

I tired the software with my tototek flash cart and it doesn't work...

You might know this already (I didn't bother reading through the entire thread), but your player doesn't seem to clear VRAM properly when starting. This is what I get on my Megadrive II + Megacart:



That garbage on the top half of the screen is leftovers from the Megacart menu.

its far worse on MD1... at least with some versions. I recall the version I have having no garbage.

One of the major issues with Genesis VGM players is the size of VGM files that do a lot of PCM playback, and the harsh limits that puts on the number of songs you can fit on a cart (at least if you have a 4MB cart like me). Decoding VGZ files in real time on a Genesis isn't really an option IMO. I briefly considered LZSS because I think it would be perfectly doable as long as you only access the data sequentially. But it would cause problems when seeking in the PCM data bank or when looping.

So instead I thought I'd extend the VGM format by using some of the unused command ranges to add some run-length encoding. I decided to focus only on compressing the 0x8n commands since they are the major space eaters.

Here's what I did:

If you have a long sequence of the same 0x8n command (like "0x84 0x84 0x84 0x84 0x84 ...") it will be encoded as 0xAn rr where rr is the run length minus one. So if you had 50 0x84:s in a row they would be encoded as 0xA4 0x32.

A far more common scenario is to have a long sequence of 0x8n commands but with varying values for n, e.g. "0x83 0x84 0x80 0x82 0x84 0x83 ...". In these cases the entire sequence (up to a length of 512 commands, and truncated down to an even length) will be encoded as 0x4E rr nm nm nm ...

rr is the number of bytes that follow, and each nm byte is a pair of n-values, where m comes from the first command and n from the second. So e.g. if you had 0x83 0x84 0x80 0x82 0x84 0x83 it would be encoded as 0x4E 0x03 0x43 0x20 0x34. Sequences of less than 6 commands will be encoded as-is (though usually these sequences are quite long).

I don't see any problems with decoding this in real time on the Genesis and still achieve accurate timing, but I'll try to add support for it to my own VGM player later to find out.

So far I've written an initial version of the encoder, and when trying it out on some VGMs that do a lot of PCM playback I've seen compression ratios of 40-70%, so it seems to work fairly well considering its simplicity.

Looks like I spoke a bit too soon.. There was a bug in my encoder which I didn't discover until I actually tried to play back one of the packed files. So the actual compression ratio is more like 30-35% when using 0x8n commands with mixed n-values. If n is always the same the compression ratio can still be something like 70%.

Here's the encoder for anyone that's interested: http://jiggawatt.org/vgmpack.zip
It's a Windows console application for now, so you invoke it with vgmpack inputFile outputFile

I don't really get what's the point to have actual VGM format on SMD side. ROM builder could convert VGM data to any other format, more optimized for playback.