"Bidirectional" bit (bit 5) in control register.

This is done by writing 32 to control

register. The command "partest1 write 890 32" will do this. After entering this
command you can read the status of switches in the hardware using the
command "partest1 read 888"

Want to know more about parallel port..?, get this book

NOTE: This sample program will not work on Windows NT/2000 or XP if you run
the program on these machines , it will show an error. use new Inpout32.dll on
NT/2000/XP machines

Inpout32.dll for WIN NT/2000/XP

The Problem
Writing programs to talk with parallel port was pretty easy in old DOS days and in
Win95/98 too. We can use Inporb and outportb or _inp() or _Outp functions in our program without
any problem if we are running the program on Dos or WIN95/98. But entering to the new era of
NT clone operating systems like WIN NT4, WIN2000, WINXP, all this simplicity goes away. Being
interested in Parallel port interfacing and programming you might have experienced the problems
in writing a program that can talk to parallel port successfully in NT based operating systems.
When we are trying to run a program which is written using the the conventional software
functions like Inporb, outportb, _inp() or _Outp on a WINNT or WIN2000 system, it will show an
error message that "The exception privileged instruction occurred in the application at location
....". The picture of such a messagebox is given below.

Staring to this messagebox, you might have been thinking that "did i make a mistake in
my program ?" it is working fine on WIN98 ... Who is guilty here. 'Nobody' that is the answer. Then
why it is happening like this ..? The answer is in the next paragraph

Being a very secure operating system, Windows NT assigns some privileges and
restrictions to different types of programs running on it.It classifies all the programs in to two
categories , User mode and Kernel mode ie; running in ring3 and ring0 modes. user mode
programs are running in ring3 mode and Kernel mode programs are running in ring0 mode. The
programs you generally write falls in the user mode category. The user mode programs are
restricted to use certain instructions like IN, OUT etc.. Whenever the operating system find that a
user mode program is trying to execute such instructions , the operating system stops execution
of those programs and will display an error message. Eventually our interfacing programs stops
where they are executing IN or OUT instructions to read or write data to parallel port. But in the
same time Kernel mode programs are in no way restricted in executing such instructions. Device
drivers are capable of running in kernel mode. So the workaround for the above stated problem is
to write a kernel mode driver capable of reading and writing data to parallel port and let the user
mode program to communicate with it. Writing a driver is not an easy job for even experienced
programmers. But writing a simple driver for communicating with parallel port is a simple task
when drivers like USB, sound card etc.. are concerned. Even though you get a working driver
from somewhere else, installing and configuring it can be very cumbersome task.

The Solution
Introducing Inpout32.dll for WIN 98/NT/2000/XP. This dll have the following features

1) Works seamless with all versions of windows (WIN 98, NT, 200 and XP)

2) Using a kernel mode driver embedded in the dll

3) No special software or driver installation required

4) Driver will be automatically installed and configured automatically when the dll is loaded

5) No special APIs required only two functions Inp32 and Out32

6) Can be easily used with VC++ and VB

7) Functions are compatible with Jan Axelsons Inpout32.dll (available at www.lvr.com). So this dll
can be used with the sample programs available with the book Parallel Port Complete, without
any modification.

How Inpout32.dll works

If you don't know what is Inpout32.dll, please read it here and then continue.

How it works

The outstanding feature of Inpout32.dll is , it can work with all the windows versions without any
modification in user code or the DLL itself. This tutorial describes how it is achieved, what
programming methods used, what are the APIs used, etc.... The Dll will check the operating
system version when functions are called, and if the operating system is WIN9X, the DLL will use
_inp() and _outp functions for reading/writing the parallel port. On the other hand, if the operating
system is WIN NT, 2000 or XP, it will install a kernel mode driver and talk to parallel port through
that driver. The user code will not be aware of the OS version on which it is running. This DLL can
be used in WIN NT clone operating systems as if it is WIN9X. The flow chart of the program is
given below.

The two important building blocks of this program are

1) A kernel mode device driver embedded in the DLL in binary form

2) The DLL itself

Kernel mode driver Hwinterface.sys

The source code of Hwinterface.sys kernel mode driver is located in "kernel_mode_driver_source"
directory. Where "hwinterfacedrv.c" is the main application source file. Three functions
implemented in the driver are

1) 'DriverEntry' , Called when driver is loaded. Creates device object and symbolic links.

2) 'hwinterfaceUnload', Called when driver is unloaded, performs clean up

3) 'hwinterfaceDeviceControl', handles calls made through DeviceIOControl API. Performs reading

writing to the parallel port according to the control code passed.

The DLL Inpout32

The functions in the DLL are implemented in two source files, "inpout32drv.cpp" and
"osversion.cpp". osversion.cpp checks the version of operating system. "inpout32drv.cpp" does
installing the kernel mode driver, loading it , writing/ reading parallel port etc... The two functions
exported from inpout32.dll are

1) 'Inp32', reads data from a specified parallel port register.

2) 'Out32', writes data to specified parallel port register.

the other functions implemented in Inpout32.dll are

1) 'DllMain', called when dll is loaded or unloaded. When the dll is loaded , it checks the OS
version and loads hwinterface.sys if needed.

2) 'Closedriver', close the opened driver handle. called before unloading the driver.

3) 'Opendriver', open a handle to hwinterface driver.

4) 'inst' , Extract 'hwinterface.sys' from binary resource to 'systemroot\drivers' directory and

creates a service. This function is called when 'Opendriver' function fails to open a valid handle to
'hwinterface' service.

5) 'start' , starts the hwinterface service using Service Control Manager APIs.

6) 'SystemVersion' Checks the OS version and returns appropriate code.

What is hwinterface.ocx ActiveX control

It is an activex control with same features of Inpout32.dll. It can be used either with VC++ or VB.
But it gives great convenience when used with VB. Data can be written to parallel port using
Outport method and can be read using Inport method.

A Tutorial on creating DLLs with VC++

Visual basic is very fast and easy tool for developing applications with high degree of user
friendliness , but it lacks some important functionalities like direct access to hardware,
multythreading(Activex servers allows some type of multythreading !). The easy and effective
solution for this problem is to write a DLL. But beginners experiance problems in understanding
how to write a dll. .Here is a simple tutorial on writing DLLs with Visual C++. I assume that you
know a little bit Visual Basic and ?C? programming.

What is Static linking and Dynamic linking ?

The libraries can be linked to the executable in two ways . one is static linking and the other
is dynamic linking. Static linking is the methode used to combine the library routines with the
application. When bulding the program , the linker will search all the libraries for the unresolved
functions called in the program and if found, it will copy the corresponding object code from the
library and append it to the executable. The linker will keep searching until there are no more
unresolved function references. This is the most common methode for linking libraries.This
methode boasts of ease of implementation and speed but will generate bulky executables. In
dynamic linking , the required functions are compliled and stored in a library with extension ?.
DLL?. Unlike static linking, no object code is copied in to the executable from the libraries.Insted
of that, the executable will keep the name of the DLL in which the required function resides. and
when the executable is running , it will load the DLL and call the required functions from it. This
methode yealds an executable with small footprint , but have to compromise on speed a little.

Example 1

Objetive

Create a Dynamically linkable library which can calculate and return the sum of two numbers
passed to it.

Tools required

visual C++ 6 , Visual basic 6

Writing The DLL

Start VC++ IDE , select ?New? from File menu. Then select ?Win32 Dynamic - link library? from ?
Projects? tab(picture-1). enter project name as ?example1? , then click OK button. Now you can
see a dialog box with caption ?Win32 Dynamic - Link library - step 1 of 1? (picture-2).
 Picture 1

Picture 2

Select ?a simple DLL project? and click Finish. Now open exaple1.cpp from ?fileview? (picture-3)
 Picture 3

add these lines in to example1.cpp

int _stdcall sum(int x , int y)

{
return x+y;
}

It is a simple function which returns the sum of numbers passed to it.

Now our function is ready. The next step is to create a ?.def? file which informs the linker to export
our function.Select ?New? from ?File? menu and then select ?text File? from ?Files? tab.Give it a
name ?example1.def?. Now you can see an empty file . Add these lines in to ?example1.def?

LIBRARY EXAMPLE1

EXPORTS
sum @1

Select ?Build example1.dll? from ?build? menu. The build process should complete without any
errors. If any error occures , correct it and rebuild again. Oce the build process is completed
successfuly , you can see ?example1.dll? in ?debug? directory.

Now we have successfuly built the Dll and it is the time to test it. For testing the DLL we have to
write a small program in VB. Open a new project in Visual Basic. Place three text box and a
command button like in picture 4.
 Picture 4

Copy the code given bellow , to the code window

Private Declare Function sum Lib "example1.dll" (ByVal x As Long, ByVal y As Long) As Long
Private Sub Command1_Click()
Text3.Text = Str(sum(CInt(Text1.Text), CInt(Text2.Text)))
End Sub

copy example 1.dll to ?windows? or ?system? directory . Then run VB ,enter some values to text1
and text2 and click ?Calculate? button. If you can see the sum in text3, you have completed
example1 successfuly ! cangratulations !.

Download the source code and project files for example1

Example 2

Objetive

Create a Dynamically linkable library which can calculate and return the sum of two numbers
passed to it.

Tools required

visual C++ 6 , Visual basic 6

Writing The DLL

Create a new win32 DLL project in VC++ just like in the previous example. insert the statement
given below before main

#include ?string.h?

Insert the following code after main

char* _stdcall to_upper(char *lowerstring)

{
_strupr(lowerstring);
return lowerstring;
}
Create a def file and insert the following code

LIBRARY example2

EXPORTS
to_upper @1

Now save the project, build it and copy example2.dll to ?windows? or ?system? directory.

Create a new project in VB, place a text box and command button the form paste the following
code to code window.

Private Declare Function to_upper Lib "example2.dll" (ByVal text As String) As String

Private Sub Command1_Click()

If (Text1.text) = "" Then

Exit Sub
End If

MsgBox to_upper(Text1.text)
End Sub

Run the program and enter some lower case characters in textbox.It should display a
messagebox with same characters with case changed.

Download the source code and project files for example2

Example 3

Objetive

Create a DLL which can read/write data to parallel port

This DLL is a very useful for interfacing parallel/serial ports. Since Visual Basic does not have any
facility to communicate with parallel port directly , programmers will have to write code for
accessing parallel port in a DLL and should be called from VB. In this DLL , in this dll , accessing
the device registers is done using functions _Inp() and _Outp(), which is declared in ?conio.h? .
More details about these functions can be found at MSDN online .

We will export two functions from the DLL.One is for reading from a device register and the other
is for writing to the device register. Let these functions be InPort() and OutPort(). InPort() will take
one parameter ie; the address of the register to be read. and Outport will take two ie; the address
of the register to which the data to be written and the data itself.

Note: to do this project , You need to have some knowledge in Parallel port interfacing.

Tools required

visual C++ 6 , Visual basic 6

Writing The DLL

Create a new win32 DLL project in VC++ like in the previous examples. insert the statement given
below before main

#include ?conio.h?

Insert the following code after main

short _stdcall InPort(short portaddress)

{
return _inp(portaddress);
}

void _stdcall OutPort(short portaddress,short data)

{
_outp(portaddress,data);
}

create a .def file with name example3.def and insert the following code

LIBRARY example3

EXPORTS

InPort @1
OutPort @2

now save the project and build example3.dll.

for testing the dll , create a new project in visual basic.Create a form like in picture5.

Picture 5

Add the following code to code window

Private Declare Function InPort Lib "example3.dll" (ByVal portaddress As Integer) As Integer
Private Declare Function OutPort Lib "example3.dll" (ByVal portaddress As Integer, ByVal data As
Integer) As Integer

Private Sub Command1_Click()

OutPort 888, 10 'Val("&h" + Text2.Text), Val(Text1.Text)
End Sub

Private Sub Command2_Click()

Text3.Text = Str(InPort(Val("&h" + Text2.Text))
End Sub

Run the program and enter some value in text1. the n click ?Write it? button. Again click the ?
Read it? button , now if text2 displays the number which you entered in text1 , your dll is working
successfuly.

Download the source code and project files for example3

IEEE 1284.3 and 1284.4

Advances in High-Speed Parallel Port Performance and Port Sharing

From it's humble beginnings as a Printer Port on the original IBM PC, the Parallel Port has become one of the most common
connectors on the Personal Computer today. Virtually every PC shipped over the past 18 years has had a parallel port interface
on it. Originally this port was used just for driving 'fast' dot matrix printers. Today the parallel port is used to interface to almost
every PC peripheral in use. Printers, scanners, data acquisition, CD ROM, tape drives, high speed modems and digital cameras
are some of the peripherals that can be purchased and used today.

From 1981 until 1994 there was tremendous growth in the power, performance and capabilities of the PC. Unfortunately there was
very little change in the performance of the parallel port. In 1994 this all changed with the release of IEEE Std. 1284-1994. This
standard defined new protocols and new interface models that would enable a 50 to 100x performance increase in the capabilities
of the parallel port. With the efforts of the IEEE 1284.3 and 1284.4 committees these enhancements are continuing today.

This presentation will provide an introduction to the state and future of the parallel port interface and the associated protocol stack.

Prior to the 1284 standard the PC parallel port model was a simple register set that the host driver could access. In order to
transfer data the host driver was required to access the register and manage all the handshaking and data transfer. Since the
parallel port was mapped into the ISA bus I/O space the fastest the driver could access the port was 1Mbyte per second. With an
overhead of 4 port accesses per data transfer this put a limit of 250Kbytes per second as the fastest the PC could transfer data
using the Centronics printer protocol. It would require nearly 100% of the PC utilization in order to achieve this rate. In order to
keep the PC responsive actual data rates were on the order of 50KB/S to 150KB/S.

The 1284 standard provided new data transfer protocols that could be implemented in an enhanced register model. One of the
key advantages of this was that the register model could remain backward compatible with the existing model but add enhanced
features for better data transfer. This was achieved by implementing hardware state machines that would offload the data transfer
handshaking form the host driver. The Enhanced Parallel Port (EPP) and Extended Capabilities Port (ECP) are these advanced
modes.
These modes enable data transfer rates of over 1MB/S with reduced host utilization on today's ISA ports, and 3-5MB/S on future
PCI implementations.

Printing, reading or writing from tape, and other peripheral communication can consume a significant percentage of the parallel
port bandwidth when active. In reality though, these activities do not occur very often and use very little of the overall available
bandwidth. This means that a significant PC resource is being wasted. To use this additional potential the IEEE 1284.3 committee
developed a protocol to allow sharing of the parallel port by multiple peripherals. The Daisy Chain protocol is the result of this
effort.

Devices that adhere to this protocol (DC devices) have two connectors on them. One connector connects to the host port of the
PC or the Pass Through port of another DC device. The other connector is the pass through port. This port replicates, or passes
through the signals from the host port when the peripheral is not communicating with the host. The Daisy Chain protocol allows
four peripherals to share a single parallel port and still attach an older 'legacy' peripheral. In this way, like the 1284 standard,
backwards compatibility with the existing installed base is preserved.

The wire protocol that is used for 1284.3 is "out of band" to the 1284 defined protocols. This allows all DC devices to utilize the full
capabilities of the 1284 standard. The 1284.3 protocol provides the means to address individual devices on the parallel port chain
and to select a particular device for use by the host. When a DC device is selected the 'downstream' devices and the legacy
device do not see any activity on the parallel port. To these devices the parallel port is idle.
One advantage of standardizing on the switching protocol is to enable the use of a common software driver on the host PC. The
host driver, possibly provided by the Operating System, can then provide the switching services for the host application. The
1284.3 Service Provider Interface defines the types of services that are required by client applications. These services will be
provided by the host.

This 1284.3 SPI is responsible for determining how many devices are attached to the parallel port and discovering what they are.
This information is obtained by the 1284 device ID method for LPT plug and play. To the client application it appears that the DC
device is the only device attached to the parallel port. The 1284.3 SPI driver manages the switching and selection of the
peripheral.

Once you have a software layer to provide the basic port enumeration services it is a natural extension to include the data transfer
functions. The 1284.3 Data Link interface defines these services. With a full software interface to the parallel port we are able to
achieve independence from the actual hardware interface. This makes it easier to migrate to newer and faster hardware without
effecting the client applications.

The 1284.3 Data Link defines a packet protocol that enables the delivery of packets of data to other side of the interface. This
creates a connection-less, peer to peer relationship between the host and the peripheral. The header provides information on the
data length and the transport protocol being used. This ensures that the data is only delivered to the appropriate client. The data
length is used to enable DMA for the reception of data.

At this point the 1284/1284.3 protocol stack provides a software interface that is independent of the actual hardware
implementation. With the appropriate implementation of the data link the parallel port could be used with many different transport
protocols. Although this is true, there was no transport layer that could take advantage of the features of the 1284 interface. In
particular the channel capabilities of the EPP and ECP modes.

The IEEE 1284.1 committee had defined a printer management standard that could operate over networks or direct attached
interfaces. They requested that the IEEE develop a transport protocol that would take advantage of the 1284 standard parallel
port capabilities but also be suitable for other physical interfaces. One of the main requirements was that the transport layer be
able to maintain multiple conversations, or sessions, between the PC and the peripheral. In addition to this the protocol should
ensure that one conversation cannot block another. An example of blocking is what you see in older Centronics interfaces. If the
paper should run out of the printer or you open the tray to add more paper you can no longer communicate with the printer. With
1284.4 these functions should be independent and not effect one another.

The IEEE 1284.4 committee was established to develop and define this transport protocol. After analysis of various existing
protocols, such as PPP and the MFP IS16550, it was determined that the Multiple Logical Channels (MLC) protocol developed by
Hewlett-Packard and Genoa Technology met the general requirements for this standard. QualityLogic™ (formerly Genoa
Technology) and HP offered this protocol as the basis for the 1284.4 standard. While MLC was the basis for 1284.4, the final
standard is not backward compatible with MLC.

The 1284.4 protocol allows a device to carry on multiple, concurrent exchanges of data and/or control information with another
device across a single point-to-point link. Blocking of one data exchange has no effect on the others. While the protocol was
required to operate over the 1284 interface it may also operate over other interfaces such as USB and IEEE 1394.

1284.4 defines a packet protocol that enables this communication. Within the packet is the identity of the source and destination
endpoints, client data, as well as control and credit information. Credit is the flow control method that is used to ensure that
channel blocking does not occur.

With credit the target of a data transfer gives the source of the data an indication of how much data it is guaranteed to accept. In
this way the source can never send more data than the target can accept. Upon initialization both sides negotiate for how much
data needs to be transferred and in what packet sizes.

The source and target identities define a connection between the sides. A source may communicate with multiple target
endpoints. In this way one client can communicate with multiple services on the target. A scanner is one example of how this may
operate. The scanner application on the host may need to communicate with two functions on the scanner peripheral. The first
function may be the scanner control and status monitor. The application will then establish a conversation between itself and this
function on the scanner. At some point a page to be scanned may be inserted. Now the scanner can request the establishment of
a connection between the scan engine and the host application. Now we have two independent conversations established
between the PC and the peripheral.

This model can be extended to many different conversations. Conversations may occur between devices on different physical
interfaces. The advantage of 1284.4 is that it can port to other PC related interfaces by the implementation of the appropriate
software interface. This means that a client application on the PC can communicate with devices on multiple physical interfaces
without any changes.

In conclusion, the parallel port is being enhanced by new hardware and software support. With backward compatibility and a huge
installed base this interface will provide a convenient and powerful port for future peripherals. This presentation will provide an
introduction to the protocol stack and issues involved in developing parallel port peripherals.