"Unidirectional" parallel port isn't really unidirectional.
Yes, data lines are unidirectional - output only, but there are also status lines - input only.

It only takes a properly wired cable - and appropriate software - to transfer data in both directions:
http://www.hardwarebook.info/LapLink/InterLink_Parallel

While certain parallel ports are "bidirectiona" in that the outputs pins
can be access as inputs, this can be very fast, as software which takes
advantage of it can move 8-bits at a time... but very little software uses
this as it's not always the case (most aren't) and it's quite possible to
move data almost as fast using the standard input/output signals 4 bits
at a time.

When using a parallel connection with my DDLINK file transfer tool, it uses:
D0-D4 as outputs -and- ERROR, SLCT, PE, ACK + BUSY is inputs.

If you want more information, cable wiring and details of how the transfer
signalling is done, it is all described in the DDLINK documentation (DDLINK is
a free download from my site below).

Of course if you want to communicate with a Model-100 or something like that,
you'd have to make sure these standard signals are software readable, and you'd have to
write software to do so. I'm not too families with the Tandy 1000 - IIRC it's a fairly basic
DOS system (like PCjr)... but I have and still use a few Model-100 - certainly would be
possible to write a .ASM program to transfer data ... but you would still have to do that.

I don't know of any OS that directly supports generalized bidirectional parallel port
transfers, but I've see it done by things like DDLINK, LAPLINK, INTERSVR are more.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Grzyb wrote on 2024-11-18, 02:39:

... It only takes a properly wired cable - and appropriate software - to transfer data in both directions:
http://www.hardwarebook.info/LapLink/InterLink_Parallel

FWIW, this link appears to be dead. A page at the site level responds (appears to be related to
the Mac "Parallels" virtual machine) ... but: ../LapLink
doesn't exist!

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

DaveDDS wrote on 2024-11-18, 03:28:

FWIW, this link appears to be dead. A page at the site level responds (appears to be related to
the Mac "Parallels" virtual machine) ... but: ../LapLink
doesn't exist!

Strange, works for me...
Anyway:

Grzyb wrote on 2024-11-18, 03:54:

Strange, works for me... Anyway: […]
Show full quote

DaveDDS wrote on 2024-11-18, 03:28:

FWIW, this link appears to be dead...

Strange, works for me...
Anyway:

The attachment laplink.png is no longer available

True weirdness - just tried it again and it worked this time!

but I tried it several times a few minutes ago to the point of taking the address
apart and trying increasing parts!

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Looks like plain HTTP works, but HTTPS doesn't...

Grzyb wrote on 2024-11-18, 04:01:

Looks like plain HTTP works, but HTTPS doesn't...

It's probably and older page they've not remover/updated.

But again weirdly, I'm using Chrome on the same PC - the first time I "tried" it ...
I just clicked the link in your message -> "404 page not found" - I literally back-space
deleted the end from the entered address, and once I removed "/LapLink..." it worked
and loaded a "Parallels VM" related page.

The second time I tried, I used the same install of Chrome on the same PC.
(ie: I did nothing "different") this time it worked with the full address -- and I just
checked if I delete back to pre "/LapLink..." it still goes to the same Paralles VM
related page.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

I'm familiar with this topic due to experimentation with Windows 95 Direct Cable Connection and the PLIP packet driver and feature in Linux and BSD.

As previously mentioned, "nibble mode" uses a cable colloquially known as a LapLink cable to hook the parallel ports of two PCs together. Sometimes called a "null printer" or four bit cable. That cable is purely passive. The five data output pins on one side affect the five status lines on the opposite end. Why five? One bit can be reserved to generate an IRQ on the other end so that the PLIP driver doesn't have to constantly poll the port because this is a bit-bang protocol. It can also be used as a parity bit.

I do not know why, but IEEE-1284 makes a distinction between "compatibility mode" which refers to ports older than the above scheme and "nibble mode" for IEEE-1284 compliant ports.

There's no reason you couldn't use "nibble mode" on your device.

Byte mode aka PS/2 or bidirectional mode adds new register bits so that software can flip the data bits to be input bits instead of output bits. I've never seen anyone attempt to design a passive cable to hook PCs up using this though as opposed to the 4-bit cable.

ECP and EPP allow for hardware acceleration, e.g. filling up a FIFO inside the parallel port with a buffer of bytes that it can output in sequence without tying up the CPU, or allow the port to output bytes directly from memory using DMA. You need an IEEE-1284 device on the other end of the cable like a Zip drive to do this; you can't use it by connecting ports with a passive cable. The vendor that supplied the Direct Cable Connection parallel driver in Win95 did sell such a "smart" cable (https://web.archive.org/web/20000302202651/ht … pt.com/UCM1.htm) but I've never seen one in real life or even on ebay.

DaveDDS wrote on 2024-11-18, 03:21:

While certain parallel ports are "bidirectiona" in that the outputs pins can be access as inputs, this can be very fast, as soft […]
Show full quote

While certain parallel ports are "bidirectiona" in that the outputs pins
can be access as inputs, this can be very fast, as software which takes
advantage of it can move 8-bits at a time... but very little software uses
this as it's not always the case (most aren't) and it's quite possible to
move data almost as fast using the standard input/output signals 4 bits
at a time.

Hi, that reminds me of something I read years ago..:
I read that it was possible with the older, 80s era Centronics ports to have the outputs working as inputs.
It worked essentially by sheer bruteforce, by applying voltage to the output pins to make the corresponding bits flip.
Of course, I can't recommending this anyone to try. It's just something that came to mind right now.
This "trick" merely worked with the older, dedicated Centronics cards that were built using discrete parts I assume.
Nowadays it would inevitable damage any modern LPT port (they're sensitive to shorts and over current).

Jo22 wrote on 2024-11-18, 11:35:

... it was possible with the older, 80s era Centronics ports to have the outputs working as inputs.
It worked essentially by sheer bruteforce ...

I've seen a couple different methods:

- separate hardware registers to set the pin mode (input or output)
- essentially open-collector outputs (with strong pull-ups) and an input
buffer on the same pins at the same
address - so basically you set the outputs high, then they can be driven
low and you can always
read their current state.

But I find 4-bit mode to be VERY fast! Much faster than serial or even
network.

Basically the only "delay" is how long it takes to do IN/OUT to the LPT
addresses...

Typical 8-bit mode software likes to start/end with the signalling pins in
known states.
Which means two trasitions,,,
- Write 8 bits of date
- Write "DataAvailable" ON
- Wait for "DataRead" bit ON from remote
- Write "DataAvailable" OFF
- Wait for "DataRead" OFF
- Repeat for each byte

4-bit transfers use two transations, which means you can use
both of the control signal states to indicate activity:
- Write high (or low) with "DataAvailable" ON
- Wait for "DataRead" ON
- Write low (or high) nibble with "DataAvailable" OFF
- Wait for "DataRead" OFF
- Repeata for each byte

The 4-bit isn't quite as "efficent" as it looks due to signal "race"
conditions. It's possible that when you write both data and "available"
at the same time, the "available" bit can be seen as having changed
state at the recever before some of the data.
There are three simple solutions:

1) A "special" cable that slow the transfer of "available"
Not a great solution as you need to slow it a lot to guarantee
that it will always been seen as changing last (It's usually
"almost instant" but things can happen). And the added circuitry
to do this makes the cable a lot more complicated.

2) The receiving software reads the pins twice once to detect
"Available" and once again to insure the data has had time to
"catch up" - no "special" cable (other than being a data transfer
cable), and no "extra" transitions on the cable - this is the way
DDLINK works.

3) You could write data then data + available (with the same data)
This is what a lot of software does.. I like 2) better because
it only does one set of transitions at a time on the cable, and
shares the "overhead" between sender and receiver more equally.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

I have an actual laplink cable somewhere in the closet. I've never used it; it had both 25 pin and 9 pin plugs on it. I assumed they were all rs232.

If it also has 9-pin it's just a null modem cable, though that could also be used with LapLink. DigiKey still sells the parallel cables; p/n AK250-3

FWIW, these are a couple little "connect adapters" I made many years ago.
(The one on the right is just to show "What's inside")

They take any 25-pin "straight through" cable and make it into a "serial null
Modem" or a "Parallel Interconnect" (Laplink) cable.

I've got boatloads of various length 25-conductor flat ribbon cables which I
use these with all the time when moving data to/from a non-networked system.

I of course also have plenty of the requiste "off the shelf" 25F<->25F, 25M<->25M,
9F<->9F, 9M<->9M, 9F-25M and 9M-25F for adapting cables to whatever type
is suitable for the systen I'm connecting to.

Makes everything you could need from time to time fit nicely into a fairly
small box.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

so now that I know of a way to have two-way communication via parallel port (even unidirectional ones, it seems), I gotta figure out how to talk to the serial port programmatically.

Hamby wrote on 2024-11-20, 04:57:

so now that I know of a way to have two-way communication via parallel port (even unidirectional ones, it seems), I gotta figure out how to talk to the serial port programmatically.

Depending on what exactly you want to accomplish, you might be able to use my
Micro-C/PC (DOS) development toolset (free on my site):

Its library contains full interrupt-driven serial I/O capability:
int Copen(int port, int speed, int mode, int modem) - Open port (start using)
void Cclose(void) - Close port
void Cputc(char c) - Send character
int Cgetc(void) - Receive character
int Ctestc(void) - Test for received character
int Csignals() - Read modem signals (DSR, CTS, CD, RI etc).

These functions can perform as full binary transfers, or with XON/XOFF flow
control.

If Micro-C itself won't work for your requirements, you can see the source
code to these functions which I've released as part of my "Retirement project"/
look for MICROC -> PCLIB -> COMM.ASM

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

DaveDDS wrote on 2024-11-20, 12:29:

Depending on what exactly you want to accomplish, you might be able to use my Micro-C/PC (DOS) development toolset (free on my s […]
Show full quote

Depending on what exactly you want to accomplish, you might be able to use my
Micro-C/PC (DOS) development toolset (free on my site):

Its library contains full interrupt-driven serial I/O capability:
int Copen(int port, int speed, int mode, int modem) - Open port (start using)
void Cclose(void) - Close port
void Cputc(char c) - Send character
int Cgetc(void) - Receive character
int Ctestc(void) - Test for received character
int Csignals() - Read modem signals (DSR, CTS, CD, RI etc).

These functions can perform as full binary transfers, or with XON/XOFF flow
control.

If Micro-C itself won't work for your requirements, you can see the source
code to these functions which I've released as part of my "Retirement project"/
look for MICROC -> PCLIB -> COMM.ASM

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Thanks but I was thinking more in terms of parallel coms, not serial coms 😀

Hamby wrote on 2024-11-21, 00:54:

Thanks but I was thinking more in terms of parallel coms, not serial coms 😀

Here is an overview. We're assuming it's a bare-bones, output only parallel port.
For LPT1: your data port (output) is 378h. Whatever you put there goes to pins 2-9 of the parallel port.
Your status port (input) is 379h. The bits in it are 0:reserved, 1: reserved, 2:IRQ, 3:ERROR#, 4:SELECT, 5:PAPER_OUT, 6:ACK#, and 7:BUSY#
For more detail, https://wiki.osdev.org/Parallel_port

Assuming your LapLink cable has standard pinout, bits 0 through 5 go to pins 15(ERROR#), 13(SELECT), 12(PAPER_OUT), 10(ACK#), and 11(BUSY#) on the other side. Now we see the reason for the pinout. So, whatever we write to the output port is shifted to the left by 3 bits at the status port at the other end. Despite a few of these status lines being marked as active-low, it is only BUSY# that appears inverted at the other side, when using a null-printer cable (https://bitsavers.org/pdf/ibm/pc/pc/6025008_P … rence_Aug81.pdf p. 2-68).

The other piece to mention here is that when set up properly, the parallel port will generate an IRQ 7 on the proper transition of the ACK line. That allows your nibble-mode parallel port code to transition between idling and intensive bit-banging polling-mode operation. The latter is needed when exchanging nibbles to make it fast. It is a per-nibble, stop-and-wait protocol between the two sides. Another general rule is to not accept the value of the status port until it doesn't change on two consecutive reads (and you might have some number of microsend delay on reading it too).

You could review the Linux plip_send for an idea: https://github.com/torvalds/linux/blob/master … lip/plip.c#L710

Basically the sending protocol there is:

1. Place the low nibble on bits 0 through 3 of output and set bit 4 to zero. Then flip bit 4 from zero to one. This causes the BUSY# line to transition from one to zero on the opposite end.
2. Continue reading from the status port until bit 7 (BUSY#) is zero, meaning that the other side has set bit 4 to one on their end, acknowledging the incoming nibble.
3. Place the high nibble on bits 0 through 3 of output, continuing to leave bit 4 set to one.
4. Flip bit 4 from one to zero. This causes the BUSY# line to transition from zero to one on the opposite end.
5. Continue reading from the status port until bit 7 (BUSY#) is one, meaning that the other side has cleared bit 4 on their end, acknowledging the incoming nibble.

If you look at plip_receive, line 484, it is symmetric. Wait until status port until bit 7 clears, then grab bits 3 through 6 as the low nibble. Set output port bit 4. Wait until status port bit 7 sets, then grab bits 3 through 6 as the high nibble. Clear output port bit 4.

Aside from that, the complexity is in the state machine and all in the timeouts, checksums, and other error handling (like collisions) and in triggering the interrupt on the other end when needed.
As you can see at line 859, the implementation idles by writing zero to the output port (so status port bit 6, ACK#, rests at 1), and on line 777, wakes up the other end by writing 0x08 to the output port (causing status port 6, ACK#, to transition from 1 to 0 at the other end, generating an IRQ and waking it up).

Hamby wrote on 2024-11-21, 00:54:

Thanks but I was thinking more in terms of parallel coms, not serial coms 😀

Sorry, I mistook this statement in the post to which I was replying:

"I gotta figure out how to talk to the serial port programmatically."

As wanting to know how to talk serial COMs...

For example code of both Serial, Parallel (and network), you can refer to the DDLINK source code (which does all of these types of transfers)

It's available on my site under my "Retirement project - release 40+ years worth of source code"

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

DaveDDS wrote on 2024-11-21, 03:48:

Sorry, I mistook this statement in the post to which I was replying: […]
Show full quote

Hamby wrote on 2024-11-21, 00:54:

Thanks but I was thinking more in terms of parallel coms, not serial coms 😀

Sorry, I mistook this statement in the post to which I was replying:

"I gotta figure out how to talk to the serial port programmatically."

As wanting to know how to talk serial COMs...

For example code of both Serial, Parallel (and network), you can refer to the DDLINK source code (which does all of these types of transfers)

It's available on my site under my "Retirement project - release 40+ years worth of source code"

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

I'm sorry, I never caught that; it was my mistake. I should have said "parallel".