Hi Folks,
Just new to this site.
Wondering if anyone can give me any hints with an issue I am having with ADTPro (V2.0.0 or V1.3.0, I tried both). If I try either version of ADTPro with it's native Apple side client, I cannot get anything to transfer. I get a timeout on the Apple side and a abort on the PC side. However, if I use the much older ADTWin/ADT DOS apple side client with either the V2.0.0 or the V1.3.0 (also ADTWin server) I can transfer simple .DSK images well enough, but of course the older client cannot deal with .PO, .SDK., 2MG or any of the other more sophisticated image formats.
Here is what I have:
PC Side
Lenovo desktop running 32 bit Windows XP Pro
Apple side
Apple //e un-enhanced with "B" revision mother board
Apple II disk drive
Older style DISK II interface (dual headers)
Supercomm serial communications interface (supposed to be 100% SSC compatible)
Apple Expanded 80 column text card
There is other stuff but it's removed from the Apple right now.
Any clues?
It's your serial cable.
You can also visit the ADTPro support discussion directly:
https://sourceforge.net/p/adtpro/discussion/support/
Thanks for the reply DAvid, as cryptic as it is.
What might be wrong with the serial cable? It is a standard null modem cable, and as I said, it works fine with ADTWin (at 19200 baud) and even works with ADTPro if I use the older ADTWin Apple client. Does the new ADTPro require some non-standard cable?
My instincts tell me that it may be other issues as well.
You can try using a Super Serial Card II and it's jumper and switches set for bootsrapping.
There is no special cable needed for an apple iie. A straight through modem cable will work fine but you need to set the arrow on the Super Serial Card II to the correct direction.
It also may be that you need to use an enhanced iie but I might be wrong on this.
The problem I see with folks that complain of setups that work for ADT but not ADTPro are always down to the serial cable in use. Your situation is unique in that I've never seen a "Supercomm" board before, so that might yet be an issue - but probably not since both ADT and ADTPro talk to serial cards the same way.
Well, no - there is no "standard" null modem cable. They came in several flavors. When they behave differently, it is down to which handshaking lines they extended or crossed.
Here's one thing to try: in the ADTPro server, under File->Serial Configuration, tick the "Apple IIc w/Imagewriter Cable" and see if that changes anything for you.
Thanks for the replies guy's.
The Supercomm card is "supposed" to be 100% compatible with the super serial card. I has the same jumper, the two switch banks set-up the same way, it uses the same command sequences. It even uses the same chips. But who really knows.
I realize I could just turn the jumper around, but I have other uses for it that need the straight through cable. So either I use a null modem for them or for the ADTPro as I don't want top be pulling the board out and switching the jumper all the time. However, I'll use whatever combination works for me, so that is certainly one thing I can try.
By standard null modem, I mean the one that works in most cases (at least in my experience):
2 RXD <---- TXD 2
3 TXD ----> RXD 3
4 DTR ----> DSR 6 & DCD 8
5 GND ----- GND 7
1 DCD & 6 DSR <---- DTR 20
7 RTS ----> CTS 5
8 CTS <---- RTS 4
I'll try the "Apple IIc w/Imagewriter Cable" option and see how it works.
Thanks again guys.
No luck. Here is an update.
When I tried this the ADTPro 2.0.0 serial client would not even start.
When I moved the jumper and used a straight through cable I get exactly the same problem. The old client works like a charm, the ADTPro (V2.0.0 or V1.3.0) will go the receive page then stall on receiving block 0002. Then after about 10 seconds the server aborts.
I even tried 3 different straight through cables from 3 different manufacturers as well as one I made myself. All exactly the same result.
I'm going to give up on this as I do not want my limited time with my Apple to go to waste. I'll just employ CiderPress to convert images to .DSK format then use the old ADTWin client with the ADTPro V2.0.0 server. This seems to work fine.
Thanks for your time folks.
Well, at least through the process of elimination, we now know that the problem is either:
The server PC, the serial card, or your iie.
My guess is that it's the serial card. I, myself have never had a problem with serial transfers with ADTPro. Even the bootstrapping process from scratch worked great for me under ADTPro 1.19.
The problems that I had was a cable I made according to the website's pinouts for the iigs and transfers via Ethernet.
But serial transfers work great for me with my iie no matter what.
I wonder what sort of serial port the OP is using? I will guess and assume old-school "discrete" 16550 UART type or equivalent? Characterized by a DB9 connector in the back.
@david__schmidt
I wonder if the stalling on block 0002 is similar to what I'm seeing when I try to transfer BAO 5 and higher?
@BillO
Part of the fun of classic computing with Apple stuff is trying to make things work. When you get it working it's very rewarding. I'd like for you to try the ADT 2.0.0 client and set Blocks At Once to 1 instead of 2. Just do it from the client CONFI(G) screen. http://adtpro.sourceforge.net/configserial.html
I'd agree with this if the old client didn't work so darn well. As David said, both clients access the serial card the same way. I guess I could try to buy an original Apple Super Serial and try that, but that will take some time.
Yes, it a 'real' RS232 port on the PC. More than likely it's a 16550 or equivalent, but I've not actually checked that.
I'll try setting it to single blocks to see if that helps.
@david_schmidt
Are you addressing the 6551 directly or by calling the ROM routines on the Apple serial card?
Accessing the 6551 directly - hence the discussion of similarity between your card and the Super Serial card.
The process of elimination is one of the most effective means of getting something to work.
Keep eliminating possibilities until only one is left and then you will have your answer.
Keep doing this repeatedly and you will develop an instinct that will work for you to the point when your first guess concerning troubleshooting will be correct most of the time.
[quote=insanitor]
I agree completely. What I have going for me is a 41 year career in IT from being a hardware technician back in the 70's to being a executive in the software industry now and pretty much everything else during the interim years. I may have lost some of my technical acumen sitting in an office, but what I really lack now is time.
Given what David say about how the serial port is accessed I am forced to believe that getting a Apple SSC will not help me much. My problem lies elsewhere, so that's where I'll look for now. I do have a different PC I could try. I have noticed that some software using the serial port on that Lenovo does not work as expected. I have had strange problems using it with certain versions of avrdude to run bit-banger AVR programmers. I could also try a USB to serial bridge.
Thanks for the support everyone!
Do try that - USB is the most common serial pathway today. If avrdude is giving you trouble, I have my doubts about the native serial port. Keatah and I are working through a problem that may be native vs. USB related as well:
http://sourceforge.net/p/adtpro/discussion/support/thread/19d41ed8/
Update:
Changing to single block transfers seems to work on the Lenovo. It does not matter whether it's the 'real' port of the USB or at which baud rate. It needs to be set at single blocks, then everything else works. Next I will try a different PC to see if multiple block transfers are possible.
More to come...
Update:
The other PC seems to work fine. I works better at single blocks than anything else, but we're talking a pretty slow machine here (1.8gHz Celeron) and USB V1.X ports. At 115200 baud I can get most disks across in under 30 seconds. I'm good with this.
Thanks for all the help!
That should really be plenty fast for a host machine. Are you saying that transfers go more slowly with higher blocks-at-once counts? We expect the user feed back to be different (chunkier/less frequent screen updates) but overall it should result in faster overall transfer times.
I see only a 2 or 3 second difference between BAO1 and BAO40.
Yes. Once I get up above 5, it really slows down. A lot (maybe even most) of the time it stalls as keatah has reported, during transfers to the Apple. I have not yet tried it the other way (no need yet).
If you do, it is best to make sure that the chipset inside the usb to serial bridge has an FTDI chipset and not a Prolific chipset.
Read:
http://www.usconverters.com/index.php?main_page=page&id=62
It's a Silicon Labs CP2103 and works very well.