| ADTPro Issue [message #396951] |
Thu, 23 July 2020 14:04  |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
I'm having a weird problem with ADTPro and my Uthernet card on my IIgs. This setup always worked just fine up until recently. Suddenly the read cycle pauses and stutters several times when I attempt to transfer something. Sometimes it will fail after a short time (as when writing to a real SCSI hard drive), but other times it will continue for a long time (as when writing to my MicroDrive Turbo) although much slower than it should be due to all the pauses but it will always eventually crash. Any idea what could be causing this? I assume it as to be something with my router, but I haven't changed any settings on it recently.
I did turn on the trace feature, but I don't see anything obvious in there. Then again I'm not exactly sure what I should be looking for.
|
|
|
|
| Re: ADTPro Issue [message #396954 is a reply to message #396951] |
Thu, 23 July 2020 16:14  |
David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 7/23/20 2:04 PM, Tempest wrote:
> I'm having a weird problem with ADTPro and my Uthernet card on my IIgs. This setup always worked just fine up until recently. Suddenly the read cycle pauses and stutters several times when I attempt to transfer something.
[...]
In case you changed it - look in the client configuration of
blocks-at-once and make sure that's set to 1.
|
|
|
|
| Re: ADTPro Issue [message #396956 is a reply to message #396954] |
Thu, 23 July 2020 17:53 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, July 23, 2020 at 4:14:56 PM UTC-4, schmidtd wrote:
> On 7/23/20 2:04 PM, Tempest wrote:
>> I'm having a weird problem with ADTPro and my Uthernet card on my IIgs. This setup always worked just fine up until recently. Suddenly the read cycle pauses and stutters several times when I attempt to transfer something.
>
> [...]
>
> In case you changed it - look in the client configuration of
> blocks-at-once and make sure that's set to 1.
Yes it is. Also, Enable Nibbles is set to No.
|
|
|
|
|
|
| Re: ADTPro Issue [message #397143 is a reply to message #397142] |
Mon, 27 July 2020 12:43 |
David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 7/27/20 12:09 PM, Tempest wrote:
> Any other ideas?
Not really... you might look through the trace to see if there's any
retrying going on, and then back up to see what it's complaining about.
|
|
|
|
| Re: ADTPro Issue [message #397149 is a reply to message #397143] |
Mon, 27 July 2020 13:24 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Here's the trace right before it quit. Most of this doesn't make much sense to me:
7/27/20 1:20:47 PM UDPTransport.pushBuffer() exit.
7/27/20 1:20:47 PM CommsThread.sendPacketWide() calculated CRC: 12975
7/27/20 1:20:47 PM CommsThread.pullEnvelopeWide() entry.
7/27/20 1:20:48 PM UDPTransport.pullBuffer() received a packet.
7/27/20 1:20:48 PM UDPTransport.pullBuffer() pulled data:
C1 03 00 CB 09 15 B7 16 B4
7/27/20 1:20:48 PM Waiting for byteslo...
7/27/20 1:20:48 PM received byteslo: 03
7/27/20 1:20:48 PM Waiting for byteshi...
7/27/20 1:20:48 PM received byteshi: 00
7/27/20 1:20:48 PM Waiting for command...
7/27/20 1:20:48 PM received envelope command: CB
7/27/20 1:20:48 PM Waiting for check byte...
7/27/20 1:20:48 PM received checkbyte: 09
7/27/20 1:20:48 PM calculated checkbyte: 09
7/27/20 1:20:48 PM CommsThread.pullEnvelopeWide() exit.
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() entry.
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() payload byte [0]: 15
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() payload byte [1]: B7
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() payload byte [2]: 16
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() received checkbyte: B4
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() calculated checkbyte: B4
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() checkbyte on payload matched.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() Ack received; next block should be 5815.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() ACK from client: 15
7/27/20 1:20:48 PM CommsThread.sendPacketWide() didn't work; will retry #1.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() block: 5814.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() backoff sleeping for 0 seconds (or 1 second, whichever is shorter).
7/27/20 1:20:48 PM CommsThread.sendPacketWide() looping until successful to send block: 16B6
7/27/20 1:20:48 PM UDPTransport.pushBuffer() entry.
7/27/20 1:20:48 PM UDPTransport.pushBuffer() pushing 265 bytes of data:
D8 C1 00 02 D3 10 B6 16 80 10 52 FB AE F5 22 3B A6 0E 5D 92 00 18 3A DD 57 EF AE 06 4F FD BE F6
EF 00 24 80 00 56 1B 18 D9 2A E5 18 D9 2A D6 2A E5 E5 33 00 64 D3 06 33 F4 E8 1B CA 0C 27 03 CA
00 80 80 11 5D D7 F5 DD 57 D7 F6 DC 57 D7 F6 D6 5D D7 F6 C6 67 F5 DE D6 5D EF DB DF 57 D6 F7 DC
57 D7 F5 DD EB FE 80 00 00 80 11 5D 92 00 05 11 5D D6 F4 DF 57 EF DE D6 5D EF DE C6 6B D9 F3 DF
57 EF DE DC 57 D6 F4 DF 57 D6 F4 DF EB FE 80 00 2D 33 00 31 D3 2D 03 D6 27 E8 1B 00 39 CA 33 00
3C 03 00 3E E5 E5 36 D6 2A 00 44 FD 00 46 03 CA 00 76 80 00 78 80 00 80 80 11 5D D7 F3 DF 57 D7
F3 DF 57 D6 F6 D7 5D D6 F6 C7 6B F1 DE DC 57 E7 E6 DC 57 D6 F6 DD 57 D7 F3 DF EB FE 80 00 D0 A0
E0 08 FC 1C F0 F8 08 F8 08 F0 00 DC 08 FC FC 00 E4 08 FC 04 08 F0 01 07 08 F0 01 FF 01 1F F0 F8
FC FC 00 F8 80 00 00 AF 32
7/27/20 1:20:48 PM UDPTransport.pushBuffer() exit.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() calculated CRC: 12975
7/27/20 1:20:48 PM CommsThread.pullEnvelopeWide() entry.
7/27/20 1:20:48 PM UDPTransport.readByte() needs to pull a buffer; buffer is null.
7/27/20 1:20:48 PM UDPTransport.pullBuffer() received a packet.
7/27/20 1:20:48 PM UDPTransport.pullBuffer() pulled data:
C1 03 00 CB 09 06 B8 16 A8
7/27/20 1:20:48 PM Waiting for byteslo...
7/27/20 1:20:48 PM received byteslo: 03
7/27/20 1:20:48 PM Waiting for byteshi...
7/27/20 1:20:48 PM received byteshi: 00
7/27/20 1:20:48 PM Waiting for command...
7/27/20 1:20:48 PM received envelope command: CB
7/27/20 1:20:48 PM Waiting for check byte...
7/27/20 1:20:48 PM received checkbyte: 09
7/27/20 1:20:48 PM calculated checkbyte: 09
7/27/20 1:20:48 PM CommsThread.pullEnvelopeWide() exit.
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() entry.
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() payload byte [0]: 06
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() payload byte [1]: B8
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() payload byte [2]: 16
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() received checkbyte: A8
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() calculated checkbyte: A8
7/27/20 1:20:48 PM CommsThread.pullPayloadWide() checkbyte on payload matched.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() Ack received for block 5816, but we were expecting an ack for block 5815.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() ACK from client: 15
7/27/20 1:20:48 PM CommsThread.sendPacketWide() didn't work; will retry #2.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() block: 5814.
7/27/20 1:20:48 PM CommsThread.sendPacketWide() backoff sleeping for 0 seconds (or 1 second, whichever is shorter).
7/27/20 1:20:49 PM CommsThread.sendPacketWide() looping until successful to send block: 16B6
7/27/20 1:20:49 PM UDPTransport.pushBuffer() entry.
7/27/20 1:20:49 PM UDPTransport.pushBuffer() pushing 265 bytes of data:
D9 C1 00 02 D3 10 B6 16 80 10 52 FB AE F5 22 3B A6 0E 5D 92 00 18 3A DD 57 EF AE 06 4F FD BE F6
EF 00 24 80 00 56 1B 18 D9 2A E5 18 D9 2A D6 2A E5 E5 33 00 64 D3 06 33 F4 E8 1B CA 0C 27 03 CA
00 80 80 11 5D D7 F5 DD 57 D7 F6 DC 57 D7 F6 D6 5D D7 F6 C6 67 F5 DE D6 5D EF DB DF 57 D6 F7 DC
57 D7 F5 DD EB FE 80 00 00 80 11 5D 92 00 05 11 5D D6 F4 DF 57 EF DE D6 5D EF DE C6 6B D9 F3 DF
57 EF DE DC 57 D6 F4 DF 57 D6 F4 DF EB FE 80 00 2D 33 00 31 D3 2D 03 D6 27 E8 1B 00 39 CA 33 00
3C 03 00 3E E5 E5 36 D6 2A 00 44 FD 00 46 03 CA 00 76 80 00 78 80 00 80 80 11 5D D7 F3 DF 57 D7
F3 DF 57 D6 F6 D7 5D D6 F6 C7 6B F1 DE DC 57 E7 E6 DC 57 D6 F6 DD 57 D7 F3 DF EB FE 80 00 D0 A0
E0 08 FC 1C F0 F8 08 F8 08 F0 00 DC 08 FC FC 00 E4 08 FC 04 08 F0 01 07 08 F0 01 FF 01 1F F0 F8
FC FC 00 F8 80 00 00 AF 32
7/27/20 1:20:49 PM UDPTransport.pushBuffer() exit.
7/27/20 1:20:49 PM CommsThread.sendPacketWide() calculated CRC: 12975
7/27/20 1:20:49 PM CommsThread.pullEnvelopeWide() entry.
7/27/20 1:20:49 PM UDPTransport.readByte() needs to pull a buffer; buffer is null.
7/27/20 1:20:49 PM UDPTransport.pullBuffer() received a packet.
7/27/20 1:20:49 PM UDPTransport.pullBuffer() pulled data:
C1 03 00 CB 09 06 B9 16 A9
7/27/20 1:20:49 PM Waiting for byteslo...
7/27/20 1:20:49 PM received byteslo: 03
7/27/20 1:20:49 PM Waiting for byteshi...
7/27/20 1:20:49 PM received byteshi: 00
7/27/20 1:20:49 PM Waiting for command...
7/27/20 1:20:49 PM received envelope command: CB
7/27/20 1:20:49 PM Waiting for check byte...
7/27/20 1:20:49 PM received checkbyte: 09
7/27/20 1:20:49 PM calculated checkbyte: 09
7/27/20 1:20:49 PM CommsThread.pullEnvelopeWide() exit.
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() entry.
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() payload byte [0]: 06
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() payload byte [1]: B9
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() payload byte [2]: 16
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() received checkbyte: A9
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() calculated checkbyte: A9
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() checkbyte on payload matched.
7/27/20 1:20:49 PM CommsThread.sendPacketWide() Ack received for block 5817, but we were expecting an ack for block 5815.
7/27/20 1:20:49 PM CommsThread.sendPacketWide() ACK from client: 15
7/27/20 1:20:49 PM CommsThread.sendPacketWide() didn't work; will retry #3.
7/27/20 1:20:49 PM CommsThread.sendPacketWide() block: 5814.
7/27/20 1:20:49 PM CommsThread.sendPacketWide() backoff sleeping for 0 seconds (or 1 second, whichever is shorter).
7/27/20 1:20:49 PM CommsThread.sendPacketWide() exit, rc = false
7/27/20 1:20:49 PM Image transfer aborted.
7/27/20 1:20:49 PM CommsThread.sendDiskWide() exit.
7/27/20 1:20:49 PM CommsThread.dispatchCommand() exit.
7/27/20 1:20:49 PM CommsThread.commandLoop() Waiting for command from Apple.
7/27/20 1:20:49 PM UDPTransport.readByte() needs to pull a buffer; buffer is null.
7/27/20 1:20:49 PM UDPTransport.pullBuffer() received a packet.
7/27/20 1:20:49 PM UDPTransport.pullBuffer() pulled data:
C1 03 00 CB 09 15 B9 16 BA
7/27/20 1:20:49 PM CommsThread.commandLoop() Received data.
7/27/20 1:20:49 PM CommsThread.commandLoop() Received a byte: C1
7/27/20 1:20:49 PM CommsThread.commandLoop() Received wide protocol request.
7/27/20 1:20:49 PM CommsThread.pullEnvelopeWide() entry.
7/27/20 1:20:49 PM Waiting for byteslo...
7/27/20 1:20:49 PM received byteslo: 03
7/27/20 1:20:49 PM Waiting for byteshi...
7/27/20 1:20:49 PM received byteshi: 00
7/27/20 1:20:49 PM Waiting for command...
7/27/20 1:20:49 PM received envelope command: CB
7/27/20 1:20:49 PM Waiting for check byte...
7/27/20 1:20:49 PM received checkbyte: 09
7/27/20 1:20:49 PM calculated checkbyte: 09
7/27/20 1:20:49 PM CommsThread.pullEnvelopeWide() exit.
7/27/20 1:20:49 PM CommsThread.dispatchCommand() entry.
7/27/20 1:20:49 PM CommsThread.dispatchCommand() Received stray acknowledgement packet. Sending Home in response.
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() entry.
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() payload byte [0]: 15
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() payload byte [1]: B9
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() payload byte [2]: 16
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() received checkbyte: BA
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() calculated checkbyte: BA
7/27/20 1:20:49 PM CommsThread.pullPayloadWide() checkbyte on payload matched.
7/27/20 1:20:49 PM CommsThread.sendHome() entry.
7/27/20 1:20:49 PM UDPTransport.pushBuffer() entry.
7/27/20 1:20:49 PM UDPTransport.pushBuffer() pushing 6 bytes of data:
DA C1 00 00 D8 13
7/27/20 1:20:49 PM UDPTransport.pushBuffer() exit.
7/27/20 1:20:49 PM CommsThread.sendHome() exit.
7/27/20 1:20:49 PM CommsThread.dispatchCommand() exit.
7/27/20 1:20:49 PM CommsThread.commandLoop() Waiting for command from Apple.
7/27/20 1:20:50 PM UDPTransport.pullBuffer() received a packet.
7/27/20 1:20:50 PM UDPTransport.pullBuffer() pulled data:
C1 00 00 D8 19
7/27/20 1:20:50 PM CommsThread.commandLoop() Received data.
7/27/20 1:20:50 PM CommsThread.commandLoop() Received a byte: C1
7/27/20 1:20:50 PM CommsThread.commandLoop() Received wide protocol request.
7/27/20 1:20:50 PM CommsThread.pullEnvelopeWide() entry.
7/27/20 1:20:50 PM Waiting for byteslo...
7/27/20 1:20:50 PM received byteslo: 00
7/27/20 1:20:50 PM Waiting for byteshi...
7/27/20 1:20:50 PM received byteshi: 00
7/27/20 1:20:50 PM Waiting for command...
7/27/20 1:20:50 PM received envelope command: D8
7/27/20 1:20:50 PM Waiting for check byte...
7/27/20 1:20:50 PM received checkbyte: 19
7/27/20 1:20:50 PM calculated checkbyte: 19
7/27/20 1:20:50 PM CommsThread.pullEnvelopeWide() exit.
7/27/20 1:20:50 PM CommsThread.dispatchCommand() entry.
7/27/20 1:20:50 PM CommsThread.dispatchCommand() Received Home command. How charming.
7/27/20 1:20:50 PM CommsThread.dispatchCommand() exit.
7/27/20 1:20:50 PM CommsThread.commandLoop() Waiting for command from Apple.
|
|
|
|
| Re: ADTPro Issue [message #397163 is a reply to message #397149] |
Mon, 27 July 2020 17:09 |
David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 7/27/20 1:24 PM, Tempest wrote:
> Here's the trace right before it quit. Most of this doesn't make much sense to me:
>
> 7/27/20 1:20:47 PM UDPTransport.pushBuffer() exit.
> 7/27/20 1:20:47 PM CommsThread.sendPacketWide() calculated CRC: 12975
> 7/27/20 1:20:47 PM CommsThread.pullEnvelopeWide() entry.
> 7/27/20 1:20:48 PM UDPTransport.pullBuffer() received a packet.
> 7/27/20 1:20:48 PM UDPTransport.pullBuffer() pulled data:
> C1 03 00 CB 09 15 B7 16 B4
Actually, a few batches of back-and-forth right before this would be
helpful. Anyway, it seems the client thinks it is a block ahead of the
host, and the host is insisting on sending a block the client says it
already has, and they never sync up. So it's possible an ack is getting
lost.
|
|
|
|
|
|
| Re: ADTPro Issue [message #397212 is a reply to message #397189] |
Tue, 28 July 2020 17:53 |
David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 7/28/20 9:31 AM, Tempest wrote:
> Here's the whole file:
>
> atariprotos.com/temp/ADTProTrace.zip
So, the way retries normally should work is this:
1. Host sends block x
2. Client has a problem with block x, sends NAK and x
3. Host re-sends block x
4. Client likes block x, sends ACK and x+1.
And you have several locations in your log where individual packets are
bad, and it recovers normally.
What's happening at the end of your log is this:
1. Host sends block x
2. Client has a problem with block x, sends NAK and x+1
[This makes no sense; if the client doesn't like the block, it's not
supposed to increment the requested block!]
3. Host balks, re-sends block x
4. Client has a problem with block x, sends NAK and x+2
[Now we're really off the rails, hilarity ensues]
So now I'm stepping through the code trying to figure out what kind of
path could have been taken where it is sending a nak, but still got the
block counter incremented along the way. My initial guess is it's a
noisy packet that it's believing part of, and not heeding (or setting) a
carry flag as error indicator in an obscure error path.
When you said earlier that it "crashes," is it literally crashing to the
monitor - or is it at least stopping the transfer?
|
|
|
|
| Re: ADTPro Issue [message #397213 is a reply to message #397212] |
Tue, 28 July 2020 18:39 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
> When you said earlier that it "crashes," is it literally crashing to the
> monitor - or is it at least stopping the transfer?
I mean it aborts and goes back to the ADTPro menu.
|
|
|
|
| Re: ADTPro Issue [message #397558 is a reply to message #397213] |
Sat, 08 August 2020 12:19 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
|
I was thinking about this again last night, does the Uthernet card have a diagnostic program? Maybe my card is having problems?
|
|
|
|
| Re: ADTPro Issue [message #397571 is a reply to message #397558] |
Sat, 08 August 2020 17:51 |
D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Tempest wrote:
> I was thinking about this again last night, does the Uthernet card have a
> diagnostic program?
Not that I know of. But if you know enough to poke at it, you might be able
to diagnose it manually. Here's an article I wrote many years ago that
should tell you all you need to know:
https://macgui.com/kb/article/763
|
|
|
|
| Re: ADTPro Issue [message #397639 is a reply to message #397571] |
Sun, 09 August 2020 21:23 |
D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
D Finnigan wrote:
> Tempest wrote:
>> I was thinking about this again last night, does the Uthernet card have a
>> diagnostic program?
>
> Not that I know of. But if you know enough to poke at it, you might be
> able
> to diagnose it manually. Here's an article I wrote many years ago that
> should tell you all you need to know:
>
> https://macgui.com/kb/article/763
>
I realized after sending this that the linked article is likely way too much
for your situation.
Many years ago, when I was working with the original Uthernet almost every
day, I found that the presence of other peripheral cards would affect its
operation-- particularly in the old Apple II Plus and Apple IIe (with 6502
CPU). Now I see from your original post that you are using an Apple IIgs.
But it may be the case that other peripheral cards, or possibly
environmental factors like heat are at work here.
As far as diagnostics, I'd usually run Contiki, IP65, or any of the other
Uthernet networking applications to verify operation.
--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/
|
|
|
|
| Re: ADTPro Issue [message #398865 is a reply to message #397639] |
Sun, 30 August 2020 11:18 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
|
I just wanted to bump this as I'm still having the issue. I updated my router's firmware recently and I thought that maybe that might fix the issue, but no dice. Makes me wonder if my Uthernet card hasn't gone bad somehow. I suppose my next test can be to try it in my IIe and see if it has the same problems as it does in my IIgs. That would at least rule out the IIgs itself as the cause (although I honestly can't see that being the issue).
|
|
|
|
| Re: ADTPro Issue [message #398883 is a reply to message #398865] |
Sun, 30 August 2020 15:17 |
|
|
Originally posted by: Bobbi
I am wondering if this may help to debug the problem. Do you have the same issues using VEDRIVE and the ADTPro server?
If the problems manifest themselves using VEDRIVE, try my alternative Python-based VEDRIVE server. That could tell us if it is client or server-side problems.
https://github.com/bobbimanners/ProDOS-Utils/blob/master/ves erver.py
All the best,
Bobbi
On Sunday, August 30, 2020 at 11:18:54 a.m. UTC-4, Tempest wrote:
> I just wanted to bump this as I'm still having the issue. I updated my router's firmware recently and I thought that maybe that might fix the issue, but no dice. Makes me wonder if my Uthernet card hasn't gone bad somehow. I suppose my next test can be to try it in my IIe and see if it has the same problems as it does in my IIgs. That would at least rule out the IIgs itself as the cause (although I honestly can't see that being the issue).
|
|
|
|
| Re: ADTPro Issue [message #398917 is a reply to message #398883] |
Mon, 31 August 2020 09:50 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, August 30, 2020 at 3:17:11 PM UTC-4, Bobbi wrote:
> I am wondering if this may help to debug the problem. Do you have the same issues using VEDRIVE and the ADTPro server?
>
> If the problems manifest themselves using VEDRIVE, try my alternative Python-based VEDRIVE server. That could tell us if it is client or server-side problems.
>
> https://github.com/bobbimanners/ProDOS-Utils/blob/master/ves erver.py
>
> All the best,
> Bobbi
>
>
> On Sunday, August 30, 2020 at 11:18:54 a.m. UTC-4, Tempest wrote:
>> I just wanted to bump this as I'm still having the issue. I updated my router's firmware recently and I thought that maybe that might fix the issue, but no dice. Makes me wonder if my Uthernet card hasn't gone bad somehow.. I suppose my next test can be to try it in my IIe and see if it has the same problems as it does in my IIgs. That would at least rule out the IIgs itself as the cause (although I honestly can't see that being the issue).
I've never heard of VEDRIVE. What is it?
|
|
|
|
| Re: ADTPro Issue [message #398918 is a reply to message #398917] |
Mon, 31 August 2020 10:31 |
|
|
Originally posted by: Bobbi
VEDRIVE is Virtual Ethernet drive by the same author as ADT. It uses ADT server to provide two virtual drives that are mounted on the Apple II.
On Monday, August 31, 2020 at 9:50:54 a.m. UTC-4, Tempest wrote:
> On Sunday, August 30, 2020 at 3:17:11 PM UTC-4, Bobbi wrote:
>> I am wondering if this may help to debug the problem. Do you have the same issues using VEDRIVE and the ADTPro server?
>>
>> If the problems manifest themselves using VEDRIVE, try my alternative Python-based VEDRIVE server. That could tell us if it is client or server-side problems.
>>
>> https://github.com/bobbimanners/ProDOS-Utils/blob/master/ves erver.py
>>
>> All the best,
>> Bobbi
>>
>>
>> On Sunday, August 30, 2020 at 11:18:54 a.m. UTC-4, Tempest wrote:
>>> I just wanted to bump this as I'm still having the issue. I updated my router's firmware recently and I thought that maybe that might fix the issue, but no dice. Makes me wonder if my Uthernet card hasn't gone bad somehow. I suppose my next test can be to try it in my IIe and see if it has the same problems as it does in my IIgs. That would at least rule out the IIgs itself as the cause (although I honestly can't see that being the issue).
> I've never heard of VEDRIVE. What is it?
|
|
|
|
|
|
| Re: ADTPro Issue [message #398934 is a reply to message #398919] |
Mon, 31 August 2020 15:55 |
|
|
Originally posted by: Bobbi
Run ADT server as normal. Install VDRIVE 2.0.3 on your Apple II. VEDRIVE.SETUP is used to setup VEDRIVE on first run, after that you just need to run VEDRIVE.SYSTEM.
Official instructions are here ... https://adtpro.com/vdrive.html
All the best,
Bobbi
On Monday, August 31, 2020 at 10:44:22 a.m. UTC-4, Tempest wrote:
> So how would I use this? Sorry if I sound dense. :)
|
|
|
|
| Re: ADTPro Issue [message #398935 is a reply to message #398934] |
Mon, 31 August 2020 16:05 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
|
Where do I get the vdrive.dsk file? The github you linked to has source code, but I don't see the bootable .dsk image.
|
|
|
|
| Re: ADTPro Issue [message #398936 is a reply to message #398935] |
Mon, 31 August 2020 16:50 |
|
|
Originally posted by: Bobbi
Just checked and it is in the ADTPRO ZIP file ... Download from https://github.com/ADTPro/adtpro/releases
The disk image is this one (inside the ZIP):
ADTPro-2.0.3/disks/VDRIVE-2.0.3.DSK
All the best,
Bobbi
On Monday, August 31, 2020 at 4:05:37 p.m. UTC-4, Tempest wrote:
> Where do I get the vdrive.dsk file? The github you linked to has source code, but I don't see the bootable .dsk image.
|
|
|
|
| Re: ADTPro Issue [message #398984 is a reply to message #396951] |
Tue, 01 September 2020 11:16 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
|
Well I got the vedrive disk loaded on my IIgs and ran the program. It said it created two virtual drives at S1. However when I then ran ADTPro (I assume this is the next step), it froze up at the the PRODOS screen. I'm guessing this is because my Uthernet card is in slot 1, but that's just a guess. Any ideas?
|
|
|
|
| Re: ADTPro Issue [message #398985 is a reply to message #396951] |
Tue, 01 September 2020 11:53 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
|
Is there a way to connect my IIgs Uthernet card directly to my PC and try ADTPro that way? Set up a static IP or something like that? That would at least take the router out of the equation.
|
|
|
|
| Re: ADTPro Issue [message #398995 is a reply to message #398985] |
Tue, 01 September 2020 14:51 |
|
|
Originally posted by: Micah Cowan
On Tuesday, September 1, 2020 at 8:53:43 AM UTC-7, Tempest wrote:
> Is there a way to connect my IIgs Uthernet card directly to my PC and try ADTPro that way? Set up a static IP or something like that? That would at least take the router out of the equation.
That requires the Ethernet equivalent of a "null modem" cable, usually called a "crossover cable" (with the send/transmit wires swapped between them) - or a crossover adapter.
It's been a couple decades since I've used one, so I'm not totally sure if any particular configuration is required in addition. I wouldn't think so, though - not like you have to "route" the packets anywhere.
-mjc
|
|
|
|
| Re: ADTPro Issue [message #399009 is a reply to message #398995] |
Tue, 01 September 2020 17:54 |
|
|
Originally posted by: Bobbi
I think these days most ethernet ports do the crossover thing automatically, so those crossover cables are a relic of the past.
https://en.wikipedia.org/wiki/Medium-dependent_interface
All the best,
Bobbi
On Tuesday, September 1, 2020 at 2:51:09 p.m. UTC-4, micah...@gmail.com wrote:
> On Tuesday, September 1, 2020 at 8:53:43 AM UTC-7, Tempest wrote:
>> Is there a way to connect my IIgs Uthernet card directly to my PC and try ADTPro that way? Set up a static IP or something like that? That would at least take the router out of the equation.
> That requires the Ethernet equivalent of a "null modem" cable, usually called a "crossover cable" (with the send/transmit wires swapped between them) - or a crossover adapter.
>
> It's been a couple decades since I've used one, so I'm not totally sure if any particular configuration is required in addition. I wouldn't think so, though - not like you have to "route" the packets anywhere.
>
> -mjc
|
|
|
|
|
|
| Re: ADTPro Issue [message #399030 is a reply to message #399010] |
Tue, 01 September 2020 21:47 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
|
So if I were to hook my computer directly to the uthernet card via an Ethernet cable and then set the computers IP to be whatever is in the ADTPro configuration file, it should work?
|
|
|
|
| Re: ADTPro Issue [message #399093 is a reply to message #399030] |
Wed, 02 September 2020 11:10 |
|
|
Originally posted by: Bobbi
Probably. I have not tried it myself. I think only one end of the connection needs to be able to do the auto-MDX thing, so assuming your computer does it (which it will unless it is ancient) then we don't need to worry whether the Uthernet-II can do auto-MDX (it probably is a feature of the w5100 chip anyhow.)
Try it and see, I guess!
All the best,
Bobbi
On Tuesday, September 1, 2020 at 9:47:16 p.m. UTC-4, Tempest wrote:
> So if I were to hook my computer directly to the uthernet card via an Ethernet cable and then set the computers IP to be whatever is in the ADTPro configuration file, it should work?
|
|
|
|
|
|
| Re: ADTPro Issue [message #399130 is a reply to message #399125] |
Wed, 02 September 2020 20:27 |
|
|
Originally posted by: Bobbi
Didn't work how exactly? We are going to have to try and systematically work out where your issue is. When you run VEDRIVE.SETUP, does it find your Uthernet card? Do you see any activity on the port (LEDs?)
Bobbi
On Wednesday, September 2, 2020 at 6:50:35 p.m. UTC-4, Tempest wrote:
> I tried it and it didn't work.
|
|
|
|
| Re: ADTPro Issue [message #399137 is a reply to message #399130] |
Wed, 02 September 2020 21:21 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Vedrive did detect the card, but it froze when I tried to load ADTPro. I think it might be because I have my card in slot 1.
Connecting the uthernet directly to my PC didn't seem to work at all.
|
|
|
|
| Re: ADTPro Issue [message #399142 is a reply to message #399137] |
Wed, 02 September 2020 23:39 |
|
|
Originally posted by: Bobbi
Try slot 3 or 5 maybe?
On Wednesday, September 2, 2020 at 9:21:20 p.m. UTC-4, Tempest wrote:
> Vedrive did detect the card, but it froze when I tried to load ADTPro. I think it might be because I have my card in slot 1.
>
> Connecting the uthernet directly to my PC didn't seem to work at all.
|
|
|
|
| Re: ADTPro Issue [message #399148 is a reply to message #399137] |
Thu, 03 September 2020 01:37 |
Oliver Schmidt
Messages: 132
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi,
A hint to those trying to help:
> Vedrive did detect the card, but it froze when I tried to load ADTPro. I
> think it might be because I have my card in slot 1.
Have you noticed that he obviously tries to run ADTPro while he has the
VEDRIVE active?
Regards,
Oliver
PS: In case you wonder why I'm not interested in trying to help...
- He doesn't pick up good advise (try other software)
- He doesn't bother to find out things himself (e.g. about VEDRIVE)
|
|
|
|
| Re: ADTPro Issue [message #399160 is a reply to message #399148] |
Thu, 03 September 2020 09:29 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
> - He doesn't pick up good advise (try other software)
Did I miss something? What other software are you suggesting I try?
> - He doesn't bother to find out things himself (e.g. about VEDRIVE)
I did read about VEDRIVE and I was confused. Not all of us are as technical as some of you. I got VEDRIVE running and it said it made two virtual drives. I wasn't sure what to do next so I assumed that I wanted to run ADTPro to try and transfer a file to one of those virtual drives. I thought that was the whole point.
If you don't feel like helping that's fine, but I don't understand why you felt the need to try and discourage anyone else from helping me. But maybe I'll give it up. I'm in a bad place right now and I really don't need this.
|
|
|
|
| Re: ADTPro Issue [message #399173 is a reply to message #399160] |
Thu, 03 September 2020 12:48 |
|
|
Originally posted by: Bobbi
If you are trying to run ADTPro at the same time as VEDRIVE, then don't do that. It's one or the other.
All the best,
Bobbi
On Thursday, September 3, 2020 at 9:29:49 a.m. UTC-4, Tempest wrote:
>> - He doesn't pick up good advise (try other software)
> Did I miss something? What other software are you suggesting I try?
>> - He doesn't bother to find out things himself (e.g. about VEDRIVE)
> I did read about VEDRIVE and I was confused. Not all of us are as technical as some of you. I got VEDRIVE running and it said it made two virtual drives. I wasn't sure what to do next so I assumed that I wanted to run ADTPro to try and transfer a file to one of those virtual drives. I thought that was the whole point.
>
>
> If you don't feel like helping that's fine, but I don't understand why you felt the need to try and discourage anyone else from helping me. But maybe I'll give it up. I'm in a bad place right now and I really don't need this.
|
|
|
|
| Re: ADTPro Issue [message #399174 is a reply to message #399173] |
Thu, 03 September 2020 12:59 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
So once I run VEDRIVE then what do I do? How do I move and image to the virtual hard drives? I thought the whole point was to make two virtual hard drive and try and use ADTPro to transfer and image to them.
This all may be for nought though. I did some other testing. I moved the Uthernet card to another slot and it behaved the same way. I also moved it to my IIe and it still behaved the same way (having trouble with the reads and eventually aborting). So at this point the issue is either my card or my network. I'm not sure how to determine which one is the problem.
|
|
|
|
| Re: ADTPro Issue [message #399175 is a reply to message #399174] |
Thu, 03 September 2020 13:09 |
|
|
Originally posted by: Bobbi
Would be good to get the Uthernet-II working with *something* to rule out problems there. How is TELNET65 from IP65 for example? Or WEBBROWS.SYSTEM from Contiki? Get one of those working first and we know the Uthernet-II is working. Then we can return to ADTPro.
All the best,
Bobbi
On Thursday, September 3, 2020 at 12:59:06 p.m. UTC-4, Tempest wrote:
> So once I run VEDRIVE then what do I do? How do I move and image to the virtual hard drives? I thought the whole point was to make two virtual hard drive and try and use ADTPro to transfer and image to them.
>
> This all may be for nought though. I did some other testing. I moved the Uthernet card to another slot and it behaved the same way. I also moved it to my IIe and it still behaved the same way (having trouble with the reads and eventually aborting). So at this point the issue is either my card or my network. I'm not sure how to determine which one is the problem.
|
|
|
|
| Re: ADTPro Issue [message #399196 is a reply to message #399175] |
Thu, 03 September 2020 14:26 |
Tempest
Messages: 529
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, September 3, 2020 at 1:09:26 PM UTC-4, Bobbi wrote:
> Would be good to get the Uthernet-II working with *something* to rule out problems there. How is TELNET65 from IP65 for example? Or WEBBROWS.SYSTEM from Contiki? Get one of those working first and we know the Uthernet-II is working. Then we can return to ADTPro.
>
> All the best,
> Bobbi
>
> On Thursday, September 3, 2020 at 12:59:06 p.m. UTC-4, Tempest wrote:
>> So once I run VEDRIVE then what do I do? How do I move and image to the virtual hard drives? I thought the whole point was to make two virtual hard drive and try and use ADTPro to transfer and image to them.
>>
>> This all may be for nought though. I did some other testing. I moved the Uthernet card to another slot and it behaved the same way. I also moved it to my IIe and it still behaved the same way (having trouble with the reads and eventually aborting). So at this point the issue is either my card or my network. I'm not sure how to determine which one is the problem.
It's an Uthernet I BTW. It *does* work with small files (5.25" disks and usually 3.5" disks), but anything large like a hard drive file it will fail. The problem seems to manifest itself after a short time, but small data transfers are ok.
|
|
|
|
| Re: ADTPro Issue [message #399204 is a reply to message #399196] |
Thu, 03 September 2020 15:44 |
|
|
Originally posted by: Bobbi
Ah ... it's an Uthernet-I not an Uthernet-II. That would explain a lot!
The Uthernet-II uses the w5100 chip, which has a built in hardware TCP/IP stack. I am not sure what chips the Uthernet-I uses but it does not have the hardware TCP/IP stack.
The Uthernet-I works with software like IP65, and all of the TCP/IP is done in software on the 6502. This is okay for small transfers (DHCP works great!) but is very slow for larger transfers. With the Uthernet-II you can also use the 6502-based software IP stack, and this is usually done for DHCP and other simple protocols. However when it comes to really pumping data over the connection, most applications switch to the hardware stack for better performance.
When I played around writing some IP65 applications I quickly found I had to use the Uthernet-II's hardware TCP/IP in order to get reasonable data rates. It did seem to me that when using the software TCP/IP stack things started out okay but it got slower and slower and eventually choked.
I don't have any experience with the Uthernet-I, but that may be your problem.
All the best,
Bobbi
On Thursday, September 3, 2020 at 2:26:04 p.m. UTC-4, Tempest wrote:
> On Thursday, September 3, 2020 at 1:09:26 PM UTC-4, Bobbi wrote:
>> Would be good to get the Uthernet-II working with *something* to rule out problems there. How is TELNET65 from IP65 for example? Or WEBBROWS.SYSTEM from Contiki? Get one of those working first and we know the Uthernet-II is working. Then we can return to ADTPro.
>>
>> All the best,
>> Bobbi
>>
>> On Thursday, September 3, 2020 at 12:59:06 p.m. UTC-4, Tempest wrote:
>>> So once I run VEDRIVE then what do I do? How do I move and image to the virtual hard drives? I thought the whole point was to make two virtual hard drive and try and use ADTPro to transfer and image to them.
>>>
>>> This all may be for nought though. I did some other testing. I moved the Uthernet card to another slot and it behaved the same way. I also moved it to my IIe and it still behaved the same way (having trouble with the reads and eventually aborting). So at this point the issue is either my card or my network. I'm not sure how to determine which one is the problem.
> It's an Uthernet I BTW. It *does* work with small files (5.25" disks and usually 3.5" disks), but anything large like a hard drive file it will fail.. The problem seems to manifest itself after a short time, but small data transfers are ok.
|
|
|
|
| Re: ADTPro Issue [message #399244 is a reply to message #399196] |
Fri, 04 September 2020 08:39 |
Jeff Blakeney
Messages: 125
Registered: September 2013
Karma: 0
|
Senior Member |
|
|
On 2020-09-03 2:26 p.m., Tempest wrote:
> It's an Uthernet I BTW. It *does* work with small files (5.25" disks
> and usually 3.5" disks), but anything large like a hard drive file it
> will fail. The problem seems to manifest itself after a short time,
> but small data transfers are ok.
As far as I know (I've never used it) ADT is a ProDOS 8 application and
therefore only works under ProDOS 8. ProDOS 8 has a maximum file size
of 16 MB so if you are trying to transfer a 32 MB hard drive image (or
anything over 16 MB), it won't be able to fit on your local ProDOS 8
partition. That would be why it works for smaller files but not larger
ones.
I've never used VEDrive either but if it can mount a hard drive image on
your modern machine, then you should be able to use copy software on
your Apple II to copy from the VEDrive mounted hard drive to your local
drives.
|
|
|
|
Members
Search
Help
Register
Login
Home
