Page 7 of 58
Posted: Wed Jul 02, 2008 1:53 pm
Nemesis wrote:4. Timers
Two things here. First of all, I've tested the timer A registers, and confirmed that they are NOT "ganged together" like the frequency registers are. Changes to either register $24 or $25 affect Timer A the next time it overflows or is loaded, regardless of the order the registers are written to.
Secondly, I've confirmed the timer periods in the YM2612 are half the rate of the timers described in the YM2608 documentation, or in other words, the YM2612 timers take twice as long to count down as the timers in the YM2608. Here are the formulae to calculate the correct timer periods for the YM2612:
Code: Select all
To calculate Timer A period in microseconds:
TimerA = 144 * (1024 - NA) / M
M: Master clock (MHz)
Eg, where clock = 7.61Mhz
TimerA(MAX) = 144 * (1024 - 0) / 7.61 = 19376.61 microseconds
TimerA(MIN) = 144 * (1024 - 1023) / 7.61 = 18.92 microseconds
To calculate Timer B period in microseconds:
TimerB = (144*16) * (256 - NA) / M
M: Master clock (MHz)
Eg, where clock = 7.61Mhz
TimerB(MAX) = (144*16) * (256 - 0) / 7.61 = 77506.44 microseconds
TimerB(MIN) = (144*16) * (256 - 255) / 7.61 = 302.76 microseconds
So, based on the formula above is it correct to state that NTSC MD would have slightly faster timers?
For a 7.67 MHz Clock we'd have the Min values for TimerA = 18.77 ms and for TimerB = 300.39 ms.
I'd like very much to confirm the precision of this information to update my SFX Editor for Pier Solar.
Posted: Wed Jul 02, 2008 4:02 pm
There would definitely be a slight difference in the timing between an NTSC and PAL system, as the master clock for the system as a whole is slightly different (53.203MHz for PAL, 53.6931 for NTSC), and every operation any of these chips perform, including tracking the YM2612 timers, is ultimately based on the timing pulse. This will also be affecting the frequency of the tones produced by the YM2612, as well as the PSG. A given note will actually produce a very slightly different frequency between an NTSC and PAL system, although the variation would be undetetable to the human ear.
You've got to remember though that the difference in the timer periods are still "in time" with the rest of the system. Every device in the system runs slightly faster in the NTSC system, and slightly slower in the PAL system. Code running on the system won't perceive any difference in timer periods between PAL and NTSC units, as while the timers do run a bit faster, the Z80 and M68000 also run faster, in the same proportions. As a result, the code running on the system won't notice these variations. Only the user can percieve them by comparing the output with an independent timing source.
Posted: Wed Jul 02, 2008 4:06 pm
I see the ch3 instrument mystery is solved. Nemesis, your a genius
. I have something for you to test out. Ghostbuster track 10 is not emulated correctly by any other emulator except Kega and it would be nice to find out what is it doing too.
Posted: Wed Jul 02, 2008 7:23 pm
Hmmm. On first impressions it could be something to do with the LFO, but I'll need to do a lot more testing to narrow it down. I'll definitely look into it.
Posted: Thu Jul 03, 2008 8:27 am
One interesting thing : Hellfire, on MD2s (and other systems with Sega implementation of YM2612 in the ASIC) the music plays half as slow as it would on Yamaha discrete YM2612 chip (MD1, certain MD2 model). This behaviour is not evident in any emulators I've tried.
Posted: Thu Jul 03, 2008 9:13 am
Don't tell me that. =P I was hoping to get away with a single standard core for either the Sega integrated or Yamaha discrete YM2612.
I've had a brief look, and you're right of course, the music is clearly running at half the rate on the MD2. Personally, I doubt it will turn out to be a difference in the YM2612 that's responsible for this. It's probably a variation in the timing for the integrated Z80 vs the discrete Z80 in the Model 1. I've done a quick check of the YM2612 timers, and they seem to be running at the same rate on the MD1 and MD2. The only other way the YM2612 could affect the speed at which the music progresses would be differences in the delay times between writes on the integrated vs the discrete chip, but my money is on the Z80. It's highly likely there are differences in instruction execution times between the integrated Z80 in the MD2, and the discrete chip in the MD1.
Ok, so far there are two remaining sound emulation mysteries:
-Ghostbusters track 10 lead sounds wrong
-Hellfire music runs twice as slow on MD2 vs MD1
Any other unemulated/only emulated by Kega sound quirks that anyone knows of?
Posted: Thu Jul 03, 2008 9:35 am
the SSG-EG part ?
The MAME core is emulating it like described in the YM2618 manual, but still get it wrong for some games (try BGM and SFX in Asterix, Bubba 'n Stix... )
according to Steve Snake, SSG-EG is patially broken in YM2612, maybe it is related to the missing SSG part
Posted: Thu Jul 03, 2008 9:55 am
I'm a fair way along in my testing of SSG-EG mode. Gens, Kega Fusion, and MAME all have attempted support for SSG-EG, but all of the implementations are broken in different ways.
I know Steve Snake mentioned once that SSG-EG "doesn't always behave like it should" in the YM2612, but I haven't found any indication of that so far. It's always behaved in a consistent fashion for me, and everything it does matches with the documentation I've seen, once I understood what the documentation was saying. The problem is making sense of what little documentation there is, and figuring out how that relates to what it actually does.
The SSG-EG mode wouldn't have been impacted in any way by the removal of the SSG module, as they're logically separate, discrete units, with no direct connection between each other. The SSG-EG envelope generation is handled by the FM module, it just happens to be an implementation of the envelope generator that is used in the SSG module, but it is a separate implementation.
Where I'm currently up to with SSG-EG is that it's become clear from analysing the SSG-EG mode that it would be impossible to accurately emulate without first having accurate information on how to calculate the rates of each part of the ASDR envelope, and apply them to calculate the actual attenuation value over time. Minor inaccuracies in this area would be unnoticeable in normal use, but it's critical to get this right in order to emulate the SSG-EG. I'm currently focusing on calculating this information. Hopefully I'll be able to post some comprehesive information on SSG-EG, and the envelope generator as a whole, sometime in the very near future.
Posted: Thu Jul 03, 2008 11:42 am
Nemesis wrote:Hmmm. On first impressions it could be something to do with the LFO, but I'll need to do a lot more testing to narrow it down. I'll definitely look into it.
Last time when looked into it, I found if I ran envelope generator at twice the speed then the sound would get correct (to some extent, since it uses SSG-EG I think that made a bit of difference). One thing to note is that Ghostbusters tries to use channel 6 in special mode.
Posted: Thu Jul 03, 2008 12:27 pm
....since it uses SSG-EG I think that made a bit of difference....
Doh! That was the first thing I looked for, but it turns out the SSG-EG registers weren't being displayed correctly in my emulator's debugger, so I thought SSG-EG wasn't being used.
Yes, it is just bad SSG-EG support which is responsible for the incorrect sound in Gens. I've extracted the culprit instrument (channel 6) and run it through by itself, and Gens is definitely calculating the SSG-EG envelope incorrectly for this channel. Kega gets this particular case correct. There are other cases Kega gets wrong which Gens gets right.
Posted: Thu Jul 03, 2008 1:58 pm
About SSG-EG. MAME emulates it incorrectly too. Alone Coder did some fixes which I use in TFM MM. They not fix emulation completely, but makes sound more closer to real chip (YM2203) in some cases. His version of MAME code is included into TFM MM package, replayers/pc/mame/ folder. All changes in code can be found by search for 'Alone Coder' string.
Posted: Thu Jul 03, 2008 2:02 pm
thanks for the tip
and apparently, kode54 (foogep developper) also have made some modifications to the MAME core regarding SSG-EG, someone shoudl ask him about that too
Posted: Thu Jul 03, 2008 5:11 pm
Nemesis wrote:I've had a brief look, and you're right of course, the music is clearly running at half the rate on the MD2. Personally, I doubt it will turn out to be a difference in the YM2612 that's responsible for this. It's probably a variation in the timing for the integrated Z80 vs the discrete Z80 in the Model 1. I've done a quick check of the YM2612 timers, and they seem to be running at the same rate on the MD1 and MD2. The only other way the YM2612 could affect the speed at which the music progresses would be differences in the delay times between writes on the integrated vs the discrete chip, but my money is on the Z80. It's highly likely there are differences in instruction execution times between the integrated Z80 in the MD2, and the discrete chip in the MD1.
If Z80 would the the trouble maker, then overclocking should help... and I just tried and it did help, but very little. I used 4.5MHz. Also, my MD2 has a discrete Z80, a clone by Toshiba, but this should not cause the slowdown as then my sound engine must sound wrong (slower for example, the poor Z80 is moving incredible amounts of data constantly). The game uses Timers, and the Timers run at same speed, and if there would be a Timer bug, overclocking would not have helped. So only possible cause would be the Busy bit of Sega YM2612 lasting longer... my sound engine completely ignores that bit, and so do many others. One thing I know is that the Busy bit doesn't last same time for all operations. Setting TL values seems to require more time than say writing to DAC. If it helps, on MD2, if you have a PCM playback loop and you wait for the Busy bit, then maximum sampling rate you get is somewhere near 33KHz. I have not done any tests on MD1 as I got my hands on some MD1s only recently.
Posted: Fri Jul 04, 2008 4:42 pm
Shiru wrote:About SSG-EG. MAME emulates it incorrectly too. Alone Coder did some fixes which I use in TFM MM. They not fix emulation completely, but makes sound more closer to real chip (YM2203) in some cases. His version of MAME code is included into TFM MM package, replayers/pc/mame/ folder. All changes in code can be found by search for 'Alone Coder' string.
Thanks Shiru. I took some time to make some of those changes in my core and they seem to work pretty well. Didn't tested it heavily though. I'll be doing some more testing (means comparing to Kega
) on this.
BTW Nemesis, someone told me that the track 'Ammune Advice' in Dune is not emulated correctly by any emu (including Kega). Although I can't confirm this. Another thing to test out would be whether the behaviour of SSG-EG changes in ch3 special mode.
I am thinking of putting up a new 'private' build of Regen with updates to FM core.
Posted: Fri Jul 04, 2008 7:39 pm
Wow, glad to see all the progress so far.
Aamir, if you need a tester with good ears, I'm your man.
Good work Nemesis.