jaZz_KCS wrote:

May I ask what you have changed, because at least on this machine there is now almost NO difference in speed compared to the patched version. This is a game changer.

So this is going to get a bit technical... Games program the OPL2 chip by changing the values in its internal registers. Typically this goes like this:

• Write a register number to the address port
• Delay by reading the address port 6 times (needed because the OPL2 is not a very fast chip)
• Write a new value to the data port
• Delay some more by reading the address port 35 times

So all together these are 43 I/O operations. Each of these takes about 1 microsecond (the exact duration varies a bit from computer to computer). What's important to note is that of these 43 operations, only the two writes have an effect; the reads are solely there to provide a delay.

Now what the TSR does is to ask the CPU to generate a fault whenever a program accesses one of the Adlib ports. EMM386 receives this fault, does some work to figure out what's happened, and passes control to my TSR. The TSR then does the equivalent I/O operation using the parallel port. This of course causes some overhead. On 486 and later systems the overhead is tolerable but it turns out that on a 386 it's gigantic -- the entire fault handling takes about 70 microseconds. What originally required about 43 microseconds now takes 3000 microseconds. So no wonder that games run slow.

What this experimental version does is to check which instruction caused the fault. If it's a read, it's patched out. This way we need to pay the cost of the fault only for the writes. We still need to ensure that we don't access the OPL2 chip too fast, so a delay is added to the write handling in the TSR.

I guess that programs with sample playback (IPLAY/GLX212/Pinball Dreams) try to measure the I/O timings (to calculate what sampling rate is feasible etc) and get completely confused by my shenanigans.

My current feelings are that this should become an option, perhaps only enabled by default on 80386 CPUs.

8-bit guy video is now here: https://www.youtube.com/watch?v=z3DU2mNBa6M

pdw wrote:

What this experimental version does is to check which instruction caused the fault. If it's a read, it's patched out. This way we need to pay the cost of the fault only for the writes. We still need to ensure that we don't access the OPL2 chip too fast, so a delay is added to the write handling in the TSR.

A read of port 389h doesn't do anything, because the port is write-only. So you wouldn't have to redirect those reads in the first place.
A read of port 388h should return the status. So perhaps some software expects a read to be performed at least in some cases (during initialization most probably).
Perhaps you could make it so that for port 388h you perform a read the first time, but remember the address of the instruction, and patch the instructions out only if you either get the exact same address the next time (within a short time period perhaps), because then it's a loop... or if you get reads from consecutive addresses, then it's an unrolled loop.

I suppose you could also just leave the reads of port 388h in there, because it's 'only' 6 of them normally.
Most code will probably just write to port 389h and leave dx to 389h when they perform the 35 reads. So if you would only patch reads for port 389h, you're probably good to go.

Damn I wish I could code, imo it'd be a lot of fun to add an OPL2LPT to an Amiga and combine the lovel Yamaha sound with the Amiga's 4ch digital capabilities.

PS, I just ordered one for my PC's to play with, I cant wait to build it! 😎

it seems like a nice enough kit to just try out for a bit. Wonder how many opl2 chips he has left 😀

You mean the YM3812? Pretty much as many as he wants to buy, they are 2€ new and readily available.

Scali wrote:

8-bit guy video is now here: https://www.youtube.com/watch?v=z3DU2mNBa6M

Watched the video on my TV screen via Chromecast, and I can honestly say, that was an amazing video. I might get one for my Pavilion N3350 laptop since the sound card isn't really good for DOS games (ESS Maestro 3) as it cuts out or doesn't play music or SFX at all.

sf78 wrote:

You mean the YM3812? Pretty much as many as he wants to buy, they are 2€ new and readily available.

Oh I didn't expect them to be still available. Must be some retro market to satisfy still for them.

Yeah, US 😁

Harekiet wrote:

sf78 wrote:

You mean the YM3812? Pretty much as many as he wants to buy, they are 2€ new and readily available.

Oh I didn't expect them to be still available. Must be some retro market to satisfy still for them.

When people start gutting their old AdLibs and Sound Blasters to mine the OPL2 chips for resale intent (like they do with C64s and SID chips) you'll see me around with a pitchfork and flamethrower.

Beegle wrote:

Harekiet wrote:

sf78 wrote:

You mean the YM3812? Pretty much as many as he wants to buy, they are 2€ new and readily available.

Oh I didn't expect them to be still available. Must be some retro market to satisfy still for them.

When people start gutting their old AdLibs and Sound Blasters to mine the OPL2 chips for resale intent (like they do with C64s and SID chips) you'll see me around with a pitchfork and flamethrower.

I have a Yamaha PSS-460 that utilizes the YM3812 chip, and it sounds amazing. There's a video about the keyboards (aka the Sound Blaster) on YouTube: Meet the little-known "SoundBlaster" Keyboards by the 8-Bit Guy (formally, the iBookGuy), and in part of the video, he plays the opening theme for Ultima VI.

i tested today adpatch with opl2lpt and commander keen 4 cga.
it has heavy disortions on 286 12Mhz.

Seems the Write/Read Cycles to OPL2 are not correct.
Disabling music gives slightly less disortion on sounds.

matze79 wrote:

i tested today adpatch with opl2lpt and commander keen 4 cga. it has heavy disortions on 286 12Mhz. […]
Show full quote

i tested today adpatch with opl2lpt and commander keen 4 cga.
it has heavy disortions on 286 12Mhz.

Seems the Write/Read Cycles to OPL2 are not correct.
Disabling music gives slightly less disortion on sounds.

According to the 8-bit guy, the recommended CPU is a 386 or higher (but I digress).

Matze79, can you run https://2k38.be/adlipt/iospeed.exe and report which numbers you get?
Possibly the ISA bus on your 286 runs faster than standard. That would cause compatibility problems with Adlib software.

^ No offense, but I'd like to note that some 286 machines pre-dated ISA. Therefore, they did't run out-of-specifications per se. 😉
So when AdLib was released, PCs with non-8.32MHz buses were still around (up to 12MHz was common).
Anyway, checking things is generally a good idea. 😀 The 8-bit part always should provide a proper time base via the OSC pin.

Here my Machine:
https://dos-reloaded.de/forum/index.php/Threa … 12Mhz-Luggable/

And iospeed:

pdw wrote:

Now what the TSR does is to ask the CPU to generate a fault whenever a program accesses one of the Adlib ports. EMM386 receives this fault, does some work to figure out what's happened, and passes control to my TSR. The TSR then does the equivalent I/O operation using the parallel port. This of course causes some overhead. On 486 and later systems the overhead is tolerable but it turns out that on a 386 it's gigantic -- the entire fault handling takes about 70 microseconds. What originally required about 43 microseconds now takes 3000 microseconds. So no wonder that games run slow.

What this experimental version does is to check which instruction caused the fault. If it's a read, it's patched out. This way we need to pay the cost of the fault only for the writes. We still need to ensure that we don't access the OPL2 chip too fast, so a delay is added to the write handling in the TSR.

This explains why the difference in speed was so drastic on the 20Mhz 386. First I thought I made a mistake, because the speed reached with the experimental version that only pays the cost for the fault of the writes was identical to patching the game with adpatch.

+1 for the idea to 1]make this an option and 2]maybe make this option standard when a 386 is detected.

jaZz_KCS wrote:

pdw wrote:

Now what the TSR does is to ask the CPU to generate a fault whenever a program accesses one of the Adlib ports. EMM386 receives this fault, does some work to figure out what's happened, and passes control to my TSR. The TSR then does the equivalent I/O operation using the parallel port. This of course causes some overhead. On 486 and later systems the overhead is tolerable but it turns out that on a 386 it's gigantic -- the entire fault handling takes about 70 microseconds. What originally required about 43 microseconds now takes 3000 microseconds. So no wonder that games run slow.

What this experimental version does is to check which instruction caused the fault. If it's a read, it's patched out. This way we need to pay the cost of the fault only for the writes. We still need to ensure that we don't access the OPL2 chip too fast, so a delay is added to the write handling in the TSR.

This explains why the difference in speed was so drastic on the 20Mhz 386. First I thought I made a mistake, because the speed reached with the experimental version that only pays the cost for the fault of the writes was identical to patching the game with adpatch.

+1 for the idea to 1]make this an option and 2]maybe make this option standard when a 386 is detected.

A stupid question : when you get the fault, would it be possible to have a dump of the code (or run a step by step debugger), to be able to write a full patch ?
ie install a branch to your code, instead of the original code and having the error handling ?