• Please review our updated Terms and Rules here

Apple IIc Serial Port issues

dhoelzer

Veteran Member
Joined
Oct 20, 2012
Messages
523
Location
New York
I'm looking for suggestions on where to focus my efforts. My logic analyzer is in the shop and won't be back until next week, but I have time to work on this over the weekend.

I have two Apple IIc mother boards. Both appear to be fully functional.

The first board works fine with keyboard, disk, serial, etc.

The second board works fine with keyboard, disk and... sorta, serial.

If I hook up a serial line to it and do an IN#2, I can type characters across with no problem at 9600 or 19200 baud. However, if I use something like ADTPro to stream a boot disk, some comes through ok but lots and lots is garbled.

I spent a lot of time swapping cables, swapping USB serial adapters, etc, and finally decided to hook up the other board, discovering that the other board receives serial data with no issues at all.

The big problem is that there's nothing visibly wrong with the board or components and the serial issue seems "intermittent", but not so intermittent that I can successfully transfer anything over serial.

Thoughts?
 
I could of sworn that early revisions of the IIc had bugs with the serial port running at high speeds. Have you tried lower data rates?
 
9600 is pretty low. However, I have tried it at 1200 as well. Still no good.

Additionally, it's a REV 3 ROM and is actually newer than the board that works.
 
I've never seen it actually matter in practice, but it's said that ROM255 machines (PRINT PEEK(64447) returns 255) are some-odd percent slower on serial speeds above 300 baud. Just out of curiosity... is it one of those?
 
Check and replace if easy 1488 & 1489 level converters if these are used in //c like on SSC.
 
I'll check for that. Here's another interesting find:

Memory Expansion fix (ROM version ‘4’)[edit]
In January 1988, a new ROM firmware update was issued to address bugs in the new memory expandable IIc. Changes included better detection of installed RAM chips, correction of a problem when using the serial modem port in terminal-mode, and a bug fix for keyboard buffering. The ROM upgrade was available free of charge only to owners of the memory expansion IIc. This was the final change to the Apple IIc until superseded by the Apple IIc Plus (identified as ROM version ‘5’).

That's from Wikipedia on the IIc. This is in fact a Version 3 ROM. I'm going to see if I can track down a V4 ROM image and, if the chip is socket, upgrade it and try again.
 
Well, I dug up a 27256 and flashed the Version 4 ROM onto it. The system works as well as ever, but the serial transmission is still super flaky. I'm suspecting that there's something iffy about at least one of the components that handles serial IO to the modem port.

If anyone has any other thoughts of things to try I'd love to hear them before I hunker down with the logic probe and the schematics.
 
Alrighty. A whole bunch of experimentation has revealed the following:

IN#2 on the IIc set at 9600 baud (or any other speed): No problems. Able to type characters across reliably.

PR#2 on the IIc set at 9600 baud (or any other speed): Garbled characters sent to the terminal on the other end!?!?!?

So, with no visible issues, what could cause the communication to be completely garbled in one direction? ** Please note ** It's definitely not the cable. Not only can I use this same serial adapter to talk to my Alpha and Vaxen, but I can use it with the IIc cable to talk to another IIc board with absolutely no issues at all.

Thanks!
 
Alrighty. The logic analyzer is back on my bench. Here's what I'm seeing... It sorta looks like the apple is dropping something here. What you're looking at is a fresh start IN#2 PR#2 hooked up through a null modem to a terminal running screen sending the character "t" repeatedly.

If these are the pins when looking into the male end of the connector:

1 5
2 4
-3-

then bit 0 is tied to pin 4 and bit 1 is tied to pin 2. Looking at the display it looks like we're seeing the "t" character come in and then get echoed back out... but with data lopped off. It happens every single time. So, serial data from the terminal to the Apple is clean. Serial data outbound to the terminal is... not?

I've never looked at a serial connection in this way so I'm really hoping for some expert advice here. Could this be some weird setting in the serial driver? Interestingly, I can get the data to "look" right on the probe by setting it to odd parity (CTRL-A 1P) but the characters are still corrupted on the terminal end.

Thanks for your patience!
IMG_0974.jpg
 
Last edited:
Ok. First Serial port 1. Yes, it does exactly the same thing... Of course, you can't do an IN on port 1 though.

Next, I am starting to suspect that there is something fundamental that I don't understand about the IIc and serial communications. I've done this sort of thing with the IIe's that I have with no issue...

I hooked up the other IIc that has no problems receiving data from ADTPro and discovered that it exhibits EXACTLY the same behavior on the serial lines. I've attached photos of the logic probe again. Clearly there's something missing from the transmission from the IIc. I've fooled around with the parity settings, etc., but that's clearly not it.

Is it not true that I should be able to do "IN#2" and type to the IIc? *answer* Yes. I can do this. No issues here.

Is it not also true that I should be able to do "PR#2" and type back to my terminal? I *thought* that the answer was yes, but that's where the discrepancies occur. Please see the following logic screenshots and someone please enlighten me about IIc serial communication. By the way, I flashed a 27256 with ROM version 4, so it's not some mysterious ROM 3 issue. The logic analyzer pictures are from a ROM 2, but they ROM 4 shows exactly the same behavior. I am performing my tests from a fresh power-on which should leave me in 300,N,8,1.

First image is for bit 0 on the analyzer. This is hooked up to the TX line from the IIc to the terminal
IMG_0981.jpg

The second image is for both. Top trace is TX from IIc to terminal, bottom trace is RX from terminal to IIc. As you can see, it looks like the stop bit or something is missing from the end of the transmission when the IIc echoes the character back. In this trace you are looking at the ASCII character "0" being sent.
IMG_0985.jpg
 
With this logic analyzer you're trying to kill an ant with a cannon ;) I bet there is no *logic* problem in these 2c serial ports. An oscilloscope would have been much more useful in this case. But first:

1. Check +12V and -12V on your apple to be stable and within limits. If all seem OK (which I really doubt escpecially -12V) then (BTW is the floppy drive working on this apple?):
2. Since you've told us that an incoming RS232 feed is properly received with IN#n, replace all 1488 output buffers. I hope they are socketed in //c.
 
+12 and -12 are stable. Yes, the floppy drive works fine.

Before I replace chips, what leads you to believe that the 1488 chips need to be replaced? I'd really appreciate hearing your line of reasoning, especially since I have two IIcs here that exhibit exactly the same behavior.

With this logic analyzer you're trying to kill an ant with a cannon ;) I bet there is no *logic* problem in these 2c serial ports. An oscilloscope would have been much more useful in this case. But first:

1. Check +12V and -12V on your apple to be stable and within limits. If all seem OK (which I really doubt escpecially -12V) then (BTW is the floppy drive working on this apple?):
2. Since you've told us that an incoming RS232 feed is properly received with IN#n, replace all 1488 output buffers. I hope they are socketed in //c.
 
Well, I never got a response to why chips should be replaced when two boards behave exactly the same way, but me and my "overkill" logic analyzer have figured it out. To process the serial data coming from the IIc you MUST force the received data to 7 bit even if the port is set to 8 bits. As strange as that sounds, forcing it to seven bits produces clean data in both directions.
 
Sorry, I should have included these facts:

If you are using screen on a UNIX system to speak to the IIc, the following would be appropriate:

screen /dev/tty.usbserial 9600,istrip

The IIc would be configured with a control-A 14b

Similarly, using Hyperterminal, there is a property on the connection that allows you to force the input data from the serial port to 7 bit data.
 
I'm looking for suggestions on where to focus my efforts. My logic analyzer is in the shop and won't be back until next week, but I have time to work on this over the weekend.

I have two Apple IIc mother boards. Both appear to be fully functional.

The first board works fine with keyboard, disk, serial, etc.

The second board works fine with keyboard, disk and... sorta, serial.

If I hook up a serial line to it and do an IN#2, I can type characters across with no problem at 9600 or 19200 baud. However, if I use something like ADTPro to stream a boot disk, some comes through ok but lots and lots is garbled.

I spent a lot of time swapping cables, swapping USB serial adapters, etc, and finally decided to hook up the other board, discovering that the other board receives serial data with no issues at all.

The big problem is that there's nothing visibly wrong with the board or components and the serial issue seems "intermittent", but not so intermittent that I can successfully transfer anything over serial.

Thoughts?


The Apple IIc has a known bug which prevents higher baud rates from being used. The solution is to try a lower baud rate. I find the 300 baud works okay with ADT.
 
I know this is a very old post but I'm going to throw out a response anyway hoping someone might respond. I have a ][c with the same issue. It used to work fine at various baud rates then one day out of the blue it started exhibiting exactly the same behavior you described in this post.
After going through the steps and testing between a pc and the IIc I found that if I set both to 7 data bits then I got a clean flow of data in both directions.

However, what I'd like to do is use TCPSER to allow me to call out to BBSs through my IIc but TCPSER doesn't (seem to) have any way to configure it for 7 data bits. I tried changing the com port settings in my device manager but none of these settings seem to have any effect on how TCPSER sets up the port.

Given that my IIc used to work fine once I wonder if the 7 data bits solution is a work-around for an actual, physical, issue.
 
Back
Top