VOGONS


OPL2LPT

Topic actions

Reply 220 of 566, by pdw

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 222 of 566, by Scali

User metadata
Rank l33t
Rank
l33t
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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 223 of 566, by Scali

User metadata
Rank l33t
Rank
l33t

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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 224 of 566, by dJOS

User metadata
Rank Newbie
Rank
Newbie

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.

The impossible often has a kind of integrity which the merely improbable lacks.

Reply 225 of 566, by dJOS

User metadata
Rank Newbie
Rank
Newbie

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

The impossible often has a kind of integrity which the merely improbable lacks.

Reply 228 of 566, by bjwil1991

User metadata
Rank l33t
Rank
l33t
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.

Discord: https://discord.gg/U5dJw7x
Systems from the Compaq Portable 1 to Ryzen 9 5950X
Twitch: https://twitch.tv/retropcuser

Reply 229 of 566, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author
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.

Reply 231 of 566, by Beegle

User metadata
Rank Member
Rank
Member
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.

The more sound cards, the better.
AdLib documentary : Official Thread
Youtube Channel : The Sound Card Database

Reply 232 of 566, by bjwil1991

User metadata
Rank l33t
Rank
l33t
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.

Discord: https://discord.gg/U5dJw7x
Systems from the Compaq Portable 1 to Ryzen 9 5950X
Twitch: https://twitch.tv/retropcuser

Reply 233 of 566, by matze79

User metadata
Rank l33t
Rank
l33t

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.

https://www.retrokits.de - blog, retro projects, hdd clicker, diy soundcards etc
https://www.retroianer.de - german retro computer board

Reply 234 of 566, by bjwil1991

User metadata
Rank l33t
Rank
l33t
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).

Discord: https://discord.gg/U5dJw7x
Systems from the Compaq Portable 1 to Ryzen 9 5950X
Twitch: https://twitch.tv/retropcuser

Reply 235 of 566, by pdw

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 236 of 566, by Jo22

User metadata
Rank l33t++
Rank
l33t++

^ 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.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 237 of 566, by matze79

User metadata
Rank l33t
Rank
l33t

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

And iospeed:

iospeed.jpg
Filename
iospeed.jpg
File size
75.84 KiB
Views
1839 views
File license
Fair use/fair dealing exception

https://www.retrokits.de - blog, retro projects, hdd clicker, diy soundcards etc
https://www.retroianer.de - german retro computer board

Reply 238 of 566, by jaZz_KCS

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 239 of 566, by Zarchos

User metadata
Rank Newbie
Rank
Newbie
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 ?