Mike's PCjr Page

I didn't find a topic on this so I figured I'd start one so users would have a dumping ground for info and anecdotes on this subject.

What I did.....

So I managed to terminal into my PCjr from My Windows 7 machine using a null modem serial connection

Stats:
PCjr: Stock 8088, 384k ram (onboard 64k+64k internal expansion+2x 128k sidecars), 1 lpt sidecar, 1 serial port adapter, keyboard cable.
OS: DOS 2.1 (w/pcjr ram patch)/ DOS 3.0
Client PC: Panasonic Toughbook CF-52, intel i3, 8gb ram, onboard rs232 serial (COM1)
OS: Windows 7 Professional 64bit
Terminal software: TeraTerm ver 4.105

Seemed to work on both DOS 2.1 and 3.0 but I tried more things through 3.0.

Booted PCjr into DOS prompt.

Commands
MODE COM1:2400,N,8,1,P
CTTY COM1

From here I set up connection on the Toughbook though COM1 (Serial)
Configured SPEED:2400 DATA:8bit PARITY:none STOP BIT:1 FLOW CONTROL:none

CALL

hit enter

A:\dir

That's about it. From here I tried several unsuccessful attempts to transfer data both ways to no avail.
I also discovered that running Basic switched PCjr control back to the keyboard, so that's not very useful.

As you are finding out, the "auxiliary" console support in DOS is effectively useless.

"Well behaved" DOS programs that use the DOS function calls for reading character input and writing characters (TTY style) will work. Programs that do that but also use ANSI-escape codes for screen positioning might work with a simple terminal emulator. But as soon as you use the BIOS to manipulate the screen or read the keyboard it doesn't work; there is no equivalent for those functions over the auxiliary console.

Indeed.

I tried
COPY COM1 A:\
...
COPY COM1 B:\

to no avail before reading in the DOS 3.0 manual that COPY doesn't work over COM1

Sending files using the base protocol On Teraterm produced Abort,Retry,Ignore Errors. While X,Y,Zmodem only locked it up requiring I send a BREAK command to unlock it. Kermit only cycled and stopped, producing no results.

I'm going to try to look for some working terminal software next on 360k floppy.

With luck I'll find one with some X,Y,Zmodem or Kermit protocols and try using that.

I have no working bridge machine so I was hoping this would be a way to transfer some key files.

I'm also gonna try the ram disk method you mentioned in one of your info blurbs.

What exactly are you trying to do - just basic file transfer over the serial port?

I've used Procomm 2.4.3 on the PCjr for years. PC-Talk (both the interpreted BASIC and compiled BASIC) versions are fine too. Zmodem should be fine too. But you've got to have it on diskette already; there is nothing built-in that will let you transfer files like that.

In a pinch you could try something like this for pure ASCII files:

mode com1:1200,n,8,1
copy com1: testfile.txt

(And then send the file from the other machine.)

That works and it is legal because it is a non-binary file transfer. To terminate the transfer you press Ctrl-Z (DOS End Of File character) on the sending machine.

Binary files don't work over the serial port because you can't signal when the end of the file happens.

Does this copy it to the disk (A:) or do I still need to setup a ram disk and the copy it from there?

And yes, I am trying to to basic file copy. My bridge machine, an IBM PS/2 286 is still on the blink and i can't get the external 5.25" floppy drive to work.

Copying to disk files is fine. It's just doing "binary" copies that is the problem.

GOT IT!

Thanks much!

Okay, it worked once then not at all.
Not sure what I'm doing wrong.
Is there a file size limit?

Has anyone ever run Minix, early Coherent or QNX, PC/IX, Venix, ELKS, or Idris on a Jr? They all supported generic 8086/8088 systems at one point. Though impossible to offer memory protection or demand paging, the segmentation scheme does act a bit like a rudimentary MMU for 16-bit relocatable virtual address spaces.

Think about the serial port vs. a disk drive. Serial ports work one character at a time, while disk drives are block oriented.

With a disk file, you know the exact number of bytes to copy. In reality the machine has to copy full blocks, so even if you have just 10 bytes in a file 512 bytes are going to be copied. On a serial port you just get 10 bytes.

So the problem comes in when you are trying to move a file over the serial port. COPY works in either Binary or ASCII mode depending on the source/target and the command line switches. The console (con: or stdin/stdout if using redirects) is ASCII by default, while disk files are Binary by default. In ASCII mode you mark "end of file" by putting a Ctrl-Z at the end of the file or sending Ctrl-Z.

So the problem with sending files over the serial port is simple; it's expecting ASCII mode and a Ctrl-Z to mark the end of the transfer. You can't use binary mode on the serial port because Ctrl-Z has no special meaning anymore (it can appear all over a binary file), and you don't know the number of bytes to read because the file size is unknown in this mode. Which is why copy doesn't support /b when reading from the serial port to and writing to a disk file. (It does support /b when writing a disk file to the serial port because in that case even though it is a binary transfer, it knows the number of bytes to send.) Receiving using the copy command from the serial port is always assumed to be an ASCII only operation, and never can be done in binary mode.

The file size limit is effectively the amount of free space on the disk.

So what did you do that worked once and then stopped working?