First of all thanks for implementing the arrow-keys for disk image selection. I only played with it a little, but it seems to be in order. Now I found some possible bugs. Maybe I have a hardware issue someplace? Maybe not.
Possible bug #1
Number of blocks being sent at once. Only 1 or 2 seem to work correctly. 5 through 40 cause a problem where the client seems to lock-up, but ESC aborts back to the menu. I'm guessing some sort of error is happening somewhere. This happens with both my virtual setup of Applewin and com0com serial emulator or real PC with real Apple II.
Possible bug #2
Assume the following:
1 PC powered up.
2 SSC in slot 2.
3 SSC connected to serial port on PC
4 Apple //e not yet powered up
5 ADT server on PC not running yet.
Turn on the Apple and boot ADT 2.0.0
You're presented with the ProDOS boot screen and soon enough the select connection screen (S)erial (E)thernet (A)udio (Q)uit. Good enough so far.
And then the disk whirs for a moment, and loads the appropriate client. But no text is displayed. You're presented with a black screen.
Now, start the ADT server on the PC by doing adtpro.bat. The server starts up. And then the client NOW moves on and displays the familiar (S)end (R)eceive .. etc .. screen.
However, If I skip item number 3 and not have the //e connected to the PC, then the (S)end (R)eceive comes up normally.
Additionally another scenario, if I repeat the above process except changing item #5 to ADT server running and waiting, I still get the blank screen until I hit connect or do something in the pulldown File menu. Then the client magically continues on to the (S)end (R)eceive screen.
This problem does not happen with my Applewin and com0com serial port emulator, only my real-world hardware.
I hope that all makes sense and I'll be happy to clarify anything or try some experiments in the next few days while I have the time.
I have not read through the revised documentation, so if this is described there then sorry..
Bugs certainly are possible. Did you have any specific ones in mind? ;-)
Ha, yes of course. I accidentally reloaded the page and it interpreted that as a genuine post so as not to lose anything entered - which was nothing at the moment.
Incidentally I have zero problems with Bootstrapping on real or virtual hardware. For some inexplicable reason (when I'm drunk) I find it quite amusing to bootstrap Applewin!
Possible bug #1: It would be interesting to see the server log for 5 blocks at once. This is pretty basic functionality, and I regularly use higher BAO counts.
Possible bug #2: I see that behavior too, and it all depends on the nature of your serial connection; where the null-ness of the null modem comes in, and so on. So it's not unexpected. It can get stuck waiting for a state to change. The null modem, USB adapters, etc. all play a part here.
Drunk bootstrapping: I'm in complete agreement. You should try with the Apple ///... it's even prettier. I have a disk with the 'grub' bootstrap program in block zero, so I can test (and re-test and re-test) very quickly.
ADT server can make a log? Where is it saved? How do I tell it to make one?
Note: I can send from Apple-to-PC with BLOCKS AT ONCE 40 just fine.
PC to Apple seems to be stuck at 15 if I select 5, 10 at 10, 20 at 20, and 40 at 40.
Baud rate and doesn't seem to affect this. Neither does changing flow control or fifo buffers options.
Using regular SSC with 6ft serial cable and old-school p3 with real serial ports. And back to windows com1 and com2 default settings.
This doesn't affect how I use ADT. Just trying to figure out what is different with what I thought to be a standard default setup. All other serial port stuff in ADT seem to be working just fine.
Ok I found the trace function.
I turned it on and attempted to send a disk to the Apple. BAO-5
As expected the client seemed to stop at receiving 15 blocks.
In my virtual Applewin + com0com setup it freezes at 10 blocks.
I'm watching the ADTproTrace.txt grow and grow. I hit ESC on the client when the log grew to 175kbytes. It stopped at 181Kbytes. Log is from real hardware.
As the server tries to send blocks 10-15 to the client, the client consistently reports negative acknowledgement, and asks the server to re-send. Which it does, three times, then gives up on the client. (I see I need to exchange a "go home" packet when that happens... the client never gives up, and continually asks to a resend until you hit escape.)
So something is going wrong at the client end. I'll have to pull together an SSC and a II+ or IIe to try this on my end. The failure points sound suspect... they are falling on some interesting boundaries. It is working fine for me with serial over IP right now, but that's not a fair comparison because SIP has a different server path than straight serial. So I'll have to poke more.
Ok, I just tested with a Super Serial card in an enhanced IIe - I was successful at 5BAO and 40BAO transferring the same disk as you, so I'm out of ideas why it wouldn't be transferring successfully for you at a higher BAO count.
Possible bug #2: I figured out why you are seeing that. In versions before 2.0.0, the main menu is displayed before any communications happens. Now, an initial message is sent before the menu is displayed. In both cases, you hang on any serial port communications - so in version 1.3.0, you'd see the menu, but any attempt to communicate would hang until you made the final connection. The problem in 2.0.0 and above is that you hang before anything is displayed. That's probably worth changing, but the fact remains that the hardware will block you if you're not connected.
Are you trying transferring both ways, S)end and R)eceive?
I can try a different serial card, cable, and port on the PC and see what happens. But it also fails in my virtual setup.
Yep, I tried both ways. A variable I'd like to see you change is the host. A different PC or Mac would be interesting.
Turning off the baud rate emulation in com0com fixes my virtual setup.
Ok. Does that leave other scenarios still broken?
Real PC, apple, ssc, real cable, real serial db9 port still won't receive BAO5 or higher. I have the parts to build up another pc but it will take some time.
My virtual setup with Applewin - com0com - ADTpro can now transfer disks BAO 1-40 in both directions. It even works with all 3 pieces of software in a VM.
My virtual/emulation setup is on one pc, while my real hardware is an entirely different setup.
I put together the other PC and installed a XP and Java and thats it. I still got the same failure. I'm using a "standard" (Belkin F2L088-01) DB25-DB9 serial cable.
The pinout is:
DCD 1---8 DCD
RxD 2---3 RxD
TxD 3---2 TxD
DTR 4---20 DTR
G 5---7 G Signal ground
DSR 6---6 DSR
RTS 7---4 RTS
CTS 8---5 CTS
RI 9---22 Ring indicator
I tried a different SSC card and Apple //e I had laying around. The only original things remaining are the SSC connector's rainbow dongle and serial cable (which ohm out correctly).
The common thread here is a native serial port. I've probably got an old PC around here I can try as well. Have you tried the "IIc w/Imagewriter II cable" tickbox?
So you are using a USB - RS-232 adapter for testing and development? I've been meaning to get one of these for a long time.
Yes I tried the Imagewriter IIc option. I seem to lose ALL communication then. Lockups.
Yes, I haven't had/used a computer with a real serial port for a long time. About 99% of my users use them [USB serial adapters] too, so I've spent a lot of effort researching and validating compatibility of USB adapters through the years. You're the first to mention a native serial port in... years. Not that that's a bad thing. I do need to circle back and try that myself.
When troubleshooting this: keep in mind I can (s)end from the Apple to the PC at any BAO setting, 1,2,5,10,20,40.
Good news - I was able to reproduce the problem of 5 BAO and up with a native serial port. Flushing the cache every 256 bytes or so rather than waiting until a full blocks-at-once count is reached seems to keep native serial hardware happy without affecting USB ports. So that fix is in the code now.
Hello, I found an easy-to-fix but show-stopping bug for Linux users.
If ADTPro-2.0.0 is installed in a directory path that has spaces, for example, "Apple II/Utilities/ADTPro-2.0.0", then the adtpro.sh script will immediately complain and die:
./adtpro.sh: 17: export: II/Utilities/ADTPro-2.0.0: bad variable name
The solution is to enquote the variable assignment argument in two locations:
./adtpro.sh: 62: export: II/Utilities/ADTPro-2.0.0/lib/rxtx/rxtx-2.2pre2-local/x86_64-unknown-linux-gnu: bad variable name
Once I figured that out, it worked flawlessly to bootstrap from my Kubuntu 14.04 Linux -> ROM 3 Apple //c! Thank you so much! :)
Thanks, Michael - this is the most useful kind of bug report. It even includes the solution. I would only add that 1) no red-blooded Unix user would EVER consider using a space in a directory name, but it still needs to be fixed and 2) this certainly deserves its own thread. But I'll get it fixed either way.
You're welcome, and I won't take that personally about spaces in my filenames. I happen to find it makes things more readable. And for better or for worse, Canonical is facilitating my newbie friends to gracefully enter into the Unix world, and we want to be friendly and welcoming to them, right? :)
Thanks for the fix!
So, I'm in the code now looking up line 17 - and I have backticks surrounding the pwd call:
Which should solve at least the first problem. (I have to defend myself - I did try this out on Mac to be sure people could use spaces in paths.) Can you explain how/why your original adtpro.sh (or why you had one at all on OSX - you should have adtpro.command insetead) differs from that?
(Edit - I see that my backticks are missing from the text above... evidently the forum is interpreting some characters for formatting. So my real question is... this works as-is on OSX. Is it just broken on Kubuntu?)
Oh yeah, I see that this forum has stripped out the backticks in the code I originally posted. Grr!
So I made a pastebin of my modified code here: http://pastebin.com/EyetfVGB
The changed, relevant lines are 17 and 62.
To answer your question: I would guess if it works for you under OSX then the script is broken on Debian, Ubuntu, Kubuntu, Lubuntu, etc. Not sure why bash would allow assignments like that on OSX.
I've had to make this fix for other Linux games that assume paths with no spaces.
Oh and by the way, the ac.sh script will need a similar fix on line 10.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.