Gameboy VGM player

[mic_]

This is a VGM player I've written for the original monochrome Gameboy (and Color/Light/SGB/Advance).

 You can download it and the source code here
 And you can see/hear it in action here

 It obviously doesn't cover all the chips supported by the VGM format. Only the SN76489 is emulated (used in Sega Master System and Game Gear).

 Since the waveform channel on the Gameboy only has 4 different volume settings it'll probably sound weird in some songs. Loading new waveforms dynamically to simulate 16 volume settings didn't seem like a good option.

[Conle]

Excellent , i've posted it on the news page 

And by the way , here's build instructions(for just the tool) for unix users :
http://www.neoflash.com/forum/index.php/topic,6217.msg50701.html#msg50701

 

[Conle]

Awesome this works great on real gbc with a 64Mb smart card 

[mic_]

I might try to make a version for the NES. But I'll probably cheat and use the VRC6 mapper to get the extra square wave channel that's needed, so that will require either a PowerPak or an emulator. The only other way I see of doing it is to have a DPCM sample for each frequency/volume combination (16384 in total) and use something like MMC3 to swap in different samples dynamically, and that doesn't seem like a good solution to me
 

[Conle]

It would be interesting to see a vgm player for the NES , but have you thought of making a sound chip emulator and then
do vgm playback engines for more advanced hardware ?

For example , some target platforms would be : n64/ps1/saturn/dreamcast/ps2/xbox/(even .. pc) (you get the idea , porting the code would be easy)
 

[mic_]

This is a sound chip emulator. A very specialized one that only works on a single platform.

On more powerful systems like N64 or Dreamcast you could just use libgme together with some platform-specific back-end that interfaces the sound hardware.

I might do a Saturn version, but that again will be a custom implementation, because the sound processor is controlled by a M68k running at 11 or 12 MHz, not by the main CPUs.

[Conle]

What im talking about is an emulator for all the chips that are interesting to support and be able to switch to different
chips at runtime(For example , SNES'S DSP / SN76489 / Random chip switching with fade in/out effects etc).

Right now your vgm vms are platform specific , but if you could do something generic then it could be ported on "any" platform of interest without much work.

[mic_]

What im talking about is an emulator for all the chips that are interesting to support and be able to switch to different
chips at runtime(For example , SNES'S DSP / SN76489 / Random chip switching with fade in/out effects etc).

You could probably do that with libgme. It contains emulators for SPC, 2A03/VRC6/N106/FME7 (NES), SN76489, POKEY, AY-3-8910, HuC6280, and maybe some others.
I usually work on systems with very limited resources so I have to do specialized solutions.  If you're interested in doing a multiformat chiptune player for, say, the N64 then I'd suggest that you check out libgme.

[Conle]

You could probably do that with libgme. It contains emulators for SPC, 2A03/VRC6/N106/FME7 (NES), SN76489, POKEY, AY-3-8910, HuC6280, and maybe some others.
I usually work on systems with very limited resources so I have to do specialized solutions.  If you're interested in doing a multiformat chiptune player for, say, the N64 then I'd suggest that you check out libgme.

Nice! That library seems to be able to do what i had in mind 
My only compain is the code though.In order to get any descent performance for the things i have in mind on ps1(for example) you would have to re-write all the un-needed cpp code to c.
.....For simple things like exclusive playback it should be "fine" but if you do non exclusive vm calls(to sync other stuff) there's going to be some extra overhead...

[mic_]

I don't know how good the MIPS version of g++ is, but there should be very little overhead from just calling object methods and accessing object members.

[Conle]

I don't know how good the MIPS version of g++ is,

I don't know either , but i guess with the proper optimization flags(and proper code) it should be descent.

but there should be very little overhead from just calling object methods and accessing object members.

Probaby if you're going to play a small sample it wouldn't matter at all , but if you want more off of it or if you simply want to stream large samples then i see alot of problems in the code and mainly with the io/memory handling containers.

The code itself is a great resource though.

[ChillyWilly]

I don't know how good the MIPS version of g++ is, but there should be very little overhead from just calling object methods and accessing object members.

If you're using a v4.x version of gcc, there really isn't such a thing as a "MIPS" or "X86" or "68000" version of gcc/g++. It's all been consolidated into one compiler that generates an intermediate representation that is then directly converted to the proper assembly. That was the whole point of the v4 GCC rewrite - to get rid of all the different architecture-dependent compilers and replace them with a single compiler that worked on C/C++ optimization from a non-architectural standpoint. So the "MIPS version" of g++ is just as good as any other... from v4.0 on.