Hi All!
I've come across this forum a couple of times and everyone here has been very helpful getting me up and running on my ][+. The machine works, and I have been able to use the casette ports to get some disks and games. That was a good time, so I decided to order a Super Serial Card and see if I can get that working with ADTPro. I'm having an issue where everything that comes across on the serial port is showing up as a bunch of carats, at symbols, and slashes (^^/@@@@) etc.
I started by digging into the SSC manuals to verify switches and error codes. As far as I can tell the switches are correct (and the comms parameters set correctly on my PC). I checked the SSC status register for errors per the manual (via PEEK) and it returned no errors. Just to make sure it wasn't something specific to ADTPro I connected my PC serial out to the SSC and connected as a terminal via PuTTY. This worked surprisingly well in that whenever I type on my PC keyboard it shows up on the ][+ monotor (still garbled though). I went into the serial monitor on my PC to see what it thinks it's sending, and it seems to be trying to send the correct data. Unfortunately I will have to wait until tomorrow to do a true loop-back with another PC to verify the serial cables, as my other laptop with a serial port is sitting at work over the weekend.
Have you guys seen something like this before? I'm thinking maybe the rom on the SSC is bad (341-0065-B) and is for some reason spitting out garbage instead of the correct ASCII codes, which is being interpreteda as those symbols by the motherboard rom/processor.
Thanks in advance for all of the help, and thanks for having me on the Forum!
-TMH
Well, I had a detailed explanation for you almost all typed up, but somehow a Ctrl-L missed the editor and caused the browser to move to a new URL rather than the editor setting a link, and when I hit "back" I was given a blank entry box, with twenty minutes of work gone. (I am really not liking the this forum's editor; that doesn't happen in Chrome with a standard text entry box. And this, BTW, is why other editors use Ctrl-K to format text as a link.)
Anyway, short summary, which may or may not be of help:
1. Apple II sends "ASCII" chars with 8th bit set; PC uses 8th bit clear. When trying to show text with a comm program, trying "mark" or "space" parity on either end may help.
2. The SSC manual describes the Ctrl-A commands used to change SSC settings. Don't trust the switches; reset everything via these if you're having problems.
3. Near the end of this post I describe setting up Linux to show the output of PR#2 on my IIc; some of the information there may be useful.
Hello and thanks for the reply!
I'm not familiar with "8th bit set/8th bit clear", but I took your advice and tried mark/space/none on both ends in every combination. Garbage still showed up, but at least it was different garbage sometimes. The same garbage showed up for "mark" and "none" with parity, which i think was expected if I'm reading the RS232 infomration correctly (1 being the default before start). I also tried this with several different baud rates, and interestingly the different baud rates showed different garbage, which might point to a timing or clock error.
I also took your advice on setting up the SSC via the Ctrl-A commands, which was fun to learn (despite no better results).
My next plan is to scope the clock signal and possibly reprogram the rom (if I can figure out how - I dont own a programmer). If you can think of further troubleshooting steps please let me know, I'm kinda easter egg hunting now.
-TMH
(Argh! Ctrl-L once again sent my browser to another page, wiping out
my post, instead of setting a link. And "Markdown" format here doesn't
actually render any Markdown at all, as far as I can tell. Ok, off to
plain text format and an external editor we go; sorry if the formatting
is a bit ugly.)
So as you probably know, ASCII is a 7-bit encoding of characters,
ranging from $00 to $7F (table at [1]), and PCs normally display 8-bit
values in that range (most significant bit (MSB) clear) as the regular
ASCII characters. Higher values (MSB set) will be displayed as either
"graphics" characters or considered part of a multi-byte sequence
representing a character, depending on settings.
The Apple II uses only 8-bit codes for characters, but normally uses
$80-$FF to represent ASCII characters $00-$7F, i.e., the MSB is set,
and this is what it will be sending out the serial port when using 8/N
(8-bit, no parity) mode. So you need to deal with this in some way,
especially if the terminal you use interprets bytes with the MSB set
as the start of a multibyte character sequence (e.g., UTF-8 encoding)
rather than as a single "graphics" character or whatever.
On Linux this is easy: use 8/N and `stty istrip` to tell the terminal
driver to clear the MSB of every character that comes in. On Windows
I'm not sure your terminal program can do this, so switching to 7 bit,
mark parity on the reciever (always expects MSB=1) or 7 bit space
parity on the sender (always sends MSB=0) was my thought to try to
work around that. (Though I'm not _totally_ sure that I've not
reversed mark and space here; I've never actually used either.)
Anyway, if you have a 'scope debugging becomes much easier: put a
channel on the TX line from the Apple II, set the vertical range to
let you see -15 V to 15 V, and refer to Wikipedia[2] for details of
how to decode what you're seeing.
When no data is being transferred you should see TX at -12 V relative
to ground on that interface, indicating a space condition. If you put
the 'scope in single-shot mode triggering on a rising edge anywhere
around 0 V, sending a character will initiate a capture that you'll see
on the screen. That rising edge is the start bit and you can decode
the rest based on that, remembering that the _LSB_ is sent first (i.e.,
you need to read the bits in reverse to get the value). A good character
to send is one with LSB 1 (so the first pulse shows you the bit length)
and lots of transitions: try %10101010 = $AA = `*` on the Apple.
This will make it easy to see whether the Apple SSC is sending broken
stuff or you just have a serial communications setup problem.
[1]: https://github.com/0cjs/sedoc/blob/master/ascii.txt
[2]: https://en.wikipedia.org/wiki/RS-232#Physical_interface