That is a beautiful workbench 😎

Hello there!
I wonder if anyone with a real OPL3 & DOS & cpu>=486 can tell if Adlib Tracker II needs an opl_latency=1 option to play correctly? I bumped into a problem that OPL3-enabled games I tested (WAR2, Descent, Blood,... ) are all ok, but AT2 plays rubbish if opl_latency is set to 0 (default) and ok if set to 1.
Thanks!

LABS wrote on 2023-07-20, 09:18:

Hello there!
I wonder if anyone with a real OPL3 & DOS & cpu>=486 can tell if Adlib Tracker II needs an opl_latency=1 option to play correctly? I bumped into a problem that OPL3-enabled games I tested (WAR2, Descent, Blood,... ) are all ok, but AT2 plays rubbish if opl_latency is set to 0 (default) and ok if set to 1.
Thanks!

Hm, I have the Colani 486SX with a OPL3 on a Jazz16 board. I think I could test, if AT2 runs on such a machine. I remember it being quite CPU hungry.

Love the card! I see you are still using the BlasterBoard like mounting of the bracket -- why not use standard keystone brackets...? You need only drilled holes anyway, right? Should be relatively easy to make. Also the bracket would be properly grounded then.

root42 wrote on 2023-07-20, 09:42:

..Colani 486SX with a OPL3 on a Jazz16 board..

That would be great, if you'll be able to run it on a 486SX. My attempt was unlucky on ICL ValuePlus 486SX/8Mb RAM - it detected the OPL3, but hanged before entering the UI. The manual mentions a 386DX as a minimum req, so I guess it is co-proc issue. By the way, can you run AdPlay on your SX? Looks like it requires co-proc too, which is rediculous. Maybe it just needs to be recompiled with appropriate switches.

root42 wrote on 2023-07-20, 09:42:

..you are still using the BlasterBoard like mounting of the bracket..

Did not decide on the bracket yet, for faster design the prototype uses the same bracket layout

LABS wrote on 2023-07-20, 09:18:

Hello there!
I wonder if anyone with a real OPL3 & DOS & cpu>=486 can tell if Adlib Tracker II needs an opl_latency=1 option to play correctly? I bumped into a problem that OPL3-enabled games I tested (WAR2, Descent, Blood,... ) are all ok, but AT2 plays rubbish if opl_latency is set to 0 (default) and ok if set to 1.
Thanks!

I can check this on my 430HX/166MMX test bench tonight 😀 It would help if you could attach the Adlib Tracker II that you want me to test though.

appiah4 wrote on 2023-07-20, 10:35:

LABS wrote on 2023-07-20, 09:18:

Hello there!
I wonder if anyone with a real OPL3 & DOS & cpu>=486 can tell if Adlib Tracker II needs an opl_latency=1 option to play correctly? I bumped into a problem that OPL3-enabled games I tested (WAR2, Descent, Blood,... ) are all ok, but AT2 plays rubbish if opl_latency is set to 0 (default) and ok if set to 1.
Thanks!

I can check this on my 430HX/166MMX test bench tonight 😀 It would help if you could attach the Adlib Tracker II that you want me to test though.

Probably this one: http://www.adlibtracker.net

root42 wrote on 2023-07-20, 10:54:

appiah4 wrote on 2023-07-20, 10:35:

LABS wrote on 2023-07-20, 09:18:

Hello there!
I wonder if anyone with a real OPL3 & DOS & cpu>=486 can tell if Adlib Tracker II needs an opl_latency=1 option to play correctly? I bumped into a problem that OPL3-enabled games I tested (WAR2, Descent, Blood,... ) are all ok, but AT2 plays rubbish if opl_latency is set to 0 (default) and ok if set to 1.
Thanks!

I can check this on my 430HX/166MMX test bench tonight 😀 It would help if you could attach the Adlib Tracker II that you want me to test though.

Probably this one: http://www.adlibtracker.net

Yes
http://www.adlibtracker.net/downloads.php

LABS wrote on 2023-07-20, 11:34:

root42 wrote on 2023-07-20, 10:54:

appiah4 wrote on 2023-07-20, 10:35:

I can check this on my 430HX/166MMX test bench tonight 😀 It would help if you could attach the Adlib Tracker II that you want me to test though.

Probably this one: http://www.adlibtracker.net

Yes
http://www.adlibtracker.net/downloads.php

Consider it done tonight 😀 However, IIRC I used to use this program to play MODULES\VOID\ALLOYRUN.RAD (I'm addicted to that tune) and it would play without a hitch on my ES688/OPL3 sound card. Is there a specific OPL3 card you want me to test?

EDIT: Here is AT2 playing Alloyrun in DOS, recorded 4 years ago using a YMF719E sound card and default settings (ie no opl_latency specified).

I will double check tonight though.

appiah4 wrote on 2023-07-20, 12:15:

..play without a hitch on my ES688/OPL3 sound card..

most probably this is the answer, however if you could please test CT1740 or CT2800 to be sure?

appiah4 wrote on 2023-07-20, 12:15:

I will double check tonight though.

thanks, man

LABS wrote on 2023-07-20, 09:18:

Hello there!
I wonder if anyone with a real OPL3 & DOS & cpu>=486 can tell if Adlib Tracker II needs an opl_latency=1 option to play correctly?

The machine I use is a good deal faster than a 486, but I can confirm the behaviour you described. As you deal with faster processors, more care needs to be taken in implementing the delays between I/O operations to the OPL3. Since many applications/games were shipped with sloppy timing routines (or routines based on certain unfortunate assumptions), they are often inadequate when run on faster machines. The result is that the OPL3 ends up in an inconsistent, rather unpredictable state, and produces some rather awful noises that can be difficult to silence.

On some machines, making sure you don't operate the ISA bus much faster than 8 MHz can help, as well as increasing 8-bit I/O recovery time. Some designs also need 16-bit I/O recovery time to be increased, though this is less common. For an application like Adlib Tracker II, specifically, even with I/O recovery time set to the maximum allowed, it will misbehave sooner or later on faster machines, unless the latency option is enabled. I can confirm this to be the case on the Ad Lib Gold 1000 (YMF262), as well as all existing Orpheus designs bearing a YMF289. Interestingly, the on-chip Crystal FM implementation is mostly immune to this, and mostly works fine without it.

LABS wrote on 2023-07-20, 13:41:

most probably this is the answer, however if you could please test CT1740 or CT2800 to be sure? […]
Show full quote

appiah4 wrote on 2023-07-20, 12:15:

..play without a hitch on my ES688/OPL3 sound card..

most probably this is the answer, however if you could please test CT1740 or CT2800 to be sure?

appiah4 wrote on 2023-07-20, 12:15:

I will double check tonight though.

thanks, man

I have just tested with the CT1740 on my P166MMX test bench and indeed, AT2 playback is busted without opl_latency=1 in the .ini

It seems I made my recordings using RAD2 in the past for this exact reason - I actually couldn't figure out the workaround for this until now! Only upon checking my notes from 4 years ago I find mention of this, weird!

So LABS, I can replicate your garbled sound from OPL3 behaviour completely 😀

640K!enough wrote on 2023-07-20, 18:34:

.. I can confirm the behaviour you described..

appiah4 wrote on 2023-07-20, 19:56:

..AT2 playback is busted without opl_latency=1 in the .ini..

Thanks a lot, guys! Was worried it is a problem of my design. I wish asking you earlier 😀
Most likely AT2 is configured by default for using it with a DosBox - without any internal software delays. However, now I found a warning about it in the manual ADTRACK2.DOC:

You may encounter playback problems when you are using some older soundcard with OPL2 chip or with derived OPL3 chip. In this case, toggle on the safely OPLx latency (set option "opl_latency" to 1).

In ADTRACK2.INI, however, it is written:

1opl_latency=0         ; OPLx register writes latency:
2                      ;   [0] opl3-optimized (recommended)
3                      ;   [1] 3.3 + 23 us (use in case of troubles only)

Which makes no sense, as the opl3-optimized (recommended) setting does not work for a real (derived?) OPL3. Hence the confusion. For the OPL3 AT2 needs to switch on the OPL2 delays (3.3us + 23us), which slow things down even more than for the OPL2, because OPL3 has a thicker byte flow during playback.

Just to make things clear I investigated a bit further. The popular OPL3 programming guide (https://www.fit.vutbr.cz/~arnost/opl/opl3.html) states:

Unlike Adlib (OPL2), OPL3 doesn't need delay between register writes. With OPL2 you had to wait 3.3 us after index register write and another 23 us after data register write. On the contrary OPL3 doesn't need (almost) any delay after index register write and only 0.28 us after data register write. This means you can neglect the delays and considerably speed up your music driver. But using reasonable delays will certainly do no harm.

0.28 us = 280 ns(~4MHz), which is a half of ISA speed, but one 4-clock access cycle for 16-bit ISA device is 500 ns long, so there is a 220 ns margin and no soft delays needed at all. But this guide seems to be misguiding. The YMF262 datasheet says:

Considering 14.3(18) MHz clock, 32 cycles takes ~2.2 us, which is ~4.5 x 16-bit ISA access cycles. So "reasonable delays" mentioned in the guide for the OPL3 should be minimum 2.2 us for index and 2.2 us for data register writes as compared to OPL2's 3.3 us and 23 us respectively.

Seems like AT2 uses "the guide" timings rather than from the datasheet, which makes it DosBox-only beast when opl_latency=0 (default, opl3-otimized, recommended).

EDIT: Where the timings from the mentioned guide came from?

EDIT EDIT: How OPL3 music was produced for Descent games if it is lagging on a real OPL3?

EDIT EDIT EDIT: Who really killed Laura Palmer?

640K!enough wrote on 2023-07-20, 18:34:

..as well as increasing 8-bit I/O recovery time. .

Pull down /IOCHRDY for 16 wait-states? Jumper-activated for faster machines?

LABS wrote on 2023-07-21, 12:32:

Pull down /IOCHRDY for 16 wait-states? Jumper-activated for faster machines?

I'm not sure that would solve the problem, and I'm also not sure you really want to be hogging the bus in that way. I won't have the cash or equipment to do this anytime soon, but I have been considering the idea of taking actual measurements on the ISA bus, with no memory managers or extra TSRs loaded, and with AT2's latency options enabled and disabled. That might give us a few clues.

One approach could be to experiment with a small FIFO buffer for OPL3 accesses, and only perform the actual writes once the timing constraints have been met. This can have a few other problems, but I'm not sure it would be any worse than what we have now. I would start with a dedicated MCU for this task, and consider integrating it with other functions only if there are enough spare clock cycles and it is relatively certain not to introduce bugs like Creative had for years.

I have done FIFO approach on some custom hardware and for a different YMF chip with great success. Host CPU only got stalled when FIFO was full and this wasn't a common occurence. System performance was muuuuuuuch higher with the FIFO than without and the FIFO allowed all the limited YMF bandwidth to be utilized for cycle perfect things, whatever they may be 🤣

Cool idea. How about using vintage shift-registers? They're quick and need no µC.
I mean, the YMF262 is write-only for most parts, unlike the YMF289 (OPL3-L).
Not sure if that approach affects AdLib detection routines, though. 🤷‍♂️

Tiido wrote on 2023-07-21, 23:06:

I have done FIFO approach on some custom hardware and for a different YMF chip with great success. Host CPU only got stalled when FIFO was full and this wasn't a common occurence. System performance was muuuuuuuch higher with the FIFO than without and the FIFO allowed all the limited YMF bandwidth to be utilized for cycle perfect things, whatever they may be 🤣

For custom hardware, it probably makes a lot of sense. In this case, we're talking about implementing a standard Ad Lib-compatible design with FIFO, and then running standard x86 software without modification. I strongly suspect that it can be made to work there too, but not without some trickery. For instance, such a design would have to account for reads of status registers while the FIFO is non-empty and you're still processing writes. An answer would be expected during that read cycle, so you can't just stick it in a FIFO and wait until you're ready. It would take some experimentation and measurements (statistics on FIFO usage, for instance) to get it right, I think.

Jo22 wrote on 2023-07-22, 03:58:

Cool idea. How about using vintage shift-registers? They're quick and need no µC.

I'm not sure about that. My suspicion is that you would need more crafty routines to manage the timing and other tricks, so the MCU would be justified, even absolutely necessary, anyhow.

You stall ISA via wait state mechanism on filled FIFO or when a read is issued so that the chip receives all the writes before any data is going to be returned. There isn't a need for any extra status registers and it will be completely transparent to the software unless it specifically tries to analyze access timings but even that is riddled with issues since ISA bus speed and CPU speed itself are highly variable. The FIFO mechanism in the music making device I made is also transparent to the software, although the FIFO full and empty status is exposed to optimize the software end to minimize any bus stalls and loss of performance that happens way. The FIFO has was implemented is 256 levels deep and basically never fills. Only time it get filled is in initialisation bits in a new track where all channels get their instruments written, but this is with a 50MHz single cycle access bus on the other end of the FIFO and not a really slow ISA interface.

There was a slight unexpected delay in SB8 development, but now I'm back in the lab

The prototype so far looks like this and still work in progress:

Overall it worked fine, but had problems running Wolf 3D on <486 machines. After some timing corrections in the hardware and rewriting the firmware from scratch to literally match the original SB2's one, Wolf 3D became stable and it finally was detected by test-sbc.exe even on Pentium 166 (even SB2.0 can't do that!! 🤣).

Currently the card shows strange behavior only with one of my 486 machines (SB2.0 and BlasterBoard runs fine on it) and needs to be defeated.

Will also try to implement FIFO for OPL3. If this thing will allow us to run AT2 in OPL3 timing mode + Indiana Jones and SOMI on Pentiums + hearing no lags during Descent music for the first time in ~30 years = that would be an epic universal victory

No prototype is complete without big bodges hahaha

I have done a FIFO on FM chips before, it works very well but I used a FPGA + its internal memory for that. There are actual FIFO chips out ther but the logic necessary can be quite big to utilize them...
You can avoid garbage sounds etc. by utilising the ISA wait states mechanism though, it won't cure any stutters but it can still be an improvement. The logic requirements aren't probably too much lower that a FIFO, you still need a counter that mimics the access windows of the FM chip.