SDX PCLink Recursive Copy to Atari

[MrFSL]

I tried searching the forum and did not find an answer which makes me believe I must be doing something wrong.

 

I use the PCLink driver to copy the SDFS formatted partitions to my PC. This works great with something like:

 

COPY /R D3:\ PCL1:\

or

CD PCL1:
COPY /R D3:\

The problem I have is going the other way around. It always fails when it gets to the first directory.

 

COPY /R PCL1:\ D3:\

 

Does anyone else see this same problem? Can anyone else recommend an easy way to copy the contents of several SDFS formatted disks to and from the PC?

 

I'm currently stuck creating a SDFS formatted ATR on the PC and then mounting it and copying the data to it.

[_The Doctor__]

What version of SDX are you using... I vaguely remember a couple of issues during BBS backup that Kyle22 also had, there were I think... 2 causes to the problem and were fixed, also what version of RespeQT?

It may matter... as we grasp into the ether..

[MrFSL]

27 minutes ago, _The Doctor__ said:

What version of SDX are you using

4.48 or 4.49

 

27 minutes ago, _The Doctor__ said:

RespeQT

r5.3 --- but also sio2bsd-2020-12-20

 

[GoodByteXL]

Given you are using real hardware, there are a few things to keep in mind ...

 

If there is a hardware cache inside your machine, it might not work with the PCL driver. Disable it (like I recommended that in the manual for the FIFO).

SIO high speed might be too high (here I cannot use the PCL driver at higher settings than PD 4 with PCL). Starting with PD 3 and lower creates that experience you described then. Of course this is related to my hardware. It might be different over there.

If possible, please use the latest version of SDX -> 4.49g and the corresponding tool kit.

 

Used RespeQt 5.3 (test-wise, standard version is 4.0 here) under Linux to recursively do copies to and from a PCL drive; works fine here. I do my backups also that way.

 

To speed the process up a little bit you could use COPY /RS switching off ANTIC.

[flashjazzcat]

Issue is reproducible here (under Windows/RespeQt) with SDX 4.49g and the latest toolkit. IO working perfectly well when copying from PCL: to the Atari until it hits a directory and produces a 'Path not found' error. This is with an SIO2SD which works perfectly reliably at divisor 0 in all circumstances, and bumping it down to standard speed makes no difference here.

 

I tried the same operation in Altirra using the same SDX version and same PCLINK.SYS version and it fails there too, but this time silently, simply giving up after creating a directory on the target volume and emitting no error message at all.

[flashjazzcat]

Right: since this did not seem hardware related, I started to wonder if this was a PEBCAK problem, and it was. Recursive copies don't like trailing path delimiters (which would be perfectly acceptable in a non-recursive copy operation, but never mind). This doesn't work (when directory 'TEST' exists on PCL2: and it contains other files/directories):

COPY /R PCL2:TEST> C:>

But this does:

COPY /R PCL2:TEST C:

 

[GoodByteXL]

1 hour ago, flashjazzcat said:

Right: since this did not seem hardware related, I started to wonder if this was a PEBCAK problem, and it was. Recursive copies don't like trailing path delimiters (which would be perfectly acceptable in a non-recursive copy operation, but never mind). This doesn't work (when directory 'TEST' exists on PCL2: and it contains other files/directories):

COPY /R PCL2:TEST> C:>

But this does:

COPY /R PCL2:TEST C:

 

Good catch. Indeed do not use those trailing path delimiters in my batches. Will for the time being put a note in the manual with the PCL driver.

[flashjazzcat]

In circumstances like these (where it's unclear what was wrong with the path), it might be useful for the COPY command to actually display the problematic path on the screen along with the error message. The issue would then have been easy to spot (I'm assuming it ended up with two consecutive delimiters in the path).

[+bf2k+]

So this is only when using PCLINK... correct?  Because I use the delimiters all the time in my normal recursive copy operations

 

like:  COPY /R A: C:STUFF>

 

 

[MrFSL]

7 hours ago, flashjazzcat said:

I started to wonder if this was a PEBCAK problem, and it was.

.... not so sure about this. We could discuss the meaning of trailing delineation and how it is handled in other systems all day --- but in the end I think the Atari should be held to it's own standards. Copying from the Atari to PCLINK destination works, the return journey does not. If it failed both ways I could understand. No, this smells like a bug.

 

7 hours ago, flashjazzcat said:

which would be perfectly acceptable in a non-recursive copy operation, but never mind

more evidence as I mention above. There should be a consistency in operations.--- In other OSs I expect during a copy operation ending in a delineator it to copy the contents of that directory. If I remove the delineator I expect it to copy the directory.

 

5 hours ago, flashjazzcat said:

it might be useful for the COPY command to actually display the problematic path on the screen along with the error message

This could be helpful. On sio2bsd you do get output that looks like this:

FFIRST (fno $0a): mode: $14, atr1: $20, atr2: $a8, path: '>', name: '???????????'

But when everything is working you still get output that look like this:

FFIRST (fno $0a): mode: $14, atr1: $00, atr2: $08, path: 'SYS>APT>', name: '???????????'

The later makes the former non-obvious.

 

-----------------------------------------------------------------

In the end:

D3:
CD DEST
COPY /R PCL1:

works as expected placing the recursive contents of PCL1: in the directory D3:\DEST

 

Thanks @flashjazzcat for taking the time to test on your systems. I'm still rocking the atari800 emulator so I am not as high-speed as the rest of ya'll with your virtual hardware.

 

Thanks also @GoodByteXL. Anytime I am working with the the PCLINK driver I always manually set my speed using SIOSET 15 US 0. I have found that this increases my reliability at divisor 0. Without setting it manually I get worse results. (Or its my imagination) When copying large amounts of data it sometimes fails at 0 but it works well at 1 on my 800XL. Though I can't explain why using the SYSCHECK II card as a memory expansion has allowed me to get these speeds without lifting caps (an this is not my imagination.) I get similar results with the Antonia memory expansion (tested across 3 different 800XLs.)

[_The Doctor__]

both issues were covered (nice).       In pclink recursive copy direct path > and delimiter \ should not be used in a recursive copy. PCLINK is walking in both the Atari World and the PC world of differing DOS(Filesystem) flavors.  The other issue of hardware cache off SIO speed pd (divisor) may need adjustment depending on PC hardware and cable that is used.

The versions listed should be ok as the other bugs were squashed.

Remember that there is a difference between the developer branch and the master branch currently... same revision works fine from one and not the other in regard to enhanced drive support. Reading the notes explains that and I really wish this could be cleaned up.

Edited May 11, 2022 by _The Doctor__

[GoodByteXL]

11 hours ago, MrFSL said:

Though I can't explain why using the SYSCHECK II card as a memory expansion has allowed me to get these speeds without lifting caps (an this is not my imagination.)

 

off topic

 

This is something I tried to confirm for all the decades since the 80's. And the result to me: it is nonsense to blame the capacitors, as long as they are fine.

I never (!!!) had and have the need to extract the SIO caps in more than 40 machines over the decades to get reliable SIO highspeed. And I had a lot of discussions about it over the decades. To my experience a clean SIO signal has absolutely no problem to function as Atari produced it.

 

To proof this I repaired an old 800 XL mainboard, Rev C, last winter and tested it. NO issues! Next I extracted ALL CAPS C71 to C78. No difference. A friend of mine checked that using a logic analyzer and told me that there is a very small cleanup effect by doing this, but nothing spectacular. This is why PD 0 is no issue on the side of the Atari machine itself. The signal might get disturbed by other devices and then deteriorates - in this case it might help.

 

The only instance I know is concerning the XE machines. The original Atari schematics for the 130 XE floating around do show an important error.

 

C71-78 are doubled in those drawings: 1 set guided directly to the POKEY, another set close to the SIO port. I saw XE mainboards carrying both cap sets. These machines might have problems to get higher speeds than PD 4. The caps close to the SIO port are superfluous, if the ones around POKEY are on the board.

 

Of course there are so many other issues having an effect on the SIO lines, that every user might get a different experience and coincidentally does something that heals the problem. Then with the next re-arrangement of the setting the game might start over again.

Edited May 11, 2022 by GoodByteXL
typoo

[MrFSL]

5 hours ago, GoodByteXL said:

C71-78 are doubled in those drawings: 1 set guided directly to the POKEY, another set close to the SIO port. I saw XE mainboards carrying both cap sets. These machines might have problems to get higher speeds than PD 4.

This exact scenario was reported to me by a friend not long ago... 2 sets of caps on their 130XE. Thanks again for the assistance.

[phaeron]

It's very suspicious that the copy fails in the same way in Altirra as it does with SIO2BSD, as they are independent implementations of the PCLink protocol.

 

I put a trace on the system calls made by the COPY /R command in the emulator and it looks like this may actually be a bug in that command:

FFIRST('PCL:BLAH>*.*.')
PCLINK: Received ffirst() command: [BLAH>]
PCLINK: Sending status: Flags=$00, Error=  1, Length=0000
PCLINK: Sending status: Flags=$00, Error=  1, Length=0000
PCLINK: Received fnext($01) command.
PCLINK: Read at pos 23/115, len 23, actual 23
PCLINK: Received ftell($01) command.
PCLINK: Sending status: Flags=$00, Error=  1, Length=0000
PCLINK: Received close($01) command.
FFIRST('PCL:BLA>FOOBAR>*.*.')
PCLINK: Received ffirst() command: [BLA>FOOBAR>]
PCLINK: Sending status: Flags=$00, Error=  1, Length=0000
PCLINK: Sending status: Flags=$00, Error=  1, Length=0000
PCLINK: Received fnext($01) command.
PCLINK: Read at pos 23/23, len 23, actual 0
PCLINK: Received close($01) command.
FFIRST('PCL:BLA>*.*.')

The problem, as far as I can tell, is that the recursive code in COPY only handles drive prefixes that are one or two characters long, because it only has one branch to check for a single-char drive prefix and patch up a two-char drive prefix:

 

    21CD: 20 7D AC  L21CD   JSR $AC7D
    21D0: 20 20 A0          JSR $A020
    21D3: 30 6B             BMI $2240
    21D5: 18                CLC
    21D6: AD 61 07          LDA $0761
    21D9: 45 8A             EOR $8A
    21DB: D0 01             BNE $21DE
    21DD: 38                SEC
    21DE: 66 86     L21DE   ROR $86
    21E0: A2 FF             LDX #$FF
    21E2: E8        L21E2   INX
    21E3: BD 17 27          LDA $2717,X
    21E6: C9 3A             CMP #$3A
    21E8: F0 0A             BEQ $21F4
    21EA: C9 9B             CMP #$9B
    21EC: D0 F4             BNE $21E2
    21EE: A9 3A             LDA #$3A
    21F0: A2 00             LDX #$00
    21F2: F0 05             BEQ $21F9
    21F4: A2 00     L21F4   LDX #$00
    21F6: BD 17 27  L21F6   LDA $2717,X
    21F9: 9D 98 27          STA $2798,X
    21FC: E8                INX
    21FD: C9 3A             CMP #$3A
    21FF: D0 F5             BNE $21F6
    2201: A0 00             LDY #$00
    2203: B9 A0 07  L2203   LDA $07A0,Y
    2206: 9D 98 27          STA $2798,X
    2209: F0 06             BEQ $2211
    220B: E8                INX
    220C: C8                INY
    220D: C0 3E             CPY #$3E
    220F: 90 F2             BCC $2203
    2211: C0 00     L2211   CPY #$00
    2213: F0 15             BEQ $222A
    2215: B9 99 27          LDA $2799,Y
    2218: C9 3E             CMP #$3E
    221A: F0 0E             BEQ $222A
    221C: C9 5C             CMP #$5C
    221E: F0 0A             BEQ $222A
    2220: A9 3E             LDA #$3E
    2222: 99 9A 27          STA $279A,Y       ;<-- the problem
    2225: A9 00             LDA #$00
    2227: 99 9B 27          STA $279B,Y
    222A: A0 0B     L222A   LDY #$0B
    222C: B9 61 07  L222C   LDA $0761,Y
    222F: 99 BB 26          STA $26BB,Y
    2232: 99 B0 26          STA $26B0,Y
    2235: 88                DEY
    2236: D0 F4             BNE $222C
    2238: 10 06             BPL $2240
    223A: A2 FF     L223A   LDX #$FF
    223C: 60                RTS

 

The result is that when copying from PCL: it drops one character off the path, and with PCL1: it drops two.

 

[flashjazzcat]

Expertly figured out. I'll bet that one dates back to the ICD days.

[+bf2k+]

1 hour ago, flashjazzcat said:

Expertly figured out. I'll bet that one dates back to the ICD days.

Hmm... I can find no mention of PCLINK in my original ICD SDX manual.

[MrFSL]

1 hour ago, bf2k+ said:

Hmm... I can find no mention of PCLINK in my original ICD SDX manual.

No, I think what is being referred to is not PCLINK directly --- but to the copy command which definitely has been around for a bit.

 

So the website says to report bugs to the appropriate thread here and has a link so I guess I will drop a reference to this there.

 

Thanks everyone!

 

[flashjazzcat]

4 hours ago, bf2k+ said:

I can find no mention of PCLINK in my original ICD SDX manual.

As MrFSL says, the bug appears to be in the COPY command, and the fact PCLink is a recent invention (and one would rarely refer to standard disk drives by their DSK: ID) only makes this more likely.