VOGONS

Common searches


Timing patches

Topic actions

Reply 21 of 71, by dvwjr

User metadata
Rank Member
Rank
Member

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 😊

Reply 22 of 71, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Reply 23 of 71, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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!

Reply 24 of 71, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Attachments

  • Filename
    iodelay2.diff
    File size
    2.52 KiB
    Downloads
    47 downloads
    File license
    Fair use/fair dealing exception

Reply 25 of 71, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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?

Reply 26 of 71, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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 […]
Show full quote

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.

Reply 29 of 71, by Og

User metadata
Rank Member
Rank
Member
h-a-l-9000 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!!!

Reply 30 of 71, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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);

Reply 34 of 71, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author
//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!

Reply 38 of 71, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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?

Reply 39 of 71, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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