noop wrote:

pdw wrote:

If it's a read, it's patched out.

I think it is better to redirect read to any other port, so the delays remains as before. Easier said than done though.

It's probably best to patch out the reads, and instead perform the delays in the TSR itself, after the writes.
The problem with redirecting ports is that it has huge overhead on slow 386 machines.

dr.zeissler wrote:

I think it behaves like a COVOX which means it will work in real dos, but not within win9x/2k/xp, or am I wrong here?

True, but if there are AdLib drivers for these versions of Windows, they could be patched.

does an OPL2LPT work as a covox when placing it after a DSS adapter?
i am currently thinking about this.

ISA Multi/IO (no soundcard at all)
-> COM-Port => SoftMPU => MIDI device
-> LPT-PORT => DSS -> OPL2LPT

Greetings
Doc

No, it will not work, OPL2 is not a Covox Device 😀

Joey_sw wrote:

is Miles Sound System adlib drivers patchable?

As far as i know its opensource (source avaible for download..) now ?
Or RAD Game tools for MS-Dos ?!? ahh can't remember..

Also SSI-2001 Replica got Miles Soundsystem Driver.. and works on Warcraft ^^

I have bought a OPL2LPT for my IBM PC since the MCA sound cards are difficult to obtain. However it does not work.

I have tried on newer systems like a later 386 with typical MultiIO card and it works fine on the LPT. Something must be different on the IBM machine, as I get only random sounds there (also with OPL2TEST). The system is a Model 80 with a 386DX-16.

Anyone had similar problems? Any ideas how to get it working?

Scali wrote:

noop wrote:

pdw wrote:

If it's a read, it's patched out.

I think it is better to redirect read to any other port, so the delays remains as before. Easier said than done though.

It's probably best to patch out the reads, and instead perform the delays in the TSR itself, after the writes.
The problem with redirecting ports is that it has huge overhead on slow 386 machines.

No, re-read the discussion. The whole problem is that making reads too fast breaks some software, and it is not port reads themselves that are too slow, but port reads that get intercepted by the driver. If you change them to not be intercepted by the driver, they will produce the expected amount of delay without breaking anything.

matze79 wrote:

No, it will not work, OPL2 is not a Covox Device 😀

Though it is actually possible to make it emulate covox via the same sw driver. Except it is will be quite slow.

I would be amazed if there would be an OPL3LPT with the Covox Speech Thing for SFX and voice.

Just noticed that the OPL2LPT is also a great tool for testing the parallel port. 😎

System is an AMD Duron 800 running MS-DOS 6.22 from a DOM.

noop wrote:

No, re-read the discussion.

No, inform yourself who you're talking to, instead of assuming I know nothing about AdLib programming and delays.
Also, read my posts more clearly.

noop wrote:

The whole problem is that making reads too fast breaks some software, and it is not port reads themselves that are too slow, but port reads that get intercepted by the driver.

Duh. I literally said the port redirection is slow (as in being redirected by being intercepted by EMM386 and transferred to the TSR driver). I never said port reads are slow.

noop wrote:

If you change them to not be intercepted by the driver, they will produce the expected amount of delay without breaking anything.

That assumes that you have the freedom to intercept only writes, not reads on the same port. Which you don't, with the EMM386 API that is being used:
http://www.delorie.com/djgpp/doc/rbinter/id/69/48.html

As you can see here:
https://github.com/pdewacht/adlipt/blob/maste … lipt/res_opl2.c
You set up a single function, that is called for both reads and writes to the port you are virtualizing:
unsigned emulate_adlib_address_io(int port, int is_write, unsigned ax, codeptr next_opcode);
unsigned emulate_adlib_data_io(int port, int is_write, unsigned ax, codeptr next_opcode);

Whether it is a read or a write is passed as a parameter. So by the time you find out, it is already too late, because you have already gone through the virtualization layer.
This is why you need to patch out the reads, so they don't trigger the virtualization after the first call. You'd almost think that it was a deliberate choice to patch out the reads, by someone who knows what they were doing...

Scali wrote:

I literally said the port redirection is slow (as in being redirected by being intercepted by EMM386 and transferred to the TSR driver). I never said port reads are slow.

noop wrote:

If you change them to not be intercepted by the driver, they will produce the expected amount of delay without breaking anything.

That assumes that you have the freedom to intercept only writes, not reads on the same port. Which you don't, with the EMM386 API that is being used:

Sorry for making it look like I'm doubting your experience, and not making my thought clear enough(I'm not a native English speaker), but this is NOT what I proposed:

noop wrote:

pdw wrote:

If it's a read, it's patched out.

I think it is better to redirect read to any other port, so the delays remains as before. Easier said than done though.

I proposed to patch reads from the Adlib port with reads from any other port that is not being intercepted by the driver Because most ISA reads generate roughly the same delay.
This is my third attempt to explain.
Though, actually, it is hard to apply such a patch, as you need few more bytes to generate extra instructions (but I have an idea how to do that)

Scali wrote:

No, inform yourself who you're talking to, instead of assuming I know nothing about AdLib programming and delays.

What does this even mean? I never made such assumptions.
Why did I need to study your profile before trying to better explain what I actually meant?
Anyway, I think my reply still sounded rude. This did not mean I'm doubting you experience. I was wrongly assuming you've missed the part where software breaks due to reads patched out.
Btw you are welcome to check my profile as well.

elianda wrote:

I have bought a OPL2LPT for my IBM PC since the MCA sound cards are difficult to obtain. However it does not work.

I have tried on newer systems like a later 386 with typical MultiIO card and it works fine on the LPT. Something must be different on the IBM machine, as I get only random sounds there (also with OPL2TEST). The system is a Model 80 with a 386DX-16.

Anyone had similar problems? Any ideas how to get it working?

I have the same problem on a PS/2 P70 386DX 20 - no idea why it doesn't work. Someone else on here has it working on a different PS/2 though.

its not worth to emulate a R2R Ladder on this Plug.
Even simpler to include it on the PCB Backside and make it switchable.

SteveC wrote:

elianda wrote:

I have bought a OPL2LPT for my IBM PC since the MCA sound cards are difficult to obtain. However it does not work.

I have tried on newer systems like a later 386 with typical MultiIO card and it works fine on the LPT. Something must be different on the IBM machine, as I get only random sounds there (also with OPL2TEST). The system is a Model 80 with a 386DX-16.

Anyone had similar problems? Any ideas how to get it working?

I have the same problem on a PS/2 P70 386DX 20 - no idea why it doesn't work. Someone else on here has it working on a different PS/2 though.

I have also tried on a XT system and it works there on a controller card. So it does not seem to be a speed issue but more like a hardware problem on the IBM PS/2s.

noop wrote:

I proposed to patch reads from the Adlib port with reads from any other port that is not being intercepted by the driver Because most ISA reads generate roughly the same delay.

And what advantage would that have over handling the delay inside the write?

elianda wrote:

SteveC wrote:

elianda wrote:

I have bought a OPL2LPT for my IBM PC since the MCA sound cards are difficult to obtain. However it does not work.

I have tried on newer systems like a later 386 with typical MultiIO card and it works fine on the LPT. Something must be different on the IBM machine, as I get only random sounds there (also with OPL2TEST). The system is a Model 80 with a 386DX-16.

Anyone had similar problems? Any ideas how to get it working?

I have the same problem on a PS/2 P70 386DX 20 - no idea why it doesn't work. Someone else on here has it working on a different PS/2 though.

I have also tried on a XT system and it works there on a controller card. So it does not seem to be a speed issue but more like a hardware problem on the IBM PS/2s.

Can confirm this to be working on the IBM PS/2 L40SX (386SX-20), but that is a laptop and memory mapping might be different.
I will also try this on a Toshiba T3200SX (386SX-16) next.

Is that PS/2 MCA based?

Don't PS/2 machines have a special parallel port (EPT) ?
http://philipstorr.id.au/pcbook/book2/parallel.htm