Re: Help Transporter _modem_

[dempson@actrix.gen.nz (David Empson)]

In article <9408162021.tn35872@aol.com>,  <JohnJ76@aol.com> wrote:
>   
> Hello:
>   
> 	Please allow me to take a few moments of your time and thank
> those that have been so willing to give advice, comment, and for
> having encourage me regarding the dilemma I have encountered with
> high speed modem transmissions with AE's PC Transporter.

I've never got the PCT working faster than 2400 (at least, an
effective data rate of 2400).  Without an accelerator in my IIgs, it
can't even quite manage 2400 transmission.

> > Tom O'Neill <tdon@delphi.com> writes in part:
> > I'm looking for a more current copy of the PCT software ...
> > v2.0.4 or 2.0.5
> 
> Mr. O'Neill, I have 2.04.  Send your snail mailing address to me at
> <jax@tenet.edu> Cc <JohnJ76@aol.com> .  Be sure and reference
> this!  If anyone has the 2.0.5 let me know too!

Does anyone know what the difference is between 2.0.5 and 2.0.4?
AEPC.SYSTEM in 2.0.5 says 2.0.4 on the title screen.

Does anyone know if there is a legitimate source for PCT software
updates, now that AE is no more?

> I don't much think the Transporter is capable of running Windows.
> Remember, it thinks it is an 8088.  If I am not mistaken, it takes a
> 80286 or better to run Windows.  It will run MS-DOS 6.2.

Windows 3.1 requires a 286.  I think Windows 3.0 or earlier will work
in "real" mode on the PCT, in 320x200x4 CGA.  Not a pretty sight.  :-)

Of course, it only has 640k RAM available, which means you can't run
much.  Most current Windows programs require 3.1 and/or "standard"
mode, which requires a 286 or better.  Other programs require "386
enhanced" mode, which requires a 386 or better.

I use MS-DOS 5.0, which works fine.

> > Paul Creager <wily@sypal.org> writes in part:
> > It's a limitation of the PCT hardware.  You will not be
> > able to overcome it.  I'm afraid.  ...  The UART must have
> > only a 1 byte "buffer", causing major character loss at
> > high speeds. Better UARTs are available now, but the whole
> > board would have to be redesigned.
   
I'm not quite sure what Paul is talking about here.  The PC
Transporter emulates an 8250 (the standard PC serial chip), which does
only have a one byte transmit and receive buffer, but that is not the
problem.

The problem is that every character transmitted and received by the
PCT has to be processed by the "portware" code running in the Apple
II, and passed through the standard serial firmware.  This adds a
MAJOR amount of overhead.  Accelerating your Apple II will make a
significant difference.

The PCT's portware scheme works by causing the PCT to "freeze" when it
accesses an emulated I/O location.  The code running in the Apple is
watching for a portware access, and is able to detect the PCT's
processor bus state (read/write, address, data, etc.).  It vectors off
to the appropriate handler.  For a read, the handler stores the
appropriate data byte in the PCT, then allows the PCT to resume
execution.  For a write, the the handler reads the data byte from the
PCT and allows it to resume.

> Mr. Creager.  It seems to me that a versed IIGS programer could
> overcome it with a better interface program between the Apple side
> and the PC side. 

Ha!  That would require a lot of work trying to find out exactly how
the PC Transporter works.  I've delved into some parts of
AEPC.SYSTEM, and know enough to understand how the TRANSFER program
works (I could write a better one, but I rarely need to use it, because
I mostly read files from MS-DOS disks, and I have a SuperDrive and
System 6.0.1, with the MS-DOS FST).

I would need to do a lot more work to find out exactly how the
portware works, and the structure of the drivers.  I doubt that much
could be achieved in the end, because you're still limited by the
speed of the serial firmware.  Perhaps if the portware driver also
implemented an interrupt driven serial handler, or bypassed the IIgs
serial firmware...

You might get better results with a Super Serial Card (I've never
tried).

> The other peripherals (CRT, printer, HD) seem to be interfacing
> faster than the 24. 

The video display is built into the PCT and doesn't require software
assistance from the Apple, hence it runs a lot faster than most other
PCT I/O.

A printer may run at a higher baud rate, but will not actually be able
to print characters that fast (a laser printer is a possible
exception), so you just haven't noticed.

(There is nothing stopping you setting the serial port to a higher
baud rate than 2400; you just can't send and receive characters much
faster than 240 per second.)

You're calling the hard drive interface on the PCT fast?  I suppose it
is faster than a floppy, but not much.  Every sector read or write
performed by the hard drive BIOS turns into a ProDOS Read or Write
call (possibly preceded by a SetMark).  This might be bearable on a
RamFAST, but an Apple SCSI card is quite slow under ProDOS-8.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand