Highrez

In my MATLAB thread on this forum I noted that I have found that both inpout32 and inpoutx64 work quite well with SOME PCI printer port cards (contrary to reports on this forum and at logix4U).
Here's the story in a nutshell. MOST of the PCI, PCMCIA, ExpressCard and Cardslot add-on peripherals that implement printer ports (i.e., LPT1, etc.) use a USB chipset that emulated the printer port via a complex serial driver that cannot be used to implement real-time digital I/O. These are the cards that are not useful with inpout32 and inpoutx64. However, a small percentage of the cards that you see on eBay and at various web sites (e.g., the SYBA SD-EXP50021 Expresscard with parallel port and 2 serial ports) support TRUE PARALLEL PORT interfaces that can be used successfully with inpout32 and inpoutx64. I have used various PCI add-on cards and Expresscard add-ons successfully under 32-bit Windows 2000, XP and Vista and most recently on 64-bit Windows 7. Look for a card that implements the interface using either the MOSCHIP MCS9901 chip (1 parallel port, 2 com ports) or the MCS9805 (1 parallel port). Sometimes these chips are listed as NETMOS instead of MOSCHIP...
Good luck with your interfacing exploits...and many thanks to Phil and Logix4U for making the inpout322 and inpoutx64 device drivers available to the world!!!

Hey Moundtop!

I was wondering what version of inpout32 you used for your tests. Since I didn't manage to get it to work with a MCS9805 pci parallel port card. I would be glad for some code as well. The pci card has a port address of 0x1110.

Likewise, it might be useful to specify what version of InpOut32 and what OS you are using?
(I dont know the answer to your question, but I imagine at least v1.3.0.0 of my port if it was working on Windows 7!)

Thanks,
Phil

I'm running on a Windows 7 (32bit). The problem is that I'm using a JAVA JNI Port (Jnpout32pkg_v10.zip) which can be found here (http://www.hytherion.com/beattidp/comput/pport.htm) and I'm not sure what version has been used in this port.

If anyone has successfully used the InpOut32 or maybe even your port to 64bit with Java, it would be great if the person could share the code.

OK that is looking rather old - so its almost certain it wont be using my port. The orriginal InpOut32 should work on 32bit Windows 7 but there are potentially all sorts of UAC admin issues. The driver must be installed with Admin rights - I accomplish this using an elevated installer EXE but that wont work with the old inpout32 DLL (or driver).

Could you try running your java app as administrator (or an account in the local administrators group) to see if it makes any difference?

I don't know of anyone else using this through Java so I cant really suggest much more. Sorry about that!
It might be a good idea to try my port and test code (.net ideally) to see if you can actually use the PCI card - because right now, with this JAVA bit also, there are perhaps more unknowns in the mix which could be making life more difficult. The test app should be sufficient to see if you can write to the address of the parallel port (and if you can monitor the outputs on the port to be sure - even better).

Thanks,
Phil

Thanks for the hint there ...actually I was able to run my Java code (webstart) as an administrator and it worked!!!! So it's actually possible with inpout32.dll!

Well done. Don't expect the orriginal InpOut32.dll to work on an x64 machine though

I'd like to share with you my experience with a PCI parallel port. On my application I've had no issues with onboard ports. I basically am just using Inp32() and Out32().

With the PCI version, the address the port took up was E000-E007 instead of the normal 0378-037F. And when I tried passing the E00X address to Out32 it would give me an arithmatic error. I am using VB.NET 2005. The problem is E000 needs an unsigned short, not a short. And that is the parameter for the port address. I was able to get it to work by downloading the source, changing the parameter to an unsigned short and re-compiling inpout32.dll. I dont know why it was giving me an error passing an unsigned short to a short since they occupy the same amount of space but it was.

Overall, it might be nice if for future versions you change port address from a short to unsigned short to allow for those higher addressed PCI cards. Just wanted to provide some feedback for you and anyone else having similar issues. Great DLL, its pretty ridiculous Microsoft neglected to put any parallel port support in .NET, but I suppose it is a dinosaur now days.

Thanks for the info.

Are the DLPortIO functions I added not working in this area - or do they suffer the same problem I wonder.

As you are probably aware, I didn't write the code, I just ported the driver to x64 and added a few extra calls (that I never properly tested!). I'm glad you managed to get it working, but one worry I would have changing the interface, it could break any application already using it. So I think it would be better to introduce new functions with the correct DLL interface.

Thanks,
Phil

but one worry I would have changing the interface, it could break any application already using it. So I think it would be better to introduce new functions with the correct DLL interface.

True. Only copying Out32 to Out32_2 with the same body but an unsigned address parameter would help a lot. However, I presume the driver has to have the same function overloaded to?

No the driver does not have any of these function overloads. The drive is controlled by IOCTL's I think - the code is all there for anyone to see/change and the dll can be changed/fixed as much as anyone wants (as you have already done!) without having to re-sign the driver (that is where it gets sticky - even I cant do that!).

To be honest, while I'm happy to keep hosting the files and to some extent this forum, I have no use for Inpout32 these days so I'm not exactly keen to keep making changes to something that is a) not mine in the first place, b) open source, c) not something I actually use any-more.

Ideally Logix4U would have gotten their heads round x64 by now and this port could be retired or at least updated and hosted by them, but I guess that they are in a similar position and don't want to support legacy stuff like this (I can only presume that by their general lack of comment/communication on their web site).

Having said that, I will every now and then go on an update splurge with these things. I suppose its handy to have somewhere these things are all consolidated (and where people can actually talk about them and get a response, even if its not from the authors lol).

Thanks,
Phil

Weel, I decided to try the hard way and make the fix myself, even though as an objectPascal regular, for me it's a long time no C...

The way I see it, the exported function could easily be doubled with an unsigned pendant:
The original out32 relays either to _outp, which already takes an unsigned short for the address, or is transfered by LOWORD to Buffer, which in tur also is of (unsigned short *). Therefore, the modification may be linited to
The new Out32u needs be exported, of course. I even think that it wouldn't break existing code if one would just change out32() to the unsigned form, but I'd rather avoid guessing that.
Given that the adddress cannot possibly be negative, and seeing the iplementation, I think the signed form is but a historic mistake.

I cannot test it right now, and I don't know whether this is my only problem, but possibly later this week I can tell more.

Thanks Wim,

I'm not sure I understand why you have a problem with the signed short, at the end of the day its just 2 bytes. I guess it does depend on the code in the DLL and its been years since I looked, but your right, there should not be a bug difference.

The only obvious problem I can think of is if somewhere it gets stored in a larger (or smaller) structure i.e. cast to an 32bit INT (or maybe a 64bit one ). That would cause havoc - maybe that's the problem!

Anyway let me know what your find.

Thanks,
Phil

Well, I am not a C-man, so perhaps I am reading the code wrong. But it seems to me that both calls are by value. That would mean that with addresses upto 7EEE there's no problem, for they can be represented both by signed and unsigned two-byte integers. Higher address values, such as my CD00, are interpreted by the functions expecting a signed short as negative numbers. So my CD00 (56320) is taken for a -9216. When this value in turn is assigned to any unsigned variable, the code ought to raise a range check/integer underflow-error. Or does C just shift the 16 bits ? In programming languages I am familiar with I'd need a pointer operation for that.

Well, that seems to work! The motor is running now. Apparently I don't understand the role of the sys driver files. I have a 32bit application running on XP64 (AMD). According to dbgView it's loading the x64 driver. But it doesn't work until both files have been copied tot system32\drivers.

I think other people here will be helped if you'd take over my suggestion into the official inpout-dll?