Notes on YM2612

[TmEE co.(TM)]

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.

[TulioAdriano]

Now that my flash cart is rocking again and my new NTSC Sega Genesis is arriving, if you write benchmark programs to measure these timers frequency and whatever else, I can run then on both Genesis and
Mega Drive and let you know what the results are.

[Shiru]

ALWAYS write the high part first if some regs are "ganged together"

This caution is present in any documentation for YM2612 (twice in sega2.doc).

DAC can play samples at 60KHz continuously, anything above is unstable.

Like we discussed somewhere on this forum, this frequency resembles work frequency of internal serial DAC of YM2612, so it can explain this limitation.

2 NOPs after each write to YM2612 is ALWAYS enough

That not very detailed information. How exactly you write data? There is some different ways to do that:

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?

[TmEE co.(TM)]

As fo NOPping I've wrote to YM2612 like so :

Code: Select all

LD   HL, FMPORT2
LD   B, $12
LD   A, $34
LD   (FMPORT1), A
NOP  #2
LD   (HL), B
NOP  #2

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 ?

[Eke]

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:

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)

[Shiru]

data gets written to YM2612 at the last ticks, so it doesn't matter how you write

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:

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).

[TmEE co.(TM)]

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.

[TmEE co.(TM)]

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.

[Chilly Willy]

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.

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:

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.

[TmEE co.(TM)]

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

[Shiru]

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.

Thats right for all other algorithms too (operators 2 and 3 in that manual must be exchanged).

Back on the Amiga...

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).

on 68K side it'll work well, but nobody with brains would want to use 68K in sound production process in MD

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)]

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).

[Shiru]

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...

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.

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).

[Chilly Willy]

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...

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)]

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...