SEGA GENESIS VGM PLAYER
Moderator: Mask of Destiny
-
- Interested
- Posts: 28
- Joined: Sat Dec 08, 2007 10:50 pm
- Location: UK
- Contact:
SEGA GENESIS VGM PLAYER
I have created a vgm player for the genesis that works quite well, with dac sample support. Plays nearly all the vgm tracks that I have tried flawlessly.
I originally emailed fonzie of genny4ever.net and he told me that people here may be interested in this little thing I have made. I am at this time triying to create a small website with some of the things I have made in the past year (not much) but its not up yet so if anyone is interested enough to want a copy then then can email me and I will send it to them.
michaelstamper1@gmail.com
I originally emailed fonzie of genny4ever.net and he told me that people here may be interested in this little thing I have made. I am at this time triying to create a small website with some of the things I have made in the past year (not much) but its not up yet so if anyone is interested enough to want a copy then then can email me and I will send it to them.
michaelstamper1@gmail.com
-
- Interested
- Posts: 28
- Joined: Sat Dec 08, 2007 10:50 pm
- Location: UK
- Contact:
If anyone is interested iv'e put up a small website featuring some of the other crap I have made. A few good things on there, and whatever else I can find on my hard disk.
http://mjsstuf.x10hosting.com/
http://mjsstuf.x10hosting.com/
-
- Interested
- Posts: 28
- Joined: Sat Dec 08, 2007 10:50 pm
- Location: UK
- Contact:
To the question of making a vgz player: -
------------------------------------------------------------------------------------
1. The vgm format is in its raw state very taxing on the 68000, just to get it to play dac samples I had to highly optimise the assembly.
2. On most if not all vgm players supporting vgz there is enough ram available to decompress the entire file at once. Without such ram one would have to seek back and forth through the compressed data to access the dac samples. Whilst a custom decompressor could probably be made to do this it would be far to slow for dac sample files.
3. Its possible that one could decompress the pcm data block but leave the rest compressed since it is read siquentialy (pcm does'nt compress to well anyway) Even then like in part 1 I stated the vgm format was taxing, what with its unaligned reads, complex list of commands ect.
4. The only way to really thin down the files is to completely re-encode them into a more simplified file. With the delay calculation built in to the re-encoded file. And also for vgms from the same game sharing of commmon parts of the pcm data blocks. I am actally planning to do this at some point.
-------------------------------------------------------------------------------------
To sum up that bable I shall state here and now as what I belive to be a fact. There is no chance of getting the genesis to play vgz files:- well maybe very simple ones but not dac sample filled ones. Its working at its max just to play standard vgm's
------------------------------------------------------------------------------------
1. The vgm format is in its raw state very taxing on the 68000, just to get it to play dac samples I had to highly optimise the assembly.
2. On most if not all vgm players supporting vgz there is enough ram available to decompress the entire file at once. Without such ram one would have to seek back and forth through the compressed data to access the dac samples. Whilst a custom decompressor could probably be made to do this it would be far to slow for dac sample files.
3. Its possible that one could decompress the pcm data block but leave the rest compressed since it is read siquentialy (pcm does'nt compress to well anyway) Even then like in part 1 I stated the vgm format was taxing, what with its unaligned reads, complex list of commands ect.
4. The only way to really thin down the files is to completely re-encode them into a more simplified file. With the delay calculation built in to the re-encoded file. And also for vgms from the same game sharing of commmon parts of the pcm data blocks. I am actally planning to do this at some point.
-------------------------------------------------------------------------------------
To sum up that bable I shall state here and now as what I belive to be a fact. There is no chance of getting the genesis to play vgz files:- well maybe very simple ones but not dac sample filled ones. Its working at its max just to play standard vgm's
-
- Very interested
- Posts: 326
- Joined: Mon Mar 12, 2007 1:53 am
- Contact:
I see. I know nothing about programming, but I trust your competence. The reason I'm asking is because of the high quality of the vgz rips and they're availiability through project2612.org (they have already covered most titles). Maybe it's possible to do accurate conversions from vgz to vgm?MIKE-STAMP wrote:To sum up that bable I shall state here and now as what I belive to be a fact. There is no chance of getting the genesis to play vgz files:- well maybe very simple ones but not dac sample filled ones. Its working at its max just to play standard vgm's
-
- Interested
- Posts: 28
- Joined: Sat Dec 08, 2007 10:50 pm
- Location: UK
- Contact:
A vgz file is just a zip file with a different extension. I you open the vgz file with winzip or zome other zip program you can extract the contents. Most vgms are under 2meg in size when extracted. So will work with my vgm player.
(the reason the full size of the cart can't be used is that the cart ram is at 2meg. I hav'nt written a rom builder yet that parses the vgm and at a convinient spot useing a free opcode to signal the player to jump over the ram. I'm so pressed for clocks that just adding the one extra range check would cause a buffer exhaustion).
(the reason the full size of the cart can't be used is that the cart ram is at 2meg. I hav'nt written a rom builder yet that parses the vgm and at a convinient spot useing a free opcode to signal the player to jump over the ram. I'm so pressed for clocks that just adding the one extra range check would cause a buffer exhaustion).
-
- Interested
- Posts: 28
- Joined: Sat Dec 08, 2007 10:50 pm
- Location: UK
- Contact:
What I meant in that terably written text file is that. If I re-encoded the vgm files in my own format, Taking into account that only one register can be written per sample, I could remove the code that deals with the sample lag, If I use an extra opcode in the re-encoded vgm data to tell the player when the buffer should rap around the range, checking for this could be removed, then there would be some free cpu time. But with unmodified files... they only just play. No time for rest.
Oh, has anyone got any documents on the sega cd, someone said something that gave me the idea to try and make vgm player for it. Though that greatly depends on the cpu overhead for accessing the cd rom.
Oh, has anyone got any documents on the sega cd, someone said something that gave me the idea to try and make vgm player for it. Though that greatly depends on the cpu overhead for accessing the cd rom.
I wasn't aware that you absolutely had to use SRAM at $200000 if you didn't want to. I thought that was a function of the cart hardware (plus notation in the header that the SRAM exists). Have you tried just using the whole 4MB yet? Have you tried such a ROM on real hardware (using something like the Tototek cart)?MIKE-STAMP wrote:(the reason the full size of the cart can't be used is that the cart ram is at 2meg. I hav'nt written a rom builder yet that parses the vgm and at a convinient spot useing a free opcode to signal the player to jump over the ram. I'm so pressed for clocks that just adding the one extra range check would cause a buffer exhaustion).
-
- Very interested
- Posts: 615
- Joined: Thu Nov 30, 2006 6:30 am
You are correct sir. The Genesis/MD just maps the first 4MB of address space to the cart port. It's up to the cartridge itself to manage mapping in any save RAM if available. A fair number of carts did map ROM to $0 and SRAM to $200000 though simply because it's quite simple to do and can be done with a single off-the-shelf part (a 2 to 4 line decoder for instance).LocalH wrote:I wasn't aware that you absolutely had to use SRAM at $200000 if you didn't want to. I thought that was a function of the cart hardware (plus notation in the header that the SRAM exists). Have you tried just using the whole 4MB yet? Have you tried such a ROM on real hardware (using something like the Tototek cart)?MIKE-STAMP wrote:(the reason the full size of the cart can't be used is that the cart ram is at 2meg. I hav'nt written a rom builder yet that parses the vgm and at a convinient spot useing a free opcode to signal the player to jump over the ram. I'm so pressed for clocks that just adding the one extra range check would cause a buffer exhaustion).
I have some documentation on my site: http://www.retrodev.com/ though I believe the official documents are floating around now.MIKE-STAMP wrote:Oh, has anyone got any documents on the sega cd, someone said something that gave me the idea to try and make vgm player for it. Though that greatly depends on the cpu overhead for accessing the cd rom.
Generally speaking using the CD-ROM drive doesn't place any burden on the Genesis/MD CPU as the SUB-CPU (the one in the Sega CD itself) manages the drive. There's a small amount of overhead involved in sending data between the two processors.
You can use the SLO source as a base if you want. I think I have a newer version than what's on the site laying around somewhere if you want it.
-
- Interested
- Posts: 28
- Joined: Sat Dec 08, 2007 10:50 pm
- Location: UK
- Contact:
No you don't have to use the ram if you don't want to, the vgm player needs the ram. The 68000 parses the vgm file and the z80 performs sample accurate timing. The 68000 takes the complex vgm format and breaks it down into the most simplest form to put in the shared buffer in the cart ram.
The 68000 code could probaly be improved a little bit but the z80 code is perfect. Gives simple functions with known length in samples.
I had just started writting a essay about the working of the vgm player but then realised that would be deviating from the response to the previous post.
----------------------------------------------------------------------------------------
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.
The 68000 code could probaly be improved a little bit but the z80 code is perfect. Gives simple functions with known length in samples.
I had just started writting a essay about the working of the vgm player but then realised that would be deviating from the response to the previous post.
----------------------------------------------------------------------------------------
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.