New Documentation: An authoritative reference on the YM2612

[TmEE co.(TM)]

I have made some good progress and comparing my output with real chip and I am getting correct EG updates and envelope shapes and lengths, and operators 4 to 7 produce correct spectrum !
I have been having some difficulties with Algo3. I get correct output when I have all but first op enabled, whet I have that in play the spectra goes completely wrong... but I will investigate it more tomorrow, it is very early in the morning here hehe

EDIT:
When I have Op1 > Op2 all is fine, but when I got Op1 > Op2 > Op3 then the spectrum goes all wrong compared to real chip...
(Op1 + Op2) > Op3 works out perfectly though, spectrum is much like real chip and of course sounds like so too...

[neologix]

Do you clip or otherwise limit the output in any way before you feed to Op3?

[TmEE co.(TM)]

Only thing I do is shift the 14bit output right 1 time and then add to 10bit output of PG. This I am not too sure of being right.

And I now identified a problem in my EG, my attacks last a lot less that they should. I still have to find out if they reach max too soon or something else...

10 bit EG output + 10 bits of TL I clamp to 10 bits, changing it makes everything go completely wrong so I believe this part is right.

EDIT :
My SL level was not handled right, so far 3 ops work perfectly and produce correct spectrum. 4 ops should work too, I'll test in a moment
...and 4ops work correctly too, producing correct spectrum !
......I can start adding LFO and SSG-EG now.

[andlabs]

I guess I could just update everything at once for now, though knowing how the hardware times updates would be best, and in retrospect GManiac's suggestion makes the most sense =P

Also, are the various EG register values sent to the EG on every cycle and then stored, or on every EG cycle and used immediately?

And how wide is the globalCycleCounter, 11 bits? (I think this might have been answered elsewhere in this thread; I don't remember right now... it's been a while =P )

Thanks.

[Mamizou]

So after struggling with Gimp like crazy for most of the day yesterday, I started tracing out the components on my sliced up version of the OPN2 chip die shot. I started with the DAC because the layers there were the clearest. A lot of it is still unclear, and I don't think it'll get better unless the metal layers are also removed. Anyway, take a look at my progress:

https://www.dropbox.com/s/kbsocon4v6v14 ... g-wip2.png
(Higher resolution available too, if requested)

Color legend
Blue: Metal
Green: Diffusion
Red: Polysilicon
Cyan: Analog voltage supply (A VCC)
Orange: Analog ground (A GND)

[Eke]

You totally right! Analog value matrix is 8x32 (256 levels). 9th bit is a sign.
Sign bit conect DAC matrix to AVCC or AGND via Source/Sink power switches. That is why between two samples on MOL/MOR are 1/2 of AVCC. Thus, 8bit DAC pulls up to the AVCC or pulls down to the AGND which depends on 9th sign bit. Whoah.

Looking a bit more into this, I was wondering: the way sign bit is handled means that the DAC voltage references are basically inverted when sign bit is set (V+ is GND and V- is Vcc) and so resistor array analog output is simply inverted (ideally, 0 1111 1111 would output 255Vcc/256 and therefore 1 1111 111 would be -255Vcc/256), right ?

However, since the 9-bit input value is a two's complement binary (-256 = 1 0000 0000, -255 = 1 0000 0001, ..., -1 = 1 1111 1111), an offset therefore needs to be applied on the analog outputs when sign bit is set.

"ideal" offsets would be:

Code: Select all

 -256Vcc/256 for -256 ($100)
 -254Vcc/256 for -255 ($101)
  ...
 -2Vcc/256 for -129 ($17F) 
  0Vcc/256 for -128 ($180)
+2Vcc/256 for -127 ($181)
  ...
 +250Vcc/256 for -3 ($1FD)
 +252Vcc/256 for -2 ($1FE)
+254Vcc/256 for -1 ($1FF)

I have no idea how this could be implemented (reusing the existing resistor array ?), sign bit seems to do more than basic voltage source switching (it goes to a complex control unit below the 5-to-32 line decoder) but I think that the bug on negative values (what you call "ladder effect" ?) is directly related to this conversion and offsets calculation. There might be additional imprecision which affects both positive and negative values because of non-ideal resistors.

Does that make sense ? maybe it is known stuff and only pointing the obvious without really explaining it but I figured it would be worth mentioning.

[HardWareMan]

Look at DIE shot, where source multiplexer. Sign bit goes to output piece of schematic each other bits and seems to somehow affect to it. Maybe it just makes the necessary inversion of the other bits of data.

[Aly James]

Regarding the "ladder effect emulation" Something that might help on my last post on this page..
viewtopic.php?t=1402&start=21

[TechnoZealot]

That .wav sample you gave sounded like something that used to happen occasionally when I would use the Tone function on my Arduino with a speaker I have, and that was just outputting a raw, digital square wave with PWM.

It seems like there's some sort of an output logic reversal going on, but I might be completely incorrect.

[Aly James]

About the LADDER effect...
As previously stated in the FMDrive Vst thread, a simple way to implement the ladder effect is to add the clean output with the following...
(same behavior is observed on the hardware when you mute a channel, you still ear the distorted part at lower volume..)
This will produce an almost similar signal, spectrum and sound wise.
WAV recordings:
Megadrive PAL model 1 recording

FMDrive MD1 mode recording

and for the sake of comparison here is a clean signal from a YM2164 (from a FB01 unit)

We will do something when the output is negative...
--------------------------------------------------------------------------------------
Ladder output:
-Let's consider the pure clean sine wave signal is going from max +1 to -1
as "sineout"
-Make a condition:
If sineout goes down past -0.009 then output a negative voltage almost 50 times lower then the clean maximum signal.
Else output 0.0 (and this will also prevent audio clicks)

Now let's see what happens to the "Ladder output"...
As you can see on the graphic, as the amplitude of the sine goes much lower, the period where the condition is true will also reduce..and this is what we clearly ear at the end.
green is our "Ladder output".



Note that you will also need to filter a bit (lp filter) the ladder output before adding to the clean signal.

Code snippet from FMDrive..
If you make any use of this, credit would be nice

Code: Select all

//Start of very fast ladder code 
while( --sampleFrames >= 0 )  // sampleFrames = how many samples to process (may change). repeat (loop) that many times
	{
		    sineout = *in; // max -1 +1

   //ladder condition, VCC or GROUND

 if (sineout<-0.009f)
{ladder=-0.02f;               // output is almost 50 times lower than the clean signal, can be adjusted or optionally controlled..

 }
 else
 ladder=0.0f; // grounded no signal


*ladder_out = ladder;  //then filter this before adding to sineout

 ladder_out++;

 in++;

}

Here you can see a very fast decay envelope that kind of shows the process

[trap15]

I know this was asked earlier, but the answer wasn't exactly clear.

I've been working on a YM2203 emulator (yes, not quite a YM2612, but most everything else here has been extremely helpful and accurate, so I have no reason to believe that this is different), and I've run into an interesting concern.

If I update the EG counter on every "output cycle", the EG is too fast. Here's what that update process looks like:

Cycle 0: Update output latch, increment EG counter, Update Op0 of Chan0
Cycles 1-3: Update Op[2,1,3] of Chan0
Cycles 4-7: Update Op[0,2,1,3] of Chan1
Cycles 8-11: Update Op[0,2,1,3] of Chan2

Now, if I modify my code to update the EG every 3 "output cycles", the EG seems to be updating at the proper rate. Here's what that looks like:

Cycle 0: Update output latch, increment EG counter, Update Op0 of Chan0
Cycles 1-3: Update Op[2,1,3] of Chan0
Cycles 4-7: Update Op[0,2,1,3] of Chan1
Cycles 8-11: Update Op[0,2,1,3] of Chan2
Cycle 12: Update output latch, Update Op0 of Chan0
Cycles 13-15: Update Op[2,1,3] of Chan0
Cycles 16-19: Update Op[0,2,1,3] of Chan1
Cycles 20-23: Update Op[0,2,1,3] of Chan2
Cycle 24: Update output latch, Update Op0 of Chan0
Cycles 25-27: Update Op[2,1,3] of Chan0
Cycles 28-31: Update Op[0,2,1,3] of Chan1
Cycles 32-35: Update Op[0,2,1,3] of Chan2


Considering that this works and sounds correct, I'm willing to bet it's the correct (or at least similar to the correct) functionality. However, I'm not quite sure how or why, and I doubt the accuracy of it as well. I'd really appreciate any insight or information for this.

A little side question as well, and not nearly as important, is what order the updates occur in. As in, is the output latch updated on cycle 0, or cycle 11? Is the EG counter updated on cycle 0, or cycle 11 (or 35 or whatever)?

[Aly James]

IIRC EG updates every 3 FM update cycles..

[Mamizou]

Just a heads up, someone at siliconpr0n.org decapsulated a YM3438 and did high-res scans of the metal layer. It's definitely a different layout than the YM2612, although the typical YM chip functional blocks are still recognizable.

Looks like the EG was shifted to being 'below' the ROMs instead of off to the opposite side of the PG (assuming 'top' is to the left on the scan, so it's comparable to the YM2612 scan). Probably so there's less trace distance between those functional blocks. The DAC is still in the 'upper-right' (upper-left of the scan).

[TmEE co.(TM)]

That is awesome ! It looks quite a bit different from 2612.

I have been adding SSG-EG to my YM core, that is going somewhat well. I'll likely have questions about it later on.

LFO info never really appeared here, so, will it appear here ?

[Nemesis]

I just don't have time to write up info on it right now, and I've probably forgotten half of it anyway, but I'm working towards the source release of my emulator Exodus, which has my heavily commented YM2612 core in it, so you'll be able to refer to that soon as a working reference model. I wrote that core in tandem with my testing and findings, verifying the output to the chip on many points, including the LFO. That said, I think there were one or two questions I had remaining about the LFO I never got back to testing. If so, those questions should appear as comments in my source marked with //##TODO## or //##FIX##.