I'm trying to use ADTPro to get files to my Apple IIgs. I know I did this a couple of years ago, but I was using a different machine then, and I only have foggy memories of how it worked. I've followed the tutorial video, and everything goes smoothly until the point where I'm suppose to start the serial connection on my Windows machine. As soon as I click on "Serial," the program disappears. Obviously, it's impossible to start bootstrapping at that point.
The machine recognizes the USB-to-serial converter I'm using (and it worked in the past--albeit on a different computer), so I'm pretty sure that's not the problem. I think I have prepped the IIgs properly as well, if that's an issue (Ctrl-reset to get the command prompt, IN#2 <return>, Ctrl-A 14B <return>). I'm running the latest stable version of Java. The only other thing I can think is that my MSI has some custom software that's interfering (it's got internet management software, and sound management stuff that consistently interferes with game programs).
Anyone else have any other ideas?
Thanks in advance,
Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you go to File->Serial Configuration, on the Port tab - what is your COMx port set to? And does that match what you expect your USB converter to be talking on?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right, but you should know precisely which COM port your USB adapter is claiming (or, it may not be there at all, if you haven't installed a driver for it yet). You can deduce that by bringing up the list of ports with and without the adapter plugged in - but be sure to close and re-open the configuration dialog between plugs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you. I think I wrote my response poorly. I verified in Device Manager that it saw the USB adapter, verified the port (COM3 was the automatic assignment), and then when I went over to ADTPro, the Serial settings were set to the same port. As an experiment, I went back to Device manager and switched the port over to COM1. When I restarted ADTPro, it actually automatically detected that COM1 was the only thing that worked--in other words, it was set correctly.
When I go to Device Manager, I can only see the USB Serial device--there are no other COM devices (although when I switch the port, it says COM4 is unavailable, so something must be using that). I don't know if that makes any difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, thanks for taking the time to help. I appreciate the program--it's been very helpful in the past. I'm teaching a Games & Culture course at my university, and I have a historic game lab where the students are playing through old systems. This week includes the Apple IIe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I typed up a long response to this, and just as I hit the "Post" button, SF went down for a day and a half. I'll be moving to Github shortly. I've finally had enough of SF's shenanigains.
In the mean time: what you need to do to further diagnose is edit your adtpro.bat file. Look at the second-to-last line - the line starts with this:
Get rid of the "start /min" bit, and then run that right from a command line. When ADTPro vaporizes, you should see a Java dump right thre in the command window. That will tell us what went wrong!
Last edit: David Schmidt 2017-09-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cool! I'll try that next week when I'm back in the office--I was busy with a conference the last couple of days.
In the meantime, I did identify that the problem was my computer: I pulled an old XP machine out of storage and was able to successfully communicate with the Apple IIgs. However, I'd like to help de-bug this for future users who might have problems similar to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So just removed "start /min"? I did that (using notepad) and ran the program from the command prompt, and when it stopped working, nothing got dumped in the command window. Or did I need to delete more?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow, then it must be crashing within JNI when it's trying to talk to the hardware layer. You might try enabling tracing and seeing if there are any additional clues within the trace file, but my guess is it's crashing so deep in the OS that we're not even aware of it on the application layer.
Interim question 1:
Are you seeing the messages:
ADTPro Server version v.r.m
args.length = 0
When you start up?
My next line if inquiry is bit-width agreement in your OS vs. Java. What does java -version return to you in the command prompt? Do you know if your OS is 32-bit or 64-bit?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The line Log.println(true, "args.length = " + args.length); is unconditional in both 2.0.1 and 2.0.2; you should absolutely be getting that in your console. (Any reason you're not on 2.0.2? Not that I expect that would change anything, but...)
If you push the audio button and then the disconnect button, do you see these lines?
AudioTransport opened.
CaptureThread.run() entry with hardware mixer index 0
CaptureThread.run() using audio mixer ADTPro Default Audio Capture.
AudioTransport closed.
CaptureThread.run() exit.
I don't expect trace to tell us anything interesting, but it's under File->Activate Trace.
Last edit: David Schmidt 2017-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. Nothing happens with the audio button--no text shows up. It says connected. When I disconnect, nothing happens there either.
Interestingly, when I tried to connect with serial with nothing plugged in, it gave a long string of feedback, starting with "gnu.io.NoSuchPortException" But when I plugged the usb serial port adapter back in, it did the same thing: stopped working and gave no feedback.
I dunno why I have 2.0.1. Maybe I downloaded the wrong version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
p.s. sorry for the slow responses--I'm working and just coming back here when I have a minute. I'm also about to go AWOL for the day--teaching all afternoon and then leaving work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, that's the problem then: the serial layer can't communicate with your serial adapter. It might be getting stuck during enumeration (though you initially said it showed up, which is strange). But the fact that the comms thread is never getting its messages out seems to indicate there is a problem between Java, the serial driver, and the OS. The solution is going to come from the driver - either an updated or different one. But the one you've got now isn't playing nice in the environment it's in.
Last edit: David Schmidt 2017-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. Well, hopefully that's of use to someone. I got a different one (accidentally ordered a 2nd one) so I'll try that later and report back if that solves the problem. Thanks for all your troubleshooting!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That seems consistent with what you've been seeing - it's crashing in the rxtx layer (native interface between Java and the serial device driver). What is the chipset manufacturer of your USB adapter?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FDTI CDM is the only info I have. I have another one (USB to Serial adapter), but apparently, it's someone ripping someone else off, and the actual manufacturer has updated the driver to block the function of any rip-off chips (which I had no idea I was purchasing). I may have found a workaround for that one... maybe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Windows may download the correct driver on its own, but if it differs from what you can get from FTDI directly, that would worry me: http://www.ftdichip.com/Drivers/VCP.htm
You definitely want to stay away from Prolific and bad clones thereof.
Last edit: David Schmidt 2017-10-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm trying to use ADTPro to get files to my Apple IIgs. I know I did this a couple of years ago, but I was using a different machine then, and I only have foggy memories of how it worked. I've followed the tutorial video, and everything goes smoothly until the point where I'm suppose to start the serial connection on my Windows machine. As soon as I click on "Serial," the program disappears. Obviously, it's impossible to start bootstrapping at that point.
The machine recognizes the USB-to-serial converter I'm using (and it worked in the past--albeit on a different computer), so I'm pretty sure that's not the problem. I think I have prepped the IIgs properly as well, if that's an issue (Ctrl-reset to get the command prompt, IN#2 <return>, Ctrl-A 14B <return>). I'm running the latest stable version of Java. The only other thing I can think is that my MSI has some custom software that's interfering (it's got internet management software, and sound management stuff that consistently interferes with game programs).
Anyone else have any other ideas?
Thanks in advance,
Kevin
Hi, Kevin -
When you go to File->Serial Configuration, on the Port tab - what is your COMx port set to? And does that match what you expect your USB converter to be talking on?
Yes. I've tried both COM1 and COM3. ADTPro is configured to use the same COM port.
Right, but you should know precisely which COM port your USB adapter is claiming (or, it may not be there at all, if you haven't installed a driver for it yet). You can deduce that by bringing up the list of ports with and without the adapter plugged in - but be sure to close and re-open the configuration dialog between plugs.
Thank you. I think I wrote my response poorly. I verified in Device Manager that it saw the USB adapter, verified the port (COM3 was the automatic assignment), and then when I went over to ADTPro, the Serial settings were set to the same port. As an experiment, I went back to Device manager and switched the port over to COM1. When I restarted ADTPro, it actually automatically detected that COM1 was the only thing that worked--in other words, it was set correctly.
When I go to Device Manager, I can only see the USB Serial device--there are no other COM devices (although when I switch the port, it says COM4 is unavailable, so something must be using that). I don't know if that makes any difference.
Oh, and I did install the driver, btw.
Also, thanks for taking the time to help. I appreciate the program--it's been very helpful in the past. I'm teaching a Games & Culture course at my university, and I have a historic game lab where the students are playing through old systems. This week includes the Apple IIe.
I typed up a long response to this, and just as I hit the "Post" button, SF went down for a day and a half. I'll be moving to Github shortly. I've finally had enough of SF's shenanigains.
In the mean time: what you need to do to further diagnose is edit your adtpro.bat file. Look at the second-to-last line - the line starts with this:
Get rid of the "start /min" bit, and then run that right from a command line. When ADTPro vaporizes, you should see a Java dump right thre in the command window. That will tell us what went wrong!
Last edit: David Schmidt 2017-09-28
Cool! I'll try that next week when I'm back in the office--I was busy with a conference the last couple of days.
In the meantime, I did identify that the problem was my computer: I pulled an old XP machine out of storage and was able to successfully communicate with the Apple IIgs. However, I'd like to help de-bug this for future users who might have problems similar to me.
Sounds good. I'll be interested to see what it is.
So just removed "start /min"? I did that (using notepad) and ran the program from the command prompt, and when it stopped working, nothing got dumped in the command window. Or did I need to delete more?
p.s. if you want to move this to the new GitHub forums, just let me know.
That's ok, we can finish this up here, then I'll make this forum read-only.
So, when you ran the program and it "stopped," did the command prompt simply return to you?
Yup. No extra dump of code or feedback or anything.
Wow, then it must be crashing within JNI when it's trying to talk to the hardware layer. You might try enabling tracing and seeing if there are any additional clues within the trace file, but my guess is it's crashing so deep in the OS that we're not even aware of it on the application layer.
Interim question 1:
Are you seeing the messages:
When you start up?
My next line if inquiry is bit-width agreement in your OS vs. Java. What does
java -version
return to you in the command prompt? Do you know if your OS is 32-bit or 64-bit?Let me do the simple stuff first. When I start from the Command Prompt window, the message reads:
ADTPro Server version 2.0.1
And that's it.
The Java is 64-bit and my machine is 64 bit.
How would I enable tracing? Sorry for the ignorance.
The line
Log.println(true, "args.length = " + args.length);
is unconditional in both 2.0.1 and 2.0.2; you should absolutely be getting that in your console. (Any reason you're not on 2.0.2? Not that I expect that would change anything, but...)If you push the audio button and then the disconnect button, do you see these lines?
I don't expect trace to tell us anything interesting, but it's under File->Activate Trace.
Last edit: David Schmidt 2017-10-02
Ok. Nothing happens with the audio button--no text shows up. It says connected. When I disconnect, nothing happens there either.
Interestingly, when I tried to connect with serial with nothing plugged in, it gave a long string of feedback, starting with "gnu.io.NoSuchPortException" But when I plugged the usb serial port adapter back in, it did the same thing: stopped working and gave no feedback.
I dunno why I have 2.0.1. Maybe I downloaded the wrong version.
p.s. sorry for the slow responses--I'm working and just coming back here when I have a minute. I'm also about to go AWOL for the day--teaching all afternoon and then leaving work.
Ok, that's the problem then: the serial layer can't communicate with your serial adapter. It might be getting stuck during enumeration (though you initially said it showed up, which is strange). But the fact that the comms thread is never getting its messages out seems to indicate there is a problem between Java, the serial driver, and the OS. The solution is going to come from the driver - either an updated or different one. But the one you've got now isn't playing nice in the environment it's in.
Last edit: David Schmidt 2017-10-02
Ok. Well, hopefully that's of use to someone. I got a different one (accidentally ordered a 2nd one) so I'll try that later and report back if that solves the problem. Thanks for all your troubleshooting!
Hold up! I updated the driver and I got an error dump. Check this out:
ADTPro Server version 2.0.1
args.length = 0
SerialTransport opened port named COM1 at speed 115200.
A fatal error has been detected by the Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000180005b00, pid=11132, tid=12148
JRE version: Java(TM) SE Runtime Environment (9.0+181) (build 9+181)
Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
Problematic frame:
C [rxtxSerial.dll+0x5b00]
No core dump will be written. Minidumps are not enabled by default on client versions of Windows
An error report file with more information is saved as:
D:\Program Files (x86)\Utilities\ADTPro - Apple II file transfer\ADTPro-2.0.1\disks\hs_err_pid11132.log
If you would like to submit a bug report, please visit:
http://bugreport.java.com/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.
Sorry for the huge font! Dunno what happened in paste.
That seems consistent with what you've been seeing - it's crashing in the rxtx layer (native interface between Java and the serial device driver). What is the chipset manufacturer of your USB adapter?
FDTI CDM is the only info I have. I have another one (USB to Serial adapter), but apparently, it's someone ripping someone else off, and the actual manufacturer has updated the driver to block the function of any rip-off chips (which I had no idea I was purchasing). I may have found a workaround for that one... maybe.
Windows may download the correct driver on its own, but if it differs from what you can get from FTDI directly, that would worry me:
http://www.ftdichip.com/Drivers/VCP.htm
You definitely want to stay away from Prolific and bad clones thereof.
Last edit: David Schmidt 2017-10-04