New Documentation: An authoritative reference on the YM2612

[Stef]

Definitely very precious informations you're revealing here Sauraen !! The 9th bit of the DAC which is actually present in the test register, wonderful finding
Something i'm really wondering, you said it would be pretty difficult to predict the behavior of the BUSY flag, but from what i understood it seems that only registers linked to OPN / FM states requires sort of processing time. Does it mean that writing to port 0 and port 2 (register index value) can be done at any time ? or at least that we can immediately write to port 1 or port 3 just after writing them ?

if i do something as :

Code: Select all

- wait while BUSY become 0
- write register index in port 0/2 then immediately write register value in port 1/3

Does it should always work ?

[Sauraen]

Definitely very precious informations you're revealing here Sauraen !! The 9th bit of the DAC which is actually present in the test register, wonderful finding

Thanks! I'm having a lot of fun with this too.

Something i'm really wondering, you said it would be pretty difficult to predict the behavior of the BUSY flag, but from what i understood it seems that only registers linked to OPN / FM states requires sort of processing time. Does it mean that writing to port 0 and port 2 (register index value) can be done at any time ? or at least that we can immediately write to port 1 or port 3 just after writing them ?

I took a look at the BUSY signal and associated stuff, and this is what I've found so far.

-- The signal that appears in bit 7 of the default read register is NOT the same as the signal that appears on the Test pin when it's configured as an output (by $2C:7 = 0).

-- Neither signal affects any logic between the external I/O bus and the chip-level registers. This includes all the $2X registers, and also the address register and data register that all other addresses use. (I.e. when you write $78 to $52, it immediately stores $52 in the address register and $78 in the data register, and then when that operator--determined by the current address register--comes around in the circular buffers, it actually changes the value to whatever's in the data register.) This has the following results:

• The only limit on how fast you can write to the $2X registers is the YM2612's internal clock. Certainly it would need to have one cycle (6x 68000 clock cycles) for it to catch anything; I'd give it at least 2 (12) or maybe 3 (18), but hardware testing on this point would be great. Writing the address and writing the data should take the same amount of time. Writing data doesn't unlatch the address, you can keep writing data over and over to the last address. (I'm assuming this might be useful for the DAC.) Of course writing to the DAC faster than the YM2612's sample rate (external clock / (6*24)) will be useless.
• You can write to a $2X register while you're waiting for the channel/operator register write to complete. (EDIT: this is unfortunately not true)
• If you write to another channel/operator register while the last one is still pending, the previous write will be lost--it won't block the new write. The one exception is that if you write one address and data, and then you write a new address and data, but between writing the new address and writing the new data the new address's register comes along, it will write the old data in the new address (and then 24 cycles later the new data at that address, assuming the address didn't change before this). I'm just being specific here because someone might think "for any write, EITHER the chip misses it completely OR it gets it"--but this is a circumstance in which it gets the write wrong.

-- The signal that appears on the Test pin originates from a "master sequencer" control unit (other outputs of which, for example, are the control signals for the algorithm in the operator unit, and a bunch more which I haven't traced yet). This control unit is located at the upper right of the PG and has a sizable decoder "table" and a couple smaller tables. (Sorry, Nemesis--this is a table you're not going to have worked out every bit of in your source code already! ) Some of the outputs go directly into the interconnect, others go into push-pull buffers and then are routed throughout the chip. The Test pin output signal is one of these--it also ends up going to the PG, one of the timers, the channel register file, and probably a couple other places. I haven't traced the rest yet--hopefully more info coming soon.

-- I hope I'm wrong about this, but this is what it looks like as best I can tell: the signal that appears on the default read register bit 7 (i.e. "BUSY") comes from a small timer/counter whose only inputs are the two clocks [the chip has clocks of both polarities throughout], system reset, and the "please read data off bus into registers" signal. The counter has 5 or 6 stages and is probably an asynchronous counter rather than a shift register, meaning it counts 32 or 64 cycles (of the internal clock, which is divided by 6 from the external clock). Since there's no other inputs, this means the timer starts when you write data and BUSY goes high, counts a certain number of cycles, and then clears BUSY. I'm guessing it's 5-bit and 32 cycles, because 24 cycles would be enough to ensure that all the operator registers have been updated. (Of course these are internal clock cycles, which is the external [68000] clock divided by 6.)

I say I hope I'm wrong because if this is true, it means:

• The BUSY bit doesn't actually tell you any useful information about the chip's internal state, it's just a dumb timer for a fixed interval after a write. You might as well do timing in software.
• It implies that "the chip is busy", but in fact there's a lot you can do with the chip during that time (most importantly DAC writes).
• It overestimates the amount of time needed by 33% (32 instead of 24 cycles).
• 32x6=192 68000 cycles (about 90 Z80 cycles) is a lot of wasted time! I really hope it's not 64 internal cycles for some dumb reason!
• It makes the sound driver wait more than one sample between writes (assuming the sound driver does wait for it). This means the sound driver could never play a sample at the full YM2612 sampling rate, let alone do that and play other music at the same time.

Can someone please test writing to various registers and counting Z80 cycles until the BUSY bit (bit 7 of the read register) goes low? Your counting doesn't have to be very accurate, one count every few Z80 cycles is plenty. Just check and see whether it's the same for a chip register, a channel register, and an operator register; and do the test a few times each, to make sure it's constant in each case.

[TmEE co.(TM)]

From my tests if you write to DAC faster than half the YM sample rate you get missed writes, sound gets noticably worse at that point.
When you wait for busy you get roughly 22KHz sample rate when waiting for the DAC on some chips and roughly 32KHz on others (that is what i recall someone saying, I no longer remember results from my own tests).
Some writes such as TLs seem to take longer to process than other stuff, I do full software timing in my old sound driver and I always had to have longer delays on TL writes or the data got mangled and I got wrong output. Same deal with the LR flags register. Others seemed to work faster. It doesn't make too much sense on hardware level though, at least if I designed the thing it wouldn't work like that

From what I have observed if you write too fast to the chip the new write will overwrite the old data messing up previous operation. Your research seems to confirm it.
The busy flag SHOULD tell you when the chip is ready to grab new data. I would have thought the busy flag is cleared every sample or so. I guess it isn't the case...

[Stef]

Strangely in my case i never test the BUSY flag for DAC write and writing above 22 Khz does seems possible. Actually i logged output between 22 Khz DAC output and 32 Khz DAC output and i observed a real difference. Still it's quite difficult to say how much was actually played by the YM2612 DAC as my notebook microphone jack is pure shit but i can definitely saw the 32 Khz signal was better and more defined than the 22 Khz.
You can easily do the test by yourself by using the "sound" sample given in SGDK, the first driver test allow you to play the same sample at different output rate (from 8Khz to 32Khz).

About the BUSY flag itself, well in my case i never measured how much time it stay up but if it counts one sample for each write (even after address register write ?) then that is a pure waste of time :-/ What i can say is that the effective process time by the YM2612 is dependent from the register you are actually writing (as TmEE said). I observed than some registers requires no more than ~25 Z80 cycles to be processed but others can take a long than ~70-80 Z80 cycles... so now to be safe i am always testing the busy flag.

I would say that a good practice to write YM register is to always check BUSY flag to be 0 first.
Then if you need to write severals 2x registers you can write them really quickly with maybe 2 NOP to be safe between each write.
When you write a specific register you write its address then you can immediately write its value, no need to check the BUSY flag between the address and value write... If that work then that is already a good thing to know

You said that :
<<You can write to a $2X register while you're waiting for the channel/operator register write to complete.>>
But if you do that, you can change the address register before the write to channel/operator occurred so the value is lost (or happen in the 2X register) ?

Oh and by the way, internal clock of YM is not Z80 clock but 68000 clock (i just said that in regard of the Z80 cycle informations i gave) =)

[Sauraen]

Some writes such as TLs seem to take longer to process than other stuff, I do full software timing in my old sound driver and I always had to have longer delays on TL writes or the data got mangled and I got wrong output. Same deal with the LR flags register. Others seemed to work faster. It doesn't make too much sense on hardware level though, at least if I designed the thing it wouldn't work like that

The busy flag SHOULD tell you when the chip is ready to grab new data. I would have thought the busy flag is cleared every sample or so. I guess it isn't the case...

Haven't checked yet, but this is how I think it is:
- All $2X registers will update within one internal clock.
- All operator registers update once every 24 internal clocks. But you never know where in the cycle you're going to be, so you have to wait at least 24 clocks in all cases to be sure.
- Some channel registers are like the operator registers and only update once every 24 clocks. Others update every 6 clocks. Hopefully I'll figure this out soon.

The BUSY flag/bit does indeed tell you that the chip is ready--it just waits longer than the maximum necessary, so if you wait for it you're guaranteed to not mess anything up.

About the BUSY flag itself, well in my case i never measured how much time it stay up but if it counts one sample for each write (even after address register write ?) then that is a pure waste of time :-/

No, it's triggered by data write, you can write addresses all day and the BUSY flag won't be affected. But yes, it waits more than one sample, since one sample is 24 clocks and it waits 32.

One other thing to mention: it's possible they might have changed the BUSY flag in the YM3438 to actually only wait 24 clocks--I took a quick look at the die of that chip, and it's completely different, almost unrecognizable. The YM2612 is not only similar to the YM2203, they actually copied-and-pasted blocks from the YM2203 to the YM2612--in fact the position of some of the control units in the operator unit of the YM2612 matches where they were in the YM2203, even though this positioning doesn't make sense anymore in the YM2612. But anyway, both of these chips are built in NMOS, not CMOS (there's no P-channel FETs, and they vary transistor lengths rather than widths to control current and timing--breaking all the rules I'm learning in VLSI class!), so when the chip was redesigned in CMOS, it had to be completely redone from the ground up, they couldn't keep a single register. If they indeed changed the BUSY flag timing, this might explain how that one track in that one game plays faster on one system than another.

I would say that a good practice to write YM register is to always check BUSY flag to be 0 first.
Then if you need to write severals 2x registers you can write them really quickly with maybe 2 NOP to be safe between each write.
When you write a specific register you write its address then you can immediately write its value, no need to check the BUSY flag between the address and value write... If that work then that is already a good thing to know

I would say this:

• Always give at least 1 YM2612 internal cycle (about 4 Z80 cycles) between any writes to the chip.
• Don't ever check the BUSY flag between writing address and data, it'll never be set anyway (unless it was already set before you wrote the address).
• Don't check the BUSY flag if the last address written was a $2X register.
• For all other writes, do software timing of just over 24 YM2612 internal cycles (about 70 Z80 cycles); this will save you about 25% from waiting for BUSY (about 90 Z80 cycles).

Could someone please check this on hardware? I especially want to see what the minimum timing is for $2X writes and between address and data for all writes.

You said that :
<<You can write to a $2X register while you're waiting for the channel/operator register write to complete.>>
But if you do that, you can change the address register before the write to channel/operator occurred so the value is lost (or happen in the 2X register) ?

I did mean that, but after thinking about it I take it back. The address register and data register for all other chip writes are at the same "level" as the $2X registers. So the access time for any of them is the same, and there ordinarily would be no reason you couldn't put an address and data in the operator/channel address register and data register, and then write to another $2X register immediately afterward. However, unfortunately, the operator/channel address register is enabled by any address which is not $0X. If I was designing it, I would have made it enabled by any address not $0X or $2X (would have taken slightly less logic than they actually have)--but the way it is, if you write another $2X register the operator/channel address register will get overwritten with that value as well. Sorry!

Oh and by the way, internal clock of YM is not Z80 clock but 68000 clock (i just said that in regard of the Z80 cycle informations i gave) =)

Fixed, thanks! Dumb mistake, I've been playing with hardware clock circuits for these chips for the past few days, I know their frequencies.

[Stef]

Haven't checked yet, but this is how I think it is:
- All $2X registers will update within one internal clock.
- All operator registers update once every 24 internal clocks. But you never know where in the cycle you're going to be, so you have to wait at least 24 clocks in all cases to be sure.
- Some channel registers are like the operator registers and only update once every 24 clocks. Others update every 6 clocks. Hopefully I'll figure this out soon.
...
No, it's triggered by data write, you can write addresses all day and the BUSY flag won't be affected. But yes, it waits more than one sample, since one sample is 24 clocks and it waits 32.
I would say this:
...

• Always give at least 1 YM2612 internal cycle (about 4 Z80 cycles) between any writes to the chip.
• Don't ever check the BUSY flag between writing address and data, it'll never be set anyway (unless it was already set before you wrote the address).
• Don't check the BUSY flag if the last address written was a $2X register.
• For all other writes, do software timing of just over 24 YM2612 internal cycles (about 70 Z80 cycles); this will save you about 25% from waiting for BUSY (about 90 Z80 cycles).

Thanks, definitely gold informations for anyone developing Z80 driver
You sometime need to write a lot of data to the YM2612 so saving cycles for write is important !

One other thing to mention: it's possible they might have changed the BUSY flag in the YM3438 to actually only wait 24 clocks--I took a quick look at the die of that chip, and it's completely different, almost unrecognizable. The YM2612 is not only similar to the YM2203, they actually copied-and-pasted blocks from the YM2203 to the YM2612--in fact the position of some of the control units in the operator unit of the YM2612 matches where they were in the YM2203, even though this positioning doesn't make sense anymore in the YM2612. But anyway, both of these chips are built in NMOS, not CMOS (there's no P-channel FETs, and they vary transistor lengths rather than widths to control current and timing--breaking all the rules I'm learning in VLSI class!), so when the chip was redesigned in CMOS, it had to be completely redone from the ground up, they couldn't keep a single register. If they indeed changed the BUSY flag timing, this might explain how that one track in that one game plays faster on one system than another.

I observed than write processing time on YM3438 is actually *slower* than YM2612 ! I got some issues on my MD2 with my initial driver implementation because i only tested it on MD1 for a long time :-/

[TmEE co.(TM)]

26KHz is the effective max for the YM DAC register from my tests, going higher makes the sound worse. I haven't done any actual investigation but there cannot be anything else happening than missed writes. I played some real music and all the higher freq stuff was getting garbled when you went beyond 26KHz.

The game Hellfire has 2x slower music on MD2 than on MD1. The game spams YM with unnecessary writes and is being polite about it (waits for busy).
Discrete YM3438 didn't seem to run 2x slower (I no longer remember the result...), but it has issues in other games (I recall Sonic Spinball being one).

[Sik]

Suddenly using blind cycle counting instead of BUSY in Echo is looking like a scaringly good decision.

Also this reminds me, isn't it possible for the 68000 to read BUSY before it gets the chance to get set, at least on the YM2612?

[Sauraen]

Thanks, definitely gold informations for anyone developing Z80 driver
You sometime need to write a lot of data to the YM2612 so saving cycles for write is important !

Thanks, but I hope it's right! This is why I keep asking for someone to write some tests and run them on real hardware. I will be able to do so soon with a discrete YM2612 in a prototype board for my synth, but I don't have a Genesis flash cart nor do I know Z80 or 68000 ASM.

I observed than write processing time on YM3438 is actually *slower* than YM2612 ! I got some issues on my MD2 with my initial driver implementation because i only tested it on MD1 for a long time :-/

The game Hellfire has 2x slower music on MD2 than on MD1. The game spams YM with unnecessary writes and is being polite about it (waits for busy).
Discrete YM3438 didn't seem to run 2x slower (I no longer remember the result...), but it has issues in other games (I recall Sonic Spinball being one).

Interesting. I have two different revision Genesis 2's (US models), and I will probably end up with a model 1 at some point. I also plan to throw a discrete YM3438 into the synth board at some point and see what happens.
Also, that seems to answer the question at least in a general way. YM3438 has a longer BUSY delay because it has a longer internal register write delay as well. So the sound driver waits for BUSY, ends up waiting longer (maybe missing every other timer rollover or something?), and ends up slower.

26KHz is the effective max for the YM DAC register from my tests, going higher makes the sound worse. I haven't done any actual investigation but there cannot be anything else happening than missed writes. I played some real music and all the higher freq stuff was getting garbled when you went beyond 26KHz.

That may not be entirely true. While it may be that there's some weirdness with the chip that causes the DAC value to be outputted only once every other sample (haven't seen this yet), I think what's more likely is that since this is roughly half the sampling rate, if you play music between this and the full sampling rate, it will play some samples once and some twice, which will introduce a whole bunch of aliasing at basically random frequencies. However, it should be that if you play samples at the full sampling rate, exactly (68000 clock) / (24*6), or exactly 144x 68000 instructions per sample, it will sound crystal clear. (Well maybe that's a stretch--it's still 8-bit, or 9-bit if you use the extra bit from $2C...)

Suddenly using blind cycle counting instead of BUSY in Echo is looking like a scaringly good decision.

As long as the BUSY delay is indeed longer than it needs to be, then yes.

Also this reminds me, isn't it possible for the 68000 to read BUSY before it gets the chance to get set, at least on the YM2612?

Yes, if you violate the address/data timing requirements for the YM2612! Remember the internal clock is divided by 6 from the 68000 clock, so it takes at least 6 cycles if not 12 or so for the YM2612 to respond to its I/O bus. If you write a data byte and manage to "read" the data bus again in 3 or 4 68000 cycles, whatever data you read will be completely invalid. But as far as its internal clock, BUSY should get set on the same cycle as the data register gets loaded internally (which is probably the cycle after the I/O bus was written), and it should be externally readable on the cycle after that. So that could be up to 18 68000 cycles--so I could easily see how the status register could be read before BUSY was set.

[Eke]

From what I remember, Hellfire sometimes reads the FM status (timers and busy flags) from $4001-$4003 instead of just $4000 as recommended so maybe some (or all) of those flags can only be read correctly when A0 is low ?

[Stef]

Also this reminds me, isn't it possible for the 68000 to read BUSY before it gets the chance to get set, at least on the YM2612?

When i designed my sound driver i first though it was possible but then i realized i was trying to read the busy flag from port 1/2/3 instead of port 0. Even from the 68000 i am not sure you can go that fast so you can read the busy flag before it actually turns to 1, also i never saw any Sega technical information about it and i believe that an issue like this one would have been probably notified by Sega engineers back in time.

26KHz is the effective max for the YM DAC register from my tests, going higher makes the sound worse. I haven't done any actual investigation but there cannot be anything else happening than missed writes. I played some real music and all the higher freq stuff was getting garbled when you went beyond 26KHz.

I don't know how you achieved to obtain these result as myself i never experienced worse sound by going higher... i have to admit i never tried going above 32 Khz anyway, 32 Khz is already quite high and eat rom very quickly :p

Also, that seems to answer the question at least in a general way. YM3438 has a longer BUSY delay because it has a longer internal register write delay as well. So the sound driver waits for BUSY, ends up waiting longer (maybe missing every other timer rollover or something?), and ends up slower.

That is the problem, if we want to maintain compatibility with the MD2 we still have to wait for that BUSY flags as we don't know how slow is the YM3438 :-/ And maybe that unlike the YM2612, it does even requires a small wait between the address write and the value write (i hope that is not the case !)

[Sik]

Echo just assumes 19 Z80 cycles is enough. It seems to work for the most part (the only problematic part is instrument loading where it bangs 29 writes in a row, but moving 1 or 2 more instructions in the loop does the job).

also i never saw any Sega technical information about it and i believe that an issue like this one would have been probably notified by Sega engineers back in time.

That means nothing, most addenums are still missing. Also the fact we're still missing the documentation for the 3 button controller should say something.

[Stef]

Echo just assumes 19 Z80 cycles is enough. It seems to work for the most part (the only problematic part is instrument loading where it bangs 29 writes in a row, but moving 1 or 2 more instructions in the loop does the job).

19 cycles is enough for what ? Depending the register wrote on YM2612 you actually need to wait *a lot more* than 19 Z80 cycles.

[mikejmoffitt]

Discrete YM3438 didn't seem to run 2x slower (I no longer remember the result...), but it has issues in other games (I recall Sonic Spinball being one).

Given that the discrete YM3438 has different behavior than the ASIC one, and the ASIC one is further different from the YM3438 design, are we sure the ASIC one isn't actually a Sega fixed-and-improved YM2612 core?

[TmEE co.(TM)]

Service manuals say "YM3438" in the ASIC diagram.