Next up --
The routine to get around the parallel port restriction in Windows has been solved!!
Now to get access to the low memory vectors, specifically the tick timer (int 0x1c) vector Windows restriction.
I want to connect an interrupt.
Any ideas?
ACCESS TO OTHER OPERATIONS DENIED BY WINDOWS
Re: ACCESS TO OTHER OPERATIONS DENIED BY WINDOWS
Sorry, no idea. But t sounds to me like you need to be writing a proper kernel driver, not anything in user space. That's not going to play well with interrupts I suspect!
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
Re: ACCESS TO OTHER OPERATIONS DENIED BY WINDOWS
Also, the IRQ7 interrupt can be generated through the parallel port's ACK status register bit input if it is enabled in the control register.
But without setting the vector to point to my routine, it is a NOP. Nobody uses IRQ7 so messing around with its vector does no harm.
This does work perfectly in MS DOS since the INT21 bios call can give control of the IRQ7 vector.
But, as you say the kernel would be involved.
But without setting the vector to point to my routine, it is a NOP. Nobody uses IRQ7 so messing around with its vector does no harm.
This does work perfectly in MS DOS since the INT21 bios call can give control of the IRQ7 vector.
But, as you say the kernel would be involved.