ADTPro Issue

[Tempest]

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.

[David Schmidt]

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.

[Tempest]

Yes it is. Also, Enable Nibbles is set to No.

[Tempest]

Any other ideas?

[David Schmidt]

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.

[Tempest]

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.

[David Schmidt]

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.

[Tempest]

Here's the whole file:

atariprotos.com/temp/ADTProTrace.zip

[David Schmidt]

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?

[Tempest]

> 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.

[Tempest]

I was thinking about this again last night, does the Uthernet card have a diagnostic program? Maybe my card is having problems?

[D Finnigan]

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

[D Finnigan]

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/

[Tempest]

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).

[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/veserver.py

All the best,
Bobbi

[Tempest]

I've never heard of VEDRIVE. What is it?

[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.

[Tempest]

So how would I use this? Sorry if I sound dense. :)

[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

[Tempest]

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.

[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

[Tempest]

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?

[Tempest]

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.

[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

[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

[Micah Cowan]

!!!!!!!

...Oh. Well. Maybe that explains part of why it's been a very long time since I've needed one, lol. ^_^

-mjc

[Tempest]

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?

[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

[Tempest]

I tried it and it didn't work.

[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

[Tempest]

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.

[Bobbi]

Try slot 3 or 5 maybe?

[Oliver Schmidt]

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)

[Tempest]

> - 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.

[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

[Tempest]

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.

[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

[Tempest]

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.

[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

[Jeff Blakeney]

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.

[Tempest]

ADTPro works with 32MB hard drive images. I've done it plenty of times before.

This setup worked up until quite recently. I was able to transfer hard drive images (and floppy images) to my IIgs and IIe without issue. This problem is new, so it's probably not an ADTPro issue as ADTPro hasn't changed in a long time.

I'm thinking this might be related to my router. I had to get a new router a few months ago, but I *thought* it was working under the new router. It's hard to remember the last time I had ADTPro working and when I got my new router. I'm using DD-WRT on my router, so maybe there's a setting that ADTPro doesn't like? I searched through my router logs and saw this error two of the three times the transfer failed. Not sure if it's related though (Atari-Router in my router's name BTW):

>> Sep 4 09:08:26 Atari-Router daemon.err httpd[1265]: httpd : Request Error Code 408: No request appeared within a reasonable time period


If it's not the router, my only other guess is that something went bad with the Uthernet I card. I find this hard to believe though because it still works on smaller files. You'd think that if something was wrong with the card then nothing would work.

[David Schmidt]

On 9/4/20 8:39 AM, Jeff Blakeney wrote:
> 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.

ADTPro doesn't transfer individual files, it transfers disk images in a
series of chunks. A 32MB drive is chunked up and sent a piece at a
time, reconstituted on either end of the wire, depending on which way
it's going. So file size isn't at issue here; it's networking.

[Tempest]

>>So file size isn't at issue here; it's networking.

Yes, at this point I'm 99% sure it's a network issue. However I have no idea where to start looking for issues or ever what could be causing them. Something with my DD-WRT settings on my router obviously, but what? Perhaps if we can narrow down the potential possible causes I can figure it out? DD-WRT has a lot of customizable settings. Too many honestly, much of it is above my head.

[Bobbi]

Can you borrow a router? Would be interesting to swap it and see what happens.

Bobbi

[Tempest]

I wish. Honestly that would be the easiest way to test this, but no I don't.

[Tempest]

Turns out I do have an old router (a DIR 655) that I was able to try out. I get the same issue. This router is stock with no custom firmware and I do remember it working with ADTPro back when I used it. At this point it's either got to be the card or possibly my modem. Those are the only two things left to check, I've changed out everything else!

[Delfs]

On Monday, September 7, 2020 at 12:25:31 PM UTC-5, Tempest wrote:
> Turns out I do have an old router (a DIR 655) that I was able to try out. I get the same issue. This router is stock with no custom firmware and I do remember it working with ADTPro back when I used it. At this point it's either got to be the card or possibly my modem. Those are the only two things left to check, I've changed out everything else!

Have you considered you ADT maybe bad? Maybe start with a fresh copy of that. -Ed

[Bobbi]

Firewall settings is something else to check.

Bobbi

[Tempest]

Re-downloading ADTPro was the first thing I did. Same issue.

I can look into the firewall possibility, but if it was the firewall you'd think that absolutely nothing would work. Firewalls are generally all or nothing. Also I don't think that other router I tried had a firewall enabled. Still, something to look into.

At this point I'm thinking that my Uthernet card might be damaged somehow. Is there anything on the card that could get damaged but still allow it to function partially? Like I said, it works for short transfers still.

[Tempest]

While ordering an Uthernet II card I noticed the manual had a quick test you could run. I'm not sure if this is specific to the Uthernet II or if it will work with the original card so I tried it and got this result:

*C094: 80
*C094: 03
*C094

00/C094- 09

According to the manual I should get a 03 not and 09 back. Like I said, I don't know if this test is valid for the original Uthernet or not, but I thought I'd post the results here in case they're useful.

[Bobbi]

I am not sure what that test does exactly -- writes to C094 twice then reads back ... Pretty sure it would be specific to Uthernet-II though.

Aside from the fact that both Uthernet and Uthernet-II are Apple ][ cards and have an Ethernet connector they are quite different in terms of implementation. Don't be fooled by the similarity of the names.

All the best,
Bobbi

[Delfs]

Did you try using a hub instead of a switch? Did you try a cross over cable to hook the source machine to your Apple?

[Tempest]

> Did you try using a hub instead of a switch? Did you try a cross over cable to hook the source machine to your Apple?

No, but I did hook it directly to my router, bypassing the switch entirely. I don't think I have a crossover cable here at home, I'll have to borrow one from the office next time I'm in.

[Tempest]

On Thursday, September 10, 2020 at 2:12:26 PM UTC-4, Bobbi wrote:
> I am not sure what that test does exactly -- writes to C094 twice then reads back ... Pretty sure it would be specific to Uthernet-II though.

Is there a list of all the differences between the two? I'm curious now. I assumed that the II was just an upgraded version of the original.

[David Schmidt]

The list is: everything. It's a new chipset, a new programming
interface, and everything in between. The only thing they share is the
name.

[Tempest]

> The list is: everything. It's a new chipset, a new programming
> interface, and everything in between. The only thing they share is the
> name.

Ah ok, I guess it's time to upgrade. :) At this point I'm pretty sure my Uthernet card is just broken somehow, it's the only thing that makes any sense. Maybe some stray voltage or something zapped it? Who knows.

I gave it one last test after updating my router's firmware. It still fails after a bit with the ACK errors but it doesn't do that weird 'halting/chugging' thing it used to do. What I mean by that is that the transfer bar would halt for a second then resume but it would keep doing that and eventually fail. Now it keeps going at the smooth fast speed you'd expect, but then it randomly fails and aborts. I really thought it was working all the sudden, but alas.

>>9/11/20 11:28:31 AM CommsThread.sendPacketWide() Ack received for block 12515, but we were expecting an ack for block 12513.

[Tempest]

I got my Uthernet II today and it works perfectly. So the problem is with my Uthernet I card itself. I've inspected the card and everything *looks* ok, but I'm not sure how to diagnose it further. There don't seem to be many components on the board itself, is there any one in particular that I should inspect/replace that might cause a problem like this?