Apple Disk Transfer ProDOS Activity
Transfer disks and disk images between the Apple II and the real world
Brought to you by:
david__schmidt
Activity for Apple Disk Transfer ProDOS
-
Apple Disk Transfer ProDOS released /applesilicon/ADTPro-v.r.m.tar.gz
-
-
-
-
-
David Schmidt posted a comment on discussion Support - archive
Note that the project is now on GitHub: https://adtpro.com/
-
David Schmidt posted a comment on discussion Support - archive
Regarding pps - there are checksums for the (full) data block and retried until success or 5 or os retries are exhausted. For example, see the protocol specification here: http://adtpro.com/protocol.html#Image_Get_Packet
-
Thomas Sontowski posted a comment on discussion Support - archive
thanks for the quick answer - I did get it working now with another, old ftdi USB-serial adapter and a change of baud rate. It looks like it is really hard these days to find one that supplies the voltages (?) plus baud rate my German PAL-IIc needs here. And works with OS X. Or I was just plain unlucky. Also my IIc in this working setup still just doesn't want to work with 2400 baud - which I tried most of the time since it was the lowest baud rate for the initial bootstrapping. Worked in the end...
-
Hi, Thomas - You almost certainly don't want to do the old 'copy libs' trick. You'll want to back those changes out immediately. Back to your USB woes - each adapter will require a driver specific to the chipset in the adapter in order to mesh with OSX. It sounds like you might have a good one for FTDI, but not for the others. And cheap clones of the 'Prolific' chipset generally are poorly supported on OSX. I've heard of some other uplevel OSX folks having trouble with the Java support since Apple...
-
Hi, I am new to the Apple II -but not to retro computers in general- and have a hard time trying to get ADTPro up and running. Initially ADTpro didn't see my usb<->serial converters, I did the 'copy libs to /Library/Java/Extensions/ manually advice and afterwards it did allow me to select them. When sending the bootstrap data I got a bunch of unexpected garbage on my IIc so I tried with a terminal app instead and tested the connection this way - which showed that the converter was at fault. So I...
-
OTOH, downloading the driver manually means the old one may still be there and conflicting; it's also possible to choose the wrong driver. The only way to know for sure is to go into the hardware manager and find the USB manifestation and see what driver (and revision) it's using. Since this is Windows 10, I'm assuming the only possible bit-width is 64, so we're not looking at a mismatch there. But there's definitely something hinky going on with your driver setup. I'd get real familiar with hardware...
-
OTOH, downloading the driver manually means the old one may still be there and conflicting; it's also possible to choose the wrong driver. The only way to know for sure is to go into the hardware manager and find the USB manifestation and see what drivert (and revision) it's using. Since this is Windows 10, I'm assuming the only possible bit-width is 64, so we're not looking at a mismatch there. But there's definitely something hinky going on with your driver setup. I'd get real familiar with hardware...
-
Kevin Schut posted a comment on discussion Support
Ah. The other new one was indeed a Prolific clone, now that you mention the name. So that's not going to fix things, huh? I got the very latest driver directly from the FDTI website--it was uploaded August 30, 2017. So I'm not going to do better than that. I guess that my configuration of Windows 10 is just not going to be happy with USB to Serial adapters.
-
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.
-
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
-
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.
-
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?
-
Sorry for the huge font! Dunno what happened in paste.
-
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)...
-
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!
-
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 ...
-
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.
-
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. 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.
-
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()...
-
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, 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...
-
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.
-
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...
-
Yup. No extra dump of code or feedback or anything.
-
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?
-
p.s. if you want to move this to the new GitHub forums, just let me know.
-
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?
-
Sounds good. I'll be interested to see what it is.
-
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.
1 >