CUSTOM WINDOWS NT 4.

PARALLEL PORT DEVICE DRIVER

A COMPONENT OF A NETWORK PERFORMANCE

MEASUREMENT TOOL

By

Angel Yu

Senior Project

Computer Engineering Program

California Polytechnic State University

San Luis Obispo

1998
 Table of Contents

Acknowledgements ...................................................................................................i

Abstract....................................................................................................................ii

1. Introduction ...................................................................................................... 1
1.1. Senior Project Report Review ....................................................................... 1
2. Background ....................................................................................................... 2
2.1. Cal Poly–3Com Network Testbed for Network Performance Measurements. 2
2.2. Problem of Measuring Network Latency in NT Environment ....................... 3
2.3. Use of Parallel Port Signal and PCI Instrumented with Logic Analyzer ........ 4
3. Requirements for a Parallel Port Driver.......................................................... 6
3.1. What is a Parallel Port?................................................................................. 6
3.2. Interface with Windows NT.......................................................................... 8
3.3. Performance ............................................................................................... 10
4. Development Process....................................................................................... 10
4.1. Reference to Baker Driver .......................................................................... 10
4.2. Use of Microsoft DDK and SDK ................................................................ 11
4.3. Final Development Procedure Used ............................................................ 11
5. Design of NT Parallel Port Driver .................................................................. 12
5.1. Software Design for Interface to NT Software ............................................ 12
5.2. Software Design for Interface to Parallel Port Hardware Signals................. 13
5.3. User Interface to Parallel Port Signal Function............................................ 14
6. Installation of Driver....................................................................................... 17
6.1. Installation Procedure ................................................................................. 17
6.2. Installation Configuration Considerations ................................................... 19
7. Testing of NT Parallel Port Driver and User Interface ................................. 20
7.1. Test Plan and Procedure ............................................................................. 20
7.2. Test Results ................................................................................................ 22
8. Alternate Approach ........................................................................................ 23
8.1. Existing Parallel Port Driver with Peek and Poke Functions........................ 23
8.2. User Interface to Peek and Poke ................................................................. 23
8.3. Testing ....................................................................................................... 23
9. Recommendations for Future Work .............................................................. 25
9.1. Parallel Port Driver..................................................................................... 25
10. Conclusions .................................................................................................. 26
10.1. Summary of Results of Senior Project ..................................................... 26
Biblography ........................................................................................................... 27

Appendices............................................................................................................. 28
A Alternate Approach Source Code
B Graphical User Interface using Borland C++ Builder
C Test Results from Alternate Approach
 List of Tables

Table 1: Parallel Port Registers.................................................................................. 7

Table 2: Status Register ............................................................................................. 8

Table 3: Control Register........................................................................................... 8

Table 4: Functions for Interface to NT Software...................................................... 12

Table 5: Test Procedure........................................................................................... 21

Table 6: Parallel Port Pin Assignments .................................................................... 24

Table C1: Parallel Port Output Values ..................................................................... 31

List of Figures

Figure 1: Configurations to measure network performance ........................................ 2

Figure 2: OSI Network Model ................................................................................... 5

Figure 3: Interface Layers........................................................................................ 15

Figure 4: GUI for Parallel Port Signal Test .............................................................. 16

Figure 5: BUILD Directory Path.............................................................................. 18

Figure 6: Registry Directory .................................................................................... 19

Figure 7: Parallel Port Physical Pin Out ................................................................... 24

Figure 8: Parallel Port Bit Shifting........................................................................... 25

 i

Acknowledgements

First of all, I would like to thank my advisor, Dr. James Harris. His encouragement,

support, and guidance throughout the project have been invaluable. His never-ending

passion to learn has inspired me and will keep me motivated throughout my career in

college and in industry. I would also like to thank Brian Hemme, a Cal Poly graduate

for his willingness to always help. His experience with Windows NT drivers was very

beneficial and he provided a multitude of resources.

This project is supported by 3Com, Inc.

 ii

Abstract

Measuring network performance from a user’s perspective mainly involves response

time. To study the response time of the network, an investigation must be conducted

on the time it takes for each network layer to encapsulate the data. The investigation

will require a tool that will measure the network performance. As a step towards

developing a network performance measurement tool, this project proposes to

develop a parallel port driver that will send a signal level change to the parallel port.

A logic analyzer can be attached to the parallel port and can be configured to trigger

on the signal level change. By generating a signal to the parallel port immediately

before a write request to the server, the network latency can be determined from the

logic analyzer data.

 1

1. Introduction

1.1. Senior Project Report Review

From the perspective of a network user, the most important performance criterion is

response time to the user’s request for data. Responses less than ten milliseconds will

not be perceived by a human, and responses as long as one hundred milliseconds may

even be acceptable. However, in the marketplace, the two measures of client adapter

performance are throughput and client computer central processing unit (CPU)

utilization. These measurements are fine for network design but do not address the

user’s performance criteria.

To study the response time performance of the network, the computer architecture

model for CPU/memory will be applied. The user of the client computer will take on

the role of the CPU. For non-real-time data requests, using cache memories should

improve the response time performance. The ultimate goal of this project is to

participate in the investigation of maximizing network performance through network

caching. A step toward this goal is to develop a driver for the Windows NT 4.0

operating system that will provide a parallel port signal for the measurement of the

network latency. This senior project consists of the development of this parallel port

driver.
 2

2. Background

2.1. Cal Poly – 3Com Network Testbed for Network Performance Measurements

3Com has provided a testbed that consists of a five-computer Ethernet network with

100/10 Mbps hubs and adapter cards. With the assistance of 3Com and Intel, the

testbed will also contain an iq-sdk development system. This testbed will be used to

take network performance measurements. Comparisons of network performance will

be made on two configurations (Figure 1): 3Com driver installed on the NT operating

system (Network Driver Interface Specification, NDIS) and driver installed on the

i960 processor of the iq-sdk development system with the ported driver from the NT

operating system (Intelligent Input/Output, I20).

Windows NT Windows NT
Operating Operating
System System

3Com LAN
OSM

PCI Bus
PCI Bus

3Com NIC
DDM

HDM
(a) NDIS configuration
PCI Bus

3Com NIC

(b) I20 configuration

Figure 1: Configurations to measure network performance

 3

2.2. Problem of Measuring Network Latency in NT Environment

Performance as defined by a user is not based upon how fast a system can respond to

a series of requests (i.e. throughput) but how fast it responds to an individual request.

It is suggested that the latency of the system handling user-initiated events, such as

keystrokes, is a better measurement for user-perceived performance [10].

As discussed in Endo and Seltzer [10], because a user can spawn multiple

applications, the only parties who know when event-handling begins and ends are the

user and the applications. Since users' perceptions vary from user to user, the reliable

source of data is the application. There are three different methods for obtaining data

from the application. First, it could measure its own latency. This probably provides

the most accurate data but it would require access to the application's source code.

Another technique is to use interposition to intercept every application call and

deduce the event latencies. This method is error-prone due to the interpretation of the

trace. The last technique requires the operating system to try to extrapolate the

beginning and ending times of events. All of these approaches are not feasible since

they require the Windows NT source code and it is not available.

Endo and Seltzer [10] also noticed another component of response time that is not

even included in the above techniques is the time that the system spends delivering a

hardware event (i.e. keystroke) to the application. Event-delivery time measurement

is based upon time-stamping every keyboard and mouse interrupt. This can be
 4

accomplished by modifying the drivers. However, to associate a higher-level event

delivered to the application with a keystroke or mouse-click requires access to the

operating system source code. As input is processed, the path that is executed must be

traced with check points.

From the two cases above, it is clear that measuring the latency between a user

request and an application reply is difficult without operating system/application

source code. Applying this to the network protocol stack, there will not be a feasible

way to measure the latency at the application layer, let alone the whole protocol stack

itself. However, the tool that is proposed in this senior project avoids depending on

the source code.

Instead of measuring the network latency within the kernel or application, this tool

will seek measurements using signals from the parallel port and from data provided

by the PCI bus. The tool will consist of a logic analyzer that can monitor data across

the bus and a user interface to the parallel port.

2.3. Use of Parallel Port Signal and PCI Instrumented with Logic Analyzer

Open Systems Interconnect (OSI) Network Model

The OSI model consists of seven layers in its protocol stack: physical, data link,

network, transport, session, presentation, and application as shown in Figure 2. Each

machine has a protocol stack that conducts the transmission of data packets between
 5

other machines. The packets travel through the layers. When a machine sends a data

packet, as it travels through a new layer, it is encapsulated with information specific

to that layer. Similarly when a machine receives a data packet, it also travels through

the protocol stack. As it passes a layer, the information specific to that layer is

stripped.

Network Layer
High Level Layer
Application
Presentation
Session
Transport
Network
Data Link
Low Level Layer Physical

Figure 2: OSI Network Model

The first step is to understand the nature of network performance. For example, when

a client makes a request to a server through a network, the user experiences a delay.

This delay is the time it takes for the server to respond. The request travels from the

client working its way through the protocol stack (starting from the application layer

to the physical layer). At the server end, the request travels from the physical layer to

the application layer. The server's response must also travel back through its protocol

stack and back through the client's protocol stack. The response time depends on how

much time is spent in the layers of the network and how busy the machine is.
 6

A tool will be developed to measure the time spent in attaching each layer of the

network to each data packet. Using the logic analyzer, the packets can be monitored

from the PCI bus. At the application level, the client will send a signal (a signal level

change, such as a clock transition) to the parallel port just before initiating a request

to the server. The logic analyzer will be able to trigger on the signal. Using the logic

analyzer’s absolute timing mode, the time it takes for the request to travel through the

NT system is measured. In other words, this tool can measure the latency from the

parallel port signal (i.e., the application request to the network) to the very first data

packet of the user request as it appears on the PCI bus, i.e. response time.

3. Requirements for a Parallel Port Driver

3.1. What is a Parallel Port?

The parallel port was originally designed for the printer. The port was used to

communicate with printers. Today, however, many devices can be accessed through

the parallel port. Devices such as optical scanners and disks are attached to the

parallel port. Because the parallel port is traditionally used for the printer, the

following sections refer to the printer as the device that is attached to the port.

Physical Component

The DB-25 connector supports many signals. The most important ones are listed

below:
 7

‰ Initialize – The CPU requests the printer to be initialized.

‰ Data – There are eight lines for data. The CPU sends a byte of data to the
printer using these eight lines.

‰ Strobe# – The CPU informs the printer that valid data is ready on the data
lines. This signal is active low.

‰ Busy – The printer informs the CPU that it cannot accept any data at this
instant.

‰ Ack# – The printer informs the CPU that it is no longer busy. This signal is
active low.

‰ Errors – The printer may use many lines to inform the CPU of any errors.

Software Interface

There are three eight-bit registers that provide the software interface to the parallel

port. One register is located at the base address and the other two registers are located

at consecutive addresses (See Table 1). In Windows NT, the addresses are 0378H-

037AH, with the data register at 0378H (the base address), the status register at

0379H, and the control register at 037AH. The details of the status and control

registers are described in Table 2 and Table 3, respectively.

Table 1: Parallel Port Registers

Offset from Base Register Access Description

Address
0 Data Read/Write Byte of data transferred
1 Status Read Only Current status of parallel port
2 Control Read/Write Commands sent to parallel port
 8

Table 2: Status Register

Bits Description
0-1 Reserved (normally contain 1)
2 0 – Interrupt requested by port
3 0 – error occurred
4 1 – printer is selected
5 1 – printer is out of paper
6 0 – acknowledge
7 0 – printer is busy

Table 3: Control Register

Bits Description
0 1 – strobe data to/from parallel port
1 1 – automatic line feed
2 0 – initialize printer
3 1 – select printer
4 1 – enable interrupts
5 0 – Reserved
6-7 1 – Reserved

Parallel Port Driver

The main function of the parallel port driver is to manage data transfers and control

operations for printers. Writing to and reading from the three parallel port registers

have many effects such as, data transfers, printer requests, port and printer status, and

printer commands. However, for this senior project, the parallel port will not have any

device attached to it, except for the logic analyzer. The project will only require a

means to send a signal to the parallel port and also to read its status.
 9

3.2. Interface with Windows NT

The parallel port driver alone does not access the parallel port. To “talk” to the

parallel port, the user must be able to communicate with the driver. A module must be

created to guide the user’s requests through the Windows NT operating system to the

driver. The application programming interface (API) is designed and implemented for

this purpose. With any Windows operating system, Microsoft Win32 API is used.

Microsoft Win32 Application Programming Interface

Win32 API is the standard programming interface for Windows NT [6]. Programmers

use 32-bit addresses, instead of the old 16-bit addresses used in earlier versions of

Windows.

Win32 basically consists of five categories [9]:

1. Windows Management

2. Graphics Device Interface (GDI)

3. System Services

4. Multimedia

5. Remote Procedure Calls (RPCs)

For this senior project, only one of these categories is used: Windows Management.

For details on the remaining components see the Win32 development web page [9].
 10

The purpose of Windows Management is the development and management of a user

interface. An interface can be designed to prompt for input, display output, etc.

Applications must also be able to control the interface. In order to do this, the

application creates a window class with corresponding window functions. The class

and its functions comprise the user interface.

3.3. Performance

Due to the API, another layer is added to the many layers that are to be measured.

This may add more latency between initiating a request to the server and receiving a

response. However, for the time being this is not a problem; relative measurements

will be taken for each platform configuration. Ultimately, the API latency, if any, will

be stripped from the final measurements.

4. Development Process

4.1. Reference to Baker Driver

The Windows NT parallel port device driver runs in kernel mode. This kernel-mode

driver is a collection of subroutines that are called as needed by the input/output (I/O)

manager. Some of the subroutines include driver initialization and cleanup routines,

I/O system service dispatch routines, and data transfer routines. The Windows NT

Device Driver Book [1] provides a detailed example of a parallel port device driver.
 11

To understand the development process, the parallel port driver code provided by

Baker was compiled. The final product was installed on one of the machines in the

testbed.

4.2. Use of Microsoft DDK and SDK

Because of the non-trivial nature of Windows NT device drivers in general, Microsoft

provides a Device Driver Kit (DDK) [4]. The DDK contains sample code for many

types of device drivers. It also contains many utilities for device driver development.

The general I/O port driver provided by the DDK can be applied to the parallel port

driver.

Microsoft also provides a Software Development Kit (SDK) [5], which provides

libraries and sample code to develop Win32 APIs.

4.3. Final Development Procedure Used

The parallel port used for this project is based on Baker’s parallel port driver. The

initial stages consist of using Baker’s driver, which includes additional functionality

that is not needed. However, as the code for the parallel port driver is understood

more, the functions that are not needed are to be excluded to make the driver more

efficient.
 12

The API is created by using the SDK and the Microsoft’s web page on Win32 API

development [9].

5. Design of NT Parallel Port Driver

5.1. Software Design for Interface to NT Software

Proposed Routines

The interface to the NT software is basically a program that communicates with the

I/O control layer of NT. The functions in this layer control the I/O manager, allowing

interaction with the parallel port driver. The program is based upon four proposed

routines that call the I/O control layer functions: Init, GetByte, PutByte, and Kill.

Table 4 describes the functions in detail.

Table 4: Functions for Interface to NT Software

Function Description
Init Initializes connection to the parallel port driver, creating “handle” to the
driver
GetByte Reads a byte from the parallel port*
PutByte Writes a byte to the parallel port
Kill Terminates connection to the parallel port driver
* Used for testing purposes only
 13

Current Status

The parallel driver is installed on one of the machines in the testbed. However, all of

its functionality cannot be tested since a file handle could not be created for the

driver. See section 7.2 for details.

Proposed Direction

An existing driver for an input/output port modified from the DDK is up and running

on machines outside of the established testbed. A possible approach to determine the

file handle name is to compare the DDK driver to Baker’s driver. A detailed analysis

should be performed on the sections of code containing how the file handle is created.

Another possibility is to research Win32 API for function or procedure calls that can

provide an interface directly to the driver.

5.2. Software Design for Interface to Parallel Port Hardware Signals

The interface to the parallel port hardware is the driver itself. The routines in the

driver are called by the I/O Control functions as described in section 5.1.

As seen in Baker [1], there are many parts that comprise the driver. The “init.c” file

contains all hardware initialization and setup routines. It contains a routine called

“DriverEntry.” This code is executed when the driver is loaded onto the machine. The

routine initializes the driver, sets up the hardware resources needed by the driver, and
 14

creates the objects needed to process I/O requests. DriverEntry calls another function

“XxCreateDevice” which is the module that actually carries out the hardware

initialization.

The “transfer.c” file contains three main routines that are relevant to this parallel port

application [1]. The first routine “XxStartIo” completes any processing needed before

the actual transfer of data. It also initiates the transfer. The routine

“XxTransmitBytes” actually transfers the bytes to the parallel port.

The “unload.c” file contains routines that make the driver unloadable. The main

routine “XxReleaseHardware” basically undoes the initialization, i.e. undoes the work

from “DriverEntry.” This procedure is also executed by parts of the driver

initialization since both routines need to perform the same cleanup. See Baker [1] for

more details on unloading the driver.

5.3. User Interface to Parallel Port Signal Function

Proposed Interface

A graphical user interface (GUI) is provided to initiate a signal to the parallel port. It

is basically a Win32 API (see Section 3.2). It contains two buttons. One button

generates a signal level change to the parallel port only.

 15

The other button is used to initiate the signal level to the parallel port and initiate a

request (client writes a file to the server). The request generates a FTP socket using

Winftp and begins transferring a file to the server [3]. This provides an easy way for

the user to accomplish both tasks with one button click. Of course, there is still some

latency between generating the signal and issuing a request. However, with this

method, the latency would not include human reaction time, since a request would be

initiated automatically after the parallel port signal is initiated.

The user interface is essentially the interface to the NT software, as described in

section 5.1. The only difference is that it provides a graphical interface instead of a

console interface. Figure 3 shows the different interfacing layers.

GUI

Interface to NT Software

Parallel Port Driver

Figure 3: Interface Layers

Current Status

Using Borland C++ Builder, a GUI was created. It has been altered many times for

the testing phase of the Parallel Port I/O for Windows NT [7] (see section 8).

Currently it contains a memo box, edit box, and a button (see Figure 4). The GUI
 16

allows the user to enter the value (signal) to send to the parallel port in the edit box.

When the button is pressed, the value (signal) in the edit box is transferred to the

parallel port. The memo box displays status messages for testing purposes only.

Figure 4: GUI for Parallel Port Signal Test

Proposed Direction

The next step is to develop buttons to generate signal level changes. One button will

be used to generate a low-to-high-to-low level change and the other will be used to

generate a high-to-low-to-high level change. The logic analyzer will then be able to

trigger on either one of these signal level changes.

After implementing the buttons for the signal level changes, the button to generate a

signal change and send a write request to the server may also be implemented.
 17

6. Installation of Driver

6.1. Installation Procedure

Once the source code of the parallel port driver is developed, it must be “built”. The

BUILD utility provided by the DDK is basically a wrapper for NMAKE. BUILD

forms appropriate NMAKE commands from the source files. Then it runs NMAKE

which constructs one or more BUILD products (binary output files). There are

CHECKED and FREE versions of the binaries. CHECKED builds are basically used

for debugging; they contain extra debugging information. Binaries compiled with

optimization are called FREE builds. They are smaller, faster, and should be used for

final release of the driver.

To build the driver executable, the following steps should be taken:

1. In the same directory where the source code is, create a file called SOURCES,

which identifies the parts of the final driver. The SOURCES file consists of

keywords that specify the type of driver to be generated, the source files that

make up the BUILD product, and directories for files. See Baker's book for the

details on the keywords and the SOURCES file format.

2. Create another file called MAKEFILE in the same directory. MAKEFILE should

only contain the line: !INCLUDE $ (NTMAKEENV) \MAKEFILE.DEF This file

should not be modified in any other way. It invokes the standard makefile that is

needed by any driver created with BUILD.

 18

3. A directory tree must be created. As shown in Figure 5, subdirectories

CHECKED and FREE are created under subdirectory i386.

4. Set the environment variables of the CHECKED and FREE directories for either

the debug or final release of the driver, respectively.

5. Move to the directory that contains the SOURCES file.

6. Run the BUILD utility. The driver (“.SYS” file) will be in either the CHECKED

or FREE subdirectory.

(TARGETPATH)

i386

CHECKED
..
FREE

Figure 5: BUILD Directory Path

After building the utility, the executable driver must be copied to the device driver

directory. Using the Windows NT Explorer, change to the \SYSTEM32\DRIVERS

directory. Copy the .SYS file into the DRIVERS directory.

The driver must also be entered into the Registry. Specific Registry keys and values

must be set. Edit the Registry by opening the RUN command from the startup button

and type in "REGEDT32" to start the utility. After arriving at the subdirectory

CurrentControlSet by following the directory path as shown in Figure 6, the name of

 19

the driver must be entered. This is done by selecting "ADD" and then "KEY." Values

should be added to the key also. This is done by again selecting "ADD" and then

"VALUES." The required values are shown in Figure 6 (ErrorControl, Start, and

Type). For details description of key values and optional key values, see Baker [1].

After entering the driver into the Registry, the machine must be rebooted. Then the

driver should now be recognized by the system.

HKEY_LOCAL_MACHINE

System

CurrentControlSet

(Device driver name)

ErrorControl: REG_DWORD: 0x1

Start: REG_DWORD: 0x3
Type: REG_DWORD: 0x1

Figure 6: Registry Directory [1]

6.2. Installation Configuration Considerations

After rebooting the system, this parallel port driver should be set up so that it is the

only driver started for the parallel port. This can be done by changing its startup

properties. From the Start menu, select Settings and then click on Control Panel.

From the Control Panel menu, click on Devices. A window is opened, which displays
 20

a list of devices along with their status and startup configuration. If another parallel

port device has been started, its status will be listed as “Started”. Its status must be

changed. To stop any other device, select the device and click on the Stop button on

the right-hand side of the window.

This parallel port driver may also be setup to start automatically or manually. For this

driver, the startup configuration is set to automatic by clicking on the name of the

driver and then selecting the Startup button. A new window appears that displays a

list of different startup options. From the Devices window, a selected device may be

started or stopped using the associated buttons located on the right-hand side of the

window. All other devices that use the parallel port may have an automatic

configuration but they cannot all be started at the same time.

7. Testing of NT Parallel Port Driver and User Interface

7.1. Test Plan and Procedure

Without some kind of an interface between the NT software and the parallel port

driver, the driver is virtually unusable. Therefore, an interface is essential. Because it

is the link between the user and the actual parallel port driver functions, it will

provide a means to test the driver functions.

The first step is to test the routines (that are relevant to driving a signal to the parallel

port) provided by Baker [1]. The Table 5 below lists the various conditions to be
 21

tested. In order to test some of these routines, the interface to NT software includes

additional features that are not needed for the measurement tool itself. These features

will be removed once testing is complete.

The next step is to test the graphical user interface with a "dummy" routine. This will

ensure that when a user does click on a button, the event (button click) will be

registered and call the specified routine.

Table 5: Test Procedure

Pass Fail Description Comments

Driver is loaded successfully
Driver is initialized successfully
Driver writes to the control register
successfully
Driver transmits a byte to the parallel
port successfully
Driver reads the status register
successfully
When the driver is stopped, its is
unloaded successfully

Finally, the graphical user interface will be integrated with the interface to NT

software. For example, when a user clicks the button to send a signal to the parallel

port, the button click will call the routine that will actually initiate the signal. After

obtaining successful results for this test, the other button can be tested. Clicking on
 22

the second button should call the routine that sends the signal to the parallel port,

generates a socket to the server, and sends a file to the server.

7.2. Test Results

The parallel port driver was loaded and unloaded successfully. However, problems

arose when initializing the driver. When a driver is registered, the system references it

with a file name, i.e. file handle. In Baker's code, the name should be "xx1." But

when this name was used in the test program, no connection was established between

the test program and the parallel port driver.

Another test program was created to try to decipher the file name. It produced every

possible combination of printable characters, starting with one character up to sixteen

characters. After running this for two days, the program was still processing for 5

character words. Three file names were successful in connecting the driver and the

test program: "con" "nul" and "ndis." However these file names are irrelevant to the

parallel port driver. Due to these unsuccessful attempts at finding the file handle, the

driver initialization could not be tested.

This problem led to another strategy: there may be an existing utility that allows a

user to read and write to the parallel port addresses directly (see section 8). By using

this approach, the file handle problem can be avoided.

 23

8. Alternate Approach

8.1. Existing Parallel Port Driver with Peek and Poke Functions

After searching the internet, a parallel and input/output port driver for NT that allows

direct access to the ports' addresses was found [7]. The utility only contains variations

of 1-byte, 2-byte, and 4-byte peek and poke functions. It can access the three registers

(data, status, and control) of the parallel port.

The utility is loaded and ready once it is installed (using the loader provided); the

system does not need to be rebooted. Also the included dynamic link library must be

placed into the "system32" directory. See [7] for more details on installation.

8.2. User Interface to Peek and Poke

The next step consisted of developing a user interface to the parallel port signal

function. Using Borland C++ Builder, a GUI was created. The GUI contains one

button that sends the data value to the parallel port and an edit box, which allows the

user to specify a value to send.

8.3. Testing

For test purposes, initially a button was created to send a value of 0xFF to the parallel

port. When the parallel port was connected to a logic analyzer, the data pins (see

Figure 7 and Table 6) had all high outputs. Therefore writing to the parallel port was

successful.
 24

1 2 3 4 5 6 7 8 9 10 11 12 13
14 15 16 17 18 19 20 21 22 23 24 25

Figure 7: Parallel Port Physical Pin Out [11]

Then the GUI was enhanced to accept a decimal value to send to the parallel port.

However, unexpected results occurred. For the value 0, the logic analyzer displayed

high outputs for the three most significant bits of the data register while the rest were

low.

Table 6: Parallel Port Pin Assignments (See [8] for more details on lines)

Pin Number Line Pin Number Line

1 #Strobe 10 #Ack
2 Data0 (LSb) 11 Busy
3 Data1 12 Paper Empty
4 Data2 13 Select
5 Data3 14 #Auto Feed
6 Data4 15 #Error
7 Data5 16 #Initialize
8 Data6 17 #Select In
9 Data7 (MSb) 18-25 Ground

These unexpected results led to further testing. It turns out that for the range 0-7 the

data register contains the same value. Other numbers were also tested. The range 8-15

resulted in high outputs for the three most significant bits and the least significant bit,
 25

while the others were low. A pattern had developed for other numbers that were

tested. The three least significant bits in a nibble of the value to be written to the

parallel port were being ignored. The ignored bits were reflected in the three most

significant bits on the parallel port itself. The value is shifted to the right three times

and then three most significant bits become high outputs on the parallel port (See

Figure 8).

Values greater than decimal 255 should not be used since the tool only needs to send

an 8-bit signal level change to the parallel port. The GUI is developed to read only

one byte of data from the edit box.

Bit Contents a7 a6 a5 a4 a3 a2 a1 a0
Bit Address 7 6 5 4 3 2 1 0
a. Bits 0-2 are ignored. Each bit is shifted to the right three times.

Bit Contents 1 1 1 a7 a6 a5 a4 a3
Bit Address 7 6 5 4 3 2 1 0
b. After the shift, “1” is shifted in on the left to replace the three bits that were
ignored.
Figure 8: Parallel Port Bit Shifting

9. Recommendations for Future Work

9.1. Parallel Port Driver

As stated earlier, the parallel port driver provided by Baker [1] is installed on one of

the machines in the testbed. However, Baker’s parallel port driver includes printer
 26

functionality, which is not needed for this tool application. As a future goal, Baker’s

driver should be stripped, leaving the basic functions for a driver (initialization, clean

up, etc). Also a function should be implemented to generate a signal change to the

parallel port, i.e. a simple function that will transmit bits.

10. Conclusions

10.1. Summary of Results of Senior Project

The initial proposal to develop a parallel port driver for the instrumentation of a

measurement tool was not accomplished as planned. There were many complications

with Baker's driver. However, a basic understanding of the complex process involved

with device driver development was gained.

Although the reason why the new parallel port driver manipulates some bits is not

understood, it does perform the function that is required for this measurement tool. It

is capable of sending a recognized bit pattern to the parallel port. As shown in Section

8.3, the logic analyzer can recognize the parallel port signal.
 27

Biblography

[1] Baker, Art, The Windows NT Device Driver Book, Upper Saddle River, NJ. Prentice-

Hall, Inc., 1997.

[2] Hsu, John, Computer Networks: Architecture, Protocols, and Software, Norwood,

MA. Artech House, Inc., 1996

[3] Liang, Yu, “Network Latency Measurement for I2O Architecture”, June 1998.

[4] Microsoft Corporation, DDK Platform, Microsoft Developer Network, Redmond,

Washington. January, 1996.

[5] Microsoft Corporation, Win 32 SDK, Microsoft Developer Network, Redmond,

Washington. January, 1996.

[6] Newcomer, Joseph M., and Rector, Brent E., Win32 Programming, Reading,

Massachusetts. Addison Wesley Longman, Inc., 1997.

[7] Parallel Port I/O for Windows NT

http://www.tmo.hp.com/tmo/pia/HPVEE/PIANews/software/English/HPVEE_Win3

2_NTPPIO.html

[8 ] Pinouts for Various Connectors in Real Life

http://margo.student.utwente.nl/stefan/el/componen/fpinout2.html#PINOUTS_006

[9] Win32

http://www.microsoft.com/win32dev

[10] Endo, Yasuhiro, and Seltzer, Margo, "Measuring Windows NT - Possibilities and

Limitations", USENIX Windows NT Workshop, August, 1997.

[11] Zip Parallel Port Cable Pin-out

http://www.iomega.com/support/techs/zip/2079.html
 28

Appendices

A Alternate Approach Source Code

See [7].

B Graphical User Interface using Borland C++ Builder

File: “test2.cpp”
//---------------------------------------------------------------------------
#include <vcl\vcl.h>
#pragma hdrstop
//---------------------------------------------------------------------------
USEFORM("ppsig.cpp", Form1);
USERES("test2.res");
//---------------------------------------------------------------------------
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
try
{
Application->Initialize();
Application->CreateForm(__classid(TForm1), &Form1);
Application->Run();
}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
return 0;
}
//---------------------------------------------------------------------------

File: “ppsig.h”

//---------------------------------------------------------------------------
#ifndef ppsigH
#define ppsigH
//---------------------------------------------------------------------------
#include <vcl\Classes.hpp>
#include <vcl\Controls.hpp>
#include <vcl\StdCtrls.hpp>
 29

#include <vcl\Forms.hpp>
//---------------------------------------------------------------------------
class TForm1 : public TForm
{
__published: // IDE-managed Components
TMemo *Memo1;
TButton *Button1;
TEdit *Edit1;
void __fastcall Button1Click(TObject *Sender);

private: // User declarations

public: // User declarations
__fastcall TForm1(TComponent* Owner);
};
//---------------------------------------------------------------------------
extern TForm1 *Form1;
//---------------------------------------------------------------------------
#endif

File: “ppsig.cpp”

//---------------------------------------------------------------------------
#include <vcl\vcl.h>
#pragma hdrstop

#include <stdio.h>
#include "ppsig.h"
#include "cppapi.h"
//---------------------------------------------------------------------------
#pragma resource "*.dfm"
TForm1 *Form1;
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
HINSTANCE ppHandle;
char pBuf[128];

ppHandle = LoadLibrary("ppppapi.dll");
if (ppHandle == 0)
{
sprintf(pBuf,"Couldn't open ppppapi.dll\r\n");
 30

Memo1->Lines->Add(pBuf);
Button1->Enabled = false;
return;
}
Poke8 = (int (*)(USHORT, USHORT, UCHAR, int *))GetProcAddress(ppHandle,
"Poke8");

if (Poke8 == 0)
{
sprintf(pBuf,"Couldn't find Poke8");
Memo1->Lines->Add(pBuf);
}

Peek8 = (unsigned short (*)(USHORT, USHORT, int

*))GetProcAddress(ppHandle, "Peek8");

if (Peek8 == 0)
{
sprintf(pBuf,"Couldn't find Peek8");
Memo1->Lines->Add(pBuf);
}
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button1Click(TObject *Sender)
{
char pBuf[128];
int iStatus, iretStatus;
unsigned char val;
unsigned short retval;

//get string from edit box & convert string to integer

val = (unsigned char)(atoi(Edit1->Text.c_str()));

sprintf(pBuf,"The string value in hex is %x",val);

Memo1->Lines->Add(pBuf);

//write data "val" to the data register of the parallel port (0x378)
Poke8(0,0,val,&iStatus);
sprintf(pBuf,"The status is %d",iStatus);
Memo1->Lines->Add(pBuf);

//read status register (0x379) into "retval"

retval = Peek8(0,1,&iretStatus);
sprintf(pBuf,"The value in the status register is %x",retval);
 31

Memo1->Lines->Add(pBuf);

//read control register (0x37A) into "retval"

retval = Peek8(0,2,&iretStatus);
sprintf(pBuf,"The value in the control register is %x",retval);
Memo1->Lines->Add(pBuf);

}
//---------------------------------------------------------------------------

C Test Results from Alternate Approach

Table C1: Parallel Port Output Values

Parallel Port Output (binary: MSb..LSb) Value Sent to Parallel Port (decimal)
11100000 0–7
11100001 8 – 15
11100010 16 - 23
11100011 24 – 31
. .
. .
11111110 240 - 247
11111111 248 - 255