z80 vgm player

bastien · Post by **bastien** » Thu Oct 25, 2012 6:39 pm

hi,
i have tried to compile it but SGDK return me some error.
for exemple :

error: syntax error before "nop"

in the L92 of vgm_drv.c

you have defined DELAY with this :

Code: Select all

#define DELAY \
 __asm \
  nop \
  nop \
  nop \
  nop \
  nop \
  nop \
  nop \
  nop \
  nop \
  nop \
 __endasm;

maybe you could use asm like this :

Code: Select all

#define DELAY
asm(
"       nop\n"
"       nop\n"
"       nop\n"
"       nop\n"
"       nop\n"
"       nop\n"
"       nop\n"
"       nop\n"
"       nop\n"
"       nop\n"
);

i'm actually try to fix and compile it for sgdk

kubilus1 · Post by **kubilus1** » Thu Oct 25, 2012 7:11 pm

Are you compiling the vgm_drv.c file, or are you compiling one of the sample programs that use the driver?

What dir are you in and what command did you type?

Mostly, you won't have to compile the vgm_drv.c because I include the vgm_drv.h that the front end uses. If you do want to work on the vgm_drv.c, then be sure to use the included Makefile for that and to patch your sdcc tree as specified by sigflup.

If you just want to *use* the driver under sgdk, then take a look at the examples under sound_drvr_export/client/sgdk.

bastien · Post by **bastien** » Thu Oct 25, 2012 7:39 pm

that's works now

sorry for the mistaken and thanks !

bastien · Post by **bastien** » Thu Oct 25, 2012 8:03 pm

You're driver is just Amazing

Looks at this roms :

http://sega4ever.power-heberg.com/tutod ... 0clash.bin

Thanks you very much for your job , that's the best way for making music for Sega Megadrive easily !

Manveru · Post by **Manveru** » Sun Oct 28, 2012 9:15 am

Great job kubilus1. I am begining with genesis coding and learning SGDK and your driver is a great help for me.

I have tested a pair of tracks downloaded from http://project2612.org in some emulators, replacing the tracks from the example in the files with my tracks after executing bin2c on them , but they play a bit slow, like slow motion. Am i doing something wrong or i need to resample the vgms?

Thanks

kubilus1 · Post by **kubilus1** » Mon Oct 29, 2012 12:51 am

Manveru,

You are right that a lot of the VGM files posted on project2612 play slow. Mostly the vgm driver is tested with VGM files outputted from Deflemask in either 1.60 or 1.61 format. The files on project2612 all seem to be 1.50 format. Not sure if this is necessarily the cause.

I also notice that the VGM files downloaded from project2612 are very large in size, even for similarly sized songs. I think they just have too much data for the poor driver to keep up with. I'm not sure if they were intended to be played in such a manner.

I would stick with 1.60+ format and stuff spit out from Deflemask for now.

-Matt

Manveru · Post by **Manveru** » Mon Oct 29, 2012 3:41 am

Thanks for your answer kubilus1.

You are right, the OST of the games i have try are about 8mb.

I have downloaded and checked Deflemask but i have no idea about music edition or creation. I look for an option to import audio and save as vgm but i cant find it either in the software or the help. I just would like to take my wav/vgm track and convert or use it in my SGDK project. Sorry for my sincerity but i am a completely ignorant managing with music software...

kubilus1 · Post by **kubilus1** » Mon Oct 29, 2012 4:09 pm

Deflemask seems more suited for music creation than music conversion. There are several example music tracks that you can try out. Just open the 'DMF' file and save it as a 'VGM' file. That's where the Green Hill Zone track in the example comes from.

If you just want to play WAV files I know that SGDK already has some tools to do that. You are looking for PCM playback. Unfortunately, you will find the sound quality to be poor for music and the file sizes to be quite large. Great for sound effects, and perhaps good enough for some grungier sounding music.

If you just want to play other VGM from other games, you will just have to look around for files that will work, or use a different kind of player. The Road Rash tracks I included in the example are actually from this website: 'http://ocremix.org/chiptunes' and they seem to play just fine, but are much much more compact than the files from project2612. I might have to compare some of the same tracks from both sites when I have time.

Now that I've hacked on this project for awhile I feel like I understand the Z80 assembler a bit better and may rewrite parts or all of this in assembler eventually. Still not sure if it will be adequate to play some of those dense VGM tracks. The Z80 runs at half the speed as the 68k and is 8bits instead of 16bits. Might be fun to try, however.

Mostly I wanted to do this to have a way to create new music and have it run in the background with the Z80, for that it seems adequate at this point.

Manveru · Post by **Manveru** » Tue Oct 30, 2012 7:00 am

I will follow your advise and i will use Deflemask for testing and to add some music to my proyects because i have downloaded a OST from ocremix and i get slow too. Maybe in the future i will test if other OST works fine. I have read something about music in SGDK but in the project web there is not any tutorial for sound yet and i cant find another source of help.

Thanks again kubilus1 for your help and for your work in the driver.

kubilus1 · Post by **kubilus1** » Tue Oct 30, 2012 7:32 pm

Okay, I think I have a solution for you. For the slow and bloated VGM files compress them with 'vgm_cmp' first. You can get the tool here:

http://www.smspower.org/forums/viewtopic.php?t=12441

This seems to work on the examples I've tried. They play the right speed and the files are much smaller.

Manveru · Post by **Manveru** » Wed Oct 31, 2012 10:55 am

Thanks mate, you are right, the files are much smaller and the music speed is better, although i have tried 2 tracks and they still play slower than it should be, but faster than before.

foobat · Post by **foobat** » Wed Oct 31, 2012 8:11 pm

The main cpu hog in VGM seems to be the wait instructions and PCM commands. If you can combine 3 or more consecutive 1-nibble wait instructions (0x7n commands in the VGM file) into one 2-byte wait instruction (0x61) you might be able to get much better performance. You can also usually combine consecutive 2-byte waits which is huge, or combine a 0x8n followed by a 0x7n into one 0x8n if the total of both "n" is less than 15.

I'm not sure exactly what vgm_cmp is doing, probably some or all of the above.

Chilly Willy · Post by **Chilly Willy** » Wed Oct 31, 2012 10:32 pm

To really get an idea about how fast the code is, you need to disassemble the object file after compiling. The switch statement in particular... is it a series of compares, or a jump table? A jump table is far faster for handling VGM commands than a series of compares. Compilers will usually turn a switch statement into compares if the values are different beyond some internal value, and a jump table if they are rather similar.

kubilus1 · Post by **kubilus1** » Wed Oct 31, 2012 11:36 pm

foobat - I did some combining of consecutive waits, such as multiple x62 commands to make PCM playback sound less stuttery. Combining the short single cycle waits is problematic since the time it takes to deal with them approaches the required wait time. Pre-processing seems to be the way to go with multiple redundant statements, because not only does it run quicker, the resulting files are less bloated in size.

Chilly Willy - I think I saw what you did with the lookup table in the 68k VGM player posted awhile back. That really does look like that way to go if I were to re-write in ASM. sdcc conveniently spits out the equivalent assembly code, and from that I can see that multiple compares are done with the case statement. I've already re-written some parts (such as bank switching) in straight assembler, the case statement would seem to be the next thing to do!

Thanks for the tips!!

Chilly Willy · Post by **Chilly Willy** » Thu Nov 01, 2012 12:42 am

No problem. When I was working on my 68K VGM player, I noticed that one compare is faster, two compares roughly about the same, and anything else is faster using a jump table. Since there's no one command that dominates VGMs, it's faster to just use a jump table. For your z80 player, maybe you can make the dispatch asm and leave the rest as C. I'd try that first, then slowly replace C with asm over the rest... that or bite the bullet and redo the WHOLE DAMN thing at once.