Re: //c serial cable

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

<daimyo@powersurfr.com> wrote:

> i've tested my pins with a multimeter so i know the individual leads
> are good.  any suggestions on how to further test the cable?

Assuming the pin numbering has been ordered correctly and you are
plugged into the correct port, the remaining problems that occur to me
are:

- wrong serial port settings (baud rate, data format, etc.)

- speed mismatch problems due to the design flaw of the original IIc
motherboard.

> perhaps i'm screwing up elsewhere.  as per the ADT README documentation,
> i am using a modem program (specificallly telix, configured to the serial
> port in question) with ascii uploads to the //c after typing "IN #2"
> at the //c DOS prompt (incidentaly, i am using prodos when the readme
> suggests DOS 3.3 - problem? i can't imagine how).

I don't think ProDOS vs DOS 3.3 would be an issue.  Either should work
just as well, unless subsequent operations through the port are
dependent on commands or code that is specific to one OS or the other.

If you haven't changed the serial port settings, then the IIc modem port
is running at 300 bps with 8 data bits, no parity and one stop bit.

The printer port's default settings are 9600 bps, 8 data bits, no
parity, 2 stop bits, with some printer-related formatting options
enabled: 80 characters per line, line feed added after carriage return
(transmit).  I'm not sure whether any other mode settings might be
interfering.

I have no idea what ADT wants to do once this connection is established,
but I expect it will send commands down to the Apple II and set up a
small machine code routine to allow binary data to be transferred.

> i also tried redirecting output with "PR#2" but i have yet to see
> evidence of any communication between the two machines.

This is probably a better place to start.  Try to get this working
before worrying about data going the other way.

The key settings in Telix would be the baud rate (300), and disabling
all flow control options.  After that, you should be able to use PR#2 on
the IIc and see any subsequent output come out on the PC.

If nothing works, then I'd be inclined to check the cable, preferably by
going through a breakout box and observing whether any data is actually
being sent by the IIc, and that the appropriate signal lines are being
driven as expected.


It would be useful to know whether you might be affected by the design
flaw I mentioned above.  In BASIC on the IIc, type PRINT PEEK(64447).

If the value printed is 255 then you have the original firmware and
almost certainly the original motherboard, which suffers from this
problem.

If the value printed is 0 then you might have the original motherboard,
or might have a revised version that has the serial problem fixed.
Knowing the history of the machine should help to answer the question
here.

If the value printed is 3 or 4, then you almost certainly have a newer
motherboard (with a memory expansion slot) that does not have the serial
port problem.

If the value printed is 5, then one of us is insane, because you
actually have an Apple IIc+ which doesn't have DIN-5 serial connectors.
:-)


The design flaw is basically that Apple took a shortcut with the
original motherboard to save a little money, and use a readily available
but slightly incorrect clock frequency to drive the serial ports.  This
has the effect of slowing down the serial ports by about 3%, which is
enough to prevent some devices from interacting correctly with the IIc.

The usual symptom is data corruption, not complete lack of
communication, so I doubt this is the problem here.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand