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 DOS386, 20.09.2011, 09:10

> I did some experimenting today on one of my computers, and it
> looks like toggling the A20 line is the sole culprit.
Voila. Problem gone. No need for multi-core "technology" :-)

> statements that vary from (paraphrasing), "There are a lot of programs that depend
> on A20 being disabled so you shouldn't EVER leave it enabled,"
No right to exist for those. ;-)

> "There are only a few poorly written 8086-era programs that depend on A20 being
> disabled, and nobody uses them any more."
Right.

> but just wondered what others feel/know about the real situation
See above.

> I guess that the best choice is a standarised DPMI 1.1 Multi-cores, Multi-thread extension
Right. Considering that not a single useful DOS standard has been established during last 20 years. Whenever the need for a standard is mentioned in some forum, people start digging inside >= 20 years old problems private to Macro$oft and soon also making exciting "discoveries" :clap:

> > > I think that A20 is fiddled only when acessing HMA so it's useless for
> > > reaching MMIO at higher address.
> wrong. A20 must be fiddled with for every access above 1M.
Are you sure ??? Are all lines >= A20 disabled or only A20 ??? Because if only A20 is dead, then you can perfectly use PM and access MMIO ... as long as you access only addresses having the a20 bit ZERO. This should be true even for a VESA LFB 640x480x24bpp, as the VESA LFB is always aligned to an integer multiple of 64 MiB and for this mode smaller than 1 MiB. This should be also possible for OHCI/EHCI, assuming the MMIO size is below 1 MiB and also sufficiently aligned (2 MiB at least). Untested.

> BUT early versions of Microsoft LINK /EXEPACK and early versions of PKLITE
> (pre 1991) had a bug, and relied on A20 being disabled.
:confused:

> and my HIMEM's behaviour was 'enable A20 and leave it in this state'.
:-)

> I still think the possibility of using a second core to make the mode switches faster
I don't think so. Huge cost for probably no benefit. And I ASS'ume the A20-BUG affects both cores the same way ?

> changing system state at some randowm interrupt time might be one of the worst
> ideas in operating system design ever - even worse then 'my driver needs a second core'
Really ??? AFAIK mode switches inside IRQ are a "standard" DPMI aproach. NOT amused, either.

> now randomly enabling A20 at some randowm interrupt time removes the predictability
Leave A20-line ON and A20-BUG OFF, point.

> If I remember well A20 was controlled via KBC chip through some IO port on old PC
most PC ... and old KBC (+PIT) ports are HELL SLOW (cca 1000 cycles per access) ... not to talk about "wait until KBC ready" loops :-(

Solution ideas:

- Georg's driver has the /R option to completely avoid PCI MMIO and INT $15 / $87.

- Try to ignore A20 and access addresses with a20 line ZERO (sufficient?).

- Execute SMSW, if V86, then INT $15 / $87, if RM, then INC CR0 - completely avoid BIOS.

- Ensure A20-line is always ON while your driver is active (how?).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Post reply
 

Complete thread:

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