OPL3 is designed to emulate 2 OPL2 chips. There are minor differences, but I'd be surprised if these differences were noticeable in any actual game. OPL3 has much lower access delays, clocked @4x speed, and has MSB flipped in its DAC output format, so OPL2 DAC (3014) is not compatible with it, but later DACs(3015, 3016, YAC512) are backwards compatible with OPL3 and OPL2 due to having switchable input format.
Also, it is possible to design a special DIP socket that accepts both OPL2 and OPL3(via SO-DIP adapter), which is what I did in my crude prototype.

640K!enough wrote:

The Ad Lib Gold, arguably the card that set the standard for OPL3, did exactly that: the OPL3 was at 388H through 38BH by default, with nothing at or near 220H.
...
but I remember specifying 388H for OPL3, even after moving to a Sound Blaster 16.

I think I will stick to AdLib/SB16 compatibility. So OPL2 will be at 388h (and choices of 0x218/0x288/0x318 will be also available, as was on AdLib). SB16 I think had OPL3 routed from 388h for AdLib compatibility, but another way to address it was through 220h. So for "SB-compatible OPL3" I think I should stick with 220h.
Also, can you help with number of ports required by OPL3? As I know, for OPL2 it is two ports: base+1 (0x388, 0x389). How many ports if required for OPL3? Four? 😕

carlostex wrote:

I really don't see the need of including OPL2/OPL3 capability. Adlib/Sound Blaster/Sound Blaster Pro and clones are very common, so it would be easy to pair this multi sound card with another OPL2/OPL3 card. That would simplify the design and open space for something else.

I want to include OPL3 or both just to cover "all of them". OPL3 in SMD variant is pretty compact, it doesn't need much space. You can always disable parts of the card, that you don't need. And there are also some "OPL-wars" about frequency responses, filtering, background noise and so on. I want to have good OPL3 implementation on my card (I will spend some time experimenting). I've already implemented two pretty different variants of output filters for OPL3 on my debug-board, I will be comparing those.

carlostex wrote:

Unfortunately Covox Sound Master is not finished yet, which i would actually prefer to be included as yet it provides another rare sound option to be added.

Yep. I miss that synth too. As I understand that synth is more or less the same "AY", that was added to ZX Spectrum. For the moment I have all equipment for carefull disassembling any board like that, examing and putting it back intact. I still need some traces under those ICs for my re-routed version. But I doubt that any owner of those cards will accept such an action. 😢 To add an "AY" chip to my board - that would be just perfect!

carlostex wrote:

I would also wouldn't mind to have Covox Speech Thing and Disney Sound Source capability as this would tackle another part of DOS gaming sound. I know that the focus is on synths, but this would very cool.

I don't sure about that yet. Main focus is on synth, rudimentary DACs are not synths. Maybe, if there will be any space left, I'll integrate some variant of those.

carlostex wrote:

About CMS: i've noticed that you aren't supporting all of the CMS ports on the original CMS card. Reason is that i already have ALL games that support CMS patched to port 210h.

I've simply took Tronix's schematic and put it to the PCB. You've made a good point about 210h port... I think, current address decoder should be remade to add support for 210h. If only I knew how to construct those decoders easily with 74HC138s... 😊

carlostex wrote:

So anyway, i very much appreciate Fagear's work and this is truly awesome. If you manage to pull this project out that'll be amazing!

Thanks! I'm trying my best at the moment to move it forward. Even I lack some knowledge in schematics and 74 logic.

Here are some hints and progress of the project:

Fagear wrote:

base+1 (0x388, 0x389). How many ports if required for OPL3? Four? 😕

Recently discussed here.
RemapCMI - Tool for emulating DOS audio ports on C-Media CMI8x38 soundcards

For some additional detail in the discussion of address maps of various cards, I found this nice document with details for Creative cards. Interestingly, while it does seem to support Scali's assertion that Creative only exposes FM functionality at 388H/389H, it also states that the range at 38AH and beyond is "reserved for future expansion".

I haven't owned a Creative card in a long time, but I was sure some games with more generic OPL3 support detected it at 388H, and still had it work, though my memory isn't perfect.

Very cool idea! I'd love to have all of that hardware on a single board, especially the CMS and SSI-2001. But, just as a heads up, out of everything you listed only the OPL2 & OPL3 are actual FM synths. The rest of them are just categorized as sound generators.

Ok, here's my 2 cents about the terminology.
Yamaha OPL chips are FM, because they are digital chips supporting generation of sounds with complex spectrum by using several "algorithms" for modulating frequency/phase of one generated sound wave with another. Being completely digital, they don't have any "filters" inside, but usually external low-pass antialiasing/reconstruction filter is applied after its DAC, because these Yamaha DACs don't do oversampling/antialiasing themselves.
SID is a subtractive synthesizer chip. It is a hybrid digital/analog chip, capable of shaping spectrum of its sound by (rather crude) analog filter, in addition to having other features mostly found in "real" subtractive synths, such as PWM and (pseudo) ring-modulation.
The rest are PSG (Programmable Sound Generator).

640K!enough wrote:

I haven't owned a Creative card in a long time, but I was sure some games with more generic OPL3 support detected it at 388H, and still had it work, though my memory isn't perfect.

People say OPL3 works on 388-38B range on most Creative cards and (probably)all clones even if technically Creative does not guarantee OPL3 at 388h, just OPL2 compatibility.
Some games try to detect specifically Adlib Gold at 388-38F range, or SB at 220h/240h/etc., but most OPL3 FM drivers will happily work with any of these base ports, without checking if you have Adlib Gold, SB, PAS etc.
BTW, Adlib never actually had a jumper to allow other ports than 388h, despite promising it in the documentation. Therefore, old Adlib-compatible software often does not support other ports without patches.
Adlib Gold theoretically supported remapping, in practice, nearly everybody still expects OPL series chips at 388h.

YMF711/715/718/719 chips put OPL3 on 388...38B range, and if YMF704/721 is present it fills entire 388..38F range (extra ports are for the sampler and CPU part).

noop wrote:

Adlib Gold theoretically supported remapping, in practice, nearly everybody still expects OPL series chips at 388h.

Now that you mention it, I should try moving the Gold to another address to see if software can still find it. I suspect software that still works will be rare; likely only the few titles with decent Gold Sound Standard support. I expect those with generic OPL3 support will ignore it altogether.

Tiido wrote:

YMF711/715/718/719 chips put OPL3 on 388...38B range, and if YMF704/721 is present it fills entire 388..38F range (extra ports are for the sampler and CPU part).

Does your design support different addresses, so that it could, in theory, co-exist with an Ad Lib Gold or other OPL4 card?

My card allows YMF704/721 OPL3 to be placed at 380, 388, 390 and 398 and OPL3 of YMF71x can be placed anywhere from 210 to FF8 (in steps of 8 . There's also write only feature provided by YMFDEC for YMF704/721 to allow it to complement an existing chip/clone to get authentic FM output if that's desired.

noop wrote:

Recently discussed here.
RemapCMI - Tool for emulating DOS audio ports on C-Media CMI8x38 soundcards

As I can understand - it is always 4 ports for "native" OPL3. Or 2 ports in "OPL2 mode".

640K!enough wrote:

I found this nice document with details for Creative cards. Interestingly, while it does seem to support Scali's assertion that Creative only exposes FM functionality at 388H/389H, it also states that the range at 38AH and beyond is "reserved for future expansion".

Yep, I've had that document and indeed, there is OPL at 388 in all of them (for AdLib compatibility I presume). Nevertheless in cards with OPL3 there are olny two ports available (if we'll stick to specs).

noop wrote:

Adlib never actually had a jumper to allow other ports than 388h, despite promising it in the documentation. Therefore, old Adlib-compatible software often does not support other ports without patches.
Adlib Gold theoretically supported remapping, in practice, nearly everybody still expects OPL series chips at 388h.

Yes, AdLib had a footprint on the board to support addresses 0x218, 0x288, 0x318 and 0x388, but there was hardwired link to 0x388 instead of jumpers.
I'm thinking about removing all that 0x218/0x288/0x318 nonsense and add 0x228 instead, which is used on all SB cards.

Tiido wrote:

YMF711/715/718/719 chips put OPL3 on 388...38B range, and if YMF704/721 is present it fills entire 388..38F range (extra ports are for the sampler and CPU part).

Thank you for the information!

So...
OPL2 was assumed at ports 0x388...0x389 on AdLib, at 0x228...0x229 and at 0x388...0x389 on early SB cards.
OPL3 was assumed at ports 0x388...0x38B on AdLib Gold, PAS, (probably some) SB cards, Yamaha boards, at 0x220...0x223 (0x2*0...0x2*3) on Sound Blaster Pro and SB16+.

I think I'll choose set of ports 0x228, 0x388 for OPL2. Probably I'll add SB variants of base port: 0x248, 0x268 if it will be not very difficult. Two ports will be available.
For OPL3 I'll choose 0x220 and 0x388. Probably I'll add 0x240, 0x260 as I've mentioned above. Four ports will be available.
If anybody has any useful information about OPL2/OPL3 - please post it! I'm still in process of researching.

In the meantime I've made "address decoder simulator/visualizator" in M$ Excel. And with it's help I've redid address decoder for CMS block to support 0x210 and other addresses from original card.

Fagear wrote:

If anybody has any useful information about OPL2/OPL3 - please post it! I'm still in process of researching.

I did a significant amount of research (but too little actual work 🙁 ) but not sure about what else you may want to know. I can say that if you don't "unlock" OPL3 functionality by setting some specific bits, it essentially remains OPL2 and works through 2 ports only.
Or that "old" SBPro 1 used 2 OPL2 chips, taking 4 consecutive ports instead of one OPL3. After being "unlocked", OPL3 behaves almost but not entirely like 2x OPL2 (with some features added and one mostly unused feature lacking). If not "unlocked", it behaves basically like one OPL2.
On SBPro 1, AFAIK, only 2 ports at 388-389 range are used, but 4 ports at 220-223 range. A value written to 388 gets duplicated into 220 and 222, so both OPL2 chips receive the same data and operate synchronously and only way to used them separately and obtain stereo audio is to use 220-223 (sb_base .. sb_base+3) range.
You may already know that OPL3 can actually output 4 channels of audio, not just 2. This is used in at least one modern ISA audiocard.

Both chips require delays between accesses or they go mad. OPL3 requires much smaller delays.
Some OPL2 games with incorrectly programmed delays produce garbled music on faster machines. On OPL3 cards there are no problems with these games.
Usually "proper" delay is done by just reading data from OPL2/OPL3 ports many times, because ISA reads typically take around 1 microsecond.

noop wrote:

Usually "proper" delay is done by just reading data from OPL2/OPL3 ports many times, because ISA reads typically take around 1 microsecond.

Yes, this is where the danger is.
One factor is that slower CPUs require a lot more time than just the actual read for an 'in' instruction (read from IO port). On fast CPUs, the time is pretty much entirely dictated by the IO cycle time of the bus.
So on an 8088, performing 6 reads will take longer than on a 286, even if the bus speed is the same.

The other factor is that ISA bus speed is not the same on all systems. Especially 'performance oriented' motherboards would often 'cheat' by running the ISA buses at slightly higher speeds, to improve video card and harddisk performance, among others.
So even with the same CPU, on some boards, performing 6 reads will take longer than on others.

So, especially older games would use a certain number of reads that is 'good enough' on the systems they tested with, but would stop to work correctly on newer/faster systems.

The obvious downside is that slower systems get longer delays if you just hardcode N read instructions. Slower systems already had more trouble playing the music.

noop wrote:

On SBPro 1, AFAIK, only 2 ports at 388-389 range are used, but 4 ports at 220-223 range. A value written to 338 gets duplicated into 220 and 222, so both OPL2 chips receive the same data and operate synchronously and only way to used them separately and obtain stereo audio is to use 220-223 (sb_base .. sb_base+3) range.

Thank you again!

noop wrote:

You may already know that OPL3 can actually output 4 channels of audio, not just 2. This is used in at least one modern ISA audiocard.

Yes, I know about Resound OPL3. Interesting, but I don't think it's useful in gaming or existing OPL music. My board is all in stereo and doubling number of channels without any profit is a waste in my opinion. So, I'll stay with stereo OPL3.

noop wrote:

Both chips require delays between accesses or they go mad. OPL3 requires much smaller delays.
Some OPL2 games with incorrectly programmed delays produce garbled music on faster machines. On OPL3 cards there are no problems with these games.
Usually "proper" delay is done by just reading data from OPL2/OPL3 ports many times, because ISA reads typically take around 1 microsecond.

Maybe it can be solved with some delay circuit as it's done on SSI-2001, where number of 74HC74 use ISA IO_RDY line to manage transfers to SID. But is it worth the effort to implement something like this?

And I'm a little confused about interrupts for OPL. AdLib card can use IRQ2/IRQ3/IRQ5. But what about OPL3? I didn't find any information about OPL IRQ usage in SB manuals. Is it used on any other card with OPL3 Synth?

Fagear wrote:

Maybe it can be solved with some delay circuit as it's done on SSI-2001, where number of 74HC74 use ISA IO_RDY line to manage transfers to SID. But is it worth the effort to implement something like this?

I think that it was a deliberate choice of Yamaha to decouple the writing of registers from the processing of the data.
That is, if the chip would hold the bus for the entire duration, it would slow the machine down a lot.
With the current implementation, register writes are 'fire and forget', and the CPU can do other work in-between.
Problem is more that most developers were too lazy to do that, so they just waste CPU time by delaying.

Since all software expects to handle their own delays, mostly using dummy reads, it doesn't seem to make much sense to modify this behaviour. It would only make the delay loops needlessly slow.

Fagear wrote:

And I'm a little confused about interrupts for OPL. AdLib card can use IRQ2/IRQ3/IRQ5. But what about OPL3? I didn't find any information about OPL IRQ usage in SB manuals. Is it used on any other card with OPL3 Synth?

The AdLib never had the IRQ line connected to the OPL2 (the interrupt flag of the OPL2 can be polled by reading 0x388, the top 3 bits indicate the timer irq status). I don't think any OPL3 card has it connected either. At least the common Sound Blasters and clones do not.

Scali wrote:

The AdLib never had the IRQ line connected to the OPL2 (the interrupt flag of the OPL2 can be polled by reading 0x388, the top 3 bits indicate the timer irq status). I don't think any OPL3 card has it connected either. At least the common Sound Blasters and clones do not.

Is there any software that relies on IRQ from OPL? I'm not familiar with software from that period. Or was it from AdLib and on never used? AdLib had the header footprint to select ISA IRQ, but it seems that it was never populated and used. And on OPL3 cards IRQ line was not connected at all... So, maybe I just should drop IRQ select jumpers for both OPLs?..

No software uses the IRQs because no hardware ever provided them even though they could have. Stuff like Sound Blasters and other sound cards don't provide OPL IRQ either (but YMF71x based chips could, but no software programs the OPL IRQ to go anywhere because no software is aware and thus it would be waste of IRQ).

Maybe some one can put a Covox Soundcard on a X-ray Scanner 😁

So all traces should be visible without destroying it ?

Scali wrote:

I think that it was a deliberate choice of Yamaha to decouple the writing of registers from the processing of the data. That is, […]
Show full quote

Fagear wrote:

Maybe it can be solved with some delay circuit as it's done on SSI-2001, where number of 74HC74 use ISA IO_RDY line to manage transfers to SID. But is it worth the effort to implement something like this?

I think that it was a deliberate choice of Yamaha to decouple the writing of registers from the processing of the data.
That is, if the chip would hold the bus for the entire duration, it would slow the machine down a lot.
With the current implementation, register writes are 'fire and forget', and the CPU can do other work in-between.
Since all software expects to handle their own delays, mostly using dummy reads, it doesn't seem to make much sense to modify this behaviour. It would only make the delay loops needlessly slow.

My opinion is that these chips weren't intended to work with advanced buses or maybe Yamaha just saved on silicon/pin count. These chips were initially designed for various cost-sensitive 8-bit systems & propietary synths (most Yamaha FM chips use very similar bus interface and DAC data format(which is designed to be forward&back compatible, up to 16 mantissa bits and only changed slightly once) ) and I don't think you can do much useful work on these CPUs, overlapped with OPL register writes.
Proper solution would be to introduce hw that delays the next access until timeout has expired. I'm not sure this would stop the CPU that just performed a single write operation.
But there are different delays for index reg writes and data reg writes which complicates things.

YMF704/721 actually implements hardware based delays for its MPU401 and OPL3 access, there's no additional delays needed even on most fastest possible hardware. But it won't help with wasted power with all the existing software that does traditional delays.