I picked up an AE serial pro a week or two ago. And just now getting around to testing it out. But I'm not having any luck. The card ROM seems good, when I do a IN#1 (or 2 depending on the slot I'm testing in) and press Ctrl-I (or A depending on the mode it's set to), the configuration screen comes up. The battery is no longer holding a charge, so settings are not retained between power cycles. It does however seem to retain them between OA-Ctrl-resets. I have all the dip switches in the open position, which the manual indicates is the best default settings. One block of switches determine if interrupts are used, and the default of all open is no interrupts (which is how I have my SSC set). The other set of switches appear to remap a couple of the hand shaking signals for some printers looking for them on odd pins. With that block all open, should be using standard pins for handshaking.
The default configuration settings appear to be printer mode, 9600 8-n-1, which should be fine for an IW2. I have the db25 IDC connector installed on the appropriate header depending on if I'm testing my IW2 or a serial session to my PC using a terminal. I have the IDC connector installed so the cable is coming out the bottom, which is what the manual seems to indicate as the proper orientation.
When in slot 1, configured as printer, and connected to my IW2 using the same cable that works with my SSC, I can't get any output with a PR#1 in basic. Normally with my SSC after issuing a PR#1, the IW head wil jerk for a split second, then echo anything I type and press return on. With the AE card, the head does not jerk after the PR#1, and nothing ever prints. I also tried Print Shop, and ran the config/self test. Instead of printing the normal "welcome to print shop" block graphic, it printed a couple lines of text garbage.
When in slot 2, configured as a communication device, and cabled to my pc with a usb to serial adpter and null cable, I fired up pro comm. I bring the pro comm terminal online, and my pc receives the same garbage character no matter what I type on the IIe. When I type on my PC terminal, nothing comes through to the IIe. Before doing this, I confirmed this method did work as expected with my SSC, and I could see the text correctly in both directions.
All the chips are socketed on the AE card, so I tested what I could on my Backbit Chip Tester pro v2. All the LS chips passed. The 6551 passed. The PAL dumped and it mapped the input and outputs, but I have no idea if it's correct. The ROM also seemed to dump fine as well. That leaves just the clock chip (which I don't think would affect this - along with the dead battery), and the 1488/1499 line drivers, as they apparently require 15v to test and the CTPv2 can't supply that.
At this point I'm out of ideas on what to test/check next. So, hoping someone here would have some advice or ideas. I don't have any kind of RS232 signal breakout/tester, but willing to spend the $20 or water to get one from Amazon if it would help.
TIA
Just to rule out an issue with either the DB25 connector and cable or it's orientation, I took some continuity tests and compared them to the SSC. All the pins beeped out to somewhere on the card, and seem sane based on tracing out the SSC. So The cable/connector should be good, and the orientation looks good as well.
Edit: I tried copying and pasting the grid from a spreadsheet, but it seems to be treating it as an image, and then the image is broken when the post went live. Not show how else to easily share this chart in a readable format. A intermediate copy/paste to note pad gives as least text, but hard to read.
DB25 PIN SSC SP
1 – Frame GND r7 r?
2 – TX 1489 – 10 (In C) 1489 – 1 (In A)
3 – RX 1488 – 8 (Out C) 1488 – 11 (Out D)
4 – RTS 1489 – 4 (In B) HS SW-1 & Pin 5
5 – CTS 1489 – 4 (In B) HS SW-1 & Pin 4
6 – DSR 1488 – 11 (Out D) 1488-8 (Out C) & Pin 8
7 – Signal GND GND GND
8 – CD 1488 – 6 (Out B) & 1489 – 1 (In A) 1488-8 (Out C) & pin 6
19 – SRTS SW 2-7 HS SW-3
20 – DTR 1489 – 13 (In D) 1489 – 13 (In D) & HS SW-4
There is a variable cap on this card, but I suspect it has to do with time drift, as it looks like its connected to a small oscillator near the battery (as opposed to the much larger oscillator near the headers for the serial portion of the card. I guess I could try swapping the 1488 and 1489 from my known working SSC as a test. But I try to avoid "swapnastics" as a last resort or unless something strongly points to it. I should also mention as far as tools available to be to troubleshoot are a DMM and Rigol oscilloscope. But I'm not too handy with a scope, and might be hard to probe anything on card.
Are you using the original ribbon cable between the card and the rear panel? Does it look like the photo in the advertisement? I ask because the ribbon cable connector has 26 pins, but only 25 are used to connect to the DB-25 socket. The colored cable begins with pin 1 (brown) on the left and ends with pin 25 (green) on the right. One position in the connector (26) is empty.
When you used your cabling with the SSC, which way was the block facing? The two headers on the Serial Pro take the place of the reversible wiring block, so the top PRINTER header is used where the block's arrow points down towards TERMINAL on the SSC, and the bottom MODEM header is used where the block's arrow points up towards MODEM on the SSC. The SSC's wiring block is a built-in null modem. It is wired straight through when pointed to MODEM, and it crosses over when pointed to TERMINAL.
Can you check the 1.8432 MHz crystal? If it's broken then all comms will be garbled. A break-out box can't diagnose that: you need a frequency counter or oscilloscope. Some DMMs can count fast enough, most can't.
AFAIK, its the original cable, but who knows as I got this second hand off ebay. Its not rainbow colored, gray with a red stripe on pin 1. Which when connected as shown in the manual has pin 1 towards the front of the card. When I compared the cabling and pin outs in my last post, I had the SSC set to Terminal, and the DB15 was connected to the printer header on the serial pro. I tried putting my scope on the crystal, but I wasn't getting anything. There is no room on the card to connect the ground lead to the crystal leg, So I had to tack a short wire on to one of the legs on the back side, which is less than ideal. The image was kind of a mess, and the scope calculation was all over the place. I tried the same on my SSC, and at least got a better looking image. But the calculations on the scope were all over the board.
I just remembered I have a cheap-o frequency counter that I use when setting my RF generator for when I work on old AM tube radios. Assuming I made good contact, I'm only seeing like .032Mhz on the AE card. Doing the same on my SSC resulted in the correct 1.8Mhz. So maybe it is the crystal? Are there any specs that are important (other than the frequency) I should be looking for at Digikey/Mouser?
Actually, I think I was able to decode the existing part number based whats on the crystal and find a datasheet:
1843.2
18-32
ECS8E
Obviously the first number is the frequency. Guessing based on the bottom line that this is an ECS part, seems like it's the ECS-18-32-1. Which isn't in stock at Digi or Mouser. But they did have links to the datasheet, which is is the HC-49U series. They do stock the ECS HC-49UX series though. Stability matches at +/- 50ppm, tolerance at +/- 30ppm (Disgikey lists 20ppm, which would be better, but I'll trust the datasheet), and ESR matched at 750 ohms. Load capacitance on the original was 32pf, the new one 30pf. I'm going to assume that 2pf difference isn't an issue. Physical specs match as well. guessing the "X" means this is the lead free version of the the previous series.
I've been keeping a list of some parts I want but don't need immediately. Guess this is a good as time as any to order up my list and see what happens.
ECS is the manufacturer, but these crystals are pretty much generic. You don't even need to use the same case size if the pins will fit the board footprint. Just match the frequency and the load capacitance (the parallel capacitor looks to be one of the yellow ceramic discs south of SW2). It's probably on the order of 30 pF. Matching the load capacitance exactly will make the crystal operate more precisely and reliably.
Got the crystal today that I had ordered, replaced it, and BOOM - working. Robespierre wins the prize. Although, its acting a little odd. When I did my 2400 baud test with putty to my PC, I could see everything sent from the IIe. But Proterm wouldn't show anything from my PC/putty. I hooked up my Wimodem, same thing. I could see the commands showing on the Wimodem screen (like the init string), but Proterm wasn't getting back the OK. So I forced it to on-line mode. Same thing as the putty test. The Wimodem showed all my commands, but when I did a ATI, I got nothing back. So, I fired up ADTPro at 115200 using my Floppy Emu, and everythign went great. I sent a disk from my IIe to my PC, and then wrote that image back on a blank Prodos image. The image booted fine. So I'm not sure whats going on with 2-way communication in proterm. I pulled the AE and put my SSC back in slot 2, and Proterm had no problem with 2 way communication with my Wimodem using the exact same Proterm config. I happened to pick up a 2nd AE card which arrived today. It's behaving the same way. So I'm not sure what is going on. It's not the end of the world, as I intended to use the AE card in slot 1 with my IW2 (which I'll dig out of the basement and test tomorrow). But it kind of bothers me it's not working as expected.
For the record, on my first AE card with the bad crystal, it was a little green ceramic cap below the crystal. It was rated 1kv, and said 39k. It was originally covered in a white powder that I cleaned off with 99% IPA and a qtip. Which I assume means 39pf, and the k is a tolerance. The other AE card I just got in the mail today is a slightly different. It has a footprint for a larger crystal, like found on the SSC, and the (presumably) 39pf cap doesn't have a footprint on the front of the card. Instead, the cap was bodged on the back of the card. The value is facing the PCB, and i didn't want to bend it to to see the other side. I just noticed now down by the battery, the one with the small crystal footprint and cap installed properly in vias is labeled REV B. The one I just got with the larger footprint crystal and cap bodged on the back says REV A. It's also got a 1.4v ROM, as where the B had a 2.0 ROM. I'll dump the 1.4 and add it to the thread I necroed the other day when i dumped my 2.0 ROM. If anyone can decompile it and spot the differences, I'd be curious. I'll probably find someone who can burn 2.0 for me and replace 1.4 on the REV A card.
I have some new nimh Vartas on the way (again, thanks robspierre for the tip). Once I get them, I'll have to figure out the clock function. I know you have to have a ProDOS disk and have the clock driver .system file first on the disk. But I'm assuming I'll also have to make sure any disk expecting to use the clock will also have an updated ProDOS version that understands y2k+ years?
Local/remote echo can be a problem with serial terminals. If a serial link is capable of full duplex (simultaneous send and receive), then remote echo is usually chosen (keys you type are sent from the host without being displayed, then are interpreted and echoed by the remote host, and appear on the local display the same way all of the remote host's output appears). This makes possible all the fancy line editing, screen editing, concealed passwords, hotkeys, and so forth. This is how SSH or Telnet act by default, also most BBSs, and is most familiar.
If the link can handle half duplex only (send, then receive, then send, etc), you usually need to use local echo. If the echo mode is mismatched on the two ends of the link, you either can't see what you are typing (local host is set for remote echo, but remote host doesn't echo anything), or else keys appear double or even triple (local host echos locally, and remote host echoes the same keys).
A lot of early/primitive terminals can only work with half duplex. These were called "glass TTYs" because they could only work the way a teletype worked: each key you type is always displayed at the current cursor position, and control codes to move the cursor are nonexistent. The Apple I is like this. It can't even backspace to delete mistyped characters.
But you will appreciate that there is a kind of problem if two terminals are connected directly together instead of a terminal connected to a server port (shell, BBS, etc). This kind of "peer-to-peer" connection can only work if both ends are set to local echo only. Because a terminal never echoes what it receives from the remote host back to the host. So if you connect two terminals (Proterm on one side, PuTTY on the other, e.g.) in their default modes (full duplex/remote echo), then you won't be able to see what you are typing. In this peer-to-peer setup you must switch both terminals to Local Echo.
Just a thought, maybe Proterm expects to see CD (carrier detect) go true before it will display anything? A communication program from before the Hayes SmartModem may behave that way, because early modems did not have a command level. The SW2 on the Serial Pro can connect CD to various handshake lines on the port to make that work.
I could be misunderstanding, but doesn't echo just apply to what you are typing, and not what is received on the line? I always seemed to recall turning echo on in order to see whatever AT commands I was entering. But even if echo is off and I couldn't see me typing ATI<enter>, Proterm still displays what returns from the Wimodem.
At startup, Proterm issues an init to the modem, and expects an OK back. If it gets the OK, it prompts you to flip the disk (which happens with my SSC and Wimodem). If it doesn't see the OK, then it warns you and gives you 3 options (which is what the AE card is doing with my Wimodem), one of which is to ignore it and flip the disk to still go into the terminal. So Proterm can't even see the OK from the init with the AE card.
As to the handshaking option block, the manual says this only applies to the printer header, and not the modem header.
A couple more data points, and a pretty sure I found the resolution. I went into the PT config, it has an option for the AE serial pro instead of SSC. Changing that made no difference. In the SP control panel there is a local echo option. I enabled it, still no difference. To rule out a PT config issue, I tried Agate. Same issue, anything the IIe transmitted was fine, but it never seemed to receive anything back.
I dragged my IW2 up from the basement and moved the card to slot 1 and moved the connector to the printer header. Everything worked as expected in basic when I did a pr#1. I went into print shop, it passed the test in the config section and printed "welcome to print shop".
At this point I was sort of at a loss. Then I realized something. Both of these serial pro cards had the 6551 interrupt enabled when I got them. Which I thought was odd, as the SP manual tells you interrupts are usually not needed. I checked the SSC manual, it also says in most cases it should be off. So I turned them off on the SP. But I looked at my SSC from slot 2, it was on. So I turned it on the SP. now I could see things coming in from either putty on my pc or the Wimodem. I turned interrupts off on my modem SSC, and it began to behave the same way - it could send data but not receive.
Based on this, I guess this is a case where following both the SP and SSC manuals directions of "you shouldn't need interrupts in most cases" is a bad idea. It's been years since I setup my modem SSC. So I'm not even sure how I determined to turn interrupts on. Actually, I just figured out where. In the Wimodem232 forum, there is a guide for configuring IIc, IIe, and IIgs. In there, is a picture of a SSC and tells you to set the dip switches exactly like this, and sw2-6 is on. So I must have turned it on based on the Wimodem232 forum.
I looked at the SSC I was using for printing, and interrupts are off on that. I guess since that port pretty much only sends data, it's not an issue. But now that begs the question, should interrupts be on for the card driving the printer? I've never seen any issues with it off, so it's probably fine. But now I'm curious as to what the best setting is.
Edit: a thought I just had, why does ADT Pro work with the interrupts off, but basic serial communication with a modem or terminal does not?
A regular Super Serial Card will not send data to the screen unless the Carrier Detect pin is asserted.
This is a hardware/firmware issue (a feature?), and not a software issue.
With ADTPro you'd normally be using a null modem cable which usually ties DTR from the host computer (the modern PC) to the CD pin (and often the DSR pin) on the client (Apple II). This ensures proper data throughput into the Apple.
I would suspect that the AE card is similar in that regard if it shares firmware routines with the SSC.
Get yourself a cheap RS-232 analyzer like this Radio Shack doodad:
https://www.ebay.ca/itm/276482283113?_skw=rs232+analyzer&epid=534725633
It will tell you what's what, if data is being sent, received and most importantly, the status of all the handshaking pins.
A simple AT command to the Wimodem232 will assert CD. AT&C1 ought to do it if the polarity of the CD pin is set correctly (Wimodem232 has a command to invert the polarity of most of the signals - this is a throwback to the C64 that has all the serial port statuses ass-backwards.
Except it doesn't appear to be a CD issue. Everything remaining exactly the same I have issues with my modem and putty/PC terminal (but not ADTPro) ONLY if interrupts are off. If they are on, everything works perfectly with my modem and terminal connections. Which implies it's not CD related, as all signals would have been in the same state in both cases. Also, I was using a null modem cable when connected to my PC/putty. And I observed the same behavior with interrupts off. Which means the theory of the null modem cable fixing the issue for ADTPro is invalid. Somehow ADTPro is able to function with them off. And from what I can tell in the SSC and SP manuals, there is no command to force interrupts. Seems like its only changeable via hardware switch.
I guess I should have looked at the Proterm manual instead of the SCC or AE SP manuals which both say you really don't need interrupts. Page 281 of the PT says interrupts must be on. And they show pictures of the SSC and SP cards with the interrupt dip switches on. But it's obviously not just Proterm that has the issue. Agate needed the interrupt too.
Yeah, this is a given, regardless. The SSC can function with interrupts off, but if I recall from testing a few years ago, it only works reliably at 300 baud. Even 1200 baud drops characters on a II+ (using ASCII Express) with interrupts off.
On a IIe, (my memory is a bit fuzzy here) it works ok at 1200 baud, but not 2400 baud with interrupts off.
But regardless, nothing will be returned to the Apple II unless CD is asserted.