Copying large files with RISC OS 3.70

[Trapper]

Just thought I'd make a quick post in case anyone else goes through this hell!

I've wanted to keep RISC OS 3.70 in ROM on my StrongARM RISC PC to give me much more flexibility with games. It's also partially because of the nostalgia factor with the 3.xx versions of the OS.

I couldn't get a CF/SD solution working reliably using ADFS and onboard IDE so I bought a brand new 40GB PATA HDD on eBay. I used !HForm v2.56 to format it and it seemed fine.

I then had major problems getting my NIC working. It turns out the original !Boot that came with 3.70 had some major bugs even when softloading v4 of the TCP/IP suite. I used this !Boot as I had the original StrongARM upgrade floppy discs to hand.

I downloaded the Uni!Boot via 3QD and used a Zip 100 drive to copy it over.

After changing over my NIC worked. That's when I found I'd get a disc error 20 or bad freespace map when copying files over 1MB in size. This was from any source (ShareFS, LanMan, ZipFS, CDFS, RAMFS etc.) to ADFS. If I copied from CDFS to RAMFS or ShareFS to ZipFS it worked fine.

I assumed with a HDD partitioned at 37GB on 3.70 this was the cause. So I backed everything up onto an external HDD via network and my Pi and used !HForm to shrink the partition down to 25GB.

This didn't solve the problem! I made sure ADFSBuffers were set to zero - no joy. I made sure that RISC OS 3.70 ROM Patch 3 was installed - no joy.

I was about to plop my RISC OS 4.02 ROMs back into the machine and call it a bad job, but just before calling quits I paid 3QD the £12 to download the easy RISC OS 4.02 softload. I now had the problem that the .ROM was 4MB in size and I couldn't copy it to my HDD.

This is when I found a weird hack that worked.

The file in question HAS to be zipped, and has to be on a remote filing system. In this case the 4.02 ROM was in a zip file located on my RaspPi SDFS drive. I used !OmniClient to access it via ShareFS.

Using SparkPlug or Spark/SparkFS will not work. It will crash out. However if you use !ZipEE on the RISC PC (not on the Pi, as it crashes) to open the zip file via ShareFS you can extract it directly to your local ADFS HDD. No errors.

I have no idea why this works. I assume !ZipEE doesn't use ADFS to run the file operation. But it works.

Now I can softload into 4.02 where the bloody problem of copying large files persists about 20% of the time! Better than 100% of the time.

However it means that I can choose between 3.70 or 4.02 to run my games and more importantly I've shown my dominance over this balky hardware!!

[sirbod]

It sounds like the PATA is having compatibility issues, possibly the same that most SD/CF have. Ironically, I was having the exact same issue (error 20) on an Iyonix with the latest 5.23 ROM over the weekend, which doesn't occur on 5.22 so the issue is definitely software related. Off the top of my head, disc error 20 is a command data mismatch error so the driver is receiving an unexpected response from the HD.

The problem you have is that any write is potentially going to corrupt the free space map, requiring DiskKnight to get you back to a working system. As much as it pains me to say it, you should probably consider purchasing a known working SD/CF solution from a RISCOS supplier.

[Trapper]

I tried using the CF system which worked perfectly in my A3010 with a 40 pin to 44 pin IDE adaptor.

It worked fine for a while, but in the end I think too much power was going through the interface and it effectively burnt out the CF cards!

Interesting knowing what is causing the errors now. This HDD was manufactured circa 2003, so it's probably a bit too new for RISC OS 4.02. I wonder if a 4.39 or 6.20 softload would fix the problem?

For the time being I've got a complete copy of the HDD contents on my Pi and on rpc_Emu so if the drive does fail nothing will be lost, and I've been using DiscKnight for years so I can fix any problems!

[sirbod]

I wonder if a 4.39 or 6.20 softload would fix the problem?

If you find one that does work, in theory you can save the relevant Modules and load them early on in the boot sequence to fix RO3.7. I do that to add long filename support to RO3.71, which I detailed and posted in one of your other threads.

[Trapper]

I've found a 32-bit version of !OmniClient lying around in a zip file.

I copied a 200MB DOS drivefile from ShareFS to ADFS on 4.02 with no problems at all.

[sirbod]

I've found a 32-bit version of !OmniClient lying around in a zip file.

I copied a 200MB DOS drivefile from ShareFS to ADFS on 4.02 with no problems at all.

I'm not sure copying from ShareFS will generate DMA transfers large enough to trigger error 20. Copying it from one directory to another might though, you'll need to find a repeatable method to reproduce error 20 reliably!

[sirbod]

I wonder if disabling background transfers might resolve this issue? Looking at the ROOL sources, ADFS 3.40 was the first version to support all DMA modes. As far as I can tell, pre 3.40 it only supports PIO which may be where the compatibility issue is.

In theory setting ADFSbuffer to 0 should disable DMA, but I believe it really needs bit 8 cleared on all FileCore DiscOP 1's and R5=0 when ADFS calls FileCore_Create.

[Trapper]

Hmm even softloading later ADFS and FileCore produces an error. Either Error 20, total lockup or data lost.

The drive does verify OK and DiscKnight reports no problems. I am starting to wonder whether it's worth stick 4.02 back in ROM and softloading 4.39 and be done with it. Then I can reformat and get long files names.

Between ADFFS, Aemulor and StrongGuard I can play most games.

[sirbod]

softloading later ADFS and FileCore produces an error. Either Error 20, total lockup or data lost

Which versions of ADFS did you test? Just in case someone whats to have a play with more recent versions.

[sirbod]

I can confirm it's not fixed in later ADFS versions as I've been plagued with the error on my Iyonix today, which is running the nightly build of 5.23 with a 4GB CF on an IDE->CF adapter.

Retrying the write appeared to work in every instance, so I wondered if its a command timeout issue. With that in mind, I took a quick look in the ADFS source and noticed its a DRQ timeout that's generating "disc error 20".

Increasing the DRQ timeout may have resolved the problem on my Iyonix as I've not seen an error since, that said I've not exhaustively tested it and have no idea what the knock on effect of increasing the timeout is. If you want to try this hack on your RiscPC (or Archimedes even), run the code below and then run the patched ADFS Module that it saves.

Code: Select all

REM Increase DRQ timeout in ADFS

DIM temp% 8
P%=temp%
[OPT 2
MOV R1,#700
MOV R1,#65536
]
C%=!temp%
D%=temp%!4

SYS "OS_Module",18,"ADFS" TO ,,,A%
S%=!(A%-4)

DIM adfs% S%
FOR L%=0 TO S% STEP 4
  Z%=A%!L%
  IF Z%=C% THEN
    adfs%!L%=D%
    PRINT "DRQ timeout increased ("+STR$~L%+")"
  ELSE
    adfs%!L%=Z%
  ENDIF
NEXT

OSCLI "SAVE $.ADFS "+STR$~adfs%+"+"+STR$~S%
*SetType $.ADFS Module

[Trapper]

ADFS 3.33 and FileCore 3.22 that you provided with your little !Boot for multi-OS.

I ended up running PowerIDE and formatting the damn drive. It was doing my head in. So I can partition it with a small !Boot with short filenames and then the much large partition with long filenames.

[sirbod]

I've tried the above patch on a RiscPC with 2GB and 4GB CF cards, in both cases no errors are seen when running the patched ADFS. With the unpatched ADFS, near enough every copy generates an error or corrupts the free map, with the patched version I've successfully copied several gigabyte of data to them.

I may just be lucky in that the CF's I have just needed a slightly longer timeout to work correctly, so if anyone has a CF adapter/CF (or even an SD) that they know doesn't work, it might be worth testing.

[Trapper]

I've found with PowerIDE that large file copies to EADFS::4 work absolutely fine, and very fast. Copy the same data to ADFS::4 and "Disc Error 20".

I'll try the patched ADFS now, as v 3.33 still errors and also messes about with EADFS.

To partition a HDD on the internal RISC PC IDE interface I need to keep using PowerIDE/EADFS? Or can I create the two partitions using !PowerMgr and then not load EADFS at next boot. Will ADFS recognise the two partitions as two different drives (:4 and :5)?

I have two HDD :4s loaded one with EADFS and the other with ADFS. If I set

Code: Select all

*configure IDEDiscs 0

will EADFS at boot still find the drive?

[Trapper]

Jon you sir are an absolute genius. The patched ADFS has stopped all the disc errors.

Damn, probably shouldn't have purchased PowerIDE now! Oh well....

[sirbod]

To partition a HDD on the internal RISC PC IDE interface I need to keep using PowerIDE/EADFS? Or can I create the two partitions using !PowerMgr and then not load EADFS at next boot. Will ADFS recognise the two partitions as two different drives (:4 and :5)?

I have two HDD :4s loaded one with EADFS and the other with ADFS. If I set

Code: Select all

*configure IDEDiscs 0

will EADFS at boot still find the drive?

I'm not familiar with !PowerMgr, but would guess you still need to load it to see the other partition as ADFS doesn't understand partitions. I'd leave it as you've configured it and just load the patched ADFS early in the boot sequence.

The patched ADFS has stopped all the disc errors.

Excellent, in that case I'll knock up a Utility to patch ADFS that can go into the boot sequence.

[Trapper]

I've just stuck mine in Boot:Utils and call it in BootRun under VProtect. Works fine there. Still need to set ADFSBuffers to zero with 3.70

I've given up with PowerIDE, it's just not design to do what I want it to. I can partition two drives with the old RISC OS map, but as soon as I load ADFS 3.33 I get weird errors trying to format the large partition with the new large filenames+ map, or if I keep it on the old map I get internal errors on boot.

It look like unless you have two physical HDD's and format them both with !HForm this is a non-starter unless an IDEFS card would work better.

[Trapper]

Found a minor niggle with ADFS v3.29 on RISC OS 3.71 - formatting a 1.6MB floppy works, but it pauses several times at the beginning before continuing on.

[rharper]

To partition a HDD on the internal RISC PC IDE interface I need to keep using PowerIDE/EADFS? Or can I create the two partitions using !PowerMgr and then not load EADFS at next boot. Will ADFS recognise the two partitions as two different drives (:4 and :5)?

I have two HDD :4s loaded one with EADFS and the other with ADFS. If I set

Code: Select all

*configure IDEDiscs 0

will EADFS at boot still find the drive?

I'm not familiar with !PowerMgr, but would guess you still need to load it to see the other partition as ADFS doesn't understand partitions. I'd leave it as you've configured it and just load the patched ADFS early in the boot sequence.

The patched ADFS has stopped all the disc errors.

Excellent, in that case I'll knock up a Utility to patch ADFS that can go into the boot sequence.

Is this utility available?
Thanks,
Ray

[sirbod]

[Is this utility available?

You don't need a Utility, just run the BASIC live-patcher in !Boot or use it to create a pre-patched ADFS by removing the END to save it to RAM: