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