I don't know how much you're willing to rewrite your program, or how much you're willing to make fundamental changes to how it works since it may corrupt what you've already done, but this solution may be worth a shot. I'm doing something similar in some of my other programs (not related to serial ports). This is sort of a variation of what Eric suggested earlier in the thread, but instead of constant polling it is still interrupt driven so it does not consume the entire CPU like a constant polling loop would do.
Instead of relying on the normal serial port IRQs, just disable those IRQs altogether. Instead, setup and use INT 70h/IRQ 8 to generate IRQ's at 1024 Hz (you can even set them up to go faster or slower than 1024 Hz, but that may not be necessary). When you receive the IRQ, gather ALL the data from ALL the I/O ports you care about (all the serial ports). Particularly if your serial ports are the newer ones that have some sort of internal buffer (more than one byte like the original serial ports had) I don't think you'd ever miss any data. To speed up the processing even more, instead of completely processing the data as soon as you received it you could just store the data received in some sort of buffer and process it outside of the IRQ handler (or at least after you had issued the End-Of-Interrupt for IRQ 8 so you're not "hanging" the machine). That would avoid all the issues with APIC and/or PCI programming, IRQ sharing (at least on the serial ports, but you will still potentially need to share IRQ 8 which is one reason why you shouldn't change the frequency from the default of 1024 Hz), etc. As long as all the serial ports use "regular" I/O ports (PIO) instead of MMIO you shouldn't have any issues getting the data. But, there are ways to get the data from MMIO without using DPMI if that is required. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
