Posted: Thu Jun 19, 2008 5:57 am
Thanks, that makes sense now. I've never seen those symbols for boolean operators before. I think I must have tried every combination of operators except the right one.
Sega Megadrive/Genesis development
http://gendev.spritesmind.net/forum/
http://gendev.spritesmind.net/forum/viewtopic.php?f=24&t=386
It is also interesting to note that the blip sound only disappears when you use the Gens' core with game music emu. Game Music emu also has the option to use MAME FM core in which case the blip sound is present (which gives the indication that it might not be the FIR filtering). I tried exchanging the operator 2 & 3 order (which is incorrect) in that pirticular Gens' FM core and the blip sound came again. I wasn't able to find any differences between that Gens FM core (which is a modified from Gens 2.10) and the current one (in Gens 2.14) although blargg has modified it very much (mostly for optimization and simplification). I would recommend others to look there for answer to this mystery. I don't have any time right now otherwise I would've looked at that myself in detail.I might look into that. I'm at the stage of planning the YM2612 core for my emulator, and it would be good to know the answer to this mystery before I repeat the same mistakes.
look at ym2151docs.pdf here:http://msx.retro8bits.com/msxdocs.htmlIt does sound a bit sus that MAME only enables CSM mode when D7 is set. The Sega documentation certainly doesn't mention anything about key on/off on timer A, they simply describe the separate frequency values for each slot. I would be surprised if every Mega Drive game has been using CSM mode without having the information about the timer A key on/off control. It's possible the Yamaha documentation has these bits switched. This definitely needs to be tested in hardware.
In Kega you are able to play samples in Stereo, but you can't do it in other emulators and real hardware... Kega won't play the currently played sample on the channel in next one when you change Left/Right reg so you can get nice and clean stereo sample playback. I made a demo which is on my OUTDATED site's MD section : http://www.hot.ee/tmeeco/MD.HTMNemesis wrote:Once again, this behaviour is emulated correctly in Kega. Does anyone know of something Kega doesn't get right?
well, this is handled correctly by the MAME emu (frequencies are updated only when A0-A2, A8-AA are written) but not by GENS (frequencies are updated every time you modify any registers)TmEE co.(TM) wrote: Great work on figuring out what the writing of freq to YM2612 in a wrong way causes. I had all kinds of trouble with it when writing my sound engine, as it didn't work on MD and Kega but worked on all other emulators... now I know that you must write high part first. I wonder if Timer A behaves in a same manner if writes are done backwards ?
I can tell you right now from initial tests, that the value it overflows to is very close to the maximum frequency value you can set normally (block = 0x7, fnum = 0x7FF). I've got a whole series of tests planned to narrow down the exact numbers though.Stef wrote:Kudos for your discover !
I searched about this "bug" for a long time, i guess now we just need to figure internal table/reg size for accurate emulation
Yeah, I'd assumed the same thing. I only found out about this behaviour because I was setting the registers the wrong way around for some of my tests, and was a little puzzled when all I got was silence.HardWareMan wrote:So, you trying to say what whole block&fnum register triggers by write low fnum byte? I always thought that warning is for write rough tune first, then write fine tune, so less error will notice between writes. But now all different. For 8-bit systems it is helpfull for change 16-bit register.
I'm pretty sure I tested on other channels, but now that you've asked, I can't remember for sure. I'll repeat the tests on a few other channels just to be certain.Eke wrote:btw, is this a bug with ch3 only or did you reproduce it on other channels ?
That's a good question. I'll add that to my list of things to test about the timers.TmEE co.(TM) wrote:Great work on figuring out what the writing of freq to YM2612 in a wrong way causes. I had all kinds of trouble with it when writing my sound engine, as it didn't work on MD and Kega but worked on all other emulators... now I know that you must write high part first. I wonder if Timer A behaves in a same manner if writes are done backwards ?
Thanks . It's nice to be able to share this information with other people who can make use of it.notaz wrote:I just want to add my thanks for your work, Nem!
do you mean that the maximal frequency the ym2612 can achieve is given by these max values ? or is the max frequency the max NUM value multiplied by the max FNUM/BLOCK value which have been added to the MAX Detune value ?I can tell you right now from initial tests, that the value it overflows to is very close to the maximum frequency value you can set normally (block = 0x7, fnum = 0x7FF). I've got a whole series of tests planned to narrow down the exact numbers though.
the incremented value is calculated each time that parameters are changed by this formula:(1) CH->SLOT[S0].Fcnt += CH->SLOT[S0].Finc;
where finc is derivated from FNUM and BLOCK values:(2) SL->Finc = (finc + SL->DT[kc]) * SL->MUL;
as you can see, in formula (2), if finc < -DT , the Phase Increment will become negative, which is no good (SL->Finc is indeed declared as signed int so it does not underflow, the only time it is negative should be when it need to be recalculated, i.e forced to -1)(3)
finc = FINC_TAB[CH->FNUM[0]] >> (7 - CH->FOCT[0]);
if (SL->Finc < 0) SL->Finc += FInc_MAX + 1;