From AtariForumWiki
Jump to: navigation, search


PARCP is a parallel port file transfer program for the Atari ST range and Atari Falcon, allowing easy file transfers from other Atari machines or computing platforms (PC, Mac, Raspberry Pi). The program can behave as a client or as server. The program uses a special parallel-to-parallel cable or parallel-to-USB adapter.


                               PARCP v2.50

                          written by Petr Stehlik

                              (c) 1996-1997

Last Update: 22 June, 1997

                            TABLE OF CONTENTS

                0. Changes in this Document

                1. Introduction
                    1.1 What is PARCP
                    1.2 Why should you use it?
                    1.3 Features
                         1.3.1 Supported computer platforms
                         1.3.2 Parallel port type (IBM only)
                         1.3.3 Operating systems
                         1.3.4 Multitasking
                         1.3.5 User interface
                         1.3.6 Internals
                         1.3.7 New features since last release
                         1.3.8 Summary
                    1.4 Future Plans
                    1.5 How much does it cost?

                2. Additional required hardware
                    2.1 PARCP cable
                    2.2 PARCP UNI-BI adapter (IBM only)

                3. Installation
                    3.1 Requirements
                    3.2 PARCP Concept
                         3.2.1 Server and Client
                         3.2.2 Running Server
                         3.2.3 Running Client
                         3.2.4 Client's commands
                    3.3 State of parallel port
                    3.4 Before running it...

                4. Configuration
                    4.1 CFG directives reference
                         4.1.1 System Specific Section
                         4.1.2 General Section
                         4.1.3 Debug Section
                         4.1.4 PARCP.CFG example
                    4.2 Command line parameters
                    4.3 Configuration under Client

                5. Miscellaneous
                    5.1 DISCLAIMER
                    5.2 Hints

                6. Resources & Acknowledgments
                    6.1 Related programs
                    6.2 Resources
                    6.3 Greetings
                    6.4 Contacting the author


0. Changes in this Document

Minor changes cover new commands (section 3.2.4).

1. Introduction

This is the second try of an useful documentation, I'm not good at that...
Please read it if you can.

 1.1 What is PARCP?

PARCP stands for PARallel CoPier. It does copy files between two computers.
It acts as a file network running over parallel ports of those computers.
This allows you to copy many and large files very quickly from one machine
to another.

 1.2 Why should you use it?

Because you have two computers at a place (home, college, a computer party)
and you want to copy files between them.

If the computers are not connected by a real ethernet based network nor by
SCSI bus (Note: home computers are usually *NOT* connected by these expensive
and complicated interfaces) then PARCP is the fastest way of copying files
between the computers.
Often people tend to use serial (null-modem) connection since it's simple
and cheap, but it is also very slow compared to PARCP. PARCP is simple and
cheap, too, but is usually more than eight times faster than a serial network.

You've got only one computer so you think you don't need PARCP? Well, and what
if your friend comes to you to show you his new notebook with a lot of new
shareware and freeware files? :-)

Important note for Atari users who want to burn their own CD: PARCP is
usually the only sensible way of transferring 700 MB of data from ST to IBM
with CD-ROM Writer...

 1.3 Features

   1.3.1 Supported computer platforms

PARCP has been designed to work on two different computer platforms:

  o Atari ST/STE/TT/Falcon and compatible computers (Medusa/Hades).
    PARCP is also compatible with all sorts of accelerated cards such
    as AfterBurner040 for Falcon etc.

  o IBM PC 386 and compatible clones (i.e. machines with 32-bit CPU).
    PARCP has been tested on AMD 386, Intel 486, Intel Pentium
    and Cyrix 6x86 processors.

(I will use the word Atari as a reference for any of the former computers
 and the word IBM for any of the latter ones in the rest of this document)

The main feature of PARCP is the ability of connecting of any two supported

  o Atari <-----> Atari
  o Atari <-----> IBM
  o IBM   <-----> IBM

   1.3.2 Parallel port type (IBM only)

Parallel ports of IBM computers are basically of two different types:

  o unidirectional
  o bidirectional

The unidirectional parallel port is not able to read bytes on data lines
but has got five additional input lines for various purposes. Nearly all
known programs use these additional input lines for reading 4-bit nibbles.
They use so called 'LapLink' cable and 'LapLink' method of transferring data.

On the contrary, PARCP together with UNI-BI interface can read data
by full 8-bit at once just like on bidirectional parallel port.
Simply said PARCP UNI-BI interface makes you bidirectional parallel port from
your old unidirectional one.
That's why PARCP is usually about two times faster than its competitors!

If you have got an ECP or a EPP parallel port, then PARCP should work
at the full speed and no hardware interface is needed.

Of course PARCP supports all standard parallel ports of IBM - you can
choose which one you will use for PARCP transfers in the config file.

   1.3.3 Operating systems

PARCP comes in three different binary files compiled for three main
operating systems (OS):

  o TOS on Atari (every version from 1.0 up to 4.04)
    Patched TOS (e.g. Kaos) and multitasking OS running on top of TOS
    (e.g. MultiGEM, Geneva) should be OK for PARCP as well.

  o DOS on IBM (perhaps from version 3.3?)
    FreeDOS and multitasking OS running on top of DOS (DESQview,
    Windows 3.x) should be OK as well.

  o Linux-ix86 on IBM (ELF, from v1.2.13?)
    I don't mean DOSemu for Linux, PARCP comes as native Linux application!

All three binary versions of PARCP look and behave exactly the same way,
which is handy for user learning its capabilities.

   1.3.4 Multitasking

PARCP runs well under following pre-emptive multitasking OS:

  Atari computers:

    o MiNT
    o MagiC

  IBM computers:

    o Windows95
    o OS/2
    o Linux-ix86

Main PARCP features under these enhanced OS:

  o non-blocking waiting for user action
    PARCP doesn't hog OS nor CPU while waiting for user - the average load
    is close to zero when PARCP is idle. Therefore other applications
    continue working at full speed when PARCP is waiting...

  o support of long file names
    PARCP allows you to copy files from one operating system to another
    with original long file names preserved. Some rather unusual combinations
    of possible transfers of long file names between different environments
    are listed here:

    o Windows95's V-FAT <-----> MiNT's minix-fs
    o Linux's ext2-fs   <-----> MagiC's V-FAT
    o MiNT's ISO9660    <-----> OS/2's HPFS

   1.3.5 User Interface

PARCP features easy to use, ftp-like command driven user interface. The working
environment can be utilized to personal needs by many switches and parameters.

PARCP can also transfer files by simple drag&drop of selected files onto
PARCP's icon on desktop (really handy and fast).

   1.3.6 Internals

PARCP is fully written in C. Additional assembler routines has been written
for the highest possible transfer speed. The source code is 100% portable
between all platforms and is compiled by GNU C 2.7.2 for all three destination
operating systems - the result is very efficient full 32-bit code.

The support of special features of various operating systems is a matter
of well written GNU C libraries (MiNTlibs on Atari and DJGPP libs on DOS).

It should be very easy to port PARCP to another platform with GNU C compiler
and a little knowledge of the parallel port programming (hi Amiga freaks! :)

   1.3.7 New features since last release

The list of most important changes and features of new PARCP version compared
to previously released PARCP v2.40:

  o DEL command fixed and enhanced
  o new command REN

For more detailed informations please read the file HISTORY.TXT.

   1.3.8 Summary

PARCP runs on Atari as well as on IBM computers, under all well known
operating systems. PARCP uses the best of every combination of hardware and

Of course there are programs for connecting computers via parallel ports,
but only PARCP can connect any two computers thus you need not to learn how
to use three different programs. PARCP is also much faster than its competitors,
supports more operating systems, it's simpler to use and likes multitasking.

 1.4 Future Plans

There are some things left to do, as well as a few things to fix.
The "to do" list is as follows, in no particular order.

  o better timeout handling
  o more commands (deleting a folder, renaming a file)
  o CRC of copied files for 100% safety
  o file manager similar to Norton Commander

Write me if you want another feature...
Other neat features would be:

  o mapping remote drive as a local network drive (using MetaDOS or MiNT)
  o perhaps a port of PARCP to Amiga computers?

But I haven't got enough docs (nor encourage!) at this time.

 1.5 How much does it cost?

PARCP is shareware. Everyone can distribute PARCP providing the
distribution archive remains unchanged and is distributed free of charge.

If you find the program useful and intend to continue using it you are
honour bound to pay the Shareware fee to the author. Please refer to the
SUPPORT.TXT file for informations how to register PARCP.

Since I have to earn my living and there is so much other things to do, you
should contribute if you would like to see newer and better versions of PARCP.
I have been working on this project for more than nine months so I would be
really glad to receive a reward for it. Sending me a small amount of money
would be very kind and would encourage me to continue working on this project.

A list of already registered users is in the SUPPORT.TXT file - please
read there how many people find PARCP worth registering.

2. Additional hardware

 2.1 PARCP cable

The following diagram shows you how to build your own parallel cable for
use with my PARCP (PARallel CoPy). This cable allows you to connect your
computer with any other computer if both machines have either bidirectional
parallel ports or UNI-BI adapter fitted.

The cable is not sold anywhere, as far as I know. You have to build it
yourself. Please do not try to use a LapLink cable - this one won't work
with PARCP! It's not that hard to modify it to work with PARCP, though.

The easiest way how to build the cable is to buy a cable for dataswitch.
It's usually marked as 25M-25M. That means there are MALE Canon-25
connectors on both ends of that cable. The cable has either 18 or 25 wires
in itself. The 18-wires one is sufficient for our needs, because PARCP uses
only 11 wires. When you buy that cable, you just need to exchange wires on
pins 1 an 11 at one ends of cable (and to cut the wires on unused pins such
as pin 10,12,13..24).

The PARCP cable should consist of just 11 wires. The wiring diagram is as

Canon-25 MALE                      Canon-25 MALE
-------------                      -------------
pin         connection             pin
 1 ............................... 11  (Strobe -> Busy)
 2 ...............................  2  (Data 0)
 3 ...............................  3  (Data 1)
 4 ...............................  4  (Data 2)
 5 ...............................  5  (Data 3)
 6 ...............................  6  (Data 4)
 7 ...............................  7  (Data 5)
 8 ...............................  8  (Data 6)
 9 ...............................  9  (Data 7)
11 ...............................  1  (Busy <- Strobe)
25 ................................25  (GND <-> GND)

This cable also works with ST-Trans (c) Atari 1992, with plip protocol of
MiNT-Net (c) Kay Roemer and with HDD_DMN3 by MC Soft&Hard.

Warning: if the cable length should exceed 5 meters, please get a cable
with proper metal shielding, otherwise random errors during transfer may

 2.2 PARCP UNI-BI adapter (IBM only)

The UNI-BI HW adapter for PARCP is my own invention. It allows software to
use originally unidirectional parallel port of old IBM PC's as new, fast
bidirectional one. PARCP can't use unidirectional port without this simple
hardware interface. In other words: if PARTEST.EXE detects your parallel
port as unidirectional, you must plug this interface into that port and let
PARCP know that the interface is plugged by line UNI-BI = TRUE in your
PARCP configuration file.

The UNI-BI adapter again is not sold anywhere, but you should be able to
build one yourself.

You need to buy/find_at_home:

  o 1x connector Canon-25 MALE
  o 1x connector Canon-25 FEMALE
  o 1x IC 74HC257
  o 1x IC 74HC574
  o 1x plastic cover of Canon-25 - Canon-25 reduction
  o some thin wire and solder iron (yes, you have to solder :-)

The plastic cover looks like this:

        +--+                 +--+
        |C |_________________| C|
 this   |A         a          FA|  this
 side   |NM  I   bunch   I    EN|  side
 plug   |NA  C    of     C    MN|  ready
  to    |OL  1   wires   2    AO|   for
 IBMPC  |NE                   LN|  PARCP
printer |2  _________________ E2|  cable
 port   |5 |                 | 5|
        +--+                 +--+

  The wiring diagram of UNI-BI HW adapter is as follows:

UNI (PC port)                      BI (PARCP cable)
Canon-25 MALE                      Canon-25 FEMALE
 1 ..............................  1
 2 -> IC1.2              IC1.19 <- 2
 3 -> IC1.3              IC1.18 <- 3      The IC's are also wired together:
 4 -> IC1.4              IC1.17 <- 4
 5 -> IC1.5              IC1.16 <- 5      IC1.10 ..... IC2.8 + IC2.15
 6 -> IC1.6              IC1.15 <- 6      IC1.11 ..... IC2.1
 7 -> IC1.7              IC1.14 <- 7      IC1.12 ..... IC2.10
 8 -> IC1.8              IC1.13 <- 8      IC1.13 ..... IC2.6
 9 -> IC1.9              IC1.12 <- 9      IC1.14 ..... IC2.13
10 -> IC2.9                               IC1.15 ..... IC2.3
11 .............................. 11      IC1.16 ..... IC2.11
12 -> IC2.7                               IC1.17 ..... IC2.5
13 -> IC2.12                              IC1.18 ..... IC2.14
14 -> IC1.1                               IC1.19 ..... IC2.2
15 -> IC2.4                               IC1.20 ..... IC2.16
16 -> IC1.20 + IC2.16
17 -> IC1.11 + IC2.1
25 -> IC1.10 + IC2.8 + IC2.15 ... 25

IC1 = 74HC574
IC2 = 74HC257

I think the *HC* is important, because both IC's eat current from PC's
parallel port and the maximum draw from it can be about 10 mA only IIRC.

If you didn't understand the diagram above, drop me a note and I'll try to
explain it better.

3. Installation

 3.1 Requirements

   Atari PARCP:

TOS version of PARCP comes in two versions (PARCP.TTP and PARCP030.TTP).
PARCP.TTP is compiled for MC68000 and therefore will run on every TOS
compatible machine.
PARCP030.TTP is compiled for MC68030, so it will not run on plain ST or STE,
including Mega ST/STE. It however will run on ST equipped with PAK68/3,
and of course on a TT030, Falcon030, Medusa T40/T60, Hades40/60 and all
other clones with processors MC68030/40/60.
Note: FPU is not required to run PARCP030.TTP.

Atari PARCP requires one ST compatible parallel port (driven by Yamaha YM-2149
and by MFP 68901). The Atari compatible parallel port is bidirectional
by nature, so for Atari you don't need any hardware interface...

   Common requirements for IBM PARCP:

PARCP is full 32-bit application thus it requires an Intel 80386 or compatible
CPU (386SX will do, as well as AMD, TI or other equivalents). PARCP can't
run on 80286 or lower CPU, unfortunately (should not be a real drawback
nowadays, I think :-)
PARCP runs fine on all 486SX/DX, Pentium, 6x86 and other compatible
processors, of course.
Note: FPU is not required to run PARCP.EXE.

PARCP requires one IBM PC compatible parallel (= printer) port, naturally.
You must specify parallel port's base address to let PARCP know which port
it should work with.

   IBM parallel ports:

If you choose an unidirectional parallel port (you can check it out by running
PARTEST.EXE), you must plug the UNI-BI hardware adapter into the parallel
port and tell the PARCP that you use the UNI-BI adapter (the description of
UNI-BI adapter is in section 2.2 of this document).

If you've got an ECP parallel port and PARTEST.EXE detects it as a
unidirectional port (even if it is not), it must be switched into EPP mode
(most ECP ports have EPP mode as well).

In most modern IBM and compatible machines you can use the Bios setup
(entered right after reboot by pressing the Del key, usuallly)
for selecting the type of your parallel port. For example on my machine
(Soyo 5VA motherboard) I can choose between SPP, EPP, ECP and ECP with DMA
modes. For PARCP the best is the EPP parallel port mode, though the others
work OK as well. But that again maybe a special facility of my Bios, so
please always select the EPP mode, if possible.

On some older additional ISA cards with parallel port you can usually select
the type of parallel port by setting up some jumpers on the board (see manual
of your motherboard/parallel ports card).

Both parallel port's base address and the use of UNI-BI adapter are specified
in PARCP configuration file (see detailed description of that configuration
file elsewhere in this document).

   DOS specific requirements:

PARCP is designed to be run in a DOS environment. It however works very well
under Windows95 and OS/2 in a DOS session. PARCP is a 32-bit application,
so it needs DPMI services to run in DOS environment. DPMI services are provided
by QEMM, 386MAX, Windows 3.11 and Windows95 (don't know about OS/2).
If you don't have one of these programs you can use CSWDPMI.EXE (it's enclosed
in PARCP distribution archive). All you need is to place CSWDPMI.EXE into
the %PATH% (e.g. C:\DOS) where the PARCP can find it and run automatically.

   Linux-ix86 specific requirements:

PARCP is compiled under Linux-ix86 2.0.27 (Debian Linux 1.2 distribution).
It's linked statically, so it needs no libraries. I expect PARCP will work
with any current Linux distribution.

In order to get permissions to access the hardware directly it must be run
with root privileges (i.e. run it when you are logged as 'root' - otherwise
it will ends immediately with a core file).

 3.2 PARCP Concepts

This section explains some concepts you must understand to figure out how to
run it and how to configure the PARCP options.

   3.2.1 Server and Client

When both machines are connected by the PARCP cable, one must become the PARCP
Server and the other is then PARCP Client. The Server serves the Client (it
receives or sends files and does other things Client may want).
The Client is that machine you are sitting in front of, usually.
If both computers are side by side, I choose a machine with better keyboard
as the Client ;-)

As you may see, it's up to you which machine will be the Server and which one
will be the Client - it's not important at all, since PARCP behaves always
exactly the same on all supported platforms. The only *very* important thing
is that you must *not* run two Clients or two Servers - this could lead to
a damage of your parallel ports! So please always run only one Server and
one Client!

   3.2.2 Running Server

In order to run the PARCP as Server you have to put the -s on the command line
of PARCP (please have a look at the command line parameters section in this


  Atari users will double click on PARCP.TTP and write the -s parameter into
  the command line window then press Enter.

  IBM users will use a command line interpreter (either standard COMMAND.COM
  in DOS or Linux's shell or anything like that) and put the line parcp -s
  then press Enter.

After starting Server reads the configuration file and waits for connection
with Client. It will wait until a connection occurs or until you press the
Abort Key (it's the combination of Ctrl-leftShift-Alternate on Atari and
Ctrl-C on IBM).

Running PARCP Server simply waits for Client's commands. If it gets a command,
it does what Client wants and then it waits again for another command.
Server quits when it gets the command QUIT from Client.

You can abort the Server anytime by pressing the Abort Key, however
it's not recommended, since the Client couldn't know then that Server
is down already.

When the Server runs under a singletasking OS (TOS/DOS), the whole computer
is blocked until the Server exits. If you don't like this, then simply run
PARCP Server under a multitasking OS (MiNT, MagiC, Linux, Windows95, OS/2)
where it could run in the background. This way you can continue working with
your Server computer while it copies files in background, though the transfer
speed is lower than under a singletasking OS.

   3.2.3 Running Client

By default, when you run PARCP without any command line parameter it
runs as the PARCP Client. After reading the configuration file and
initialization the Client tries to connect with the Server for 10 seconds.
If it is not successful it exits back to desktop or shell.

After successful connection the PARCP Client:

  o sends its parameters to Server (especially the length of block)
    That means if Client's block length differs from Server's one, the
    length of block will be according to Client's configuration file.
    It simply overrides the Server's value for the actual session.

  o checks the actual size of screen
    PARCP is smart - it tries to get the number of lines by tioc() and if
    it fails (or is not supported), environment variables "LINES" and
    "COLUMNS" are read. If the variables are not defined, PARCP counts on
    25 lines with 80 columns (standard TOS/DOS screen size).

  o displays some parameters
    Client shows you current settings for all parameters which can be
    changed on-the-fly...

  o ends up with prompt line:

   >> here you can type commands, the very first should be HELP
      (for discussion about every Client's command please go to next section)

However, if you start PARCP with additional parameters (without the '-'
sign in front of them) they are considered to be filenames destined for
sending to Server. In this case, after sending those files the PARCP Client
sends the LQUIT or QUIT command (please see the discussion of 'QuitAfterDrop'
command) and quits. This quick and easy way of copying files I call Drag&drop
mode, because I expect users will use this feature in GUI (such as Atari's
desktop or Windows95 Explorer) and will copy files by simple dragging them
over PARCP icon and dropping the files onto it.

   3.2.4 Client's commands

Client's user interface is very similar to a ftp client's interface. If you
are familiar with FTP'ing you may need not to continue reading :-) Anyway,
read the next lines, for sure.

Client's commands are either without any parameter or allow/require one
parameter. There are three types of parameters:

  o filename - that is a 'template' or a 'dir'
    'template' is basically a filename which can contain the wildcards
    'dir' is name of a directory or generally a path to a directory
  o boolean value: you must put there ON or OFF (or Yes and No, if you
    prefer it).
  o a number - that's just the PGLEN command's parameter

 If the parameter is in brackets ("[parameter]"), it's not required.
 If you omit the parameter of DIR and LDIR commands they simply display
 all files. If you however omit the parameters of the other commands (HASH,
 CASE,OVER,SUBD,KEEP and PGLEN) they simply negate its value (from Yes to
 No and vice-versa) and display its new state.

 About wildcards in 'template':

 The wildcards recognized by PARCP in the 'template' parameter are
 compatible with Unix's grep command and allows such specifications as
 * or * (equivelant to *.* in DOS lingo). Expressions such as [a-e]*t
 would fit the name "apple.crt" or "catspaw.bat" or "elegant".  This allows
 considerably wider flexibility in file specification.

 In the specified template string:
     `*' matches any sequence of characters (zero or more)
     `?' matches any character
     `\' suppresses syntactic significance of a special character
     [SET] matches any character in the specified set,
     [!SET] or [^SET] matches any character not in the specified set.

 A set is composed of characters or ranges; a range looks like 'character
 hyphen character' (as in 0-9 or A-Z).  [0-9a-zA-Z_] is the minimal set of
 characters allowed in the [..] template construct. Other characters are
 allowed (ie. 8 bit characters) if your system will support them (it almost
 certainly will).

 To suppress the special syntactic significance of any of `[]*?!^-\', and
 match the character exactly, precede it with a `\'.

 General rules for all commands:

 o If the commands begins with the 'L' letter, it's for the Local machine,
   i.e. for Client. Simple example is the DIR command - DIR lists files
   from remote machine (i.e. Server), LDIR lists files from local machine
   (i.e. Client).

 o Nearly all commands (GET, PUT, DIR, DEL, MD) act in the current working
   directory (CWD). The CWD can be changed by the CD command and enquired
   by the PWD command.

 o The path separator in Unix is forward slash ('/') while in TOS/DOS it's
   the backward slash ('\'). PARCP works with forward slashes internally,
   but understands the back slashes, too.

 o Unix mounts drives under normal directories while TOS/DOS uses the form
   drive:\path. If you want to change CWD on Server, please remember which
   operating system runs on it and use the appropriate form of CD parameter.

 o The resulting CWD is displayed in unified form /drive/path, which simulates
   Unix behaviour and is compatible with MiNT/MagiC way of mounting TOS drives
   under universal drive U:\.

   If you don't understand it, never mind. When PWD says "/d/tools" and Server
   runs on TOS/MiNT/MagiC, you know the working directory is on drive d: in
   path \tools\.

 The list of Client's commands is as follows:

  QUIT                 quit both Client and Server. Since PARCP Client
                       wants to be similar to FTP, you can use command
                       Bye as an alias for QUIT.

  LQUIT                quit only Client. Server will wait for another
                       Client session.

  PUT     template     send files matching template from Client to Server.
                       If SUBD is OFF, PUT sends just files matching
                       template, subdirectories are skipped. If SUBD is ON,
                       PUT sends all files and directories matching

  GET     template     receive files matching template from Server to
                       Client. See the PUT command details for SUBD

  DIR     [template]   display list of files matching the template in current
                       directory on Server. If you omit the template DIR will
                       list all files. The alias for DIR is ls.

  LDIR    [template]   display list of files matching the template in current
                       directory on Client. If you omit the template LDIR
                       will list all files. Alias for LDIR is lls.

  DEL     template     delete files matching template on Server. If SUBD is
                       OFF DEL deletes just files matching template. If
                       SUBD is ON DEL deletes also directories. Alias is

  LDEL    template     delete files matching template on Client. See the
                       DEL command above for SUBD description. Alias is

  REN     filename     rename file on Server. REN prompts for new filename.

  LREN    filename     rename file on Client. Similar to REN.

  CD      dir          change directory on Server

  LCD     dir          change directory on Client

  MD      dir          make directory on Server (alias is mkdir)

  LMD     dir          make directory on Client (alias is lmkdir)

  PWD                  prints current working directory on Server

  LPWD                 prints current local working directory on Client

  DRV                  display drives on Server

  LDRV                 display drives on Client

  HASH    [ON/OFF]   - when HASH is On, PARCP displays hash marks (dots :)
                       by every transferred block.
                     - when HASH if Off, the transfer progress is displayed
                       by percentage of the length of transferred file.

  CASE    [ON/OFF]   - when CASE is On, only files matching the template
                       exactly are processed by PUT, GET, DIR and DEL commands.
                     - when CASE is Off, the upper and lower case are
                       considered to be the same (e.g. "AhOj" = "ahoJ").

  OVER    [ON/OFF]   - when OVER is Off, you GET or PUT a file and another file
                       with the same name already exists in the dest. dir,
                       Client asks you whether to overwrite the existing file
                       or just skip the transferred one.
                     - when OVER is On, Client overwrites the file without

  SUBD    [ON/OFF]     SUBD switch affects PUT, GET, DEL and LDEL commands.
                       When SUBD is On, PUT and GET transfers also all
                       matching directories and its files. DEL and LDEL
                       deletes also matching directories. When SUBD is OFF,
                       the commands will transfer or delete just files and
                       not directories.

  KEEP    [ON/OFF]     KEEP On means that timestamp of copied files (date and
                       time of file creation) will be preserved.

  PGLEN   [number]     PGLEN sets the length of view page for DIR command.
                       PARCP is very smart in determining the size of screen
                       (it checks the TIOCGWINSZ and environment variable
                       "LINES") so you shouldn't need the PGLEN command.
                       If you would like to change the length of view page,
                       anyway, do it anytime by PGLEN. With PGLEN 0 the DIR
                       listing never stops.

  STAT                 just diplays current settings of switches

  SAVE                 saves current settings into PARCP configuration
                       file. Please note that comments on updated lines
                       will be deleted.

 3.3 State of parallel port

 Standard parallel port is set to output state (all data lines are set for
 output) by default. It's dangerous to connect two parallel ports together
 with the PARCP cable when both ports are in output states.
 That's why I included the programs PAR_IN and PAR_OUT into the PARCP

 When you run PAR_IN, it reads PARCP configuration file and sets the parallel
 port into INput state. When one or both ports are in input states, it's OK
 to connect them by PARCP cable.

 When PARCP quits it sets the parallel port into input state, too (that's
 a must, otherwise your ports might be damaged). So after running PAR_IN
 or PARCP itself the port is in input state and everything is fine.
 However after rebooting of your computer the parallel port is set to output
 state again. If you use PARCP regularly it might be a good idea to let
 PAR_IN start automatically as soon as the operating system boots.

 Let's say you would like to disconnect PARCP cable and connect printer
 cable into your parallel port without turning off the power. It's ofcourse
 forbidden to connect or disconnect any cable to/from parallel ports of
 *running* computer by all known manuals and documentations of printers and
 computers - but if you really want to do it, you would need to run PAR_OUT
 after disconnecting the PARCP cable and before you start printing on your

 3.4 Before running it...


On IBM you should check the type of parallel port first. The PARTEST.EXE
programs lets you choose the parallel port number: press number 1, 2 or 3
to indicate which parallel port you want to use for PARCP. PARTEST.EXE
will then determine the base address of that parallel port and ask you
kindly to remember the value of address and to put it into PARCP.CFG file

It will also check the type of parallel port and write you whether to use
the UNI-BI adapter or not.

If you won't use the UNI-BI HW adapter you should connect the parallel
cable only after starting PARCP or PAR_IN on one computer (at that time its
parallel port is switched to input state and can be connected with the
other parallel port without a risk of damage both parallel ports).

When using UNI-BI adapter the parallel ports are relatively safe.

Before connecting the cable please make sure the computers are on the same
electrical ground otherwise you will get a nice fire in cable and parallel
ports (You have been warned!). Putting both computers' power cables to the
same power outlet is always a good idea.


PARCP is configured through a normal ASCII file: "PARCP.CFG". You can
edit it with any file editor to change the default behavior of the emulator.

The first time you will run PARCP, there are a few things that must be
adjusted that depend of your system. Please have a look at system specific
section of PARCP configuration file (chapter 4.1.1) for details, but the
most important thing is to indicate PARCP what parallel port it should
work with and whether you have plugged UNI-BI HW adapter into the port or not.

4. Configuration

The configuration of PARCP is done by editing PARCP.CFG file (it's a plain
ASCII text file). PARCP reads it at startup. It searches for the PARCP.CFG
at several places:

  o first it looks for PARCP.CFG in the $PARCPDIR directory

  o if it fails, PARCP searches for PARCP.CFG in the directory it was run

  o at last it searches in actual folder

When it finds a valid PARCP.CFG, it will load it and stop searching. When
doesn't find the PARCP.CFG file, it will create one with default values
(handy in case you need to start editing the PARCP.CFG from scratch).

 4.1 PARCP.CFG directives reference

all tabs, spaces and texts after ';' and '#' up to end of line are ignored.
For boolean variables use either TRUE|FALSE or YES|NO - both answers are

    4.1.1 System Specific Section

 FastRoutines   = [yes|no]  if YES, PARCP will use fast assembler routines
                            for communication. The default is YES. Use NO
                            only if you have encountered problems with PARCP
                            communication. This command is Atari specific,
                            since assembler routines for Intel CPU haven't
                            been written yet.

 Port           = <adr>     base address of parallel port (in hex!).
                            The default address is 378 (LPT1), other usual
                            addresses are 278 (LPT2) and 3bc (LPT3). For
                            correct value look either at startup screen of
                            your Bios or use PARTEST.EXE which can
                            determine the base address from Bios. This
                            command is IBM specific, because Atari computers
                            I know have only one parallel port.

 UNI-BI         = [yes|no]  if YES, PARCP will use routines for UNI-BI HW
                            adapter. Default is NO. This command is also
                            IBM specific, because Atari computers' ports
                            are always bidirectional.

    4.1.2 General Section

 ProcessSubDir  = [yes|no]  indicates whether to send also subdirectories.
                            Default is YES.

 CaseSensitive  = [yes|no]  if NO, upper and lower cases in filenames are
                            considered to be the same. Default is NO.

 Overwritting   = [yes|no]  if YES, PARCP will overwrite existing files
                            without asking. Default is NO.

 KeepTimeStamp  = [yes|no]  if YES, copied files will have the same date
                            and time of creation as have the original files.
                            Default is YES.

 HashMark       = [yes|no]  if YES, PARCP will display a hash mark ('.')
                            every transferred block.
                            if NO, PARCP will display the progress
                            in percentage of length of transferred file.

 QuitAfterDrop  = [yes|no]  if YES, Server will exit after receiving
                            drag&dropped files. That's handy for single
                            file copying - just run the Server (usually by
                            a hotkey) and drop a file onto Client's icon...

 BlockLength    = <n>       length of transferred block in bytes - the
                            longer block, the faster transfer but the less
                            often the screen gets updated with progress
                            info etc.

 DirectoryLines = <n>       number of lines for directory buffer
                            one line in directory buffer takes about 60
                            bytes. If a directory has more than <n> lines,
                            they won't be shown.

 FileBuffer     = <n>       length of buffer in bytes for additional file
                            buffering. Try to increase this value for
                            better performance.

 Timeout        = <n>       the timeout value in seconds. The default value
                            (10 seconds) should be enough, but increasing
                            this value might help when the response time
                            from Server is too long and Client quits with
                            "Timeout" during DIR or GET commands.

    4.1.3 Debug Section

This is only useful for beta-testers and those who want to examine PARCP's
behaviour, trace internal routines, remember tranferred files...
You need to have a "debug" distribution of PARCP for this.

 Debug          = <n>       debug level

 LogFile        = <file>    name of logfile, where all the informations
                            are written into.

 NoLog          = <string>  string of characters

 NoDisplay      = <string>  string of characters

    4.1.4 PARCP.CFG example

# configuration file for PARCP v2.30 (9.6.1997)
Port           = 378    # parallel port base address (in hex!)
UNI-BI         = TRUE   # use UNI-BI HW adapter
FastRoutines   = TRUE	# use fast assembler routines
ProcessSubDir  = TRUE	# send also files in directories
CaseSensitive  = FALSE	# don't distinguish between upper and lower case
Overwritting   = FALSE	# ask before overwritting a file
KeepTimeStamp  = TRUE	# keep the time-stamp of copied file
HashMark       = TRUE	# put a hash-mark every transferred block
QuitAfterDrop  = TRUE	# quit the Server after receiving a drag&dropped file
BlockLength    = 131072 # the length of block is 128 kB
DirectoryLines = 200	# no more than 200 files in a directory
FileBuffer     = 262144 # file buffer is 256 kB (should be >= BlockLength)
Timeout        = 15     # Timeout is set to 15 seconds

 4.2 Command line parameters

Many command line parameters known from previous versions of PARCP have
been eliminated thanks to configuration file. The only valid options are:

        -s                     run PARCP as Server

        -f <file>              path to alternate configuration file

The alternate configuration file can be used for different configuration
sets. When the entered filename of configuration file is valid, the
configuration file will have the highest priority and will be used
instead of other configuration files found in home directory etc.

PARCP Server ignores any other parameters on command line.

PARCP Client takes all other words (without the '-' sign) on its command
line as names of files or directories to be sent to the Server. If your
environment supports so called `drag & drop', simply put the files or
directories onto PARCP icon and they will be copied to Server (into the
current working directory of Server). The Client will exit after sending
those files. Whether the Server will quit as well or will wait for another
PARCP session is defined by the directive QuitAfterDrop (see 4.1.2).

 4.3 Configuration under Client

Under PARCP Client you can change values of ProcessSubDir (SUBD),
CaseSensitive (CASE), Overwritting (OVER), KeepTimeStamp (KEEP) and
HashMark (HASH). All these changes are active only in the current PARCP
session, after quitting it the values stay as they are in PARCP.CFG.
If you would like to keep the current settings, use the SAVE command to
store your settings into PARCP configuration file.

5. Miscellaneous


    The author accepts no liability for any damages to users or to third
parties, arising in any way out of the use of the PARCP, PARCP cable and
    Do not expect endless support if you are using an unregistered version.
I am always interested in bug reports, however, and any major ones will
probably get fixed.

 5.2 Hints

  o you can create your own batch (DOS) or script (Linux) file called e.g.
    PARSERVE which will contain just the 'parcp -s' line. This way you
    could start the Server more easily.

  o if you use PARCP regularly you most probably won't disconnect the PARCP
    cable from computers. Then it's important to start PAR_IN on one or
    both computers after reboot as soon as possible (because every reboot
    of computer sets its parallel ports to output state which is dangerous
    for the other computer). That's why I suggest you to put PAR_IN.PRG
    into your AUTO folder (Atari) or PAR_IN.EXE into AUTOEXEC.BAT (DOS).

  o PARCP doesn't check the transferred files agains errors yet. If you
    want to be 100% sure that the copied files are OK, you can compress it
    with ZIP, LHarc, ARJ or similar compress program, which holds a table
    of CRC (a checksum). Then you can test the transferred file if it can
    be unpacked. However I copy megabytes of data by PARCP every day
    without any single error so far.

6. Resources & Acknowledgments

 6.1 Related programs

   o ST-Trans (c) Atari 1992
     With simple GEM interface full of bugs and rock-solid but slow
     routines it's not a competitor for me. However I got inspired by the
     handshake method used there...

   o MiNT-Net (PLIP driver) (c) Kay Roemer
     PLIP driver is a modified SLIP driver for parallel port. Can connect
     two Atari computers running MiNT and MiNT-Net. It's interrupt driven,
     so it's slower than PARCP. It's a real NET, though.

   o HDD_DMN3 (c) MC Soft&Hard 1997
     HDD Daemon is a complete solution for people with poor Atari ST
     without harddisk but with an IBM computer. HDD_DMN will connect those
     computers so Atari is able to read IBM's harddisk.
     Interesting piece of software, but a bit complicated for me.

   o PC2Am (c) Michal Kara AKA Lemming
     PC <-> Amiga parallel network software. Powerful and fast (100%
     assembler). Helped me in the beginning with bidirectional parallel
     ports programming.

 6.2 Resources

        PARCP Home Site:

        Official PARCP site. Up-to-date versions, on-line history file.

        Official PARCP ftp server.

        PARCP Support Site:

        CyberSTrider site with latest releases of the shareware and demo


I wish to thank the following persons:

Michal Kara        For the informations about IBM parallel port programing
                   and for complete source code - great inspiration!

Ian D. Gay         For the idea of PARCP Server and Client similar to PARCP
                   and source code of basic CLIENT/SERVER program

J. Kercheval       For his REGEX Globber

Jeffry J.Brickley  For the idea of configuration file stuff
                   and source code rev. 1.1.0 (a lot of bugs in it! :-)

Lukas Macura       For his HDD_DMN - it's a great competitor! :-)

Mike De.Petris     For betatesting and useful suggestions

Koos Kuil          For betatesting, bug reporting and for the 1st registration

People behind GNU  For the great GNU C compiler

Frank Naumann      For his GNU C 2.7.2 MiNT port

D.J.Delorie        For his DJGPP (GNU C 2.7.2 DOS port)

Frederic Gidouin   For his PaCifiST doc file I got an inspiration for
                   this documentation from.

My wife Leona      For her support and love.


Feel free to send any bugreports, suggestions, remarks, registrations...

netmail:     2:421/ or 90:1200/2@nest.ftn
snail mail:
             Petr Stehlik
             Pod Tlustou 5083
             CZ-760 01  Zlin
             Czech Republic

External Links