I've done my due dilligence as much as I can by scouring this forum and Google for answers, and found some suggestions, but none seemed to work. I'm trying to send and receive images to my IIe via a super serial card. I can bootstrap just fine over serial from my MBP and from my Win 10 machines, but when I try to receive a file from my host machines, I get the message waiting for reply from host.
Obviously my card is configured correctly, or else I wouldn't have gotten this far. I've tried both speed settings 19200 and 115200 for the communication speeds making sure that, at least on Windows since it can be configured, the speed on the host COM port driver is the same. The card is new and I honestly don't think has been ever used before.
The cableing and USB to serial connector should be fine since I can bootstrap. The type of USB to serial adapter is an FTDI. What else is there to try?
If I hit ESC to cancel the request, I just get a beep and no other response. If I disconnect the serial connection either physically or by using the disconnect button on the host, it'll abort the request and I can then try a different request.
I am facing such problem every few years. The reason is that somehow the 6551 chip gets burnt without apparent reason. Replacing it resolves the problem. What do you mean you were able to bootstrap?
If you don't have an ADTPro boot disk, you can use the serial port to boot and load the ADTPro software.
https://adtpro.com/bootstrap.html
I know about this feature, I was asking for confirmation from the OP in order to better troubleshoot what's going on their side.
Some time ago i tried to update my system by running it on AppleCommander-ac-1.9.0.jar instead of AppleCommander-1.3.5.13-ac.jar and some other newer java libraries, which ended with the same problem, it failed loading images from the server.
So i went back and everything is working fine again. Currently i use:
AppleCommander-1.3.5.13-ac.jar
jssc-2.9.6.jar
slf4j-nop-1.7.9.jar
Theese files are located in the lib folder beneath ADTPro.
You may also remove the /min after start in adtpro.bat, this will leave the java console open and maybe show some usefull info.
I used a host computer over the serial connection to load ProDOS and ADTPro onto my IIe. It does it at 9600 baud and works just fine. Once ADTPro is loaded and I attempt to use the menu to either send or receive an image, it hangs on waiting for host. I'll try out the alternative jar files and see if that changes anyything. Does it work on the Mac too or is that only for Windows?
For completeness, I also loaded ADTPro from disk with the same results. It loads up fine, but after selecting serial and having the program load, it's not able to connect to the host for send or receive actions. I initially used this method, and it should have worked fine. I did the other method of using the host to load ADTPro just to verify that the cand was configured correctly so that I could rule out a bad serial card or cabling. Typically, I'd like to load from disk since it's faster to load that way.
I've often wondered about ADT... I've never used it personally. It seems like something you'd really only need once if you didn't already have boot media or something. One of the first things I did when I got back into Apple II stuff after many years of it sitting around in storage was to get a flash media storage device. I have lots of vintage media so I never needed to bootstrap like that. It seems like it is just so much easier to copy disk images onto an SD card or USB drive and then if I need to I can image to real floppies from there than mess around with serial cables and software setup on both modern computer and Apple II... Maybe I'm just crazy or maybe I'm missing something?
Sure, if you have a flash/SD device like Floppy Emu, CFFA, wDrive, etc. Then you can copy all the images you want from your device to a real drive. But if all you have is a PC and real drive, you need ADTPro if you want to make floppies from images. Then you can bootstrap once and transfer over an ADT boot disk. But you'll still need ADT to make floppies of applications/games.
As to the OPs issue, sounds like something is causing an issue at baud rates higher than 9600. Using a terminal program on your PC, and dropping to a command prompt on the Apple, I believe you should be able to do an IN#2 (or whatever slot your SSC is in) and set various baud rates using the SSC prompt (matching them with your serial terminal on your PC) and send text to the IIe. Ideally you would use like Proterm or something. But if all you have to work with is a command prompt, this should work. It's been a long time though, so I might be glossing over or misremembering something here.
I need it to make an image of some disks that I want to preserve and I don't have the mass storage option available to me currently.
Is your SSC set up like this?
FB_IMG_1643330104073.jpg
(both the DIP switches, and the jumper block facing "down" are relevant)
Once ADTPro is running the DIP switches position is irrelevant. Actually on the ADTPro web site a different position for the DIP switches is defined to be good for bootstrapping.
Not all of the switches are software-defined. SW1-7, SW2-6, and SW2-7 are not. Nothing software can do to affect them.
The other missing detail concerns DOS or ProDOS. If either one is loaded, high-speed serial downloading won't be possible. If a DOS-in-ROM card is in use, for instance, or if the machine is booted from a DOS master disk.
The other thought that occurs to me is about the serial cable itself. A poorly shielded cable will produce more errors at higher speeds.
In my case, I have a NULL cable, so the arrow on the block is pointing up. But I honestly don't believe that's the issue at this point since I'm sending data successfully at 9600. The cable should be shielded enough that it shouldn't be a problem. I have it placed away from any interference as much as I can. I'll try the terminal solution to see if starting at 9600 baud and then moving to a higher rate works. That hopefully will tell me if it's a speed issue. Also, that debugging tip on not closing the JVM window could be handy.
Running a 6551 based serial card on a 1MHz machine much faster than 9600 baud is really a falacy anyway. That serial chip only as a one byte FIFO, so unless you haver super efficient code driving it, it is going to be generating a ton of IRQs or XON/XOFF or hardware handshaking a lot to keep from losing characters. Lesser serial chips like 6850s struggle to keep up at 4800.
Even on PC clones if you wanted decent serial thruput back in the day you needed a good UART like a 16550B which had mutlibyte FIFOs, and that wass with a CPU usually running at 8MHz or better.
Be patient and run serial on un-accellerated Apple II machines at 9600 or lower... You'll usually be a lot less frustrated that way.
Except that it works with ADT. And works well. I've used ADT many times with both my IIc (that has the early crappy timing circuit) and my IIe. And actually outside of bootstrapping, ADT only lets you run at 19200 or 115200. So you can't even step it down to 9600 if you wanted to.
Interesting. Maybe it works better because it isn't trying to display anything while doing the transfer. Back in the day when I was doing a lot of RS-232 work I did a lot of thruput measurement and usually even at 9600 with any kind of error checking protocol the throughput was significantly less, and it only got worse if you increased the baud rate. Maybe the ADT code is better than what we had back then.
Have you got a terminal program on your Windows PC?
Like HyperTerm? I think the last time it was included in a Windows distribution was on Windows XP.
More importantly are you able to run any sort of software on your Apple II? Like through a disk image device like a Floppy Emu, SDisk II, BootiHD or CFFA-3000?
If so I'd try running a terminal program like ProTerm 3.1 (Apple IIe) and seeing if you can type communications back and forth to HyperTerm on the Windows PC through your null modem cable and USB-to-Serial adapter (unless you have a true serial port).
Try different baud rates.
I suspect the issue is with the host modern PC and not the Apple II.
Using the SSC in an Apple IIe at bit rates greater than 19200 is sheer folly and works only under the best of conditions between a DTE and DCE devices or DTE -to-DTE devices via Null Modem cable. 9600 will always be the most reliable and accurate. Either way it is imperative that both serial communicating devices on both ends must be identically configure.
The CFFA card with CiderPress makes what you are needing to do childs play.
Perhaps the issue is the version of Java installed on the host: see https://github.com/ADTPro/adtpro/issues/151
I did some testing of the serial connection on the IIe and was able to establish a serial terminal connection to test if the speed of the connection was an issue. What I found is that with 9600 baud I was able to see any text that I typed show up correctly on the apple screen. Anything faster than that was garbled text. This tells me that the card is probably set for only 9600 max speed.
Currently, ADTPro only supports 19200 minimum speed for non- bootstrap operations. This is not going to work with my current configuration. Is there a way that I can force the server to use a slower speed? I haven't been able to find any way to do that. Is there a technical reason that it has to be one of the 2 speeds that it does allow? Besides that they're the only options that you can set. Is there a different configuration of the dip switches that allows for the faster speeds to be used? Do I need to make a sacrifice to the Apple Gods to make this work?
For anybody that wants more detail on how I did the serial testing, here's what my process was
- Connected a serial cable to the IIe SSC with the SSC dip switches in the recommended configuration for ADTPro
- Connected a MBP to the serial cable using a USB to serial adapter
- Turned on the IIe and then pressed [Control-Reset] to break out of the boot process
- Typed the following to get to switch to the serial card for input
- IN#2
- [Control-A] 14B
- Now it should accept serial input
- On my Mac I opened a terminal window and found the name of the USB serial device by executing
- ls /dev/cu.*
- This gave me a short list of devices. The device that I'm using is /dev/cu.usbserial-FTDDTMDM. Yours may be different.
- Now I establish a serial connection by executing
- screen /dev/cu.usbserial-FTDDTMDM 9600
- The "9600" is the baud speed. I started with this because I knew that it should work since that's the speed ADTPro uses for bootstrapping
- When the prompt was displayed on my Terminal, I began typing text. The text appears on the IIe screen as expected. All characters looked correct.
- I exited the serial connection by typing
- [Control-a] [Control-\] and then confirming the disconnection with 'y'
- I tried a new connection using the faster speed this time
- screen /dev/cu.usbserial-FTDDTMDM 19200
- This is the minimum speed that ADTPro uses for non-bootstrapping operations. When I started typing the same characters as before, instead of seeing them show up on the screen, I got various symbols displayed instead. This confirms that I was able to establish a connection, but the speed is not what the SSC is able to correctly interpret for some reason.
I discovered that there is an ADTPro.properties file that has some values that you can change in there. I discovered that there a baud rate that looks like it would override the options you have in the UI. I tried changing it to 9600 baud and restarted the server. I saw that it acknowledged the change, but when I tried to do a basic tests of viewing the files directory on the server from the IIe, it still wouldn't work. Something else is still not allowing it to cooperate. It's possible that the client on the IIe actually prevents it from using anything less than 19200, but I can't view the bin file to see if that's a posibility. Seriously, how has anybody gotten this to work without this much troubleshooting?
For a serial connection, both ends need to have compatible configurations in order to exchange information successfully. There's no "auto negotiation" as there is in more modern connections like USB or Ethernet, something or somebody has to configure each end individually.
When you tell screen to run at 19200 baud, you're only adjusting one end of the connection. The Apple IIe is still expecting characters at 9600, so I'm not surprised it gets confused. Looking at the Super Serial Reference Card, it seems something or someone has to send <Control-A>15B<Return> to make it switch to 19200 baud, but it's not clear to me whether that's something you can type in screen after establishing the connection at 9600 baud, or something you can type at the IIe keyboard.
I set-up ProTerm with null-modem and set to 19200 and everything seems to work in both directions. In my case I use screen with Linux but otherwise everything is about the same as your Mac. When I was troubleshooting this for mine, this is what I found:
SW1: 1001111 SW2: 1101100
Good luck!
This is irrelevant. ADTPro bypasses all the internal card software and manipulates hardware and interrupts directly.
There has never been an issue transferring disks at top speed, even on an old Apple II+ clone with a clone super serial card.
If you can bootstrap successfully, then I suspect something is wrong on the PC end of hte operation for disk image transfer. You are using an FTDI type cable, right?
Run your Apple's ADTPro program on it's delivered stock defaults and it should work perfectly.
Try an earlier version of ADTPro and try a different version of Java to see if anything changes.
Just for maximum triviality, there are some devices that attempt to autodetect the speed of their corresponding serial port (Xyplex and Digi come to mind, but many devices, particularly modems, have that feature), called ABR or "autobaud". It is definitely not implemented in an Apple II serial port card from 1981, however.
The serial link itself is transparent: the hardware doesn't interpret the data being sent from the remote host. The way the SSC sets its bit rate is by default using the DIP switches on the card, or by typing IN#2 (the card is in slot 2 by convention), then control-A, a number, B, return. The IN#2 is needed to connect the keyboard to the command handler in the card's firmware, which is what listens for control-A and interprets the following command to write certain values into ACIA registers.
Once a connection is established, if IN#2 is still active, the remote host can send commands to the Apple monitor and read or write any data it likes to the SSC's registers, which can change the speed to any value the ACIA supports. That is how ADTPro loads itself into the Apple at 115200 bps, after initially bootstrapping at the slow speed.