Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

USBDOS | A20-BUG | no need for 1'000'000'000 cores (Miscellaneous)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 20.09.2011, 19:34

> Voila. Problem gone. No need for multi-core "technology" :-)
Problem improved, but not gone. Mode switches are still too slow, IMO. What I'm suggesting only needs two cores, not a billion, and I think could possibly improve mode switching times by a factor of at least 10 (and likely way more than that). It doesn't involve any changes to the single-threaded nature of DOS, either. It just involves modifications to implementations of things like VCPI.

> I don't think so. Huge cost for probably no benefit.
It may not even be possible, or may make things worse instead of better, or may provide no benefit at all. Or it may in fact decrease switching times to virtually zero. You don't know until you actually try, now, do you?

> most PC ... and old KBC (+PIT) ports are HELL SLOW (cca 1000 cycles per
> access) ... not to talk about "wait until KBC ready" loops :-(
The "Fast" A20 switch (Port 92h) seems to be MUCH faster than using the KBC, but is still pretty slow and not universally available. Best not to mess with A20 at all if you can avoid it.

> - Georg's driver has the /R option to completely avoid PCI MMIO and INT $15
> / $87.
It's impossible to avoid PCI MMIO -- that's the only way OHCI and EHCI can work. BTW, one of the first things I tried to do (a long time ago when I first started working on OHCI) was to try and move the MMIO space down into the first 1 MB. I couldn't get it to work on my test system at the time, so abandoned the idea.

MMIO is also HORRIBLY inefficient from a memory resource perspective, so moving it down into the first MB is not desirable. As a comparison, each UHCI controller reserves 32 bytes of PIO space, and only in fact uses 17 of those bytes. OHCI and EHCI use MMIO, and MMIO must be allocated in multiples of 4k memory pages, even if only a few bytes are actually used. Unnecessarily allocating 4k memory pages out of the first MB is not a good use of limited resources.

I may re-visit this again later, though, as a way to speed things up.

> - Try to ignore A20 and access addresses with a20 line ZERO (sufficient?).
Have you experimented with this? It seems to be that A20 really affects A20+, not just A20. Moving MMIO space around after the BIOS has already configured (if that's required to align it properly) is not very practical, for a number of reasons.

> - Execute SMSW, if V86, then INT $15 / $87, if RM, then INC CR0 -
> completely avoid BIOS.
That's what HIMEMX does, and what I do now, since I know now that I can't trust the BIOS. That doesn't eliminate the A20 issue, though.

> - Ensure A20-line is always ON while your driver is active (how?).
Best you can do is turn it back on when you see it turned off. Anyway, I think the only programs that would even try to turn it off would be Memory Managers / Kernels that work like Tom is suggesting (Disable on an INT 21h EXEC and Enable on any other INT 21h), or a buggy BIOS (INT 15.87 or similar).

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 216 users online (0 registered, 216 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum