Notes on YM2612
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Notes on YM2612
There's few things about YM2612 that everyone should know about :
ALWAYS write the high part first if some regs are "ganged together" (what a funny expression). If you don't, you'll get very funny notes.
DAC can play samples at 60KHz continuously, anything above is unstable.
2 NOPs after each write to YM2612 is ALWAYS enough (if you don't plan to overclock the Z80), that comes in handy when you have all regs used, and need very fast code.
Timer B (and possibly A) timing calculations in manual seems to be incorrect, what I calcualted 50Hz is actually around 40...
If anyone have any more info, I'd be more than happy to hear it.
ALWAYS write the high part first if some regs are "ganged together" (what a funny expression). If you don't, you'll get very funny notes.
DAC can play samples at 60KHz continuously, anything above is unstable.
2 NOPs after each write to YM2612 is ALWAYS enough (if you don't plan to overclock the Z80), that comes in handy when you have all regs used, and need very fast code.
Timer B (and possibly A) timing calculations in manual seems to be incorrect, what I calcualted 50Hz is actually around 40...
If anyone have any more info, I'd be more than happy to hear it.
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
-
- Very interested
- Posts: 81
- Joined: Tue Jul 10, 2007 7:45 pm
- Location: Brazil / USA
- Contact:
This caution is present in any documentation for YM2612 (twice in sega2.doc).TmEE co.(TM) wrote:ALWAYS write the high part first if some regs are "ganged together"
Like we discussed somewhere on this forum, this frequency resembles work frequency of internal serial DAC of YM2612, so it can explain this limitation.TmEE co.(TM) wrote:DAC can play samples at 60KHz continuously, anything above is unstable.
That not very detailed information. How exactly you write data? There is some different ways to do that:TmEE co.(TM) wrote:2 NOPs after each write to YM2612 is ALWAYS enough
ld (hl),r - 7t
ld (hl),n - 10t
ld (#4000),a - 13t
ld (ix+n),r - 19t
That make different delay between register select and data write if these writes happens sequentally. There is also variations when you load values into registers - before any writes or between each write.
Also, is that additional 8T delay needed after data write (not register number) and before preparations for new writes?
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
As fo NOPping I've wrote to YM2612 like so :
Sometimes I've used other register pair...
I don't know much about this, but when you write ( I'M NOT SURE WHAT I'M TALKING ABOUT !!!) - data gets written to YM2612 at the last ticks, so it doesn't matter how you write, you have more or less the same time to wait after each write... I'm sure that's incorrect what i've said...
as far it has always worked, unless you overclock Z80 to 4.5MHz.
Anyway, does anyone know the exact connection between YM2612 master clock (7.60/7.67MHz), it's sampling rate and internal timers base freqs ?
Code: Select all
LD HL, FMPORT2
LD B, $12
LD A, $34
LD (FMPORT1), A
NOP #2
LD (HL), B
NOP #2
I don't know much about this, but when you write ( I'M NOT SURE WHAT I'M TALKING ABOUT !!!) - data gets written to YM2612 at the last ticks, so it doesn't matter how you write, you have more or less the same time to wait after each write... I'm sure that's incorrect what i've said...
as far it has always worked, unless you overclock Z80 to 4.5MHz.
Anyway, does anyone know the exact connection between YM2612 master clock (7.60/7.67MHz), it's sampling rate and internal timers base freqs ?
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
Charles Mac Donald once said he measured the timer frequency:
http://www.smspower.org/forums/viewtopic.php?p=46944
In Genesis Plus, he uses the following formulas:
The sample frequency seems to be VCLK/144 = approx. 53270Hz (less for PAL consoles)
So TimerA seems to run at the sample frequency (this counter is maybe incremented after each new sample)
http://www.smspower.org/forums/viewtopic.php?p=46944
In Genesis Plus, he uses the following formulas:
void sound_init(void)
{
/* Timers run at half the YM2612 input clock */
float clock = ((MCLK / 7) / 2);
int i;
/* Make Timer A table */
for(i = 0; i < 1024; i += 1)
{
/* Formula is "time(us) = 72 * (1024 - A) / clock" */
fm_timera_tab = ((int)(float)(72 * (1024 - i)) / (clock));
}
/* Make Timer B table */
for(i = 0; i < 256; i += 1)
{
/* Formula is "time(us) = 1152 * (256 - B) / clock" */
fm_timerb_tab = (int)(float)(1152 * (256 - i)) / clock;
}
}
The sample frequency seems to be VCLK/144 = approx. 53270Hz (less for PAL consoles)
So TimerA seems to run at the sample frequency (this counter is maybe incremented after each new sample)
You're right that actual data write always happens in last M-cycle of opcode (check this). But that not relates to delays between writes. For example:TmEE co.(TM) wrote:data gets written to YM2612 at the last ticks, so it doesn't matter how you write
ld (hl),r
ld (hl),r - 7t between writes
ld (ix),r
ld (ix),r - 19t between writes
It will be useful if you show two sequental register select and data writes. In example which you give, opcodes before ld (fmport1),a makes much bigger delay than last two NOPs. If these last NOPs helped you in this code (if code doesn't work without these NOPs and work with), that means that you need much bigger delay than 8T between two data writes (between data write and next register select, to be exact).
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
It seems that my Z80 MSE can play 2 channels of PCM samples at YM2612 sampling rate which is 52KHz. Thanks for the info !!!
As for NOPping, i'll do some deeper invertigation to get to know the more or less exact delays required.
As for NOPping, i'll do some deeper invertigation to get to know the more or less exact delays required.
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
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
There's a major incorrection in Sega YM2612 manual. The algorithm 4 is not (1 * 2) + (3 * 4) but its (1 * 3) + (2 * 4) like in TFMmaker.
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
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Ever needed more channels but don't want to spend the time scaling and summing every sample? Back on the Amiga, we did this little trick a lot. Just interleave the samples. Let's say you can output a stream of samples at better than 32 kHz. You can interleave four 8 kHz streams together like so:TmEE co.(TM) wrote:It seems that my Z80 MSE can play 2 channels of PCM samples at YM2612 sampling rate which is 52KHz. Thanks for the info !!!
As for NOPping, i'll do some deeper invertigation to get to know the more or less exact delays required.
Ch1S1 Ch2S1 Ch3S1 Ch4S1 Ch1S2 Ch2S2 Ch3S2 Ch4S2 ...
You trade off the time spent scaling the data for a lower channel sample rate. But if you need 8/16 channels of audio and only have four channels and can't spend the time adding samples together, it works great.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
I haven't tried that... but I'm not going to change my driver, it was pain to write, and even more pain to change since it works perfectly and I don't want to change that. In any case I can't easily do it, because of switching banks, and loading 256 bytes of all samples takes time, and RAM, and I can't afford to lose any... on 68K side it'll work well, but nobody with brains would want to use 68K in sound production process in MD
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
Thats right for all other algorithms too (operators 2 and 3 in that manual must be exchanged).TmEE co.(TM) wrote:There's a major incorrection in Sega YM2612 manual. The algorithm 4 is not (1 * 2) + (3 * 4) but its (1 * 3) + (2 * 4) like in TFMmaker.
And return to YM2612;) HardWareMan did some tests long ago, and he said that YM2612 work exactly that way to 'mix' FM channels outputs (he used oscilloscope to analyse YM2612 output).Chilly Willy wrote:Back on the Amiga...
So I currently have no brains;) Because I now have FM driver for M68K side and plan to do some initial tests with it (FM&PSG on M68K, digital on Z80 side) for upcoming TFM MM version for SMD.TmEE co.(TM) wrote:on 68K side it'll work well, but nobody with brains would want to use 68K in sound production process in MD
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
I can't imagine the communication between Z80 and 68K side, since both can't access YM2612 at time... and I agree with you, that's a stupid way of communication... why SEGA didn't put a buffer into MD, so you don't have to stop Z80 to communicate with it ? PCM would get so fucked up...
MAYBE I could base a TFMmaker module player on my driver... your trackers file format is less pain, since all patterns share one order... but the file may need some conversion to have more Z80 friendy structures (i.e data in 256byte blocks).
MAYBE I could base a TFMmaker module player on my driver... your trackers file format is less pain, since all patterns share one order... but the file may need some conversion to have more Z80 friendy structures (i.e data in 256byte blocks).
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
Seems like SEGA just not planned any other usage of Z80/SN76489 than SMS mode, otherwise they could make many improvements. At least INT from YM2612 to Z80 (only one wire needed!) and fast bankswitch.. They also could make separate DAC, it's just some resistors. Anyway, we have that we have.TmEE co.(TM) wrote:I can't imagine the communication between Z80 and 68K side, since both can't access YM2612 at time... and I agree with you, that's a stupid way of communication... why SEGA didn't put a buffer into MD, so you don't have to stop Z80 to communicate with it ? PCM would get so fucked up...
About sharing YM between Z80 and M68K. I think about that way: M68K stops Z80 for write one FM register, run it again and spend some time to prepare new output. So on Z80 side I can have simple digital player, and on M68K each time after FM register write I can select DAC register. So for Z80 DAC register will be always selected. Yes, there will be jitter, but I think it will acceptable for first drafts (anyway I plan to make Z80-only FM+PSG+DAC player for use into real programs).
TFM MM uses patterns format only on editor side. SMD driver uses just compressed stream of registers data (it's possible to convert VGM/GYM to format which can be replayed with driver). And, like I said before, I want to remove that limitation with one order-list (this is editor-only limitation).
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Remember that back then, circuits were expensive. You wanted to use the least number of gates possible, and stopping the Z80 was FAR less expensive than buffering it. SEGA got better about that as hardware costs dropped.TmEE co.(TM) wrote:I can't imagine the communication between Z80 and 68K side, since both can't access YM2612 at time... and I agree with you, that's a stupid way of communication... why SEGA didn't put a buffer into MD, so you don't have to stop Z80 to communicate with it ? PCM would get so fucked up...
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Well, I wasn't born "back these days"... MD was pretty expensive thing, and they cut costs from everywhere (and the sound part makes me REALLY angry !!! I'd kill that guy who designed the mixing circuits in MD !!!) And in my mind, putting a pair quad flip-flops into the chipset and few more comparators wouldn't have made things more expensive than they already were...
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