Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Using Multiple CPU Cores in DOS? (Miscellaneous)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 19.09.2011, 23:19

> wrong. A20 will be enabled almost always, and only a few microseconds after
> program has started; you won't notice a difference
IRQ's don't stop just because a "real" program starts running. Unless I'm missing something, it doesn't make sense to have IRQ's execute quickly at a command prompt and slowly while a program is running. At least that seems to me to be what you're suggesting.

> 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'
That's not what I'm suggesting. I'm saying to leave A20 on all the time in case background processes (TSR's and Device Drivers) need access to extended memory (not necessarily XMS memory). I think what you're saying is to leave A20 disabled while the system is not at a command prompt, and for TSR's that need it to be turned on to repeatedly (and slowly) toggle it on and off while processing their IRQ's when a "real" program is running.

> have a user selectable option to do it the fast way
I think the default should be the fast way, since almost nobody needs it to be the slow way.

> now randomly enabling A20 at some randowm interrupt time removes the
> predictability (of failure), and instead introduces the feature 'works most
> of the time'
Again, that's not what I'm suggesting -- though it seems to be what you're suggesting. We're apparently not communicating very effectively.

> as said above, mode switches are a few hundred thousands per second.
It could be, but I still think it might be possible to improve it considerably.

> do you really need an entire core for this USB driver ?
> one core exactly and only for your driver ?
No, that's not what I'm suggesting at all.

> or do you intend to run a real operating system on the second core, with
> an API how multiple drivers can share this core, how they synchronize with
> the real mode part, ...
I wasn't making myself clear. I was thinking of something like implementing this with INT 15.89 and/or VCPI, which would in turn affect DPMI, DPMS, and other "high level" environments that rely on those services for PM. I think this could be done transparently so that the "high level" environments wouldn't even need to know which core they were running on -- everything would (at least hopefully) just be faster. This wouldn't benefit programs that manipulate CR0 themselves.

Post reply
 

Complete thread:

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