Date   : Sun, 11 Sep 2011 15:27:26 +0200
From   : conca@... (Carlo)
Subject: Sometimes they come back... OSWORD &7F question

On 09/09/2011 21.43, J.G.Harston wrote:

> Checking through the ROM code it turns out that commands&E0 and
> &F0 are only checked for if the control block specifies exactly 10
> parameters. What the other nine parameters are I can't tell, but
> updating the library code to this works:
>
>    DEFFNdisk(addr%,cmd%,drv%,trk%,sec%,num%,den%):LOCALfs%
>    fs%=FNfs:IFfs%<>4:*FX143,18,4
>    REPEATX%?0=drv%+den%*24+8:X%!1=addr%:X%?5=3-7*(cmd%>127)
>    X%?6=cmd%:X%?7=trk%:X%?8=sec%:X%?9=num%OR&20
>    A%=127:CALL&FFF1:A%=X%?10:UNTILA%<>&10:IFfs%<>4:OSCLI"FX143,18,"+STR$ fs%
>    =A%

Thanks! I had tried disassembling the ROM code but got stuck. The modified
library works indeed. I tried it with DFS 2.24+, DFS 2.29+ and 2.45+, all
of them patched to correct the OSBYTE &7F bug.
In particular, it works perfectly with DFS 2.24+, while 2.29+ and 2.45+ 
seem to return incorrectly from the OSWORD CALL; the behaviour is erratic,
sometimes it hangs, other times it returns with incomprehensible error messages,
and most often with something like this:

   at line 80
>

Nevertheless the track is always read correctly and track data is copied
to the memory buffer. Maybe the later DFS versions mess with the stack?

One final note about the library code: OSBYTE &7F puts the result in the
first byte after the input data, so that this code:

A%=X%?10

works only with the three-byte commands (sector read, write). I'd suggest
that it be changed like this:

A%=X%?(X%?5+7)

-- Carlo.