Reply 20 of 71, by h-a-l-9000
~1 microsecond for reads and ~0.75 microseconds for write is used on that 386sx. That's how long the processor is told to wait (scope on ready# pin).
1+1=10
~1 microsecond for reads and ~0.75 microseconds for write is used on that 386sx. That's how long the processor is told to wait (scope on ready# pin).
1+1=10
h-a-l-9000,
Glad you used a scope. The Linux folk have been all over the OUT 80, AL delay considerations for their boot process. Given that the IO delay seems to be bus and not CPU related - should this make coding changes to DOSBOX a bit easier? The other consideration about IO port write delay is that crossing a PCI/ISA bridge seems to take the delay time from ~700 nano-seconds to around ~1000 nano-seconds. Go much above ~1100 nano-seconds and that delay might be a bit too long...
Just my 2 cents,
dvwjr
Edit: typed too fast: corrected milli- to nano- prefix 😊
> Edit: typed too fast: corrected milli- to nano- prefix
Yea, not even most relais computers should have been that slow 😉
> Given that the IO delay seems to be bus and not CPU related - should this make coding changes to DOSBOX a bit easier?
That's what my patch is supposed to do.
The delay also depends on the ISA bus clock frequency and I/O read/write wait states (some BIOSes have those settings).
I think we can leave PCI-bridges out of this as DOSBox does not have it.
does the io delay patch have those new delays ?
I recal something of 1.85 somewhere
Water flows down the stream
How to ask questions the smart way!
Updated iodelay patch. Don't delay pmode exceptions, differ between reads and writes.
read 1.0 write 0.75: Prince doesn't detect sound properly even at 9000 cycles
read 1.2 write 0.9: Prince more often detects soundblaster (it's not the synth detection that fails here) even at 50000 cycles.
What's the loop looking like for prince? I think i wrote somewhere
about how many loops different games use during detection code,
don't know where that was.
Do the 1.0/0.75 values work rather fine with the default 3000 cycles?
You wrote about it in the buggy programs forum.
Prince of Persia 1: tests if adlib responds within 40 executions of a tiny loop, obviously this won't work on fast PCs including […]
Prince of Persia 1:
tests if adlib responds within 40 executions of a tiny loop,
obviously this won't work on fast PCs including dosbox with
high cycle settings
Though on the Celeron 300 it uses the sound card successfully, even with "8-bit I/O recovery time" (BIOS) set to lowest.
I never saw the loop myself since disassembling is the last resort to me 😉.
On 3000 cycles it's detected even with 1 / 0.75 timing.
Ok this might make up good values then for other stuff, too, or do you
think it's just too low? As it matches the values you figured from some pc.
commited iodelay with 1.0 0.75
commited timer synching as well
Water flows down the stream
How to ask questions the smart way!
wrote:This is the first of three patches needed to make Archon Ultra and The Horde run kind of bullet-proof in DOSBox.
It took me some time to think about how to express what I am feeling right now. Eventually I decided that a phrase I once read in another forum will fit perfectly, so, here it is:
U R Gawd!!!11!<shift+1>!!1!!one!!!
I see my vga blanking ideas were merged into CVS.
One little bug though:
vga.draw.delay.parts is never initialized. Causes some un-beautifulness here and there.
Something that was not in my patch:
Epic Pinball needs the parts to be drawn later - should be ok (and sounds sane to me) if we draw the parts after the "crt beam" passed over them. That gives Pinball time to complete drawing the text GFX and ball.
//VGA_DrawPart( vga.draw.parts_lines );
PIC_AddEvent(VGA_DrawPart,vga.draw.delay.parts,vga.draw.parts_lines);
added both to beta3
Water flows down the stream
How to ask questions the smart way!
the delayed writing seems to cause graphics problems in darklands
Water flows down the stream
How to ask questions the smart way!
Displaying a corrupted frame with vertical lines?
For me it also happens with the iodelay functions commented out.
1+1=10
//VGA_DrawPart( vga.draw.parts_lines );
PIC_AddEvent(VGA_DrawPart,vga.draw.delay.parts,vga.draw.parts_lines);
That part
Water flows down the stream
How to ask questions the smart way!
Hmm in CVS for me all 3 variants cause corruption. The test build I linked to in this thread however doesn't.
1+1=10
Could it somehow be that the maximal limit of reduced cycles
is 0x40 or that some ports don't have long delays for accesses
(dma port reads)?
It could very well be that the system components (irq, dma, timer, ...) are connected to a faster bus. The timings I posted here are for the ISA bus.
1+1=10
Anybody know something about that?
@hal: could you see if it's possible to modify your test program to
measure the delay introduced by reading port 0x03 (dma transfer
counter for channel1), maybe during sb activity or so?
This probably depends on the mainboard chips very much...
I'll try to have a look at the timing. Don't expect me to add DMA activity though 😉. A DMA transfer uses a few cycles while the CPU is halted.
1+1=10