Forums

Here is Ace of Aces, a rather underwhelming game with a unique sound engine. Production quality is poor enough to convince me these may very well be the only tracks in the game. That is unconfirmed currently. The trigger address is C000. However you can only trigger the selected song. You cannot select the song, only trigger it to continue from where it last left off, or start anew if it reached the end of the song.

Samples were not difficult to obtain- 2 songs, no loops.

It would be interesting to know how the sound engine works if anyone is willing to take a look at it.

update: Tags in one track corrected

http://www.smspower.org/Music/AceOfAces-SMS

edit: it's been over a month since this was posted. Was this post overlooked, or does it take a while for submissions to be reviewed?

How long does it take to get a response, generally? I have other sets I've worked on but have been waiting to submit until after I get feedback/the two submissions i worked on are accepted.

Don't wait... Silence means a combination of people finding nothing wrong with your pack, or not having looked. When I get to it, I will listen and also upload it to the site, but I won't post feedback unless there's something wrong.

Track 2's filename has a missing space.

You could try to fill out the cover image but it's not really necessary.

The VGM7z should contain uncompressed files, to allow the solid compression to beat zip.

I'm not able to run my repacker on my phone so I can't comment on the compression quality.

Here are new versions. I uncompressed for vgmz and redid the zip.
Pic was not redone, unless it's ok to distort the text by resizing (I believe i remember resizing should not be done) or cutting a good chunk of it off and leaving the main pic surrounded by parts of letters.
I haven't seen anything like that, so I'll leave it for now.

These are corrected for pal timings. I checked just in case it's possible for a command to load a value 0x62 as well. Replaced 0x62 to 0x63. Seems easiest way to correct the issue accross players and no side effect. I left the 0x24 byte as 60 (0x3C) since that is what it was recorded as (Meka).

Strange thing, is it didn't change the time as it did when I test edited the Jungle Book files which do change length i.e. 31s >> 37s when I change the timers AND it plays slower. These files just play slower, but the timer is the same...could it be this game adjusts itself to work correctly in NTSC consoles and that is why there was no change?

In that case, these files would be too slow. Hard to tell, as I never played the original. I picked it because it seemed obscure enough that maybe no one had ripped it yet.

I'm including both files. I'll need to ask around to get some hard answers on best practices.

Just in case, here they are.

[Admin: attachments removed]

I'm not sure the adjustments you describe are correct. If you change the wait lengths then you have to change the rate in the header, and the timings too. I'd re-rip if possible. Make sure you rip with PAL emulation, regardless of the 50/60Hz setting.

I was thinking of filling the black bars in the image with some sky, but it's really not that important.

Completely redone version. Pic Borders have been refilled. Tracks redone at proper frequency. The vgmlogs for both versions are the same...only the waits/frequency/cpu speed differ. Each version has the same number of commands before each wait.

I'm not sure how this works, but the hex-edited version above seems to be exactly like the rerip except for frequency of cpu. That affects pitch only, but a peak spectrum analysis did not show even 1 cent of difference.

So it seems to be
1) DOnt make the mistake of ripping vgms at the improper frequency-make sure tv type matches the rom.
2) If you do mess up, you can a) edit byte 0x24 to change the playback rate and use in_vgm/Vgmplay..b) Also edit the waits from 62 to 63 (make sure you don't overwrite anything else..but that will still leave song lengths innaccurate...a fadeout will likely come early..so c) put the new sample length in the proper place in the header to fix that...and..d) maybe change the cpu clock. This seems to vary across certain games...so I don't know how that works.

Another game I compared did have varying number of commands between waits, but in that case the comparison was an sms pal, with ntsc gg. (they sounded the same) Maybe apples to oranges regarding this even though the code/memory locations are usually identical. Once in a while you'll find some differences,

Redone for everyone's peace of mind. Probably at the cost of a completely new pack..I still have two other sets to redo. Likely I will avoid the pal as I could not do in this instance, and use the ntsc gg version..since I now have good reason to want to look at them.

Would be nice to have an actual list of comparisons..also you mentioned a tool for (50/60) conversion . I would like to look at it just to satisfy my thirst for knowledge. Even if it doesn't work, it may help me figure out some things...especially if the source is available.

[Admin: attachments removed]

The 50/60 conversion is pretty much as you describe, except that any granular waits also need to be converted, which may introduce a tiny bit of error. It should be possible to automate it.

However, there may be other side effects - the PAL system has a lot more CPU time per frame which affects lag, so recording as NTSC may add lag to the music. When we pause hack a game, we eliminate lag so that may help.

Also, if the game compensates for 50/60Hz then an automated adjustment will be wrong.

That's interesting to know. Nice to have someone around who knows what they are talking about. Did not know the pause hack (cpu hang) got rid of lag. I still havent figured out the math on how the clock speed and 50/60 hz elements interact. It's particular because almost the same commands are seen. It could be the differences aren't an error but a proper pitch adjustment. Still unclear on how exactly the psg functions to create pitch with volume envelopes..I can't grasp the concept.

That last issue is why I gave up even when near "victory". Just better to redo it than wonder. Though the changes would probably be too small to notice...

If only the waits are changed...does that mean there's a 147 sample lag (882-735)? That doesn't make sense based on my experience (waveform comparisons -results almost identical) But I do know I would not notice a 100 sample lag..(can;t figure the math)..over time wouldn't the displacement become obvious?

Or am I thinking incorrectly, and those small differences get lost because everything plays at 44100 hz where they both line up.

Still learning how this technology works. Thanks for the info.

Let's digress :)

First, the effect of the CPU clock on a VGM. This does precisely one thing: the pitch changes, but the timings don't. Let's do the maths:

Note 0xfe for NTSC gives 3579545 / (32 × 254) = 440.4Hz
Note 0xfe for PAL gives 3546893 / (32 × 254) = 436.4Hz

That's not a huge difference.

Next, how music engines work. They could work in lots of ways, but mostly what happens is that the game updates the music once per frame. That lets us make VGMs with whole-frame timings and they don't lose much information, because the exact timing of the register writes is imperceptible (on the order of a few samples at 44kHz output). However, the game may fail to update the music every frame:

- if the rest of the per-frame work takes too long, the following frame is missed and the game might slow down by half, along with the audio. Most games avoid this, though.
- if the game is updating the screen then it might turn off interrupts, you often see this as the audio freezing momentarily as the screen goes black when changing scenes

The pause hack minimises most of this by removing most of the game logic (by removing the non-vblank code), which tends to mean the rest of the game stays static and doesn't have any work spikes to cause lag.

Let's go back to the clock rate. If you calculate the number of clocks per frame, on NTSC it's 3579545 / 60 = 59659, on PAL it's 3546893 / 50 = 70938. That means a game can get more done in each frame in PAL mode, so slowdown is less likely to happen.

Next up, volume envelopes. The music engine has to do these entirely manually, they will have some logic and counters in order to set the volume on a frame by frame basis. The same goes for other effects like tremolo and arpeggiation. So the VGM file is full of these manual adjustments, rather than capturing the intent.

Finally, music engines are quite capable of compensating for the differences. They could use a different wavelength lookup table to counter the pitch changes, and adjust timings between 50 and 60Hz to get similar sounding results. This is most likely on European releases that shared code between SMS (50Hz) and GG (60Hz globally). When this happens, the best thing is to remove the rate from the VGM header so it will disable any rate adjustment in the player.

When the engine doesn't compensate, it's hard to be sure what the intended rate was. Plenty of games were developed in Japan, or in Europe using NTSC hardware, then only released in Europe. Plenty of developers didn't make the effort to compensate for clock differences. For the Game Gear, the rate issue is gone but if there's an SMS version, maybe it was composed for 50Hz and not adjusted later.

Wow, that was an amazing response. And it all made sense!

My appetite is sated. (For now)

Thank you very much!

Maxim, are there resources available to help understand sms code data for music? SGC doesn't seem like a popular format, but I would like to be able to look at the code without wondering about anything else (vdp, etc) only what happens in the psg.

I like vgms for their simplicity, but they don't help with the original source material. A 0x50 does not seem to be the command associated with setting a tone to a particular channel.

I would like for starters, just to be able to find where the music data is, and maybe recognize a tone or two. I have no idea how values are generally stored. I imagine that the value 157 (F4 minus 28 cents if I read it correctly) would not be stored as (byte instruction) 07 15 but would likely have a bunch of instructions in between, probably some ld hl,$xxxx, ld a etc..or if it in fact works like an automated piano player reading one command to the next..so that they might be together...

Some vgm logs I've looked at (they finally make sense thanks to your post) seem to indicate that psg tones keep going until they are stopped...maybe why the logs indicate latch..(not sure what type it is -D-type/Delay flip flop?) and why converting to midi seems so accurate with sms vmgs. If that is so, are waits integrated with the music? I would imagine a separate counter/loop is used to effect the delay, but it might be stored elsewhere.

I'm guessing SMPS games use the same codes for music processing, and same values to write to the register, but anything goes with other engines.

An SGC has the pointer values in the header, but I have no idea how to use that to find the data. I've never read about how an index of songs is stored and then triggered by id, and I'm not sure of how to use the song pointer or even how the data is organized. I've tried to study the other formats gbs/hes which I prefer, but a lack of careful documentation and the absence of any active rippers makes this challenging. It seems that they can be organized however the ripper likes, in whatever order, so long as the sound play routines know where to find the appropriate song data.

Although it seems SGC never took off, I see only a few posts by one person on several sites in google, people here seem to be very knowledgable about not only the code, but architecture of the SMS/Mk III and other systems.

I'm ONLY interested in the sound aspects of the PSG and would be satisfied with cursory knowledge of how song data is organized even if it only relevant to one or two games. I have no schema of coding norms or of what to expect. I imagine it would be a bit easier if I were fluent in assembly..but even then concepts such as writing to port 7e or 7f escape me, as I have no experience with actual hardware registers or chipsets. I imagine if I found something like ld 7F,x it might have something to do with sound..but i have not found anything so convenient in my studies.

If you could help answer any of these questions, I would appreciate it. Or even some suggestions for a game you think might be easy to debug as a beginner's learning experience. Or anything at all.

Anything.

First, how the PSG works. You can only send it one byte at a time, but you need to pack in the volume and frequency control for all the channels. That means you need two bytes to set a frequency (normally). So you send a "latch" byte with some of the new value, followed by a "data" byte to complete it. The sound doesn't change until both happen. For other operations (e.g. volume changes) you can pack it into a single byte, so there is no latch.

VGM stores raw volume and frequency changes over time. They use some codes to say which chip is being accessed (0x50 for the SMS PSG) but that's in addition to the actual data. This is simple, but inefficient and hard to compose. Music engines try to take an efficient, composable format and convert it, much like how MIDI defines key events and instruments and code changes it into audio. For example, a music engine might define a time base, then tracks for each channel. For each channel, there might be key events and instrument definitions. An instrument is probably composed from a volume envelope and vibrato/tremolo/arpeggiation parameters, plus other stuff I may have forgotten.

This is then extended to support sound effects, which have to deal with priority and get mixed into one or more music channels.

The music engine then runs code for each channel to convert the intention (play this note on this channel using this instrument) into the raw frequency and volume changes over time. Every game might choose a different way to do this, but often you will find code reuse and music engines which evolve over time, like SMPS.

Reverse engineering music engines is quite hard (I think). They are easy to isolate, as almost all games put the music engine and data all in one 16KB chunk. You can use a debugging emulator to find the PSG accesses and then you can usually isolate the music engine. SGC basically does this, and finds the pointers for things like "update the PSG" and "play a new track", and bundles it into a file. It doesn't help you isolate the data.

However, looking at the assembly code for converting the data to chip commands is not necessarily helpful for figuring out what effect it is trying to make. Once you get a certain way in, you can find the data and then try to understand what it means simply by editing it to see what happens.

So you might find that some byte means "key down", followed by a 12TET related note number. The code goes to a table and looks up the frequency value corresponding to that note. Maybe there is also a sustain duration instead of a separate key up event. Gaps between notes need to be defined too.

Sega 8-bit music engines are not well reverse engineered and documented. I think there are some disassemblies for some of the Sonic games out there, but not for the most common Sega engine.

That's abit disappointing to hear, but understandable. It's a bit surprising the common engine wasn't studied. I'm actually studying the sonic 2 disassembly-found it since my last post.

Z80dasm doesn't add any labels and smsexamine doesn't put the hex codes in to compare. I tried emulicious, but for some reason it will not work even though I have java installed and the JAVA_HOME variable set.
I also tried emukon, but couldn't figure out how to disassemble.

I guess my main reason for studying the sgc was hope that it would make it easier to change the sound data. Changing something in the disassembled file just to see what happens is still more opaque than I had hoped. I guess I would be happy just learning to find song data and write memory trigger hacks. I'm not looking to design my own sms music engine or anything like that. But it's a bit unsatisfying to have such little knowledge about what I'm working with or how it was put together (even cursory knowledge).

In that sense, vgms are more satisfying in that they are easy to work with. With a little knowledge of the registers and how tones are generated (even a little) it is very easy to understand what is going on.
Most chipsets have their own codes, and for sms, it's basically a series of note/latch commands plus volume, folllowed by note off.
With amidi converter you don't need to go into the notes, but you could if you wanted to. You still need to study each chipset, but it's easy to move from there. I found it a bit unsatisfying, in the sense that it was like trying to learn a foreign language by studying a very stripped down and standardized version of it. More accessible, but the original source material, and any understanding of it remain far away..

If as you imply, understanding any sound engine is very laborious, I see why others might not want to spend their time on it rather than on some more interesting project.

Thank you. Your replies have been very helpful.

It should be easy to start disassembling a music engine. Disassemblers either interpret everything as code, resulting in a lot of nonsense, or try to split out the data. Usually there's an option to disable putting large data chunks into separate files. However, the process of identifying data vs. code is imperfect.

An SGC file gives you the music engine separately from the rest of the game which might make it easier to reverse engineer, but then it's tricky to step through. A small stub to make it a valid SMS file might help.

A first step might be to try to find some identifying signature of the music engine to check which games use it. The music trigger system which is very common might indicate that there is a great deal of common music engine code out there. Some time ago we also discovered a suboptimal note to PSG frequency table which was seen in a large number of games, another suggestion of common code.

Here's a promising start:

https://github.com/trykaar/dc-sms-dasm/tree/master/sound

Thank you. would you happen to have an idea how to add a stub to make the sgc file work? Would it be more than just adding a header and having the first line of executable code...not sure if it is 0x100..jump to the start of the sgc routine...not entirely sure where that is.
---

I just noticed that a lot of rips I had queed to work on have already been posted. (Alien Storm, Power Striker, Prince of Persia). I didn't get far (only logging and naming). Surprised I missed it considering I was using a list. I can see why I overlooked Power Sriker...I was ripping it as aleste-played through the whole thing and found a way to keep the music going while pause. But didn't notice alien storm at all..Prince of persia as well. I was only able to get two tracks from it...how did you get the rest. Did you play through or is there a memory hack/hex edit available? Would be nice if you could share.

----

I'm about to work on alien syndrome...do you know if that's been done? Cause I don't see it. That and girl's garden are the only thing remaining on my queue besides a few requests and a pack i still need to fix. There's also a game called Ninja princess I played a while ago and beat (Sg-1000). I didn't know about vgm logging then, but it's hard even with cheats. Have not been able to find a memory trigger.

Wish there was a masterlist that showed everything...completed..incomplete..in progress...like the memory triggers page. Would make things easier for the rippers....don't seem to be alot of us around...even though it's alot easier than alot of the work that goes on around here.

An SGC stub would need to be made easy to disassemble, but it would probably be a few hours' work for an experienced SMS developer. Code starts at address 0, you'd need to set up a frame interrupt handler too.

All the VGMs are either here:

http://www.smspower.org/Music/VGMs

Or here (historical):

http://www.smspower.org/Music/PendingPacks

Or in this forum (where pending packs go to wait for attention now).

I don't see Alien Syndrome anywhere. Watch out for name variations, as you saw, by browsing from the game page.

I think I ripped Prince of Persia a long time ago. It's a Krisalis game, so no trigger, but I found the play track hook and worked on that. You could rip it all easily with passwords anyway.

Maxim, Do you know if GG pal games adjust? If I set it to 50hz will it be too slow or correct? I'm thinking of working on daffy duck in hollywood, but it has 16 songs, so I'll wait until I know it will log fine at 50hz on meka, or if I should set it to 60hz...(I remember reading somewhere that gg games adjust. It's a late 1994 addition, virgin game with their music engine.

There is no such thing as a PAL Game Gear. They are always 60Hz with NTSC timings. Where a game was released on both GG and SMS, the engine may adjust so the PAL SMS and NTSC GG sound the same.

50Hz in Meka doesn't affect the VGM log, you have to select the TV type (PAL/NTSC). While logging the VGM, you can set the speed to 200Hz or whatever with no effect on the result.

Yes that's what I meant..So based on what you said...if I set the tb type to 50 or 60 it doesn't matter....or is 60 is always correct, and anything else is wrong? I could probably verify with some tests..but it would be nice to hear directly.

It's funny, cause my for my first packs I logged everything without changing the speed so it took a while. Then I realized i could speed up without affecting the output negatively...only to overlook that there was a tv type that was necessary. I thought it was just a meaningless throwback for nostalgia's sake..like sai video filter, just for novelty, and now I have a few packs I need to redo.

So I would appreciate a dumbed down answer so I'm sure I'm hearing what I think I am (When I was told meka logs everything the same regardless of the speed, I misunderstood that it also fixed 50hz timings on its own (I assumed based on rom headers). Now I know it's a bit more complicated than that, and such a solution might actually be counterproductive.

So, for the hard of hearing....one more time please? In plain english.

I am logging a pal gg game...so tv/setting can/should be....anything? 60hz?

Game Gear: NTSC always. A European GG game is not a PAL game.
Master System: NTSC if you think the game was designed for 60Hz, PAL if you think it designed for 50Hz.

Set the emulator to PAL/50 and listen to the music. Switch it to NTSC/60 and then *reset the game*. If the music is the same speed, then the game compensates.

Thanks for covering all the bases. That last tip is priceless, I might do that even when I think I'm sure, especially as I am not familiar with most of the games I log. Most of the ones I am familiar with were logged a long time ago. Pretty sure I already did the few that weren't.

Getting back to the pack, the extended cover image is not very good. I posted it nevertheless, I may have a go at the image myself.

lol. It came out better than I first imagined it would, but if you can figure a way to make a very rectangular image square without resizing. I'll take your example as a model

updated pack. track 4 had the wrong tag

Author	Message
sherpa Joined: 28 Nov 2014 Posts: 365	[VGM Pack] Ace of Aces Posted: Sat Nov 29, 2014 12:32 am Last edited by sherpa on Mon Feb 23, 2015 10:12 pm; edited 1 time in total
sherpa Joined: 28 Nov 2014 Posts: 365	Here is Ace of Aces, a rather underwhelming game with a unique sound engine. Production quality is poor enough to convince me these may very well be the only tracks in the game. That is unconfirmed currently. The trigger address is C000. However you can only trigger the selected song. You cannot select the song, only trigger it to continue from where it last left off, or start anew if it reached the end of the song. Samples were not difficult to obtain- 2 songs, no loops. It would be interesting to know how the sound engine works if anyone is willing to take a look at it. update: Tags in one track corrected http://www.smspower.org/Music/AceOfAces-SMS edit: it's been over a month since this was posted. Was this post overlooked, or does it take a while for submissions to be reviewed?

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Wed Jan 07, 2015 12:06 am
sherpa Joined: 28 Nov 2014 Posts: 365	How long does it take to get a response, generally? I have other sets I've worked on but have been waiting to submit until after I get feedback/the two submissions i worked on are accepted.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Wed Jan 07, 2015 6:59 am
	Don't wait... Silence means a combination of people finding nothing wrong with your pack, or not having looked. When I get to it, I will listen and also upload it to the site, but I won't post feedback unless there's something wrong.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Mon Jan 12, 2015 9:35 am
	Track 2's filename has a missing space. You could try to fill out the cover image but it's not really necessary. The VGM7z should contain uncompressed files, to allow the solid compression to beat zip. I'm not able to run my repacker on my phone so I can't comment on the compression quality.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Mon Jan 12, 2015 11:05 am
sherpa Joined: 28 Nov 2014 Posts: 365	Here are new versions. I uncompressed for vgmz and redid the zip. Pic was not redone, unless it's ok to distort the text by resizing (I believe i remember resizing should not be done) or cutting a good chunk of it off and leaving the main pic surrounded by parts of letters. I haven't seen anything like that, so I'll leave it for now. These are corrected for pal timings. I checked just in case it's possible for a command to load a value 0x62 as well. Replaced 0x62 to 0x63. Seems easiest way to correct the issue accross players and no side effect. I left the 0x24 byte as 60 (0x3C) since that is what it was recorded as (Meka). Strange thing, is it didn't change the time as it did when I test edited the Jungle Book files which do change length i.e. 31s >> 37s when I change the timers AND it plays slower. These files just play slower, but the timer is the same...could it be this game adjusts itself to work correctly in NTSC consoles and that is why there was no change? In that case, these files would be too slow. Hard to tell, as I never played the original. I picked it because it seemed obscure enough that maybe no one had ripped it yet. I'm including both files. I'll need to ask around to get some hard answers on best practices. Just in case, here they are. [Admin: attachments removed]

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Mon Jan 12, 2015 2:11 pm
	I'm not sure the adjustments you describe are correct. If you change the wait lengths then you have to change the rate in the header, and the timings too. I'd re-rip if possible. Make sure you rip with PAL emulation, regardless of the 50/60Hz setting. I was thinking of filling the black bars in the image with some sky, but it's really not that important.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Wed Jan 14, 2015 7:13 am
sherpa Joined: 28 Nov 2014 Posts: 365	Completely redone version. Pic Borders have been refilled. Tracks redone at proper frequency. The vgmlogs for both versions are the same...only the waits/frequency/cpu speed differ. Each version has the same number of commands before each wait. I'm not sure how this works, but the hex-edited version above seems to be exactly like the rerip except for frequency of cpu. That affects pitch only, but a peak spectrum analysis did not show even 1 cent of difference. So it seems to be 1) DOnt make the mistake of ripping vgms at the improper frequency-make sure tv type matches the rom. 2) If you do mess up, you can a) edit byte 0x24 to change the playback rate and use in_vgm/Vgmplay..b) Also edit the waits from 62 to 63 (make sure you don't overwrite anything else..but that will still leave song lengths innaccurate...a fadeout will likely come early..so c) put the new sample length in the proper place in the header to fix that...and..d) maybe change the cpu clock. This seems to vary across certain games...so I don't know how that works. Another game I compared did have varying number of commands between waits, but in that case the comparison was an sms pal, with ntsc gg. (they sounded the same) Maybe apples to oranges regarding this even though the code/memory locations are usually identical. Once in a while you'll find some differences, Redone for everyone's peace of mind. Probably at the cost of a completely new pack..I still have two other sets to redo. Likely I will avoid the pal as I could not do in this instance, and use the ntsc gg version..since I now have good reason to want to look at them. Would be nice to have an actual list of comparisons..also you mentioned a tool for (50/60) conversion . I would like to look at it just to satisfy my thirst for knowledge. Even if it doesn't work, it may help me figure out some things...especially if the source is available. [Admin: attachments removed]

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Wed Jan 14, 2015 8:38 am
	The 50/60 conversion is pretty much as you describe, except that any granular waits also need to be converted, which may introduce a tiny bit of error. It should be possible to automate it. However, there may be other side effects - the PAL system has a lot more CPU time per frame which affects lag, so recording as NTSC may add lag to the music. When we pause hack a game, we eliminate lag so that may help. Also, if the game compensates for 50/60Hz then an automated adjustment will be wrong.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Wed Jan 14, 2015 11:02 am
sherpa Joined: 28 Nov 2014 Posts: 365	That's interesting to know. Nice to have someone around who knows what they are talking about. Did not know the pause hack (cpu hang) got rid of lag. I still havent figured out the math on how the clock speed and 50/60 hz elements interact. It's particular because almost the same commands are seen. It could be the differences aren't an error but a proper pitch adjustment. Still unclear on how exactly the psg functions to create pitch with volume envelopes..I can't grasp the concept. That last issue is why I gave up even when near "victory". Just better to redo it than wonder. Though the changes would probably be too small to notice... If only the waits are changed...does that mean there's a 147 sample lag (882-735)? That doesn't make sense based on my experience (waveform comparisons -results almost identical) But I do know I would not notice a 100 sample lag..(can;t figure the math)..over time wouldn't the displacement become obvious? Or am I thinking incorrectly, and those small differences get lost because everything plays at 44100 hz where they both line up. Still learning how this technology works. Thanks for the info.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Wed Jan 14, 2015 11:38 am
	Let's digress :) First, the effect of the CPU clock on a VGM. This does precisely one thing: the pitch changes, but the timings don't. Let's do the maths: Note 0xfe for NTSC gives 3579545 / (32 × 254) = 440.4Hz Note 0xfe for PAL gives 3546893 / (32 × 254) = 436.4Hz That's not a huge difference. Next, how music engines work. They could work in lots of ways, but mostly what happens is that the game updates the music once per frame. That lets us make VGMs with whole-frame timings and they don't lose much information, because the exact timing of the register writes is imperceptible (on the order of a few samples at 44kHz output). However, the game may fail to update the music every frame: - if the rest of the per-frame work takes too long, the following frame is missed and the game might slow down by half, along with the audio. Most games avoid this, though. - if the game is updating the screen then it might turn off interrupts, you often see this as the audio freezing momentarily as the screen goes black when changing scenes The pause hack minimises most of this by removing most of the game logic (by removing the non-vblank code), which tends to mean the rest of the game stays static and doesn't have any work spikes to cause lag. Let's go back to the clock rate. If you calculate the number of clocks per frame, on NTSC it's 3579545 / 60 = 59659, on PAL it's 3546893 / 50 = 70938. That means a game can get more done in each frame in PAL mode, so slowdown is less likely to happen. Next up, volume envelopes. The music engine has to do these entirely manually, they will have some logic and counters in order to set the volume on a frame by frame basis. The same goes for other effects like tremolo and arpeggiation. So the VGM file is full of these manual adjustments, rather than capturing the intent. Finally, music engines are quite capable of compensating for the differences. They could use a different wavelength lookup table to counter the pitch changes, and adjust timings between 50 and 60Hz to get similar sounding results. This is most likely on European releases that shared code between SMS (50Hz) and GG (60Hz globally). When this happens, the best thing is to remove the rate from the VGM header so it will disable any rate adjustment in the player. When the engine doesn't compensate, it's hard to be sure what the intended rate was. Plenty of games were developed in Japan, or in Europe using NTSC hardware, then only released in Europe. Plenty of developers didn't make the effort to compensate for clock differences. For the Game Gear, the rate issue is gone but if there's an SMS version, maybe it was composed for 50Hz and not adjusted later.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Wed Jan 14, 2015 12:55 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Wow, that was an amazing response. And it all made sense! My appetite is sated. (For now) Thank you very much!

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Thu Jan 15, 2015 10:02 am
sherpa Joined: 28 Nov 2014 Posts: 365	Maxim, are there resources available to help understand sms code data for music? SGC doesn't seem like a popular format, but I would like to be able to look at the code without wondering about anything else (vdp, etc) only what happens in the psg. I like vgms for their simplicity, but they don't help with the original source material. A 0x50 does not seem to be the command associated with setting a tone to a particular channel. I would like for starters, just to be able to find where the music data is, and maybe recognize a tone or two. I have no idea how values are generally stored. I imagine that the value 157 (F4 minus 28 cents if I read it correctly) would not be stored as (byte instruction) 07 15 but would likely have a bunch of instructions in between, probably some ld hl,$xxxx, ld a etc..or if it in fact works like an automated piano player reading one command to the next..so that they might be together... Some vgm logs I've looked at (they finally make sense thanks to your post) seem to indicate that psg tones keep going until they are stopped...maybe why the logs indicate latch..(not sure what type it is -D-type/Delay flip flop?) and why converting to midi seems so accurate with sms vmgs. If that is so, are waits integrated with the music? I would imagine a separate counter/loop is used to effect the delay, but it might be stored elsewhere. I'm guessing SMPS games use the same codes for music processing, and same values to write to the register, but anything goes with other engines. An SGC has the pointer values in the header, but I have no idea how to use that to find the data. I've never read about how an index of songs is stored and then triggered by id, and I'm not sure of how to use the song pointer or even how the data is organized. I've tried to study the other formats gbs/hes which I prefer, but a lack of careful documentation and the absence of any active rippers makes this challenging. It seems that they can be organized however the ripper likes, in whatever order, so long as the sound play routines know where to find the appropriate song data. Although it seems SGC never took off, I see only a few posts by one person on several sites in google, people here seem to be very knowledgable about not only the code, but architecture of the SMS/Mk III and other systems. I'm ONLY interested in the sound aspects of the PSG and would be satisfied with cursory knowledge of how song data is organized even if it only relevant to one or two games. I have no schema of coding norms or of what to expect. I imagine it would be a bit easier if I were fluent in assembly..but even then concepts such as writing to port 7e or 7f escape me, as I have no experience with actual hardware registers or chipsets. I imagine if I found something like ld 7F,x it might have something to do with sound..but i have not found anything so convenient in my studies. If you could help answer any of these questions, I would appreciate it. Or even some suggestions for a game you think might be easy to debug as a beginner's learning experience. Or anything at all. Anything.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Thu Jan 15, 2015 12:37 pm
	First, how the PSG works. You can only send it one byte at a time, but you need to pack in the volume and frequency control for all the channels. That means you need two bytes to set a frequency (normally). So you send a "latch" byte with some of the new value, followed by a "data" byte to complete it. The sound doesn't change until both happen. For other operations (e.g. volume changes) you can pack it into a single byte, so there is no latch. VGM stores raw volume and frequency changes over time. They use some codes to say which chip is being accessed (0x50 for the SMS PSG) but that's in addition to the actual data. This is simple, but inefficient and hard to compose. Music engines try to take an efficient, composable format and convert it, much like how MIDI defines key events and instruments and code changes it into audio. For example, a music engine might define a time base, then tracks for each channel. For each channel, there might be key events and instrument definitions. An instrument is probably composed from a volume envelope and vibrato/tremolo/arpeggiation parameters, plus other stuff I may have forgotten. This is then extended to support sound effects, which have to deal with priority and get mixed into one or more music channels. The music engine then runs code for each channel to convert the intention (play this note on this channel using this instrument) into the raw frequency and volume changes over time. Every game might choose a different way to do this, but often you will find code reuse and music engines which evolve over time, like SMPS. Reverse engineering music engines is quite hard (I think). They are easy to isolate, as almost all games put the music engine and data all in one 16KB chunk. You can use a debugging emulator to find the PSG accesses and then you can usually isolate the music engine. SGC basically does this, and finds the pointers for things like "update the PSG" and "play a new track", and bundles it into a file. It doesn't help you isolate the data. However, looking at the assembly code for converting the data to chip commands is not necessarily helpful for figuring out what effect it is trying to make. Once you get a certain way in, you can find the data and then try to understand what it means simply by editing it to see what happens. So you might find that some byte means "key down", followed by a 12TET related note number. The code goes to a table and looks up the frequency value corresponding to that note. Maybe there is also a sustain duration instead of a separate key up event. Gaps between notes need to be defined too. Sega 8-bit music engines are not well reverse engineered and documented. I think there are some disassemblies for some of the Sonic games out there, but not for the most common Sega engine.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Thu Jan 15, 2015 1:34 pm Last edited by sherpa on Thu Jan 15, 2015 2:12 pm; edited 2 times in total
sherpa Joined: 28 Nov 2014 Posts: 365	That's abit disappointing to hear, but understandable. It's a bit surprising the common engine wasn't studied. I'm actually studying the sonic 2 disassembly-found it since my last post. Z80dasm doesn't add any labels and smsexamine doesn't put the hex codes in to compare. I tried emulicious, but for some reason it will not work even though I have java installed and the JAVA_HOME variable set. I also tried emukon, but couldn't figure out how to disassemble. I guess my main reason for studying the sgc was hope that it would make it easier to change the sound data. Changing something in the disassembled file just to see what happens is still more opaque than I had hoped. I guess I would be happy just learning to find song data and write memory trigger hacks. I'm not looking to design my own sms music engine or anything like that. But it's a bit unsatisfying to have such little knowledge about what I'm working with or how it was put together (even cursory knowledge). In that sense, vgms are more satisfying in that they are easy to work with. With a little knowledge of the registers and how tones are generated (even a little) it is very easy to understand what is going on. Most chipsets have their own codes, and for sms, it's basically a series of note/latch commands plus volume, folllowed by note off. With amidi converter you don't need to go into the notes, but you could if you wanted to. You still need to study each chipset, but it's easy to move from there. I found it a bit unsatisfying, in the sense that it was like trying to learn a foreign language by studying a very stripped down and standardized version of it. More accessible, but the original source material, and any understanding of it remain far away.. If as you imply, understanding any sound engine is very laborious, I see why others might not want to spend their time on it rather than on some more interesting project. Thank you. Your replies have been very helpful.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Thu Jan 15, 2015 2:05 pm
	It should be easy to start disassembling a music engine. Disassemblers either interpret everything as code, resulting in a lot of nonsense, or try to split out the data. Usually there's an option to disable putting large data chunks into separate files. However, the process of identifying data vs. code is imperfect. An SGC file gives you the music engine separately from the rest of the game which might make it easier to reverse engineer, but then it's tricky to step through. A small stub to make it a valid SMS file might help. A first step might be to try to find some identifying signature of the music engine to check which games use it. The music trigger system which is very common might indicate that there is a great deal of common music engine code out there. Some time ago we also discovered a suboptimal note to PSG frequency table which was seen in a large number of games, another suggestion of common code. Here's a promising start: https://github.com/trykaar/dc-sms-dasm/tree/master/sound

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Thu Jan 15, 2015 2:12 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Thank you. would you happen to have an idea how to add a stub to make the sgc file work? Would it be more than just adding a header and having the first line of executable code...not sure if it is 0x100..jump to the start of the sgc routine...not entirely sure where that is. --- I just noticed that a lot of rips I had queed to work on have already been posted. (Alien Storm, Power Striker, Prince of Persia). I didn't get far (only logging and naming). Surprised I missed it considering I was using a list. I can see why I overlooked Power Sriker...I was ripping it as aleste-played through the whole thing and found a way to keep the music going while pause. But didn't notice alien storm at all..Prince of persia as well. I was only able to get two tracks from it...how did you get the rest. Did you play through or is there a memory hack/hex edit available? Would be nice if you could share. ---- I'm about to work on alien syndrome...do you know if that's been done? Cause I don't see it. That and girl's garden are the only thing remaining on my queue besides a few requests and a pack i still need to fix. There's also a game called Ninja princess I played a while ago and beat (Sg-1000). I didn't know about vgm logging then, but it's hard even with cheats. Have not been able to find a memory trigger. Wish there was a masterlist that showed everything...completed..incomplete..in progress...like the memory triggers page. Would make things easier for the rippers....don't seem to be alot of us around...even though it's alot easier than alot of the work that goes on around here.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Thu Jan 15, 2015 2:33 pm
	An SGC stub would need to be made easy to disassemble, but it would probably be a few hours' work for an experienced SMS developer. Code starts at address 0, you'd need to set up a frame interrupt handler too. All the VGMs are either here: http://www.smspower.org/Music/VGMs Or here (historical): http://www.smspower.org/Music/PendingPacks Or in this forum (where pending packs go to wait for attention now). I don't see Alien Syndrome anywhere. Watch out for name variations, as you saw, by browsing from the game page. I think I ripped Prince of Persia a long time ago. It's a Krisalis game, so no trigger, but I found the play track hook and worked on that. You could rip it all easily with passwords anyway.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Thu Jan 15, 2015 5:07 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Maxim, Do you know if GG pal games adjust? If I set it to 50hz will it be too slow or correct? I'm thinking of working on daffy duck in hollywood, but it has 16 songs, so I'll wait until I know it will log fine at 50hz on meka, or if I should set it to 60hz...(I remember reading somewhere that gg games adjust. It's a late 1994 addition, virgin game with their music engine.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Thu Jan 15, 2015 7:12 pm
	There is no such thing as a PAL Game Gear. They are always 60Hz with NTSC timings. Where a game was released on both GG and SMS, the engine may adjust so the PAL SMS and NTSC GG sound the same. 50Hz in Meka doesn't affect the VGM log, you have to select the TV type (PAL/NTSC). While logging the VGM, you can set the speed to 200Hz or whatever with no effect on the result.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Thu Jan 15, 2015 10:41 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Yes that's what I meant..So based on what you said...if I set the tb type to 50 or 60 it doesn't matter....or is 60 is always correct, and anything else is wrong? I could probably verify with some tests..but it would be nice to hear directly. It's funny, cause my for my first packs I logged everything without changing the speed so it took a while. Then I realized i could speed up without affecting the output negatively...only to overlook that there was a tv type that was necessary. I thought it was just a meaningless throwback for nostalgia's sake..like sai video filter, just for novelty, and now I have a few packs I need to redo. So I would appreciate a dumbed down answer so I'm sure I'm hearing what I think I am (When I was told meka logs everything the same regardless of the speed, I misunderstood that it also fixed 50hz timings on its own (I assumed based on rom headers). Now I know it's a bit more complicated than that, and such a solution might actually be counterproductive. So, for the hard of hearing....one more time please? In plain english. I am logging a pal gg game...so tv/setting can/should be....anything? 60hz?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Thu Jan 15, 2015 11:21 pm
	Game Gear: NTSC always. A European GG game is not a PAL game. Master System: NTSC if you think the game was designed for 60Hz, PAL if you think it designed for 50Hz. Set the emulator to PAL/50 and listen to the music. Switch it to NTSC/60 and then reset the game. If the music is the same speed, then the game compensates.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Fri Jan 16, 2015 2:28 am
sherpa Joined: 28 Nov 2014 Posts: 365	Thanks for covering all the bases. That last tip is priceless, I might do that even when I think I'm sure, especially as I am not familiar with most of the games I log. Most of the ones I am familiar with were logged a long time ago. Pretty sure I already did the few that weren't.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14738 Location: London	Posted: Fri Jan 16, 2015 9:23 am
	Getting back to the pack, the extended cover image is not very good. I posted it nevertheless, I may have a go at the image myself.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Fri Jan 16, 2015 10:05 am
sherpa Joined: 28 Nov 2014 Posts: 365	lol. It came out better than I first imagined it would, but if you can figure a way to make a very rectangular image square without resizing. I'll take your example as a model

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Wed Feb 25, 2015 2:37 am
sherpa Joined: 28 Nov 2014 Posts: 365	updated pack. track 4 had the wrong tag

Forums

View topic - [VGM Pack] Ace of Aces