Bug in FileCore background transfers pre RISC OS 3.5

chat about arc/risc pc gaming & RISC OS software here (NOT the core OS!)Related forum: adventures


Post Reply
sirbod
Posts: 834
Joined: Mon Apr 09, 2012 8:44 am
Location: Essex
Contact:

Bug in FileCore background transfers pre RISC OS 3.5

Post by sirbod » Sun May 13, 2018 9:56 am

I've found what I believe is a previously undocumented bug related to background transfers on RISC OS versions pre 3.50, namely FileCore doesn't appear to terminate background scatter lists correctly. Instead of terminating with a negative address offset and zero pair, the zero appears to be an address within FileCore.

Example of a faulty scatter list as passed by FileCore:

Code: Select all

address=019E6724 size=00014000
address=01814B58 size=00000400
address=00000000 size=00000000
...
address=00000000 size=00000000
address=FFFFFBF0 size=038DB52C
What it should look like:

Code: Select all

address=019E6724 size=00014000
address=01814B58 size=00000400
address=00000000 size=00000000
...
address=00000000 size=00000000
address=FFFFFBF0 size=00000000
Ordinarily this issue doesn't pose a problem, provided the Filing System doesn't attempt to find the start of the scatter list to report an error whilst performing a background transfer. The only workaround is to disable background transfers, which in the case of ADFS can be achieved by *Configure ADFSBuffers 0, for other Filing Systems that support background transfers, possible fixes include setting R5=0 when they issue FileCore_Create or not checking for size=0 when looking for the end of the scatter list.

On the face of it, it's a variant of the ADFSBuffers issue although this isn't corrected by ADFSUtils or ADFS 2.68. Symptoms of the issue include incorrect disk addresses reported when a disk error occurs, or a lock within FileCore when a disk error occurs.

Example of a misreported disk error:
BackgroundTransfer_misreport.png
What it should report:
BackgroundTransfer_correct.png

Phlamethrower
Posts: 44
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: Bug in FileCore background transfers pre RISC OS 3.5

Post by Phlamethrower » Sun May 13, 2018 3:34 pm

sirbod wrote:not checking for size=0 when looking for the end of the scatter list.
That's probably the safest approach. In the PRMs, the diagram showing the scatter list structure does show that the address should be negative and the length should be zero - but then in the text below when they describe how to detect the loop back marker (i.e. the end of the list) they only mention that the address will be negative. So it might be that they never intended the length field to be relevant, and only showed it as being zero to provide an example of how a "well-formed" scatter list should look.

sirbod
Posts: 834
Joined: Mon Apr 09, 2012 8:44 am
Location: Essex
Contact:

Re: Bug in FileCore background transfers pre RISC OS 3.5

Post by sirbod » Sun May 13, 2018 9:56 pm

Its possible it's actually a foreground transfer that's not had the background transfer bit cleared. Foreground scatter lists aren't terminated in the same way background lists are, relying on a 0, 0 pair instead.

After further testing, a possible trigger for the issue is when the complete file being copied will fit in buffers and goes over the foreground read limit. I suppose the next thing to try is loading later FileCore versions and see if the issue is resolved, from memory 2.94 and 3.01 possibly work on RO3.11

Phlamethrower
Posts: 44
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: Bug in FileCore background transfers pre RISC OS 3.5

Post by Phlamethrower » Mon May 14, 2018 12:27 am

I thought foreground transfer lists had no terminator? You have to rely on the transfer length in R4.

Post Reply