Dear gentlemen, this is my second attempt to post this. I had to remove ZIP attachments. Turned them into URL's. ---
On 3 Feb 2022 at 16:38, Bret Johnson wrote: > In the traditional PC architecture, there are only 16 IRQs (0-15) > managed by two Programmable Interrupt Controllers (PICs). Intel > developed APIC (Advanced Programmable Interrupt Controller) in the > Pentium/multi-processor era (many years ago), mostly to to address the > requirements of multi-processor systems. But, APIC also allows you to > have more than 16 IRQs in single-processor systems. > > APIC requires support both in the hardware/BIOS and in the > OS/application. I've never seen any sort of DOS implementation that > supports APIC, but there may be something out there somewhere. I > think what you're trying to do might be possible (assuming you have > the correct hardware and BIOS support), but is going to be very > complicated and you're probably going to need to implement it > yourself. > I'd say that you do not need to deal with IRQ routing through the APIC's and serving IRQ's higher than #15. You do need to talk to the PCI BIOS (int 0x1A) to find your device on the bus and inquire its PCI config space about: - the port IO space occupied - the IOMEM space occupied - the IRQ allocated. Yes, if I understand things correctly, your PCI(-e) board does have a legacy IRQ# <16 allocated by the BIOS during post, and chances are, that if you hook that IRQ number learned from the PCI config space, you'll start getting IRQ events. Note that PCI IRQ's are level-triggered, for easier sharing. (Your IRQ line will likely be shared by several devices.) Which makes me believe that you do not need to ACK the interrupts to the old AT-PIC. Instead, try just satisfying all the interrupt sources in your UART or PCI board - if you succeed, the IRQ line gets de-asserted, and your ISR simply won't get re-invoked again right away. If there's another device with an IRQ source firing on that shared IRQ line, and you haven't handled that one already, your ISR will get called again. In Linux (not sure about Windows) this is used by the OS: the OS has a "super-ISR" per IRQ line, and as a driver writer, you register your HW-specific ISR with the OS, and the OS calls all the specific registered ISR's for that shared line in a sequence, maybe checking for their return values if that matters to the OS. In DOS, you're on your own. If you want to be polite, and expect other people's TSR's to share that IRQ, perhaps you can call the "downstream" ISR vector that you've backed up when hooking the IRQ yourself... You'll probably find a pretty good datasheet for the PCI UART chip on your addon board. And/or a Linux driver. If some snippets of information are missing in the puzzle (the docs are sketchy), with simple peripherals you can often get further by looking at the BAR's (in Linux using lspci -vvn without even programming) and then you can try poking some of the BAR's to see if you get the expected responses. A 16C550 backwards-compatible UART is no rocket science, and you don't need an IRQ to provoke some activity to the outside world. Port IO is easy - you get the base and range from the respective BAR, and you can start poking. Now if the chip's registers are memory-mapped, that's potentially hard cheese. To access memory-mapped registers in a PCI device, you need to perform an "ioremap" operation (maybe you can do without it in unreal mode) and the physical and remapped addresses are not likely in the DOS conventional memory under 1 MB = you need an OS service to do the 32bit memory management for you. In Linux and Windows this is a boring basic service of the kernel. In DOS, you need DPMI, and you probably need to compile your whole project as a 32bit application (not sure). In DOS, I can possibly suggest the DJGPP (GCC) + NASM, as an environment that I've met before and maybe done some stuff in... Not sure if Japheth is reading this mailing list, but there are other people who can certainly fill in my blanks on this :-) The PCI BIOS stuff still takes some coding and wrapping to be comfortable to use. In my archive, I've found some internal toy "projects" of mine, where such wrappers can be obtained. I'm including two ZIP files - refused by the list server, get them here: http://support.fccps.cz/download/adv/frr/smi.zip http://support.fccps.cz/download/adv/frr/pci-1716.zip The first one is heavily C-centric, including the BIOS calls (software interrupt 0x1A). The other one is Pascal-centric, and the PCI manipulation "unit" is a combination of nasm implementation with a Pascal source wrapper providing a Borland Pascal "interface". Namely, to get you inspired, check the PCI-related header file and look for macros PCI_CS_INTERRUPT_LINE PCI_CS_INTERRUPT_PIN They're offsets in the per-device window of PCI config space. You have mentioned Linux... in modern Linux, you'll see your IRQ mapped to some high number (or even an MSI, if yours is a PCI-e board) but if you tell the kernel something like "nomsi noapic", you might as well end up with the IRQ's numbered and shared the way you should expect in DOS. With a bit of success, the machine will still be able to boot :-) allowing you to check out lspci -vvn and /proc/interrupts. If you're willing to try, this should get you a few yards down the road. Should give you access to the PCI stuff in DOS, especially IO ports and hopefully the IRQ as well. The bulk of the PCI-related code is not actually mine. Let me quote from my source files: " CREDITS: The original material was downloaded from the "DJGPP mine" page. http://www.mygale.org/03/mine/ -- now probably long defunct. There's not a hint of the original AUTHOR or LICENSE. Some parts are explicitly labeled as "Copyright (c) by Kimmo Kuusilinna, 1997." " A neat wikipedia article on the PCI config space: https://en.wikipedia.org/wiki/PCI_configuration_space#Standardized_reg isters Vaguely related further reading, written by me (= cheesy self-promotion): http://support.fccps.cz/download/adv/frr/PCI104/PCI104_case.html https://electronics.stackexchange.com/questions/76867/ I haven't really seen it all before. Just a snippet. That might just as well get you on the right track. Questions welcome... Hmm... did you just say that your software can run in Linux too? In that case, why bother to write drivers for DOS ? New hardware for Linux is probably much cheaper than your time! :-) Frank
WPM$5ZWF.PM$
Description: Mail message body
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
