Check out the OPNA chip

[Wohlstand]

https://www.vogons.org/viewtopic.php?p=704730#p704730

SLON: What about the possibility of using the YM2608 core? It was distinguished by the presence of additional SSG and ADPCM (and RHY-channels), and also, as far as I know, a higher-quality DAC. True, I do not know how useful this will be for MIDI.

Wohlstand: It's dependent on the availability of necessary emulator and the chip specification I can use to provide an interface. For now, libOPNMIDI doesn't use DAC, but its support is WIP. On side of libOPNMIDI are three emulators: Nuked OPN2 is implemented YM3438 chip, but it's very powerful and won't work on slow hardware in real-time if you running more than 3 chips; MAME OPN2 is implemented YM2612, doesn't using much power, but is a most balanced emulator that gives well-accurate and doesn't eat too much CPU; And the GENS 2.10, the old and inaccurate emulator, but, the fastest emulator I have at me.

If the OPNA chip has compatible ABI, we can try to use it as an alternative chip together with existing OPN2 chips. For the case of DAC-equipped chips, they are all will have the sample-streamer on the side of ChipSet base backend, and necessary to do that from outside. The only exception would be for OPNA that does support of ADPCM.

• Provide at least one OPNA emulator at libOPNMIDI
• Provide at least one OPNA emulator at OPN2BankEditor
• Provide a support for file formats are related to OPNA bank / instrument formats
• Add PMDWinS036 OPNA emulator to verify FM block behaviour (https://github.com/pbarfuss/PMDWinS036)
• Add MAME OPNA emulator code
• Add support for OPNA-specific bank / instrument file formats are also can be used here
• Make WOPNv3 know about OPNA Rhythm instruments (NP2 supports custom samples passed, I wanna check this at evening)
• Research SSG-EG capabilities
• Research and implement PSG support
• Research and implement OPNA Rhythm
• Implement PCM voices support through YM2612's DAC libOPNMIDI#5

[freq-mod]

Regarding YM2608, one thing to remember: there were two versions/revisions of it.

• initial phase of YM2608 that had one 4-bit monoaural hardware ADPCM channel capped at 16 KhZ
• YM2608B (OPNA rev.B) that didn't have it, PCM was meant to be provided by external chip, in similar fashion to Sound Blaster 16

There were rhythm channels derived from YM3301 drum machine. 6 samples, somewhat terrible quality, stored in built-in ROM. YM2608 relied on external DAC, so there were no distortions. Also, sampling freq. was higher at 55466 Hz (hi-hats sound much more convincing on 2608 IMO 😉 )
As for emulators, there is PMDWin core, MAME YM2608, Neko-project FMGEN core... all of them should be accurate enough.

[jpcima]

There is now a WIP for OPNA on my work branch. This adds "Neko Project II Kai OPNA".
https://github.com/jpcima/libOPNMIDI/tree/neko-opna

It plays with some glitches. This is what I know so far.

• I adapted the chip to the native clock and rate, which are different than OPN2. I took the native rate as @Papiezak mentioned and the clock 7.9872 MHz which is the same as Neko emulator and maintains a factor 144. The pitches sound off, I guess it's computations of block and f-num which also need adapting.

• The emulator output is a mix of generators: FM, PSG, ADPCM and RHYTHM.
  OPNB can be enabled in place of OPNA, this one segfaults on use; it needs to be checked why.
  (template parameter selects one of 2 chip types)

• Some channels seem to skip or play wrong things, probably by the design differences of both chips. You can hear some of channels which will sometimes generate as PSG square output.
  For some reason, it is heard more frequently at 1 chip than the higher chip counts.

Other than this, I cleaned up warnings, I've marked code by // libOPNMIDI comments where are made more significant changes. At first look this seemed like a light emulator on the CPU, and also nice when it comes to license (MIT).

[Wohlstand]

I have tried to play random music on a quick hand, and I can say next:

• Sounding is good, that good, no shit-voicing sound, OPN2's voices are sounding on accessible channels fine! 🦊 👍
• Tone isn't tuned fine (a bit higher than on OPN2), looks like need to polish the coefficient to align the note tone with OPNA 🤔 Possibly, move the tone coeffient into the chipset (which is used in the frequency compution from various pitch values).
• I need the programmer spec for OPNA chip to compare with OPN2 as I guessed, their ABI is different, therefore many channels are missmatching and not working (the synthesizer is designed for 6-channels of the chip). Possibly, I'll need to align the chip communication logic to allow it use OPNA chip correctly...

[Wohlstand]

P.S. Please also convert all Shift_JIS files into UTF8 to avoid future crap and let read Japaneese comments in a quite 🦊
(UTF8 with no conversion)

(Shift_JIS with no conversion, need to save as UTF8 later)

[Wohlstand]

As a minor workaround, I have forced MIDI synthesizer to skip 3 last channels while range scan for goodness check, so, 3 first channels are in use:

And music playing fine with no missing channels!
So, I ague, it's the OPN2 and OPNA difference of post-3 channels alignment or way to call of them.

EDIT: This is safer, otherwise, the check is skipped, and previous will lead a crash...

[Wohlstand]

I have found something related, will research the stuff after sleep:
https://wiki.neogeodev.org/index.php?title=YM2610

YM2608J Translated.PDF

[jpcima]

I converted the shift-jis encoding. Also I agree that some chip-related information be abstracted through chip-base's interface, taking precaution of avoiding virtual calls at the audio rate.

I'm interested to see your handling of channels which improves playback situation, and also I forgot how is computed the frequency coefficient formula. I will look again after some rest.

[jpcima]

I scaled the pitch coefficient, and this fixed the frequency.
Next is to manage the channels correctly.

[jpcima]

Found ! It needs to set bit SCH "six channels" of register 0x29.
Then it has all the FM channels working.

[Wohlstand]

Oh, neat! 🦊 👍

[Wohlstand]

So, there is only some questions about ABI difference: which features are different between OPN2 and OPNA related to FM synth

[Wohlstand]

One thing I forgot, OPNA has some sort of PSG in place as I know...

[Wohlstand]

And, which sense of SSG-channels?

[freq-mod]

One thing I forgot, OPNA has some sort of PSG in place as I know...

It does. It's built-in YM2419 core, the same that was in ZX spectrum, Amstrad CPC, Atari ST...
It has 3 channels - each of them can produce either 50% square wave, noise or combined square wave & noise (at the same time, occupying one channel!)
It also has ADSR envelope generator, like FM synth or SID chip - common for every channel

[Wohlstand]

It also has ADSR envelope generator, like FM synth or SID chip

Looks like an easy solution of this: Wohlstand/libOPNMIDI#6

[freq-mod]

SN76489 doesn't have ADSR, just a simple 4-bit volume control. YM2419 SSG chip sounds slightly different as it's noise generator is much more sophisticated than SN crap.

2419 also has 4-bit volume control but it's just an addition to envelope generator.

[Wohlstand]

Neat!
Also, it's would be cool then add it into OPN-BE to benchmark it, I'm curious how much it loads the CPU, and, how accurate it emulates the sound in comparison to others include MAME.

[Wohlstand]

Anyway, I have checked out the CPU load by opnmidiplay, and loos NP2's OPNA is a bit faster than MAME 🦊

[jpcima]

Yeah but it's a bit like Gens also. It's not faster in full use, but it's good at saving CPU usage from the inactive parts. MAME is a stabler CPU usage.

[Wohlstand]

I also hearing that percussions are sounding differently than on OPN2 chips, due different clock and oscilators. But also means, need to tune a bit the frequency coefficient...

[freq-mod]

Yeah, that is because sampling frequency is different, 55466 rather than 53267 hertz. That's the reason percussion used to sound different on Gens core compared to Nuked.

[freq-mod]

Hmmm... i checked out OPNA emulation, SSG-EG based instruments sound completely off
Did YM2608 not have SSG-EG and this is normal?

[jpcima]

Yeah it has the SSG and I reproduce the problem. Gotta debug into this.

[freq-mod]

I'm not certain but there can be a problem with detune values... I tried porting hi-hat from some PC-9801 game and it sounded off until i (blindly) played around with detune parameters... weird.

[rerrahkr]

In BambooTracker, 8 "hard" steps means using hardware envelope which is controlled by EG frequency, C, ATT, ALT and HLD. The other 16 steps use software envelope controlled by writing volume to its level register for each tick.

The volume resolution of hardware envelope is 32, finer than software envelope that it is 16. But hardware envelope cannot change envelope shape more flexible and volume scale (volume level operation is not reflected during hardware envelope execution).
Therefore some OPNA sound drivers like PMD control SSG envelope by software envelope and don't use hardware envelope.

[Wohlstand]

So, looks like I need to make that SW envelope for here also, like for SN which is totally lacks any envelope support. Also, @rerrahkr , can you better explain how to convert MIDI tone into SSG's tone frequency? Code I have made in my sketch branch is crap and makes completely wrong tone for now. I have the valid stuff for FM.

[freq-mod]

Thanks for the info @rerrahkr!

Looking at sketch I think there should be also an option for noise or combined noise/square wave output; that's going to be crucial for many instruments. Also, Bamboo Tracker supports arbitrary waveforms for SSG produced by hardware envelope manipulation (sawtooth, triangle), it would also be neat if possible

[rerrahkr]

SSG tone is defined as: hertz = master_clock / (64 * TP)
TP is 12-bit register value, high 4 bits are "coarse tune" set to register $01, $03, $04, and low 8 bits are "fine tune" set to $00, $02, $04.
So I think:

uint32_t tp = static_cast<uint32_t>(clock / 64.0 / hertz);
WriteReg(0, 0x00 + cc * 2, static_cast<uint8_t>(0x0ff & tp));
WriteReg(0, 0x01 + cc * 2, static_cast<uint8_t>(tp >> 8));

[jpcima]

Implemented the tuning. Thanks for the information.
Have we any existing files which describe SSG-based instruments?

[Wohlstand]

SSG tone is defined as: hertz = master_clock / (64 * TP)

Implemented the tuning. Thanks for the information.

@rerrahkr , @jpcima , thanks you both for correction of the tone formula! Just now tested the thing, and it works! 🦊 😃

I have made few tweaks on that branch, and will continue the work that needs a deep refactoring, otherwise, current code is a mess... I have some idea to make, will try this possibly tomorrow or later...

[jpcima]

These are some findings about the PMD envelope generator.

1. https://pigu-a.github.io/pmddocs/pmdmml.htm#8-1
2. http://battleofthebits.org/lyceum/HistoryView/1175/#SSG%20Commands

It describes a variation of level over time for 2 envelope kinds, where length of steps are allowed to be controlled by a clock setting defined by user.

A fitting description may be as such:

• envelope type 0: pmd-like / 1: fm-like
• clock: frequency (54.17 Hz typical, second source says 54.25 Hz)
• if type=0: AL,DD,SR,RR (refer to 1. for permissible value range)
  if type=1: AR,DR,SR,RR,SL,AL

Other:

• Tone/Noise mode https://pigu-a.github.io/pmddocs/pmdmml.htm#6-5
• Noise frequency https://pigu-a.github.io/pmddocs/pmdmml.htm#6-6

[freq-mod]

I noticed that chipset wasn't updated with a Neko Project 2 SSG-EG fix (Wohlstand/libOPNMIDI#81), would it be possible to backport these changes into editor?
I want to investigate as some of my SSG-EG based instuments sound bad on YM2608 emus including MAME...

[Wohlstand]

@Papiezak , oh, forgot, gonna to sync that change now!

[jpcima]

Please note, I took Nuked OPN2 as basis for comparison as I made this;
and I'm not sure at all what this comparison is worth, these being different chips.

This was a full rewrite of this broken part of Neko OPN, based on black-box comparison of emulator's respective curves, measured in a few different cases.

[Wohlstand]

@Papiezak , Took those changes just now

[freq-mod]

I've taken a listen.
Now, at some cases (depending on AR value being 31 or not I guess) NP2's SSG-EG sounds either similarly to MAME's ssgeg (but not identical) or exactly like Nuked YM2612 🤔

Please note, I took Nuked OPN2 as basis for comparison as I made this;
and I'm not sure at all what this comparison is worth, these being different chips.

So could it be that these changes are wrong in context of YM2608 and resulted in "hybrid OPNA-OPN2 chip"?
Maybe closer analysis of PMDWinS036 emu would tell more as it seems to be the most accurate of all 2608 emulators...

[nukeykt]

I'm pretty much sure that SSG-EG behaves same at least within YM2608, YM2610 and YM2612(and possibly YM3438)

[Wohlstand]

Anyway, when I compared SSG-EG on all emulators, in my xg.wopn, the telephone is acting slower on OPNA chips than on OPN2

[freq-mod]

It's not only just slower, take the "Car Engine SFX" instument from my GS bank.
On Nuked (and now, Neko Project) it sounds much more aggressive and louder than on MAME YM2608 where it's like muffled:
https://instaud.io/3mAr - nuked
https://instaud.io/3mAs - mame OPNA
I haven't tested PMDWin yet, but it doesn't have SSG-EG implemented anyway 🤷‍♂️

@nukeykt is most likely right, but if to examine SSG-EG capabilities completely, best way would be to compare emulation to real chip.
@rerrahkr's_Bamboo Tracker supports hardware passthrough to real YM2608 (and soundcards that use it) via SCCI. When possible, if someone would provide recordings of SSG-EG instruments behaviour on real 2608, would be extremely grateful ❤️

[freq-mod]

There is a glitch on PMDWin emulator.

1. Open the bank editor without any bank loaded.
2. Set an emulator to PMDWin.
3. Play a note.

Even when instrument is blank/null (AR=0) loud noise will be heard that will last forever. Hitting "Shut up" button helps only a bit, you can still hear the crap, it's only much more quiet.

[Wohlstand]

Even when instrument is blank/null (AR=0) loud noise will be heard that will last forever. Hitting "Shut up" button helps only a bit, you can still hear the crap, it's only much more quiet.

I had same while experimented with Rhythm, when I forgot to click the "Rhythm" and tried to play blank note...

Also, about Rhythm, PMDWin is totally not responds on volume levels and panning bits, and plays all instruments quite about silent, but hearable. Good that NP2 has good Rhythm implementation, so, I have completed my test 🦊

[jpcima]

It's the same envelope problem as always, which makes it stuck forever at the current level.
Possibly related to rate table computations, or the conditions of phase transitions.

[freq-mod]

It also likes to cut short decay and release phases too...
https://instaud.io/3nXA - open hi-hat played on Neko Project 2 emu
https://instaud.io/3nXC - the same hi-hat played on pmdwin

[freq-mod]

Hello. New version of PMDWin is released, with greatly improved SSG-EG emulation and few other fixes: pbarfuss/PMDWinS036#1

[Wohlstand]

@freq-mod , uh ty, klawo! Muszę natychmiast sprawdzić, co tam jest... 👀
[Oh, wow, I should check out, what is now at that...]
P.S. because of some my friend in Telegram, I trying to learn jazyk polski, it's not hard for me 🦊

[Wohlstand]

@jpcima , can you remind me, did you some own fixes on current PMDWin thing? In my memory, you did some fixes here to make it work independently if I'm not mistaken.

[jpcima]

Hi, I did usual things that we apply, like custom panning, but also you can check libOPNMIDI marked comments for full detail.
I don't remember the whole story of it since it was long ago.
There remained an envelope-related problem I haven't managed fixing.

There is this one which is notable.

/* libOPNMIDI: prevent FM channel clipping (TODO: also adjust PSG and rhythm) */