Handling external flow control signals

[Deftaudio]

Hi Phil,
thank you for you hard work on inpout32 port and supporting it for years. I understand it's no longer supported. I have a generic question, rather than a bug fix or improvement request, hope, you'll find a moment to reply to this.
There is 30 years code that allows PC to communicate to the specialized music gear over LPT port. The primary reason for that is the interface is 8 bit bidirectional communication with strobe synchronization. I'm just trying to make it to work in one direction. I re-wrote the DOS code for Windows using your library. I'm running it under Win98 and WinXP. The original DOS code relies on ORQ for handling Acknowledgment from the receiver. These are relatively short pulses ~8us. Despite my attempts I have a high rate of missing those confirmations.
Below is the diagram of how it works:
1. PC loads DATA bus
2. PC sends STROBE
3. Receiver reads the DATA bus
4. Receiver sends acknowledgment (called BUSY input on the diagram)
5. Goto 1.

dropbox. /scl/fi/0s8qtl53hugxxz274hp7v/lptcommunication.png?rlkey=x770vbj0tz7cpvko9mkqokju4&dl=0

Obviously, If I miss BUSY input signal from the receiver then I can't proceed to the step 1. I added a timeout window, where I expect that I missed the signal and could continue anyway. It has a hit and miss and is not working reliably.

The LPT port is in the Standard mode. I haven't tried to use ECP or EPP. Do you have any advice of how to implement reliable handling of the input pulses? I understand I might be pushing user mode app for what it's not designed for. I appreciate if you have any ideas. Thank you.

[Deftaudio]

It seems that there is no way to attach or link to a picture. I hope I explained it well, so you don't need it.

[phil]

Pictures, links etc require 5 posts before they are allowed (to try and stump the spam bots).

I'm sorry but I don't think I can help much. The last time I developed software for the parallel (LTP) port myself was probably 30 years ago, very much in DOS, and maybe Windows 95.

I used InpOut32 for serial coms mostly (running at sub-standard baud rates which meant hitting the UART directly). I don't know how you could possibly run that on 98 as its an NT based device model but anyway... But as you state, your running the coms from user mode - so you have no control over when you may or may not be called, its all down to the windows scheduler. I do understand how that can mean completely missing pulse. Realistically for that you need proper interrupt drive stuff (again I'm sure that has to be kernel side) or tight polling where you can guarantee timing (again kernel side is the only way I am aware of).

So, AFAIK, for any real control you will need to write your own device driver that operates in the kernel (or closer to it - maybe in a usermode driver - not sure I've never looked into it). Of course, on Windows that is practically impossible these days for any hobyist like me - the driver signing requirements basically rule it out from the outset (short of running Windows in test mode which is no good in any kind of production environment. You'd be better off looking at other OS's maybe, or in may case, these days for anything hardware related I've personally been using USB devices, RaspPi or Arduino (and that's pretty limited too - only started playing recently and haven't not had the time to get properly into it yet - but you are operating very close to the hardware, particularly in Arduino).

For something like you are describing, it seems to me to make more sense to use a <$20 Arduino micro controller to do the precision timing/interrupt driven hardware interface and convert that to some sort of buffered USB/high speed serial link to talk on the PC side of things maybe - but I have no idea how that might apply in your scenario?!

So I'm afraid I cent really offer anything more on this. Incidentally, if its not clear, I did not write InpOut32, I simply ported (recompiled) it for x64 based Windows. The original author, Logix4U seems to have disappeared from the internet (I guess they are no longer with us, but I don't know that for sure) - I never claimed to fully understand driver development in Windows (I've never actually done it myself, although I know a few people who have). I just know it was a lot easier in DOS/Win9x compared to the locked down kernel environment in NT (particularly post Windows XP).


Regrards,
Phil

[Deftaudio]

Thank you, Phil,
I agree 100% running it on MCU is much simpler than dealing with timing issues on Windows. I wanted to do that in a very old school way but I always have Pico setup ready. Thanks for your help, I just wanted to make sure that I'm not missing anything in the documentation which is made to handle cases like this.