Dacobi wrote:

But when trying Link (Slave/Master) with LPT1 both machines says The LPT1 port is not available after maybe 30sec

After 30 seconds of transferring data successfully, or after 30 seconds of NOT transferring data?
LPT1 uses IRQ7; does the old PC have a SoundBlaster configured for IRQ7?

More likely than an IRQ conflict is that you're using a normal printer cable, not the LapLink cable (which, like a serial null-modem cable, has a crossover in it somewhere, I forget where).

Hi, also keep in mind that LPT ports have different modes. SPP, PS/2, ECP, EPP etc.
Since the program (NC 5.x ?) is ancient, it might be necessary to configure both PC to use the same old modes,
say Centronics/Standard Paralell Port (SPP) or PS/2 (aka EPT, Byte Mode)..

Also: Beware of Windows 9x. It does use probing on both serial and parallel ports.
If a non usual device is connected to the parallel port (not a printer), the parallel port could take damage during probing.
At least the old parallel port has no protection and usually outputs 5v on its pin by default.
If you can, better disable probing for the LPT port. Windows 98SE had a setting (checkbox) for this somewhere, I remember..

Edit: IRQs.. Are they even commonly used on LPT, by Norton Commander in DOS ? As far as conflicts are concerned,
I heard this rather was an issue on Windows 3.1 if both a printer and a sound card were used the same time.

They fail without ever connecting.

The cable is DIN25->DIN25, I've used it to transfer to an Atari Portfolio.

One PC does have a SBPCI with legacy setting IRQ7 but the other one uses IRQ5 and it happens on both PC's, so?
[edit] what I mean is that on the PC with SB on IRQ5, when I set it in NC to slave it also drops out after 30sec.

Can anyone tell me how I change the IRQ on a Creative SBPCI?

Dacobi wrote:

They fail without ever connecting.
The cable is DIN25->DIN25, I've used it to transfer to an Atari Portfolio.

Probably it's the right cable after all.

One PC does have a SBPCI with legacy setting IRQ7 but the other one uses IRQ5 and it happens on both PC's, so?

On the PC with the SoundBlaster PCI, configure the LPT port as LPT2 (which is IRQ5). Or, shutdown and remove the SBPCI and try again. Also, make sure that ECP is not on for either computer's LPT port.

Can anyone tell me how I change the IRQ on a Creative SBPCI?

I think you can change the SBPCI's DOS IRQ in the Device Manager under "SB16 Emulation" or similar.

Wrong forum. This forum is for DOS games on modern systems. Ask old hardware and driver/configuration questions in Marvin. Marvin, the Paranoid Android

Moved.

Jo22 wrote:

Also: Beware of Windows 9x. It does use probing on both serial and parallel ports. If a non usual device is connected to the par […]
Show full quote

Also: Beware of Windows 9x. It does use probing on both serial and parallel ports.
If a non usual device is connected to the parallel port (not a printer), the parallel port could take damage during probing.
At least the old parallel port has no protection and usually outputs 5v on its pin by default.
If you can, better disable probing for the LPT port. Windows 98SE had a setting (checkbox) for this somewhere, I remember..

I did boot Win98 with the cable attached. Does this mean that I've fried my parallel ports?

iirc the original parallel port the driver was 74LS373 or 374. These should be able to be shorted. But the most cards use some LSI, which are often not that robust.
For verifying the pinout of the cable, see for example http://masterberg.se/hberg/CablePinouts/index.htm
And, did you also test using original Laplink and Intersvr/Interlnk, to exclude potential problems with NC?

Hey, thanks for the info! I do tinker with the parallel port sometimes, but I didn't knew what kind of chips it used originally.
Speaking of the Parallel Port, I remember another user even examined a Famiclone device that contained a simple LPT port.
Edit: Just found the link: https://133fsb.wordpress.com/2010/03/21/famic … port-interface/

Dacobi wrote:

I did boot Win98 with the cable attached. Does this mean that I've fried my parallel ports?

Hm. I don't think so, the cable should be harmless. I just mentioned it for the sake of precaution. 😅
The cable probably connects the data pins (output) to the status lines (inputs) and 4-Bits in both directions.
If you're worried, you can run a utility like CheckIt! and start the Parallel Port diagnostic (with a test dongle or no cable connected).

You would probably be better served by installing Ethernet cards and using the DOS TCP stack to transfer files between computers.

Back when this crap was expensive, and software immature, LPT file transfers were possibly a useful idea. But now there are much better ways of transferring data.

canthearu wrote:

Back when this crap was expensive, and software immature, LPT file transfers were possibly a useful idea.
But now there are much better ways of transferring data.

Oh dear, my father could tell many stories about this. 😁
Back then in the 1980s to early 1990, programs like KirschbaumLink(/-Netz), LittleBigLAN and so on were very popular.
They also had good latency, despite lower speeds. The proprietary protocols of that time were slick, fast and comparable nifty.
On RS-232/V.24 networks, they performaned much better than the usual big slugs like IPX, TCP/IP and AppleTalk. 😉

Edit: There also were mixed networks. The software of the day could use Ethernet, LPT and Serial.
Even simultanously on the very same computer. Anyway, Windows 9x also had a simple network program,
which allowed to connect two computers with each other. It was called Direct Cable Connection ("shortened" DCC ?), I believe.

I was getting 300-400kilobyte per second download rate using FTP using the DOS TCP stack on a 286-12mhz using a NE2000 clone card. Even using the Win32s TCP/IP stack, you can easily outperform serial or parallel direct connection cables.

The direct link cables found a market not because they were fast or good, but because they were cheaper and simpler to use then networking back then.

For me, if using Ethernet is too slow/difficult, I move the hard drive into another computer and copy it directly.

One thing for the OP to try, go into the BIOS on the newer computer and make sure the Parallel port is set up correctly. Normal mode (not EPP/ECP) and on the normal port/IRQ for LPT1. Also, the right cable is needed, normal parallel ports cannot read data in off their data lines, so they use the status lines to do this, so you can't just wire the 25 pins from one end directly to the other and have this work.

The reason I tried Parallel port is that I don't have any old network cards lying around, and copying via floppy was killing me.

I tried Interlink but it also kept saying NOT Connected.

This week I should get a IDE2SD Adapter in the mail.

canthearu wrote:

I was getting 300-400kilobyte per second download rate using FTP using the DOS TCP stack on a 286-12mhz using a NE2000 clone card. Even using the Win32s TCP/IP stack, you can easily outperform serial or parallel direct connection cables.

Likely true, though I meant period correct software of the day (say ~'87 to ~'91), prior WfW 3.11 or mTCP/picoTCP.
Back then, the software was differently made. Being targeted (semi-) professional needs, it had APIs for certain task or important programs of the day.
The compilers also were different than what we have to day (~the last quarter of a century).
Last but not least, the type of ethernet wasn't as standardized as it is today.
There used to be ARCnet, Vines and many more, along with different typos of topology (bus vs. star etc.).
And even if cheapernet (10Base2) was used, the card likely was much simpler, lacking built-in FiFos and processing abilities.
All the hardwork or at least a part of it was done by the main processor of the computer.
Speaking of the 286 platform, it was highly fragmented. Most had MFM/RLL drives with a wrong interleave factor even perhaps,
since they were based on used XT parts (motherboard-swap with little change of the other components) and slow RAM (~80 to 120ns).
In these days, a 286 could be anything from a very slow to a decent computer.
By the late 1980s, 286es finally got reasonable company. Simple on-board VGA, ~10-16MHz clock speed,
built-in IDE (sometimes), SIMM/SIPP slots (more than a lousy MiB, finally), built-in mouse ports, 1.44MiB floppy drives etc.
Compared to the original AT/5170 with 512KiB RAM and a 6MHz CPU (ironically, the XT/286 was faster, even)..

canthearu wrote:

One thing for the OP to try, go into the BIOS on the newer computer and make sure the Parallel port is set up correctly. Normal mode (not EPP/ECP) and on the normal port/IRQ for LPT1.

Good idea, I do agree.

canthearu wrote:

Also, the right cable is needed, normal parallel ports cannot read data in off their data lines, so they use the status lines to do this,
so you can't just wire the 25 pins from one end directly to the other and have this work.

[/quote]
Well, strictly speaking you're right. But inofficially, some very ancient parallel ports could read from the data-out pins as well.
If memory serves, this had to do with the internall structure of the 74xxx chips (TTL flavours ?) that were used.
Under certain circumstances it was possible to make them accept signals as input.
This was done by basically overdriving the data pins with a strong signal, as far as I understand (speaking under correction).
Some commercial devices such as digitizer even did that, I heard. Doing that with modern LPT ports would certainly kill them.
Anyway, what I wrote was no criticism. Hope you don't mind. 😀

My recollection of the performance of communications at the time is a bit different.

In the late 1980s the 16550 was pretty common and a welcome upgrade from the 8250. However most machines still topped out at 115,200 bits per second which was limited by the UART. If you assume no protocol overhead or errors that is 14 kilobytes per second. For comparison a 360KB double density diskette drive can do around 11KB/sec. And the machine would be close to useless while you did anything because you'd be furiously polling the UART.

Ethernet, via the inexpensive NE1000 card could do around 60KB/sec, which is far faster than anything using the serial port. And the effective throughput would be faster too, as you'd be re-transmiting less. Office environments were definitely using Ethernet or other packet based network cards, not cobbling together parallel port and serial port networks.

Those cards did not have deep FIFOs, TCP/IP offload, or anything. We're still using those same exact cards on retro machines today, and they performed the same way back then. Compilers were not that much different either; the mTCP numbers for when it was compiled under Turbo C++ are about the same. It's not sensitive to code generation, as most of the sensitive parts (IP checksum) have to be done in assembly anyway.

Back then they would have used something lighter weight, like IPX. TCP/IP would have been overkill so it was not commonly used unless your office was connected to bigger things.

As for the 286 ... even an 8086 with a good Ethernet card can hit 150KB/sec using Ethernet. With the standard card of the day, a 3Com 3C503. The 8086 has a 16 bit bus comparable to an 80286 but a less efficient CPU implementation. An 8Mhz 80286 should be even faster.

mbbrutman wrote:

My recollection of the performance of communications at the time is a bit different. […]
Show full quote

My recollection of the performance of communications at the time is a bit different.

In the late 1980s the 16550 was pretty common and a welcome upgrade from the 8250.
However most machines still topped out at 115,200 bits per second which was limited by the UART.
If you assume no protocol overhead or errors that is 14 kilobytes per second.
For comparison a 360KB double density diskette drive can do around 11KB/sec.
And the machine would be close to useless while you did anything because you'd be furiously polling the UART.

Hi good point, one of my father's old utilites, Ultrafast Filetransfer Operation, says similar numbers.
As it seems, 115200 Baud is -or was- the default speed (-S, slow, uses 57600 Baud) of the program.
(It's just a basic file transfer program, though, uses 3-wire i/o, no compression, no networking, etc.)

As for the other points.. Well, some sort of a benchmark would be nice (in another thread maybe).
The whole point of the smaller networking packages was to allow for simple and quick file transfer, printer sharing, etc.
It would be interesting to see how they perform in comparison to the big software packages of the day. 😀

Edt: Another important protocol besides IPX, TCP/IP and FTP was X.25, now laregely forgotten, sadly.
It was the foundation of what once sevices like CompuServe and other networks ran on.
Not sure how much, if at all, it was used for LANs.. Anyway, i'm going too much off-topic now, so I have to stop. 😅
Edit: Just one thing. Ethernet cards like the 3COMs from 90s were different to prior designs.(link, see chapter 2).

Hmmm, some performance figures I remember from the day for ethernet.

150kb per second using old 8-bit Dlink DE-150 ethernet cards on 486 class machine using NDIS 2.0 drivers on windows 95.
1.5meg odd meg per second using Realtek 8029 PCI ethernet cards.

In the old days, getting good ethernet cards was hard, and ethernet switches were expensive, so I was using thin co-axial based 10mbit ethernet. Hence why I was using the Realtek 8029 cards .... they are pretty terrible cards by any other metric.

Once I changed to switched CAT 5 networking, I get Intel 100mbit based adapters and could pretty much max them out on a 100mbit switch.