On 28 f=E9v, 07:41, Andy McFadden  wrote:
> In comp.sys.apple2 Peter Watson  wrote:
>
> > Sadly, if I was a betting man I'd wager they merely took the DOS 3.3 FST=
 and
> > hacked it to make it work with rDOS. It's still a great effort, but a lo=
ng
> > way from writing an FST from scratch. =A0:-(
>
> DOS and RDOS don't have much in common. =A0The Pascal FST is probably clos=
er
> in principle.
>
> What makes it remarkable isn't the access to RDOS -- there's a lot of ways=

> to do that and not much reason to do it -- it's having a working FST that
> Apple didn't write.
>
> --
> Send mail to fad...{at}fadden.com (Andy McFadden) -http://www.fadden.com/
> Fight Internet Spam -http://spam.abuse.net/spam/&http://spamcop.net/

Andy is perfectly right. The main objective was to understand the
unpublished VCR and FCR structures as well as the mostly unknown
behaviour of a FST. The RDOS format in itself is in no way
interesting: simple VTOC, file data in contiguous blocks, etc.

With the disassembly of the other FSTs, I clearly understand why there
were no public docs on the subject: most of the VCR and FCR structures
depend on your needs! The other interesting point is that the SCM of
GS/OS does 90% of the job.

Next steps (in no particular order) are:
- new FSTS: DOS 3.2, RDOS 2.1 which will both require another update
of the Appledisk5.25 driver,
- update the DOS 3.3 FST to handle a new type of file (thank you
Vladimir, $9B50 is my friend ;-)
- write a documentation and create a FST skeleton,
- comment the MSDOS.FST so that somebody could play with it ;-)

Antoine
--- SBBSecho 2.12-Win32