From a previous post, I mentioned WinIo as a nice way of accessing the parallel port from win2k. However, it was slow. The authors said, “I should be using MapPhystoLin() anyways”, whenever I asked about performance. Hell if I can figure out htf I’m supposed to use it — it’s not clear to me.
So, instead of banging my head against the wall, I’m going to switch to another solution, one that appears to be pretty popular as well.
inpout32.dll is a simple DLL that contains two functions for reading and writing the parallel port. You can find download and find docs here
One note: under Visual Studio .net, you’ll need to remove a portion of two lines, basically deleting “_stdcall” — otherwise you’ll get an error, and it won’t compile.
The correct lines are :
typedef short (*inpfuncPtr)(short portaddr);
typedef void (*oupfuncPtr)(short portaddr, short datum);
(before they read typedef short _stdcall, and typedef void _stdcall) — Basically yank out _stdcall and you’ll be fine.
You’ll find this at the top of test.c in the distribution zip.
In previous posts, I mentioned that to transfer a full byte of data takes 12us, where it takes normally 16us to actually obtain the data from the drive. This is too close for comfort, and so you can also read back where I added a FIFO buffer to the SX code. In any event, 8.25us of the 12us, some 70% of the time is:
8.25us for the PC to grab the byte(store it to the harddrive, right now anyways) and raise pin 1
I think this is entirely too long. Now, new versions of my code put the received data into RAM just in case the HD takes a long time. Remember, my HD’s have cache, and they are cached by the OS too — so writing to HD isn’t as bad as it sounds.
Anyways, if I get the entire full cycle down to 8us or less, I’d be thrilled. I really hope the performance of inpout32.dll will help here.