OPL2LPT

Discussion about old sound cards, MIDI devices and sound related accessories.

Re: OPL2LPT

Postby pdw » 2017-12-13 @ 19:46

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.
pdw
Newbie
 
Posts: 33
Joined: 2016-12-26 @ 18:45

Re: OPL2LPT

Postby Scali » 2017-12-14 @ 02:47

8-bit guy video is now here: https://www.youtube.com/watch?v=z3DU2mNBa6M
Scali
l33t
 
Posts: 3595
Joined: 2014-12-13 @ 14:24

Re: OPL2LPT

Postby Scali » 2017-12-14 @ 02:53

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.
Scali
l33t
 
Posts: 3595
Joined: 2014-12-13 @ 14:24

Re: OPL2LPT

Postby Scali » 2017-12-14 @ 02:56

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.
Scali
l33t
 
Posts: 3595
Joined: 2014-12-13 @ 14:24

Re: OPL2LPT

Postby dJOS » 2017-12-14 @ 03:06

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.
User avatar
dJOS
Newbie
 
Posts: 34
Joined: 2017-5-10 @ 02:47

Re: OPL2LPT

Postby dJOS » 2017-12-14 @ 03:17

PS, I just ordered one for my PC's to play with, I cant wait to build it! :cool:
The impossible often has a kind of integrity which the merely improbable lacks.
User avatar
dJOS
Newbie
 
Posts: 34
Joined: 2017-5-10 @ 02:47

Re: OPL2LPT

Postby Harekiet » 2017-12-14 @ 07:31

it seems like a nice enough kit to just try out for a bit. Wonder how many opl2 chips he has left :)
User avatar
Harekiet
DOSBox Author
 
Posts: 1049
Joined: 2002-7-01 @ 07:14
Location: Fryslan

Re: OPL2LPT

Postby sf78 » 2017-12-14 @ 13:38

You mean the YM3812? Pretty much as many as he wants to buy, they are 2€ new and readily available.
sf78
Oldbie
 
Posts: 507
Joined: 2014-10-16 @ 15:05
Location: Finland

Re: OPL2LPT

Postby bjwil1991 » 2017-12-14 @ 13:49

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.
C64, WheelWriter 10 Series II QuietWriter 8, Pack-Mate 28 Plus, K6-2/300, Pavilion N3350, iMac G3 & G4, Socket 370, 2x Inspiron 600m, Athlon 64, Dimension 4550 & E510, ThinkPad R40, Presario C700, ASUS X54C, Raspberry Pi B+, 2B-3B+, Custom FX-6300
User avatar
bjwil1991
Oldbie
 
Posts: 1855
Joined: 2013-8-14 @ 03:10
Location: SE, MI USA

Re: OPL2LPT

Postby Harekiet » 2017-12-14 @ 17:51

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.
User avatar
Harekiet
DOSBox Author
 
Posts: 1049
Joined: 2002-7-01 @ 07:14
Location: Fryslan

Re: OPL2LPT

Postby SteveC » 2017-12-14 @ 19:19

Yeah, US :D
SteveC
Newbie
 
Posts: 68
Joined: 2017-11-25 @ 22:05
Location: Rayleigh, Essex, UK

Re: OPL2LPT

Postby Beegle » 2017-12-14 @ 21:14

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.
User avatar
Beegle
Member
 
Posts: 436
Joined: 2013-12-01 @ 02:15
Location: Canada

Re: OPL2LPT

Postby bjwil1991 » 2017-12-14 @ 21:18

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.
C64, WheelWriter 10 Series II QuietWriter 8, Pack-Mate 28 Plus, K6-2/300, Pavilion N3350, iMac G3 & G4, Socket 370, 2x Inspiron 600m, Athlon 64, Dimension 4550 & E510, ThinkPad R40, Presario C700, ASUS X54C, Raspberry Pi B+, 2B-3B+, Custom FX-6300
User avatar
bjwil1991
Oldbie
 
Posts: 1855
Joined: 2013-8-14 @ 03:10
Location: SE, MI USA

Re: OPL2LPT

Postby matze79 » 2017-12-16 @ 14:31

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
Oldbie
 
Posts: 1153
Joined: 2014-12-12 @ 14:25
Location: Germany, Frankonia

Re: OPL2LPT

Postby bjwil1991 » 2017-12-16 @ 15:22

matze79 wrote: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).
C64, WheelWriter 10 Series II QuietWriter 8, Pack-Mate 28 Plus, K6-2/300, Pavilion N3350, iMac G3 & G4, Socket 370, 2x Inspiron 600m, Athlon 64, Dimension 4550 & E510, ThinkPad R40, Presario C700, ASUS X54C, Raspberry Pi B+, 2B-3B+, Custom FX-6300
User avatar
bjwil1991
Oldbie
 
Posts: 1855
Joined: 2013-8-14 @ 03:10
Location: SE, MI USA

Re: OPL2LPT

Postby pdw » 2017-12-16 @ 15:47

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.
pdw
Newbie
 
Posts: 33
Joined: 2016-12-26 @ 18:45

Re: OPL2LPT

Postby Jo22 » 2017-12-16 @ 22:13

^ 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//
User avatar
Jo22
l33t
 
Posts: 2978
Joined: 2009-12-13 @ 07:06
Location: Europe

Re: OPL2LPT

Postby matze79 » 2017-12-17 @ 07:40

matze79
Oldbie
 
Posts: 1153
Joined: 2014-12-12 @ 14:25
Location: Germany, Frankonia

Re: OPL2LPT

Postby jaZz_KCS » 2017-12-17 @ 11:30

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.
User avatar
jaZz_KCS
Member
 
Posts: 286
Joined: 2017-8-10 @ 11:43

Re: OPL2LPT

Postby Zarchos » 2017-12-17 @ 12:10

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 ?
Zarchos
Newbie
 
Posts: 12
Joined: 2017-12-15 @ 20:56

PreviousNext

Return to Sound

Who is online

Users browsing this forum: No registered users and 5 guests