New Documentation: An authoritative reference on the YM2612

[Mask of Destiny]

Is there in fact an internal /6 divider on the clock line

Yup, this has been known for a while.

You know, now that you mention that I'm sure I had read as much, but I must have discounted it since there was way too much going on for it to finish in a cycle. I just failed to take into account the possibility of pipelining. Oh well.

By the way, the difference in channel order in the YM2612 may be observable, in so far as the YM2612 outputs the channel values sequentially.

Observable if you bypass all the analog filtering circuitry anyway. From an emulation perspective, the only way it probably matters involves how the order of processing interacts with the funky register file and register write timing.

It's gotta be 3 internal clocks of zero and 1 of a value.
1 X X X 5 X X X 3 X X X 2 X X X 6 X X X 4 X X X
Let's fill in some blanks...
1 2 3 4 5 6 1 2 3 4 5 6 1 ut-oh!
That still doesn't quite work out, simply because we know that 12 cycles after a particular channel is being evaluated (at a particular unit), a different operator from the same channel is being evaluated at the same unit. However, it clearly is 3 internal clocks of zero and 1 of a value--a couple posts down from that one of Nemesis it shows the output along with the master clock. It's clearly 18 master clocks (3 internal) between the beginning of the falling edge and the rising edge, and 6 master clocks (1 internal) between the beginning of the rising edge and the falling edge.

I think I know why it's 3 clocks of zero and 1 of value: Algorithms 5-7. Those algorithms require adding together more than 2 operators for the output. I bet those zeros become the output of operators 1-3. I wonder if we can exploit that to observe the operator update order.

[Sauraen]

From an emulation perspective, the only way it probably matters involves how the order of processing interacts with the funky register file and register write timing.

And that only matters for emulators that actually care about write timings, i.e. Exodus.

I think I know why it's 3 clocks of zero and 1 of value: Algorithms 5-7. Those algorithms require adding together more than 2 operators for the output. I bet those zeros become the output of operators 1-3. I wonder if we can exploit that to observe the operator update order.

In the YM2612 (not in the YM2203) there is, after the operator unit and before the DAC, a unit that looks at first glance like it contains 2 sets of 6-stage shift registers, plus some other stuff, all 9 bits wide. This is also where the DAC value bits and some relevant control wires enter. So obviously this unit is adding up operator values and giving them to the DAC. (Worth mentioning that the 14-bit operator outputs are lopped off to 9 bits before this unit, no rounding or anything, and the adder which adds the operator input to the stored value also must be only 9 bits.) If I do a thorough reverse engineering of this unit, we'll have our answers about the output timing. But it's hard to read actual logic from the YM2612 die shot--that's why I mostly stick to tracing wires in that die, and actually reading gates from the YM2203. (But of course this unit is not present in the YM2203.)

I doubt it's as simple as the 3 zeros are for the three silent operators. Otherwise, when using algorithm 7, we'd get the four operator values out one at a time. And also that would mean that the chip was processing the four operators in consecutive cycles, which is not true (or storing them to emulate this behavior, which would be silly).

[r57shell]

Is there in fact an internal /6 divider on the clock line

Yup, this has been known for a while. It takes 24 INTERNAL clock cycles to evaluate everything, which is 144 external clock cycles.

Hmm, if /6 then 24 cycles for whole processing?
We have 6 channels 4 operators = 24 operators in total. Also, we have X "jobs" (stages / steps).
6*4*X = total things to do. One of X takes T time. Y pipes. Summary, total time is:
6*4*X*T/Y = 144.
X*T/Y = 144/(6*4) = 6
X*T/Y = 6
So, one of possible implementation is: X = Y, and T = 6. So, pipes (workers) Y = X (stages / steps).
Other possible solution: T = 3. It's if you trigger both: CLK rising, and CLK fall. Same as in M68k.
Then X*3/Y = 6. X/Y = 2. Stages in twice more than wokers. Anyway, equation X*T/Y = 6.

We know, that period of output is 24. Ley say, X = Y. Then all is doable in straight forward way.

Code: Select all

 A  B  C  D  E  F   1 2 3 4 5 6
11 44 64 24 34 54 0 1 0 0 0 0 0 out 1 from previous 24 cycle
51 11 44 64 24 34 1 1 0 0 0 1 0
31 51 11 44 64 24 2 1 0 1 0 1 0
21 31 51 11 44 64 3 1 1 1 0 1 0
61 21 31 51 11 44 0 1 1 1 0 1 1 out 2 from previous 24 cycle
41 61 21 31 51 11 1 1 1 1 1 1 1
12 41 61 21 31 51 2 1 1 1 1 1 1
52 12 41 61 21 31 3 1 1 1 1 1 1
32 52 12 41 61 21 0 1 1 1 1 1 1 out 3 from previous 24 cycle
22 32 52 12 41 61 1 1 1 1 1 1 1
62 22 32 52 12 41 2 1 1 1 1 1 1
42 62 22 32 52 12 3 1 1 1 1 1 1
13 42 62 22 32 52 0 1 1 1 1 1 1 out 4 from previous 24 cycle
53 13 42 62 22 32 1 1 1 1 1 1 1
33 53 13 42 62 22 2 1 1 1 1 1 1
23 33 53 13 42 62 3 1 1 1 1 1 1
63 23 33 53 13 42 0 1 1 1 1 1 1 out 5 from previous 24 cycle
43 63 23 33 53 13 1 1 1 1 1 1 1
14 43 63 23 33 53 2 1 1 1 1 1 1
54 14 43 63 23 33 3 1 1 1 1 1 1
34 54 14 43 63 23 0 1 1 1 1 1 1 out 6 from previous 24 cycle
24 34 54 14 43 63 1 1 1 1 1 1 1
64 24 34 54 14 43 2 1 1 1 1 1 1
44 64 24 34 54 14 3 1 1 1 1 1 1

Last 6 columns is "up to date from last 24 cycle". So channel output always store value from 24 (144) cycles back.
Nothing bad in this delay, because anyway you can't do faster, except if you calculate faster. Anyway you need 24 cycles to make 6*4 operators.

Ah... to make it easier to understand. In any way... there is last Stage (in this example stage F), and there is last operator (in this example operator 4). So, time for certain chanell from update to update is equal to delay from appearing this channel in last Stage with last operator. So, channel 4 is updating when last operator of channel 4 appearing in last stage (in example 44 at stage F). As far, as whole sequention has period of 24, thus sequention of operators appearint at last stage (F) has period 24 too, so update time is equal to 24, and during whole that time, it has previous value. It does not matter when we output this value, anyway it's same during 24 period.

Ok, now I shut up, because... I can't help with figuring out die. I can't even open it. (:
But, it would be nice, if someone would crop its units in separate images and mark all input wires. And known ones, named somehow, so we could look at it as several more small units with pins. like as some blackbox with pins. If someone made it already, then I'm slowpoke

[Sauraen]

I'm not sure why you're trying to figure out the pipeline stages, I've already finished that, the information is in my VHDL operator unit at https://github.com/sauraen/YM2612/blob/ ... erator.vhd . There are five stages that actually do work, one that just stores the value, and an additional six-stage delay unit in the YM2612 only which lengthens the pipeline to 12 stages. The PG and EG have their own pipelines.

The image I have of the YM2612 die with several layers of drawings on it is 1.6 GB on disk and 5.7 GB loaded into RAM. Probably at some point I should actually label things better, but it will take a huge amount of effort to label every interconnect wire.

Here's the overall picture:

[r57shell]

I'm not sure why you're trying to figure out the pipeline stages, I've already finished that, the information is in my VHDL operator unit at https://github.com/sauraen/YM2612/blob/ ... erator.vhd . There are five stages that actually do work, one that just stores the value, and an additional six-stage delay unit in the YM2612 only which lengthens the pipeline to 12 stages. The PG and EG have their own pipelines.

Trouble that it's hard to verify. I did look at that vhd. What is suspicious for me, that all stages implemented as "process" in your code. I thought, it should be concurent, and what actually process is shift buffer that does shift. I'm not sure, but that is one of my questions around YM2612.

The image I have of the YM2612 die with several layers of drawings on it is 1.6 GB on disk and 5.7 GB loaded into RAM. Probably at some point I should actually label things better, but it will take a huge amount of effort to label every interconnect wire.

Thanks for brief view of YM2612 internals. I did write app to read it by parts, so I was able to look at it

I have new question: there is working NES emulator with visualisation of gates in action. I'm wondering what tools did they use to make it in vector graphics. Maybe they have tools suitable to make some represetnation of internal connections, to be able to use it with software processing. With raster images you can verify it only with your own eyes. Better would be have some vector representation, where you can process it and do stuff, like simulation.
IDK really. But they made NES, so they did it somehow, maybe they still have all tools available.

I can write my own tool for drawing vectors over schematics, and labeling + tracking them. But I guess it's repeating what already done.

[Sauraen]

What is suspicious for me, that all stages implemented as "process" in your code. I thought, it should be concurent, and what actually process is shift buffer that does shift.

Keep in mind that in VHDL, all statements in a process are executed sequentially, but in zero time. In reality, the statements in the process represent signals flowing through gates, which do happen sequentially. But all the things in a process are what happens between clock edges, which is why the process is triggered on that clock edge. So basically, I tried to have the statements in the process match the flow of data within one cycle, and the processes themselves match the pipeline stages.

Actually, in the chip, any one of these processes is divided into two halves--one with high level-triggered latches, and the other with low-level triggered latches, instead of a single edge-triggered flip-flop. I decided that this would be crazy to try to implement, and also would take much more space on most FPGAs if someone actually tried to compile it. But the only way this would lead to a problem is if there was a timing issue where data had to arrive on the correct half-cycle.

[Sauraen]

New info!

Using MIDIbox Quad Genesis and the test modes, I have confirmed the internal order of calculation of operators and channels.

These tests were performed on hardware (DIP) YM3438s, which is what I have in my synth. You may say this isn't helpful, as this is neither YM2612 nor whatever's in the VDP. But I haven't found any differences between the YM3438 and what's described here for the YM2612, even on undocumented features like the test bits and SSG-EG mode.

The tests were performed as follows:

• Turn on read data mode ($21:6 = 1).
• Select MSB or LSB of read data ($21:7 = 0 for MSB, 1 for LSB--this may be new information)
• Select the signal that appears on bit 14 of the output ($21:0, and it does seem to make a difference, but I still don't know what the two signals are)
• Select whether to read operator or channel outputs ($2C:4 = 0 for operators, 1 for channels)
• Set up to read data from the OPN2 (as if checking whether it's busy). Every OPN2 internal clock cycle, capture a new byte from the bus, for 24 cycles.
• Print the 24 bytes from the synth to a terminal.

The data format is:

Code: Select all

Channel output:
(MSB) SX00000C CCCCCCCC (LSB)
Operator output:
(MSB) SXPPPPPP PPPPPPPP (LSB)
where S is the SYNC signal (see below),
X is the unknown signal selected with $21:0,
C is the 9-bit channel output,
P is the 14-bit operator output

(I just stuck with reading the MSB all the time, since the LSB doesn't have any timing information so you just get random values. In the case of channel outputs, at least you get one bit of it, so the value is negative half the time and you can see where the 1s are.)

I was hoping/expecting that bit 15 (S) would be some sort of sync pulse so I could see where the beginning of the cycle was (and therefore be able to identify every byte subsequently). The results were close to this, but a little confusing.

Code: Select all

Operator output:
111111111100000000000000
Channel output:
111110111000000000000000

Just resetting the chip and setting up the test mode results in each of those patterns on the S signal for the 24 cycles. (Of course, in testing the pattern starts at an arbitrary place in the 24 captured bytes, and wraps around, since I have no idea when in the cycle I start capturing). In addition, during or after playing a note on any channel but channel 4, these patterns are maintained. However, as soon as a single operator of channel 4 starts playing, the S signal changes, and it doesn't change back to this pattern even after the note is keyed off and dies out completely. The new S signal looks like the old one, but with random bits among the first 10 bits, and then all zeros for the remaining 14. Frequently there's only three or four 1s, and they're often spaced out, but they never span more than 10 bits. So it looks like there's some sort of internal sync signal here, which is getting logical-ANDed with some other signal dependent on channel 4. I have NO idea what this is all about--I will do my best to trace this signal on the die.

So the S signal can be used as a sync pulse assuming you never played anything on channel 4. Based on that, I could always align the results, and so I measured all the other operators on the other channels, and filled in the blanks according to the pattern for where channel 4 must be (since I couldn't measure it). (For clarity, operator numbers are the ones from the OPNA datasheet, not the Sega docs. The numbering is such that in algorithm 0, the four operators modulate each other in the order 1->2->3->4, and the registers are in the order 1-3-2-4.)

Code: Select all

Operator output:
S  111111111100000000000000
Ch 456123456123456123456123
Op 444111111333333222222444
Channel output:
S  111110111000000000000000
Ch 226666444411115555333322
or if the S signal should actually be one more step right
S  011111011100000000000000
Ch 222666644441111555533332
(though from some attempts at measuring channel 4 output, I believe it's probably the first one)

So, in English: for operator processing, it's in the order 1324, with all channels' same operator processed next to each other, and the channels in the order 123456. This makes the most sense, and matches the registers, but it had to be confirmed. For channel output, it's in the order 153264 (which was found earlier by someone else by measuring the output with a scope).

There's more work for me to do here, but I figured I'd post what I've found so far.

[Sauraen]

I should have known.

The SYNC signal I was looking for isn't bit 15 of the test read data. It's much simpler than that.

It's on the TEST pin.

*facepalm.jpg*

Bit $2C:7 indeed selects whether the TEST pin is an input or an output. But it's the opposite of what I initially thought (since it was "common knowledge" that the BUSY signal was output from the TEST pin in normal operation). In fact, $2C:7 being 0 means the TEST pin is an input, and 1 means it's an output. The signal it outputs is always the SYNC signal: a pulse that is high for one of the 24 internal cycles, always the same one of course. The state of $2C:6 doesn't affect the SYNC signal being output. (Since I could tell from the die that $2C:6 has something to do with what the TEST input signal does, my guess is it's an enable--if $2C:6 is 0, as in the normal chip, the input is ignored, and if it's 1 the input is used for something. Don't know what it does yet though.)

Since the MBHP_Genesis boards I designed support reading back the TEST pin (as well as the IRQ pin and the PSG's DONE signal), I immediately changed the software in my synth to synchronize to the TEST pin instead of bit 15 of the read data. After some experimentation, this is what I'm using:

• Set $21 to $40 (output data mode) and $2C to $80 (test pin outputs SYNC).
• Wait for TEST to go high.
• Wait for TEST to go low (falling edge).
• Change the parallel interface to read from the OPN2's data output instead of the TEST pin and stuff.
• Wait 5-and-a-half OPN2 internal cycles.
• Capture the OPN2 data output, wait an OPN2 internal cycle. Repeat 23 more times.

With this 5-and-a-half cycle delay between the falling edge of SYNC and the first data capture, the first data captured is Ch 1 Op 1. And then the remaining operator values captured are each of the channels in order, and then the operators in the order 1324. Voila!

So now, whenever it has a little extra time between VGM commands, my synth captures the state of all the operators, calculates the channels' values based on which operators are being output, and displays all the results as VU meters on the front panel. It's quite a light show! And it's the real operators' states, read back from the chip, not an emulation of them. For instance if I turn on SSG-EG mode and push the chip into undocumented waters, the visualization always matches the sound without me having to understand what's actually going on in the EG. Shot a quick video for you all:

[TmEE co.(TM)]

Very awesome !

[Stef]

That is really a awesome discover indeed ! Great work again Sauraen !
I really wish i could have used it for my XGM player instead of trying to emulate it :p

[foobat]

I'd buy one of these if you feel like making 2 instead of 1, Sauraen. Wish I had time to assemble the kit myself, but alas. Hit me up if you feel like making another. I'm flexible on the price.

(serious offer btw, I'm fully aware of how much time and effort goes into a project like this)

[Sauraen]

I'd buy one of these if you feel like making 2 instead of 1, Sauraen. Wish I had time to assemble the kit myself, but alas. Hit me up if you feel like making another. I'm flexible on the price.

(serious offer btw, I'm fully aware of how much time and effort goes into a project like this)

I appreciate the offer, but I don't have the time. However, all the parts you would need to make it yourself are either already available for sale (including the sound chip boards, the processor board, and the MIDI board from the MIDIbox Shop, the sound chips from eBay, and all the components from Mouser), or will be for sale once I have more of the software done (the front panel board will be for sale on the same shop, and I will provide the design files for the aluminum front panel so anyone can order one). It took 10 hours for me to solder all the parts in the front panel board, by the way--there's 638 LEDs!

But you don't have to build a giant flashy box to get your VGM files playing on hardware Genesises. MIDIbox VGM Player is the stripped-down version with only a few buttons and a screen, which plays VGM files from the SD card on the hardware YM2612 and SN76489. The total cost should be under $100 and while you still need soldering experience, it's much tamer. There's also another project, MIDIbox Genesis Tracker, which is just the processor board and the Genesis board with no interface, and it lets you control the chip by MIDI using the same protocol as Littlescale's GENMDM. This is in beta, so if anyone's interested let me know and I can help you build one!

Also I would like to mention that this already is the second unit. The project was commissioned by an indie game composer, Josh Whelchel; as part of the deal, he paid for two units and I got to keep one, which I'm also developing the software on.

[Eke]

Yes, that's really a nice synth you have done

Thanks for confirming the operator and channel order.

I have some questions regarding channel and operator output seen in read data mode, not sure if you were able to figure those:

1) is the format for channel output really 9-bit signed (i.e with sign bit in MSB) or are the values similar to the 8-bit value written to Ch6 DAC register (i.e unsigned value where 0x00 is min and 0xFF is max) ?

2) same for operators, can you confirm the format being output is 14-bit signed (-8192;+8191)?

3) it was reported earlier in this this thread (viewtopic.php?f=24&t=386&start=550) that by summing at least two operators, it was possible to have [-256;+256] range in channel output i.e 513 distinct DAC levels while it was normally limited to [-256;+255] with a single operator as carrier. Did you see anything in the channel "accumulator" (or 9-bit "adder", not sure of the right terminology) that could explain this?

[Sauraen]

1) It looks like 9-bit signed, but it's a little hard to tell since you have to read the lower 8 bits and the upper 1 bit separately. But it does appear that if there's nothing playing (or after power-up), the values is 0--it would be 0x100 if it was unsigned like you say, and that's definitely not what I'm seeing. So yes, basically confirmed.

2) Yes, definitely 14-bit signed. In my synth I'm just reading the MSB and treating it as a 6-bit signed integer (throwing out bits 14 and 15 which do other things). That's the basis for the VU meters, and as you can see they seem to work.

3) I don't know at this point. I haven't reverse engineered the accumulator unit yet. I can tell you it's 9 bits wide, but it's very possible there's a feature where if the sum clips (which we know it does rather than overflowing), it sets the output to +256.

[GManiac]

Hi all!
I haven't read this topic for many years. Maybe, this info was discussed earlier, maybe I'm repeating myself, if so, pardon me.
The subject is "ladder effect". Eke gave link to my old post about DAC output, where I say

operators are shifted arithmetically (not logically) by 5 bits

Ladder effect is a large step between DAC levels -1 and 0. AFAIR, It is 3-4x times larger than usual step between other levels, for example, between 0 and +1.
Arithmetic shift logic and large step makes sound more volumetric and in case of quiet sound makes a big sense (e.g., After Burner, track Super Stripe).

Arithmetic shift is important. Why? Let's compare:
-1 asr 5 = -1
-1 lsr 5 = 0
-31 asr 5 = -1
-31 lsr 5 = 0
-32 asr 5 = -1
-32 lsr 5 = -1
If our output operator is oscillating between -1 and +1, DAC digital output will be:
- in case of arithmetic shift: -1; 0; -1; 0; -1; 0
- in case of logical shift: 0; 0; 0; 0;

Because of ladder effect DAC analogue output will be: -3.5; 0; -3.5; 0
If emulator uses 14-bit DAC, it's "analogue output" equivalent will be: -0.03125; +0.03125; -0.03125; +0.03125 (0.03125 = 1.0/32.0). Range between maximum and minimum (0.0625) is 50 times more silent than on hardware! We will here almost nothing.

So low bitness of DAC plus arithemtic shift plus large step ladder effect is NOT a bug, but feature!

When I was writing my YM emulator, i've simulated ladder and can confirm that After Burner sounded correctly.
Can anyone add this "feature" to existing emulators / players plugins? Usually I listen music via Maxim's plugin.