Device Driver for LPT1

I have written a delphi code to access my parallel port. However, I could only get 200K bytes per second from my CCD camera. Will a device driver speed things up? The QuickCam camera seems to be doing at least 600K bytes per second.

If a device driver is the way to go, how hard is it to write one for my application? Can I convert my ASM code to a VxD code?

Kind Regards
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

If you aren't running it on win95, I don't know, but I have done some experiments on '95. (My app was a portable IDE drive).

The parallel port is one of the least-protected hardware devices in '95. No traps are generated when writing directly to the port.
My experiment, performed before writing this:
win95: REP OUTSB to the port:  820-1060KB/S, depending on ISA clock. Same result in clean DOS.
IF you are using the port in EPP mode, be aware that an external wait/busy signal is fed back into the port from the CCD control logic, and thus has control over the maximum data rate. (What mode ARE you running? SPP/bidirectional, EPP or ECP?)

From your 200K data rate, it sounds as if you are manging the
strobes manually, so that your code looks like this:
  Strobe high
  Strobe Low
  Get Data
Or, if the port isn't configured as bidirectional, you may be reading 4-bit chunks, dropping the data rate further.
On a PC with a fast ISA clock, the approximate-upper-limits
for data rate are (when using two clock edges pr. cycle):
STD. unidirectional, 4 bit readback: 200KB/S
PS/2 bidirectional, 8 bit readback: 400KB/S
EPP bidirectional, 8 bit, immediate acknowledge: 1MB/S
ECP parallel: ? 1MB/S (not personally tested)

Probably your CCD driver uses EPP access. If you aren't, get IBM technical reference and do so also. If you need to use ECP mode, THEN you need to write a VxD. Porting ASM is not difficult if you can find a skeleton.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
keithcslAuthor Commented:
I am running in Win95. And yes, you are right, the slow rate of data transfer is because of manual strobes:
Strobe high
Strobe low
Read Data

and the configuration is bi-directional mode, 8 bit.

According to you answer, I can use the EPP bidirectional, 8 bit immediate acknowledge with a transfer rate of 1M/S. I would like to use this mode on my CCD camera. Are the pin configurations for EPP the same as for the bi-directional pin config? Can I use my same instructions to get the data?

And no, my CCD camera does not have a driver. I have to communicate with it directly. The protocol to access the data is as described above,
Strobe high
Strobe low
Read Data

The CCD has a DSP to transmit data at a very very fast rate. i am writing the DSP code to transmit/receive data to/from the PC. This means that I have total control over the CCD camera to do what I want. If the EPP mode is different from the bi-directional mode, this means that I have to change the protocol in the DSP to suit the EPP mode. Do you know the difference between the 2 modes?

The only problem is the PC is too slow to get the data (in bi-directional mode). I think if I use the EPP mode, I should be able to get data at a much better rate.

OK, where should I go from here? Do I still need to write a device driver? Currently,
- data is accessed from the port directly in Delphi.
- the port is configured in bi-directional mode
- data rate of 200K/S

Ideally, I would still like to use my Delphi code to read/write to the CCD, but at a faster rate. What do I have to change in order to operate in the EPP mode?
No problem! My EPP knowledge comes from the IEEE P1284/D2 september 1993 unapproved draft marked DS02709, but to my experience it is valid.

I'll try to explain how it works:
In EPP mode the port works like a bus port. it has two adresses, we'll name then DATA (base+3) and ADDR (base+4).
The physical pins are named nWrite (1), d0..d7 (2..9), Intr (10), nWait (11), nDstrb (14), nAstrb(17).

First, set all outputs (nWrite, nDstrb, nAstrb) high (electrically high measured at the physical pin). The DSP should respond with a low->nWait. This is the idle state.

Second, do a read of address [data]. nDstrb will go 0, and d0..d7 will go high impedance (simultaneously). Your DSP drives d0..d7, and responds high->nWait, WITHIN 10 uS of nDstrb-Low-edge. The data-setup-time-to-nWait-high is 0. The EPP will remove nAstrb, indicating that data has been fetched. (At this point, the ISA bus becomes 'ready' and data is returned to the x86) Your DSP floats its d0..d7 outputs and responds with low-nWait WITHIN 125* nS. (*My experience with my clone ports here is that the timing constraint is 10uS, meaning that the EPP also waits for nWait going active again. This makes sense, but I can't check it in the new spec before monday.)
The 10uS is a timer on the EPP which aborts 'never-ending-cycles', so that you can't hang the PC this way.

If the address used was ADDR instead, nAdstrb would have been set low instead.
If you WRITE to these two addresses, it will look like a read cycle, but data will be driven by the PC while nA/Dstrb is low, and the nWrite signal will be low from start (falling edge of nA/Dstrb) to finish (falling edge of nWait). Draw it on paper!

One last thing: Your DSP program should terminate a read if the EPP doesn't respond in 1 Sec (yes,10^6 uS!). This 1S comes from the spec. Otherwise a continous collision would occur, frying the weak end of the data bus. Also, BEWARE of capacitive wire-to-wire  capacitive coupling - use a 34 wire flat cable and 'fan' the cable at the PC connector. Otherwise you'll get bugged by glitches (I DID!).

Your delphi transfer code in asm will look like this:

MOV DX,portbase
ADD DX,3         //get to data port
MOV EDI, bufferpointer
MOV ECX, buffersize_in_byte
REP INSB         //get busy!

No manual strobes. Just speed. REP INSB does it all. And there's no reason to go VxD yet.
keithcslAuthor Commented:
Thank you very much kkp. I feel very excited about using this EPP protocol. I have finished testing and debugging my bi-directional program and sadly, it could only run at a maximum rate of 2.6 frames per second. Very slow. If I follow according to your advise, I should be reaching near 15 frames per second!! I will start coding the software immediately.

Oh yes, I was wondering if I could reach you by e-mail if I bump into any problems with the EPP protocol. If possible, just mail me at:

If, not just tell me how I can contact you. Once again, thanks a million...

Kind Regards,
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.