exxos blog - random goings on

[dad664npc]

I don't know how you are getting so many files in the partition.
I have HDDriver v11 and use 512MB partitions - I can not copy your test folders on to it - get "out of space" error after copying 29MB

[dad664npc]

It's probably all to do with timing.

UltraSATAN definitely violates the timing on the ACSI bus, I'm guessing that this new one does as well and happens to work on some machines most of the time.

Without debugging the firmware on the device to see if it's missing some commands (I'm guessing seeks are the most likely as they will cause corruption of the original files and FAT entries if missed) you're going to get absolutely nowhere with this. You'd need a monitor on the bus to see what's being sent and tally it with the firmware debugging to see what's being read.

Knowing the Pi Pico a bit, I wouldn't be surprised if the PIO buffers are being overrun as the ARM core can't keep up with processing the data. I s'pose that overclocking the device may help. This is where I'd investigate first rather than on the ST side.

The Raspberry PI PICO HDC does not use PIO ;)

[exxos]

I don't know how you are getting so many files in the partition.
I have HDDriver v11 and use 512MB partitions - I can not copy your test folders on to it - get "out of space" error after copying 29MB

The file sizes in total are like 59MB IIRC, but "size on disk" is like 220MB. As long as you fill the partition up with the files, that's all that matters.

My new test files are very small for more files..

Not all fits on a 220MB partition but just skip the rest when the drive is full.

fold220.zip

[stephen_usher]

@stephen_usher Timing it may be, but doesn't explain why PP driver works, ICD driver works, TOS162 works, EMUTOS works.

I've plugged in a old spinning metal drive and its about the same speed as the pico driver at first glance.

If the firmware timing is marginal, it would depend greatly upon how quickly and in what order the driver sends the commands.and hence which driver you are using.

It could well be that command processing takes far more ARM core CPU cycles than a data transfer, so if a driver sends multiple commands without a data transfer in the middle then the ARM core can't keep up sometimes and misses a command. This comes from my experience with creating a hard drive simulator for the ACT Apricot machines. You could also be hitting a timing issue with the SD card reader interface on the Pico. This can also cause issues if it's using the same ARM core as that talking to the ACSI. I've not seen the code and hence I don't know.

[dad664npc]

Commands are not being missed and if any were, the ACSI bus timeouts (100ms which is very long) so the ATARI would either retry or flag an error.
The whole ACSI bus transfer sequence is sequential - the ATARI has to wait until it gets an acknowledge from the HDC before issuing another command

[stephen_usher]

In which case the Pico based system is not following the protocol, possibly ACKing directly after the command is received by the PIO but not yet processed by the ARM core. The UltraSATAN also doesn't follow the protocol properly for speed reasons and that fails too.

[dad664npc]

The protocol is followed strictly. And I'll say again - PIO is NOT used. Acknowledge ONLY happens after the command has been actioned

[exxos]

I've dug this drive out. 220MB. Copying files to it currently. It is progressively slowing down :lol: :roll:

IMG_1015.JPG

IMG_1016.JPG

[exxos]

And.... its crashed.

So that's 3 hard drives, 3 motherboards all doing the same.

IMG_1018.JPG

[dad664npc]

The problem I had copying your folders on to sd card was MACOS. I can copy them with a virtual Windows machine.
So am now deleting.... every now and again I am seeing "Can not delete folder <xxxxx>" so hit SKIP, then that is followed with a "Can not delete file A..", then hit SKIP again to continue on its merry way (three occurrences so far with 20000 files to go :shock: )