This is a good tutorial about interfacing with the parallel port; more importantly reading from the port. Other articles I've seen only show how to write to the port. Before I get ahead of myself, the parallel port I used is an ECP (

• Inpout32 Dll Serial Port Example Key
• Inpout32.dll C#

Click to expand.lol you probobly don't know/rember but I had a Z80 project log going and apeared to go inactive on it. In reality I just got very very slow at it due to my primary A lvl electronics project taking up all my spare time. My A level electronics project was pretty amazing for an A level project, when I started out I didn't rearly intend somthing so nuts but it jsut turned out that way as I was rather unrestricted in what I could do and wanted to try out all kinds of things. I basicly ended up with a home made delta sigma modulator recording audio as a bitstream onto aload of old static rams with a PIC running the whole show. It has a recording time of aproximatly 24s on 512KB of ram and pretty good performance considering the ADC is just opamps and D type flipflops (the music is legible although definatly not hi-fi (or even AM radio)).

I didn't have much time to do mesurments but I got a THD to the 5th harmonic of 0.05% with pretyt much white noise at aprox -20dB.I don't have any pics because of disk problems but there is one at collage I will upload on monday to show people, it looks like a mad splurge. Along the way I ended up messing around with old computer SIMM's which with moden static rams of larger size avaialbe at faster speeds are just pointless interfacing nightmares (I actualy got one working but micro controller wasn't fast enough to provide ADC clocks and shift data around aswell as controll the ram).Anyway on the Z80 project front I actualy built a computer that has an 8bit input and output and have worked out how the graphics and keyboard interfaces will work.

Unfortunatly my methord of programing the EEPROM with dip switches is seriously flawed and I fidn it hard to enter more than single instruction programs. So I'm buildng an EEPROM programer that is going to read a binary file and burn my fat parallel EEPROMs that don't fit in my pic programer (which takes itty bitty I2C EEPROMs).

Inpout32 Dll Serial Port Example Key

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!!!

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. 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. No the driver does not have any of these function overloads. 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 ).

Inpout32.dll C#

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.