Mike's PCjr Page

I am having trouble with receiving files when using FTPSRV. For small files, it may work OK, but sometimes the file sizes don't match. But for larger (>100K) files, the server will timeout or fail to receive them. If it resends, I have seen it append the retransfered file to the next file.

My PCJr. has a jrIDE and a minimal configuration. The hard drive is a 256MB CF card (w/IDE adapter) formatted with only 32MB with DOS 3.3. DEVICE=C:\JRCONFIG\JRCONFIG.SYS /V32. Only the RTC program and CTMOUSE are loaded in AUTOEXEC.BAT. I am using a Xircom PE3-10BC and an (unmodified) IBM Parallel Printer Attachment. There is also the Speech Adapter, 64KB Expansion, 45W Power Board, Internal Modem and Floppy Controller, and the 8088 is being used and the BASIC Cartridge is plugged in.

I initialize the Ethernet Adapter with the following in a batch file :
c:\mtcp\pe3pd sint=60 non
set mtcpcfg=c:\mtcp\tcp.cfg
c:\mtcp\dhcp.exe

My TCP.CFG reads as follows (without the lines added by DHCP) :

PACKETINT 0x60
HOSTNAME PCjr
FTPSRV_PASSWORD_FILE ftppass.txt
FTPSRV_LOG_FILE log.txt
FTPSRV_EXCLUDE_DRIVES AB
FTPSRV_FILEBUFFER_SIZE 16
FTPSRV_TCPBUFFER_SIZE 16
FTPSRV_PACKETS_PER_POLL 10

With these same settings, and a 16-bit Ethernet card, the FTPSRV program handles transfers just fine in my 486.
While I have the ability to make the Parallel Printer Attachment bidirectional, I would really like to make sure unidirectional transfers work properly, slow as they are (but faster and more reliable than a null-modem). Are there any tested settings that would work reliably with this setup?

I should note that I am using Filezilla Client 3.8.0 to transfer files. I have also tried the Xircom with my Tandy 1000SX and even with a bidirectional parallel port, the results are the same. However, if I activate the 286 Express accelerator board, the system does not choke on larger file transfers. However, the FTP client will claim a successful transfer but some of the files transferred are larger on the destination (the PCjr or Tandy) than they were on the source (modern PC).

I set the Transfer Type to Binary in Filezilla and the problem of extra bytes seems to have gone away. I also limited the connection speeds to 25/25KB/sec, and that seems to have helped quite a bit with the file transfers of large files to the system. I also set the maximum number of simultaneous connections to 1. Transferring large files from the older system is still a problem.

The problems with Filezilla are documented in the ftpsrv.txt file:
FileZilla is also ill-behaved in that it thinks it can create multiple connections to the FTP server at once. Which is fine for faster machines, but it is wholly unnecessary and it effectively reduces the CPU and bandwidth available to each open connection. When you have so little CPU and bandwidth to spare, that is a bad idea. The fix is to limit it to one connection at a time and no more than 20 or 30KB of bandwidth per second, as you have discovered.

Part of the culprit here is modern operating systems - they all assume that TCP hosts have large receive buffers. (Large is much greater than 64KB.) When they get a connection from a machine with a small receive buffer they tend to saturate it quickly and screw up the flow control mechanisms.

Your binary mode problem sounds like a user error. Look up the difference between binary and ASCII mode and then you will understand why the files changed.

Okay, on my PCjr., everything is perfect both ways after setting the transfer type to binary, the maximum number of connections to 1, the timeout to 200 seconds and the speed limits to 25K/25K. On my Tandy 1000SX, uploading is a problem, but I have some well-founded suspicions that the parallel port I am using is damaged. The Xircom adapter will not be found unless the Tandy does a warm boot for example, even though it is properly set to LPT2, (or maybe the Interrupt 5 is conflicting with the motherboard video...)

Remember, the Xircom can be setup to not use a hardware interrupt. I think the syntax is int=0. When you do that it will hook the timer interrupt and poll the hardware instead which is slower, but it works well enough for light usage.

Use this mode to test your theory on the IRQ conflict.

Brutman wrote:Remember, the Xircom can be setup to not use a hardware interrupt. I think the syntax is int=0. When you do that it will hook the timer interrupt and poll the hardware instead which is slower, but it works well enough for light usage.

Use this mode to test your theory on the IRQ conflict.

It turns out it was the Interrupt causing the problem. Once I set the video IRQ to 2, the parallel port being set to 5, things started to work perfectly.

GHiero wrote:

Brutman wrote:Once I set the video IRQ to 2

What? On a PCjr?

Trixter wrote:

GHiero wrote:

Brutman wrote:Once I set the video IRQ to 2

What? On a PCjr?

Nah, he's talking about his Tandy 1000SX.

GHiero wrote:The Xircom adapter will not be found unless the Tandy does a warm boot for example, even though it is properly set to LPT2.

I have the same issue on my PCjr. Is there a solution for this? Otherwise, the adapter works just fine...

My Parallel Printer Attachment is set to LPT1/0x378 and is unidirectional, in other words, unmodded.

FWIW, I've done several transfers from the built-in FTP server in OS X Snow Leopard without trouble.