Test of YM2612 (run on hardware needed)
Moderator: BigEvilCorporation
Test of YM2612 (run on hardware needed)
Eke asked in neighbor thread, if multi-frequency mode works on channel 6 (channel 3 of second bank) of YM2612. I want to know this too, so I wrote small test in C (compiled with SGCC). If anybody can run this test on real hardware, we surely will know:
- If multi-freq mode works on channel 3 (must work)
- If multi-freq mode works on channel 6 (not known)
- If it possible to keyon operators separately (must work)
- Which connection has operators with bits in key on/off register (seems 0-1-3-2)
Test automatically do this things:
- Setup operators of channels 3 and 6 for multi-freq mode, Cmaj accord with octave double (C-4 E-4 G-4 C-5 for operators which correspons to registers A6A2, ACA8, ADA9, AEAA)
- Play note in normal mode on ch3 (all operators at once)
- Play note in normal mode on ch6 (all operators at once)
- Play note in multi mode on ch3 (all operators at once)
- Play note in multi mode on ch6 (all operators at once)
- Play note in normal mode on ch3, all operators switches on with small delay, one by one
- Play note in multi mode on ch3, all operators switches on with small delay, one by one
It will be better, if output sound will be recorded in sound file to analyze. Compiled test and source code is here.
- If multi-freq mode works on channel 3 (must work)
- If multi-freq mode works on channel 6 (not known)
- If it possible to keyon operators separately (must work)
- Which connection has operators with bits in key on/off register (seems 0-1-3-2)
Test automatically do this things:
- Setup operators of channels 3 and 6 for multi-freq mode, Cmaj accord with octave double (C-4 E-4 G-4 C-5 for operators which correspons to registers A6A2, ACA8, ADA9, AEAA)
- Play note in normal mode on ch3 (all operators at once)
- Play note in normal mode on ch6 (all operators at once)
- Play note in multi mode on ch3 (all operators at once)
- Play note in multi mode on ch6 (all operators at once)
- Play note in normal mode on ch3, all operators switches on with small delay, one by one
- Play note in multi mode on ch3, all operators switches on with small delay, one by one
It will be better, if output sound will be recorded in sound file to analyze. Compiled test and source code is here.
Running on a japanese Mega Drive ver. 1:
http://midnightsleazy.se/dump/YM2612T.mp3
http://midnightsleazy.se/dump/YM2612T.mp3
Big thanks. I don't think that results can vary depending from console version.
So, channel 6 does not have multi-frequency mode - I was wrong, and Eke's assumption..
D7 - operator, which frequency defined by A6A2
D6 - .. ACA8
D5 - .. AEAA
D4 - .. ADA9
So, channel 6 does not have multi-frequency mode - I was wrong, and Eke's assumption..
..is wrong too. And, operators keyon/keyoff events can be controlled separately; operators order same on real hardware. I.e.,Eke wrote:I didn't have modified the Fm core yet to support channel 6 "special mode" but I was wondering if current sound weirdness in some games (some percussion sounds for example) might come from this eventual missing feature ?
D7 - operator, which frequency defined by A6A2
D6 - .. ACA8
D5 - .. AEAA
D4 - .. ADA9
wow... that was fast
thanks for testing and clarifying this !
PS: What about the relation with Operator numbers ? I mean, do register 28h (keyoff/keyon register) bits D7,D6,D5,D4 always respectively correspond to operators 1,2,4 and 3 's state ?
Or on the contrary: bits D7,D6,D5 and D4 resp. correspond to operators 4,3,2 and 1 's state (as stated in docs and done in MAME) BUT in CH3 special mode, operators 1,2,3,4 's frequency are respectively set in registers AD-A9h, AE-AAh, AC-A8h and A6-A2h ?
In both cases, this would mean that the sega manual is also wrong somewhere as the bit correspondance is described like this:
thanks for testing and clarifying this !
PS: What about the relation with Operator numbers ? I mean, do register 28h (keyoff/keyon register) bits D7,D6,D5,D4 always respectively correspond to operators 1,2,4 and 3 's state ?
Or on the contrary: bits D7,D6,D5 and D4 resp. correspond to operators 4,3,2 and 1 's state (as stated in docs and done in MAME) BUT in CH3 special mode, operators 1,2,3,4 's frequency are respectively set in registers AD-A9h, AE-AAh, AC-A8h and A6-A2h ?
In both cases, this would mean that the sega manual is also wrong somewhere as the bit correspondance is described like this:
and frequency registers like this:(page13) REGISTER 28H:
bit 7 = operator 4
bit 6 = operator 3
bit 5 = operator 2
bit 4 = operator 1
From your testing, one of the above statement is wrong... my question is: which one ?(page 16)
Operator 1' frequency is in A2h and A6h
Operator 2' frequency is in A8h and ACh
Operator 3' frequency is in A9h and ADh
Operator 4' frequency is in AAh and AEh
Both wrong. Last part of test shows that bits relates to operators as I described in prev. post (i.e. last pair exchanged - operators has order 0,1,3,2 as anythere else in YM2612). D7 is operator 0.Eke wrote:From your testing, one of the above statement is wrong... my question is: which one ?
;)
Anyway, all that emulated correctly, at least in Gens and Fusion, test works exactly same as on real hardware.
Yes, you are right
The strange thing is that both MAME and GENS use the same bit description as in sega's doc :
from GENS ym2612.c:
In the given code, FNUM and KC tables entries 0,1,2,3 are, in order, prewrittten values from registers A2/A6h, A8/ACh, A9/ADh, AA/AEh, which mean that:
operator 0 frequency is taken from A9/ADh
operator 1 frequency is taken from AA/AEh
operator 2 frequency is taken from A8/ACh
operator 3 frequency is taken from A2/A6h
and, from above code:
operator 0 KEY ON is set by bit4 in register 28h
operator 1 KEY ON is set by bit5 in register 28h
operator 2 KEY ON is set by bit6 in register 28h
operator 3 KEY ON is set by bit7 in register 28h
which becomes equivalent to your statement (relationship between register 28h bits and registers A2-AEh frequencies), except that operators are inversed.
I think this will sound the same as hardware as long as each operators are considered to be identical (configured the same way in 30h-90h registers and each four configured as slots) but I wonder how different it will sound if you change each four operators envellop settings and the algorithm/feedback used (to differentiate each 4 operators)
Note:
In both cores, when accessing 30-90h registers, the following relationship is used:
x0h = CH1,OP0
x1h = CH2,OP0
x2h = CH3,OP0
x4h = CH1,OP1
x5h = CH2,OP1
x6h = CH3,OP1
x8h = CH1,OP2
x9h = CH2,OP2
xAh = CH3,OP2
xCh = CH1,OP3
xDh = CH2,OP3
xEh = CH3,OP3
with each operator named as stated in algorithms (ie, in algortihm #0, operator 0 is "input" and operator 3 is "output")
The following affirmation you made
I don't know if this make sense for you, sorry if I'm not very clear
The strange thing is that both MAME and GENS use the same bit description as in sega's doc :
from GENS ym2612.c:
Otherwise, both cores seem to handle CH3 mode extra frequencies this way (here is Gens code when refreshing channels):case 0x28:
if ((nch = data & 3) == 3) return 1;
if (data & 4) nch += 3;
CH = &(YM2612.CHANNEL[nch]);
YM2612_Special_Update();
if (data & 0x10) KEY_ON(CH, S0); // On appuie sur la touche pour le slot 1
else KEY_OFF(CH, S0); // On relâche la touche pour le slot 1
if (data & 0x20) KEY_ON(CH, S1); // On appuie sur la touche pour le slot 3
else KEY_OFF(CH, S1); // On relâche la touche pour le slot 3
if (data & 0x40) KEY_ON(CH, S2); // On appuie sur la touche pour le slot 2
else KEY_OFF(CH, S2); // On relâche la touche pour le slot 2
if (data & 0x80) KEY_ON(CH, S3); // On appuie sur la touche pour le slot 4
else KEY_OFF(CH, S3); // On relâche la touche pour le slot 4
if (YM2612.Mode & 0x40)
{
CALC_FINC_SL(&(YM2612.CHANNEL[2].SLOT[S0]), FINC_TAB[YM2612.CHANNEL[2].FNUM[2]] >> (7 - YM2612.CHANNEL[2].FOCT[2]), YM2612.CHANNEL[2].KC[2]);
CALC_FINC_SL(&(YM2612.CHANNEL[2].SLOT[S1]), FINC_TAB[YM2612.CHANNEL[2].FNUM[3]] >> (7 - YM2612.CHANNEL[2].FOCT[3]), YM2612.CHANNEL[2].KC[3]);
CALC_FINC_SL(&(YM2612.CHANNEL[2].SLOT[S2]), FINC_TAB[YM2612.CHANNEL[2].FNUM[1]] >> (7 - YM2612.CHANNEL[2].FOCT[1]), YM2612.CHANNEL[2].KC[1]);
CALC_FINC_SL(&(YM2612.CHANNEL[2].SLOT[S3]), FINC_TAB[YM2612.CHANNEL[2].FNUM[0]] >> (7 - YM2612.CHANNEL[2].FOCT[0]), YM2612.CHANNEL[2].KC[0]);
}
In the given code, FNUM and KC tables entries 0,1,2,3 are, in order, prewrittten values from registers A2/A6h, A8/ACh, A9/ADh, AA/AEh, which mean that:
operator 0 frequency is taken from A9/ADh
operator 1 frequency is taken from AA/AEh
operator 2 frequency is taken from A8/ACh
operator 3 frequency is taken from A2/A6h
and, from above code:
operator 0 KEY ON is set by bit4 in register 28h
operator 1 KEY ON is set by bit5 in register 28h
operator 2 KEY ON is set by bit6 in register 28h
operator 3 KEY ON is set by bit7 in register 28h
which becomes equivalent to your statement (relationship between register 28h bits and registers A2-AEh frequencies), except that operators are inversed.
I think this will sound the same as hardware as long as each operators are considered to be identical (configured the same way in 30h-90h registers and each four configured as slots) but I wonder how different it will sound if you change each four operators envellop settings and the algorithm/feedback used (to differentiate each 4 operators)
Note:
In both cores, when accessing 30-90h registers, the following relationship is used:
x0h = CH1,OP0
x1h = CH2,OP0
x2h = CH3,OP0
x4h = CH1,OP1
x5h = CH2,OP1
x6h = CH3,OP1
x8h = CH1,OP2
x9h = CH2,OP2
xAh = CH3,OP2
xCh = CH1,OP3
xDh = CH2,OP3
xEh = CH3,OP3
with each operator named as stated in algorithms (ie, in algortihm #0, operator 0 is "input" and operator 3 is "output")
The following affirmation you made
make me think that perhaps we were using different operator denomination and inverting operators. But anyway, if this is confirmed that bit D7 in 28h stands for operator 0, mame/gens cores could sound incorrect in the few games that use separate keyon/off for operatorsoperators has order 0,1,3,2 as anythere else in YM2612).
I don't know if this make sense for you, sorry if I'm not very clear
There is definitely some mess with operators denomination.
Anyway, I tried to say that if we assume that operator 0 in x0, operator 1 in x4, operator 2 in x8, operator 3 in xC, then algoritm 0 has operators connection 0>2>1>3, not 0>1>2>3 (as described in Sega.doc), and same will be with all other algorithms.
Ok, to ensure which bit in key on/off register exactly corresponds to operators, and to know very important thing about multi-mode (if it can be switched on/off while note plays), I wrote new test, which I again ask to try on real hardware.
Test do this things:
- Setup channel 1 for instrument, which has different operator settings: operator 0 has shortest DR and MUL=1; next operators longer, and MUL increments by one for each operator.
- Play note on channel 1 with only D7 set
- Play note on channel 1 with only D6 set
- Play note on channel 1 with only D5 set
- Play note on channel 1 with only D4 set
- Play note on channel 1 with all bits set
- Next, setup channel 3 with instrument with long sustain
- Switch channel 3 to normal mode
- Begin to play note on channel 3
- After short pause, switch channel 3 to multi mode
- And after another short pause switch channel 3 back to normal mode
New test with source code is here.
Anyway, I tried to say that if we assume that operator 0 in x0, operator 1 in x4, operator 2 in x8, operator 3 in xC, then algoritm 0 has operators connection 0>2>1>3, not 0>1>2>3 (as described in Sega.doc), and same will be with all other algorithms.
Ok, to ensure which bit in key on/off register exactly corresponds to operators, and to know very important thing about multi-mode (if it can be switched on/off while note plays), I wrote new test, which I again ask to try on real hardware.
Test do this things:
- Setup channel 1 for instrument, which has different operator settings: operator 0 has shortest DR and MUL=1; next operators longer, and MUL increments by one for each operator.
- Play note on channel 1 with only D7 set
- Play note on channel 1 with only D6 set
- Play note on channel 1 with only D5 set
- Play note on channel 1 with only D4 set
- Play note on channel 1 with all bits set
- Next, setup channel 3 with instrument with long sustain
- Switch channel 3 to normal mode
- Begin to play note on channel 3
- After short pause, switch channel 3 to multi mode
- And after another short pause switch channel 3 back to normal mode
New test with source code is here.
thanks a lot for your help Shiru
I was definitively mistaken about operator order in algorithm, as both cores use the following definition to index operators in tables:
which mean, with this correction, that in those cores:
PS: generally speaking, your test will clear a lot of things... I'm also wondering on what happen if the program modify any register values during note play (after KEY ON as been set for example)
I was definitively mistaken about operator order in algorithm, as both cores use the following definition to index operators in tables:
with the operator order being SLOT0>SLOT1>SLOT2>SLOT3 in any algorithms, which is exactly what you said, it was my confusion#define SLOT0 0 (operator in x0)
#define SLOT1 2 (operator in x8 )
#define SLOT2 1 (operator in x4)
#define SLOT3 3 (operator in xC)
which mean, with this correction, that in those cores:
in CH3 special mode:
operator 0 (SLOT 0) special frequency is taken from A9/ADh
operator 2 (SLOT 1) special frequency is taken from AA/AEh
operator 1 (SLOT 2) special frequency is taken from A8/ACh
operator 3 (SLOT 3) special frequency is taken from A2/A6h
in register 28h:
bit7 is used to determine operator 3 (SLOT 3) KEY state
bit6 is used to determine operator 1 (SLOT 2) KEY state
bit5 is used to determine operator 2 (SLOT 1) KEY state
bit4 is used to determine operator 0 (SLOT 0) KEY state
PS: generally speaking, your test will clear a lot of things... I'm also wondering on what happen if the program modify any register values during note play (after KEY ON as been set for example)
-
- Very interested
- Posts: 2443
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
I did a test on my MD2 and it sounds like an emulator
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
Alone Coder already did some tests on YM2203, which was verified on YM2612 - so we already knew about most of other registers, but not about special mode on/off.Eke wrote:I'm also wondering on what happen if the program modify any register values during note play (after KEY ON as been set for example) :?:
So, if we change registers after KEY ON but before KEY OFF:
- TL, MULT, DET changes sound properly and immediately
- AR, DR, SR, RR, Feedback changes does not affects on currently playing note, but affects properly after new KEY ON
I forgot about SL, RS, but generally seems like changing of any registers, which controls amplitude and frequency is affects immediately, and changing of any registers, which controls envelope parameters and algorithm is affects after new KEY ON.
Alone Coder did used fact about AR/DR/etc in his compiler of TFM music to preload some values by frame before corresponding KEY ON, that allow to reduce number of register writes per frame (by moving some of writes to prev. frames). That works fine both on TFM device and SMD.
Recently I reread YM2612 section of Genesis Technical Overview (sega2.doc), and it states that channel 6 does have multi-freq. mode (mentioned for several times). So, based on test results, this doc is wrong too.Shiru wrote:So, channel 6 does not have multi-frequency mode - I was wrong, and Eke's assumption was wrong too
But, there is two bits in register #27 which controls special mode, and sega2.doc states that B7=1 is illegal. There is no other info about B7 of that register of YM2612, so I wonder that exactly happens if that bit is set. Seems that on some of OPN family chips B7 controls CSM mode, but YM2612 does not have that feature (?).