Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Not MPXplay bug but USB vs. CTmouse problem (Announce)

posted by bretjohn(R) Homepage E-mail, Rio Rancho, NM, 28.07.2016, 17:24

> If BIOS waits for an ATA/USB data, then it can block Mpxplay's soundchip
> polling too, by switching off all interrupts during the r/w process.
> The good question is that, if BIOS doesn't use IRQs, why does it disable
> interrupts while processing?
> But this is just an idea...

The USB BIOS doesn't use IRQ's at all -- it uses System Management Mode (SMM) and the System Management Interrupt (SMI). This is somewhat reminiscent of the Non-Maskable Interrupt (NMI) because it doesn't go through the Programmable Interrupt Controller (PIC), but is even worse (from the perspective of the ability to control it).

SMI has an even higher priority in the hardware than NMI, and puts the CPU into a special mode (SMM) that only the BIOS can control. And, usually, whatever happens in SMM is very slow, so it really screws things up if you're wanting any type of "real-time" response. You really don't want to let the USB BIOS control things if you care about response times.

At least on some CPU's, it is possible to temporarily disable the SMI pin of the CPU so that the USB BIOS won't interrupt anything. I know one user was able to do this because he needed "real-time" responses and the USB BIOS was really screwing him up. I don't know the exact details of what he did (I think it might have been something in the Model Specific Registers, but don't know for sure). I do know he was able to disable the SMI pin when he wanted the USB BIOS to leave him alone.

 

Complete thread:

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