VOGONS


First post, by nukeykt

User metadata
Rank Member
Rank
Member

Hi
Recently i was working on next version of Nuked OPL3 emulator based on YMF262 die shot analysis. I think i found an error in chip design. YMF262 is specially treating attack rate 15: it just sets envelope to max value. Logic gates responding for this likely has an error. The logic looks like this: (KeyOn event or rate is not 15) and rate is 15. It is equalent to KeyOn event and rate is 15. So it will work fine if you set AR=15 before key on event, but won't work when you start with lower AR and set AR=15 during attack phase. Most likely envelope generator will stuck. I think it should be like (KeyOn event or Attack phase) and rate is 15.
But this is only theory. I haven't tested it as i have no access to any OPL3 card right now. So can anyone check it on YMF262? Possibly it was fixed in OPL3 derivatives like YMF289 and YMF7xx.
There's how to test it: Start any voice with slow attack, wait when envelope generator starts attack phase then set attack rate to 15.

Reply 1 of 15, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

I'll put it on my todo list but I can't make any estimate when that will happen.

Meanwhile, can you provide some information about this die shot reverse engineering, I'd be happy to read and maybe comment on something, although my experience is only limited to figuring out OPL2 KSL lookup table which was easy...

Edit: at least OPL4 application manual says FM attack rate for rates 60..63 (15) is immediate.

Reply 2 of 15, by nukeykt

User metadata
Rank Member
Rank
Member
Jepael wrote:

I'll put it on my todo list but I can't make any estimate when that will happen.

Meanwhile, can you provide some information about this die shot reverse engineering, I'd be happy to read and maybe comment on something, although my experience is only limited to figuring out OPL2 KSL lookup table which was easy...

Edit: at least OPL4 application manual says FM attack rate for rates 60..63 (15) is immediate.

I use die shots from siliconpr0n.org. I directly mark notes on shot in Inkscape. Sometimes logic simulation is very helpful to fugure out things. Parallelly i write code that equvalent to logic in my emulator. For now i determined all blocks on shot, figured out exact rhythm mode algorithm(appearantly noise generator updates every internal cycle, which equals to Master clock/8. Noise polynomial is simpler than was in MAME: x^23+x^14+1), checked KSL calculation. YMF262 has 16 LSI test bits. Some of them enable test data output through TEST pin(I think it serially outputs first operator's envelope or phase generator value depending on LSI register values). I'll possibly release my noted shot with the next Nuked OPL version release.

Reply 3 of 15, by Lord Nightmare

User metadata
Rank Newbie
Rank
Newbie

CR1901 did something similar for the ym2151, although that trace is not complete yet. (trying to figure out how the LFO LFSR works in AM and PM mode..)
See https://github.com/cr1901/ym2151-decap

Any chance you can post your marked up svgs from inkscape somewhere?

LN

"When life gives you zombies... *CHA-CHIK* ...you make zombie-ade!"

Reply 4 of 15, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie
nukeykt wrote:

figured out exact rhythm mode algorithm(appearantly noise generator updates every internal cycle, which equals to Master clock/8. Noise polynomial is simpler than was in MAME: x^23+x^14+1), checked KSL calculation. YMF262 has 16 LSI test bits. Some of them enable test data output through TEST pin(I think it serially outputs first operator's envelope or phase generator value depending on LSI register values). I'll possibly release my noted shot with the next Nuked OPL version release.

Wow, that's some pretty deep stuff you've been working on.

So how come the MAME polynomial matches the output of real chip then? Is it just that the operator that was under examination used every N:th bit of the noise generator, so MAME polynomial matches every N:th bit of the original noisegen? I mean, so each operator uses different noise output when it is the operator's turn to be processed, instead of all operators using the same noisebit during one cycle of sample accumulation of all operators? Could be, as MCLK/8 == 36 * sampling rate, so it also takes 8 MCLKs per operator.

Only 16 LSI test bits? There are two registers on bank0 and two registers on bank1 according to the datasheet, but are these the same? I did notice that some of them have no audible effect, but some of them do, like one might stop perhaps envelope generators and another bit might stop phase generators (I haven't closely examined what they really do, just noticed they distort the audio and these are the best guesses based on how it sounds). I've always wanted to reverse engineer the test bits as they could reveal internal operations better if it is analyzed as a black box, but the test output could further help with this.

I recall I might have one sound card where I also wired the test pin to a pin header, so I could analyze it. But on that board I used a logic buffer for extra safety and it seems the buffer is too fast or inputs change too slowly so there are glitches on the logic analyzer.

Can you see what are the initial (reset) state of noisegen, envelope clockgen, vibrato clockgen or tremolo clockgen?

Also, I'm all ears how the envelope rate generator works!

Reply 5 of 15, by cr1901

User metadata
Rank Newbie
Rank
Newbie

Hi! Noticed Lord Nightmare mentioned me so I decided to make an account.

You're doing good and fascinating work that complements my own/LN's! 😀. Might as well give an update while I'm here:

I did a blog post as a tutorial about REing NMOS chips such as the YM2151 and friends back in October. A little bit afterward, I found out jotego, someone who worked on MAME board Gryzor back in the 90's, released his YM2151 Verilog core. He was willing to help me do some vectorizing, and has his own layers committed to the repo that I haven't merged into the main silicon layers yet. My local copy of the repo is a few commits behind the because the last work I did on it, I was attempting to use Olivier Galibert's (sarayan) dietools repository to automatically extract transistors. I wanted to ensure the work I'd done up to that point was correct as a smoke test before merging the tip. Because I'm not well acquainted with dietools and/or my vectorization is off, dietools claims to find a 5V-to-GND short in my local repo.

And that brings us to today. Right now, there are a few things blocking progress, in order of immediate priority:
* 8GB of RAM isn't enough to reliably run Inkscape and dietools on this die. I need to at least double it, but real life gets in the way.
* Vectorizing was doing harm to my wrist/arm. I need to buy a mouse with better ergonomics, preferably with a trackball.
* I need to ask sarayan what I did wrong to make dietools think there's a short.
* I need to fix the short, then merge jotego's work incrementally.

At this point, I'll be ready to vectorize without hesitation that I'm either going to break my computer, my body, or the work I've already done 😜. In addition to the above jotego and I have been busy, and we've found that Inkscape isn't exceptionally well suited for collaboration. There was talk of attempting a GUI tool for vectorizing that's better for collaboration in an IRC channel we frequent, but those talks kinda fizzled out when we both got busy.

Reply 6 of 15, by nukeykt

User metadata
Rank Member
Rank
Member
Jepael wrote:
Wow, that's some pretty deep stuff you've been working on. […]
Show full quote

Wow, that's some pretty deep stuff you've been working on.

So how come the MAME polynomial matches the output of real chip then? Is it just that the operator that was under examination used every N:th bit of the noise generator, so MAME polynomial matches every N:th bit of the original noisegen? I mean, so each operator uses different noise output when it is the operator's turn to be processed, instead of all operators using the same noisebit during one cycle of sample accumulation of all operators? Could be, as MCLK/8 == 36 * sampling rate, so it also takes 8 MCLKs per operator.

Only 16 LSI test bits? There are two registers on bank0 and two registers on bank1 according to the datasheet, but are these the same? I did notice that some of them have no audible effect, but some of them do, like one might stop perhaps envelope generators and another bit might stop phase generators (I haven't closely examined what they really do, just noticed they distort the audio and these are the best guesses based on how it sounds). I've always wanted to reverse engineer the test bits as they could reveal internal operations better if it is analyzed as a black box, but the test output could further help with this.

I recall I might have one sound card where I also wired the test pin to a pin header, so I could analyze it. But on that board I used a logic buffer for extra safety and it seems the buffer is too fast or inputs change too slowly so there are glitches on the logic analyzer.

Can you see what are the initial (reset) state of noisegen, envelope clockgen, vibrato clockgen or tremolo clockgen?

Also, I'm all ears how the envelope rate generator works!

Yeah. If you take every 36th bit from it will match MAME noise generator. Internally everything rely on internal clock and it takes only two internal cycles to process one operator. YMF262 uses pipeline, so 36 internal cycles enough to process one sample. There are 8 LSI bits on each 0x01 register. Also there are no any other undocumented register. Initial noise value is 0. AFAIR, next bit is calculated as (0th bit xor 14th bit) or noise value is 0 or LSI bit. But IC value can go down at any internal clock time, resulting in different syncronisation between noise generator and rhythm slots. Envelope generator timer value is also 0 after reset. There also LSI test bit, that sets timer value to zero(possibly except 0th bit). Internal timer is 37 bits wide. I have no info about LFO.

Reply 7 of 15, by nukeykt

User metadata
Rank Member
Rank
Member
cr1901 wrote:
Hi! Noticed Lord Nightmare mentioned me so I decided to make an account. […]
Show full quote

Hi! Noticed Lord Nightmare mentioned me so I decided to make an account.

You're doing good and fascinating work that complements my own/LN's! 😀. Might as well give an update while I'm here:

I did a blog post as a tutorial about REing NMOS chips such as the YM2151 and friends back in October. A little bit afterward, I found out jotego, someone who worked on MAME board Gryzor back in the 90's, released his YM2151 Verilog core. He was willing to help me do some vectorizing, and has his own layers committed to the repo that I haven't merged into the main silicon layers yet. My local copy of the repo is a few commits behind the because the last work I did on it, I was attempting to use Olivier Galibert's (sarayan) dietools repository to automatically extract transistors. I wanted to ensure the work I'd done up to that point was correct as a smoke test before merging the tip. Because I'm not well acquainted with dietools and/or my vectorization is off, dietools claims to find a 5V-to-GND short in my local repo.

And that brings us to today. Right now, there are a few things blocking progress, in order of immediate priority:
* 8GB of RAM isn't enough to reliably run Inkscape and dietools on this die. I need to at least double it, but real life gets in the way.
* Vectorizing was doing harm to my wrist/arm. I need to buy a mouse with better ergonomics, preferably with a trackball.
* I need to ask sarayan what I did wrong to make dietools think there's a short.
* I need to fix the short, then merge jotego's work incrementally.

At this point, I'll be ready to vectorize without hesitation that I'm either going to break my computer, my body, or the work I've already done 😜. In addition to the above jotego and I have been busy, and we've found that Inkscape isn't exceptionally well suited for collaboration. There was talk of attempting a GUI tool for vectorizing that's better for collaboration in an IRC channel we frequent, but those talks kinda fizzled out when we both got busy.

Thanks. I've read your tutorial when i started to deal with Yamaha chips shots. First chip that i tried to RE was YM2612. But this attempt was failed as i had some troubles with understanding chip's logic. In May 2017 i started YM3438 REing. It is much easier to read than YM2612 and i did good progress with it. Couple weeks ago i finally started work on YMF262. Unlike you i don't fully vectorize chips, i only make notes on shot. I vectorize logic gates only when i'm not sure how they work.

Last edited by nukeykt on 2017-07-13, 04:49. Edited 1 time in total.

Reply 8 of 15, by cr1901

User metadata
Rank Newbie
Rank
Newbie
nukeykt wrote:

Thanks. I've read your tutorial when i started to deal with Yamaha chips shots. First chip that i tried to RE was YM2612. But this attempt was failed as i had some troubles with understanding chip's logic. In May 2017 i started YM3438 REing. It is much easier to read than YM2612 and i did good progress with it. Couple weeks i finally started work on YMF262. Unlike you i don't fully vectorize chips, i only make notes on shot. I vectorize logic gates only when i'm not sure how they work.

From my own experience, I end up doing more and more vectorizing because I want more of the big picture, YMMV 😀.

Re: the YM2612, there are more than enough people working on it, both from REing from oscilloscope/LA traces and from looking at die photos. I don't think the YM2151 is given enough love, despite having a similar appealing sound when used properly. So I decided just to work on the 2151 instead and let the 2612 community do their thing. That said, I would like all the YM chips documented at some point, so I'm glad that you decided to study other chip families.

Reply 10 of 15, by nukeykt

User metadata
Rank Member
Rank
Member

Finished work on envelope generator. Seems it works flawlessly 😀
Here's few records i did with DOSBox. highways.mp3 also demonstrates new rhythm mode emulation

Attachments

  • Filename
    wolf1.mp3
    File size
    2.03 MiB
    Downloads
    108 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    raptor.mp3
    File size
    1.65 MiB
    Downloads
    93 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    keen4.mp3
    File size
    846.09 KiB
    Downloads
    118 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    highways.mp3
    File size
    2.16 MiB
    Downloads
    108 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    doom.mp3
    File size
    3.69 MiB
    Downloads
    117 downloads
    File license
    Fair use/fair dealing exception

Reply 11 of 15, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Hi nukeykt.
Is this a significant bug fix that can be heard on most games like your samples above?
The technical stuff is way over my knowledge, is there a significant difference?


my important / useful posts are here

Reply 12 of 15, by nukeykt

User metadata
Rank Member
Rank
Member
James-F wrote:

Hi nukeykt.
Is this a significant bug fix that can be heard on most games like your samples above?
The technical stuff is way over my knowledge, is there a significant difference?

I think this bug never appears in any game. To trig it should change attack rate to 15 after keyon. I don't know any game that changes envelope parameters during note playback.

Reply 13 of 15, by nukeykt

User metadata
Rank Member
Rank
Member

Figured out some of the LSI test(0x01) register functions. Note that i haven't tested them on hardware.
This list can be incomplete or incorrect.
bank 0
0 - Disable EG output
1 - Disable LFO timer(possibly also timer) / Set Noise generator's next bit value to 1
2 - Reset phase generator counter
3 - Output current operator's phase generator value through TEST pin
4 - Tremolo updates every internal cycle / Set ADSR generator value to 0 / Vibrato updates every sample
5 - Output current operator's envelope generator value through TEST pin
6 - Custom envelope generator timer control
7 - Output current operator's register values value through TEST pin
bank 1
0 - TEST pin mode
1 - TEST pin mode
2 - TEST pin mode
3 - Reset envelope generator timer / Some IO/Timer control
4 - Some register array IO control
5 - Set ADSR generator value to 511
6, 7 - Some IO/Timer/Timing control

TEST pin mode:
2 1 0
0 0 0 - Disabled
0 0 1 - First set of operator's register values output
0 1 0 - Second set of operator's register values output
0 1 1 - Phase value output
1 0 0 - Envelope value output
1 X X - Undefined

Last edited by nukeykt on 2017-07-15, 08:34. Edited 1 time in total.

Reply 14 of 15, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

That is very exciting info, I am so amazed/stunned by this.
I'll definitely try these after I've tested the attack rate thing.

I've been thinking if this is the correct way to test it:
-initialize all registers so chip produces dead flat zero value silence
-configure one channel so that only one operator produces sound (other dead silent)
-set AR= something slow, like 4 or 8 or whatever
-set KON=1
-slight delay for the attack part to reach moderate amplitude (like about half)
-set AR=15
-delay for say 1 second to see what happens to the envelope
-set KON=0
-watch amplitude to fall back to 0

Reply 15 of 15, by nukeykt

User metadata
Rank Member
Rank
Member
Jepael wrote:
That is very exciting info, I am so amazed/stunned by this. I'll definitely try these after I've tested the attack rate thing. […]
Show full quote

That is very exciting info, I am so amazed/stunned by this.
I'll definitely try these after I've tested the attack rate thing.

I've been thinking if this is the correct way to test it:
-initialize all registers so chip produces dead flat zero value silence
-configure one channel so that only one operator produces sound (other dead silent)
-set AR= something slow, like 4 or 8 or whatever
-set KON=1
-slight delay for the attack part to reach moderate amplitude (like about half)
-set AR=15
-delay for say 1 second to see what happens to the envelope
-set KON=0
-watch amplitude to fall back to 0

Yes. Something like this.