The reason why i'm asking:
sb dma transfer is active
game reads dma transfer counter (low part)
[here the dma wrapping due to autoinit happens/can happen]
game reads dma transfer counter (high part)

now the highpart<<8 + lowpart is not correct (which is no
problem in general and can happen on a real pc as well as
far as i understand) but there's an overflow
the overflow doesn't happen if the wrapping in-between those
reads ONLY happens if the read low part was <=0x40 (which did
not happen in dosbox before but can happen now due to the
io access reducing cycles)

I'm trying to estimate the port delay as well but i doubt the results
from the p4 are that useful...

For me the values were the same over the ports i tried, and in the
range of what you posted.

Yes on the 386sx too. It even generated a ISA bus cycle when reading from the DMA controller register.
But on the P4 you probably have no ISA bus to compare.

There is one thing I noticed. On the real computer, the DMA transfers do only
one byte of data at time, i.e. every 40 microseconds (22500 8bit mono). In DOSBox this is done with a block of multiple bytes every millisecond. The byte count register content doesn't decrease continually.
On the real computer the game should be able to read the registers with only one decrement (worst case) of the counter.

Or the game is looking at the DMA register at the wrong moment? Is it a timer ISR? What if you restore the older timer code?

The DMA controller will
also exit the Idle Mode and enter the Program Mode when
the CPU attempts to access its internal registers.

I wonder if this is implemented in DOSBox and might have an effect here?

The byte count register content doesn't decrease continually.

Yes, and there's already coding that (tries to) care about this. That is the
counter is adjusted to reflect the estimated position in the buffer, not the
last block position. But it's hard to verify its working so some different thing
will be used. If the counter reading would not impose delays itself this
would have simplified things, but i think it can be assumed that all port
accesses actually have the delaying effect.
Thanks for verifying this!

IODelay optimization - don't multiply on every access - improves performance a little bit.

Maybe the other direction would be better, that is imposing real delays
on io-access so the reduced cycles "match" the real time spent there
to avoid the cycles guessing go off 😀

Also you shouldn't use that code:

+ if(CPU_Cycles > writedelay) { + CPU_Cycles -= writedelay; + CPU_IODelayRemoved+=writedelay; + } + else CPU_Cycles = 0; […]
Show full quote

+ if(CPU_Cycles > writedelay) {
+ CPU_Cycles -= writedelay;
+ CPU_IODelayRemoved+=writedelay;
+ }
+ else CPU_Cycles = 0;

as the CPU_Cycles=0 breaks some games (exiting to the main loop too early).

1inline void IO_USEC_write_delay() {
2	Bitu delaycyc = CPU_CycleMax/IODELAY_WRITE_MICROSk; 
3	if(GCC_UNLIKELY(CPU_Cycles < 3*delaycyc)) delaycyc=0;
4	CPU_Cycles -= delaycyc;
5	CPU_IODelayRemoved += delaycyc;
6}

Oh, it can handle negative cycles? Overlooked that.

This part does

1if(GCC_UNLIKELY(CPU_Cycles < 3*delaycyc)) delaycyc=0; 

Sorry for bumping, but I just wanted to say that I think these patches also fixed Bubble Bobble.

So does that game work in 0.70 or does it require additional stuff?

Bubble Bobble works great in 0.70, I just commented about it for the record 😐

NM...

Patch for Kellogg's game with joystick

They use 0x1 command to latch counter 0. Looks like the 1 should be ignored.

Timer mode 0 reload patch
for the DoWhackaDo demo
In mode 0 the timer does not fire twice when being reloaded before timeout.

Unfortunately the fix cannot really be seen in a normal dosbox 😉

Well I was wrong with the VGA blanking patch. The vertical blanking period doesn't exclude the overscan area.

Scanline.exe is a little tool that counts the lines and reports 400 on a real PC.
In DOSBox it's 415 or so because of the overscan. (In NTVDM on my Notebook it reports 600 😉)

The patch fixes that issue. Improves horizontal scrolling in a demo.

Thank you very much!

And no, there's nothing like a golden medal of diff for the 100th patch 😉 (not yet).

The first two things sound sensible, the 3rd one effectively prolongs the
retrace interval, right?

> And no, there's nothing like a golden medal of diff for the 100th patch Wink (not yet).

No? 😉

Two of those patches are part of the VGA patch which I thought might be useful otherwise too.

The retrace interval length stays the same but the v blanking gets extended by those ~15 lines. This is critical in the panic demo where they do their line-by-line magic but I also noticed the scrolling improvement in some other demo. Maybe some other software is affected too. This way it should also be a bit faster than before.

(I have another one but that only makes the joystick compatible with timed=true and cycles independent in horde, archon ultra and that kelloggs game)

bring it on I would say 😉

Have to put it in shape then. We can't have two write handlers for one I/O-port right?

Missing a few modes but enough for those three games...