VGM Music Maker

Chilly Willy · Post by **Chilly Willy** » Thu Jun 23, 2011 8:52 am

Shiru wrote:Chilly Willy, when there are samples in exported VGM, 0x61 is used all the way to skip time between sample writes. When samples are disabled, it uses 0x63 to skip frames instead.

Thanks, I'll check those over and get the speed right. Maybe it'll help a few other VGMs that play slow.

mic_ · Post by **mic_** » Thu Jun 23, 2011 8:59 am

Or, generally, where I can found any older specifications?

I don't know if there are backups of those. Ask Maxim at smspower maybe.

Like I said, Mike-Stamp's player should definitely support 0x8n. Nearly all MD vgms available at project2612 that uses the DAC are using 0x8n AFAIK. Well, all of them are, since that's how you write to the DAC

But I mean the delay portion of it.
And I've tested both Mike-Stamps player as well as ChillyWilly's with various tunes in the past.

Shiru · Post by **Shiru** » Thu Jun 23, 2011 9:06 am

I'm going to use 0x8n when I find the specs, I need them to create correct header. I don't want to make it for 1.60 specs, it is real overkill, and is not supported by older software.

mic_ · Post by **mic_** » Thu Jun 23, 2011 9:09 am

when I find the specs

Which spec?

The newer specs have comments in them that specify which header parts were added in which version.
If I were you I'd go for 1.50 (i.e. 64-byte header).

Shiru · Post by **Shiru** » Thu Jun 23, 2011 9:12 am

Obviously, the specs I asked about few posts earlier.

Shiru wrote:Where I can found 1.10 specifications? Or, generally, where I can found any older specifications?

Edit: Mike's VGM_PLAY v2.00 works with files exported from the editor. They play slowly if sample rate is 22050 (understandable), but play correctly with sample rate 11025. So this problem gets low priority now.

mic_ · Post by **mic_** » Thu Jun 23, 2011 9:19 am

Thanks, I'll check those over and get the speed right. Maybe it'll help a few other VGMs that play slow.

I haven't looked at the exported VGM file, but if I understand Shiru right he's using something like this:

0x80 0x61 nn nn

To output a sample to the DAC and wait nnnn/44100 s. So maybe you need to check that your "lag" calculations for the 0x80 case are correct.

Shiru · Post by **Shiru** » Thu Jun 23, 2011 9:27 am

Yes, that's how it works for now. Obviously it is far from optimal. There are thoughts: VGMs aren't supposed to be used on the hardware; VGM players for the hardware probably convert data to some internal optimal format anyway; there should be special, compact and optimized format to use the music in games/demos anyway.

mic_ · Post by **mic_** » Thu Jun 23, 2011 9:34 am

VGM players for the hardware probably convert data to some internal optimal format anyway

Optimal.. not so much.

It has to be able to decompress and process the commands at 44100 Hz on a 7 MHz 68k.
My compressor had a static dictionary of strings with "0x8n 0x8n 0x8n ..." commands and would replace such strings found in the song with references to the dictionary. Plus some other small things. Mike-Stamp's compressor worked even better, but he never released the sources AFAIK so I don't know how it works.

Anyway, cutting each DAC write from 4 bytes to 1 in your exporter should be a matter of changing 1 or 2 lines of code

Shiru · Post by **Shiru** » Thu Jun 23, 2011 9:46 am

I really don't like when people tell me how easy to fix something in my code which they never seen.

In any case it can't be 1 or 2 lines. Tens of lines, probably, and these lines will require some thinking, changing, recompiling, seeing that everything is broken now, fixing, recomiling, IDE hanging with lost unsaved code (happens often), etc.. that easily could turn into hours of work.

Anyway, I've said 0x8n tags support is in plans, but has low priority right now. I would prefer to not discuss such a minor problems in that many posts, it is half of the whole thread now. If I will spend my time to such discussions, you will have to wait new versions way longer.

mic_ · Post by **mic_** » Thu Jun 23, 2011 10:02 am

Just sharing tips about how you can generate better output, since I've done quite a few projects involving VGM files - both players and generators. So I'm not really "discussing" anything here.

And there's no need to get upset about my assumptions about how your code is structured

I figured it should be at most a couple of lines of code. If it's not, who cares? I don't..

Shiru · Post by **Shiru** » Thu Jun 23, 2011 10:15 am

TmEE co.(TM) wrote:*With some instruments on the instrument creator tab you get next note sound quiet. You play a note, and then play another and the next note is as quiet as first note was when you hit the new note. Possibly tied with PSG test envelope which seems to be derived form FM ADSR settings...?

Could you explain this in more details? PSG envelopes are similar to the FM (have the same stages, at least), and they don't have output level reset at key on as well.

TmEE co.(TM) wrote:*When loading many FM instruments at once I got an access violation error, but the program continued afterwards, all instruments do not get loaded. I don't yet know how many instruments it lets you load at once before giving the error.

I was able to load like 300 instruments at once (with ones that does not fit into the list being omited by the editor) without the error. Can you provide more information on this so I would be able to reproduce the problem?

Chilly Willy · Post by **Chilly Willy** » Thu Jun 23, 2011 10:57 am

Well, I figured out why the test music plays slow... it's a big stream of

0x52 xx xx
0x61 02 00

commands. Set the FM and then wait 2 samples. The problem is dispatching a command takes 112 cycles, then tack on the length of the command. For example, 0x52 is 112+112+66 cycles.

Code: Select all

write_fm0:
        fetch_vgm d0
        move.b  d0,0xA04000
        nop
        nop
        fetch_vgm d0
        move.b  d0,0xA04001
        subi.l  #112+112+66,d5
        bra     read_cmd

where fetch_vgm is

Code: Select all

        .macro  fetch_vgm reg
        cmpa.l  a3,a6           /* check for wrap around */
        bcs.b   9f
        suba.l  a2,a6           /* wrap bank */
        addq.w  #1,d7           /* next bank */
9:
        move.w  d7,0xA1300C     /* set PRAM_BIO */
        move.b  (a6)+,\reg
        .endm

for 56 cycles.

The dispatcher simply can't catch up at the rate the commands are trying to dispatch at.

The fetch_vgm macro cannot be shortened without losing the ability to use banks, which would limit vgms to 1MB. So it's 56 cycles just the fetch the command byte. The dispatch looks like

Code: Select all

| main player loop - process next VGM command

read_cmd:
        fetch_vgm d0            /* Read one byte from the VGM data */

        moveq   #0,d1
        move.b  d0,d1
        add.w   d1,d1
        lea     cmd_table,a0
        move.w  0(a0,d1.w),d1
        jmp     0(a0,d1.w)      /* dispatch command */

cmd_table:
        /* 00 - 0F */
        .word   reserved_0 - cmd_table
<snip>

That's 112 cycles total. I might try early-outing some commands with a compare, but that just adds to the time for other commands. Not to mention, it won't cut THAT many cycles from the dispatch - cut 30 cycles if the first compare matches, while adding that 30 cycles to all other commands, and two compares would COST more time than just doing the dispatch - 60 cycles instead of 56. That's why I don't do the compares in the first place - only ONE compare would be faster than using the jump table.

EDIT: Changed the dispatch a little

Code: Select all

|        lea     cmd_table,a0
|        move.w  0(a0,d1.w),d1
|        jmp     0(a0,d1.w)      /* dispatch command */
        move.w  cmd_table(pc,d1.w),d1
        jmp     cmd_table(pc,d1.w)      /* dispatch command */

That helps a little, but it's still not enough for the test music. Buttville sounds better, though.

EDIT 2: A little more...

Code: Select all

read_cmd:
        moveq   #0,d0
        fetch_vgm d0            /* Read one byte from the VGM data */
        add.w   d0,d0
        move.w  cmd_table(pc,d0.w),d1
        jmp     cmd_table(pc,d1.w)      /* dispatch command */

Still not good enough for the test music.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Thu Jun 23, 2011 11:14 am

Seems you can discard the loading many instruments at once bug I mentioned. It is most probably related to Win98SE+KernelEx setup, since VGMmaker no longer works on vanilla Win98SE (it says SEGAPSG.DLL expects newer version of windows, aswell as MSVCR90.DLL).

And I did not mean PSG itself, I meant it may be using derived PSG volume value for new FM notes that you play on keyboard in intrument creator.
I don't seem to be able to reproduce it. I was testing out some bass instruments and I constantly got quiet notes between normally loud ones.
I will still keep my eyes on it (or should I say ears) and will save the instrument when I get it again and try it out in a freshly loaded editor.

Right mouse button does seem to cause interesting results on the keyboard when you try out PSG noises, some keys do periodic noise, some do white.
This one seems to happen all the time.

Is the YM2612 output having that small DAC bug emulated that causes 2 values to be same ? Output seems to be 9 bits like real chip ...?
If DAC bug is emulated, would it be possible to make it so that it can be turned off so the output is like on YM3438 (that MD2 uses) ?

Shiru · Post by **Shiru** » Thu Jun 23, 2011 11:21 am

The dlls aren't actually required anything special by itself, this crap is attached by the compiler (MSVC 2008 Express), and I can't find how to fix this. Source code for the dlls is provided with the editor, so maybe someone can recompile them to remove that dependency.

PSG envelope is completely separate from the YM2612, it only uses settings of the instruments, but runs by itself (and it is much simpler, no angles etc there).

RMB does not work properly for PSG instruments, true. I've forgot to test it, actually.

YM2612 emulation code is from MAME, I don't know if the DAC bug is emulated there. Source code of YM2612 emulator is included.

Shiru · Post by **Shiru** » Thu Jun 23, 2011 4:07 pm

VGM Music Maker v1.01, fixes the problems that were found so far.

v1.01 23.06.11

+ MIDI support is improved, now the editor works with MIDI USB keyboards
* Wrong file extension has been added to the instrument name on the instrument save
* *.vge instruments were not displayed in the open instrument dialog
* Changing instrument number through MIDI marked all the selected instruments
* PSG mute has not been initialized at start up, probably the reason why PSG sound was absent sometimes
* Group loading for samples has not worked properly
* Right mouse button has not worked properly for PSG instruments when used with on-screen keyboard
* VGM output is optimized, now files are smaller and works better with VGM players for actual Genesis/Mega Drive consoles
* FM polyphony in the instrument editor is increased to six channels
- DLL dependency with MSVC 2008 Redistributable is removed

It wasnt 1-2 lines of code. Also, should say in_vgm provided me many uncool moments. It is completely unforgiving, if you made a mistake, it hangs and loads CPU to 100%, so I literally had to wait minutes to kill the process, few times.