johnmac@fawlty.towers.oz (John MacLean) (07/02/90)
Arrrrggggh!
I guess I just got another 'backup regularly' reminder.
My DOS 3.3 FST I am working on just transferred my PRO.FST into a
$0100 byte per block FST.
Needless to say, ProDOS does not work too well with $0100 byte
blocks, and quite a lot of my hard disk was lost before I realised
what was going on (the Finder kept writing FINDER.DATA files out
and destroying each directory I looked at just after I looked at it).
Nothing that a good few hours with ZAP couln't fix (in the end only
one important file was lost).
Anyway, the current status of my FST, for the interested:
I have got the FST correctly identifying DOS 3.3 volumes,
calculating space available etc. (WOW!!!)
I am working on the identification of files.
More importantly, I have worked out the calling protocols etc, so
it now seems quite likely that I could get the thing fully functional,
given enough time, even without any documentation.
A read only, single file open at a time, limited FST seems very likely.
As I said in a previous post, there are two entry points.
One of these is just a GS/OS call passed on to the FST with the
X register = call number times 2. So for volume calls ($0008) you
get X = $0010.
The most important bit of info to get then becomes the direct page usage.
This info comes from several areas, including the GS/OS reference which
tells you how a driver should be called.
Other stuff, which comes mainly from disassembly includes:
$36 = device number, so this needs to be copied to $00 for the device call.
$32 = address of parms to class 1 call.
I use $80 for my own purposes (should be safe, as PRO.FST uses it).
If anyone out there has any of the Direct Page usage for GS/OS I would
really appreciate some mail.
So to support VOLUME calls, all you need to do is read track $11, sector $00,
check identification, calculate total space and space available, etc,
and copy this info to the parameter space passed.
As a minimum, I think I need to support:
VOLUME, OPEN, READ, CLOSE.
I might also need calls like SET_MARK.
So my next aim is to be able to select the volume from a standard file
dialog and see a list of filenames - I'll post when I succeed.
BTW, I was amazed at the amount of mail I got which had a general theme
of 'This is too difficult' or 'Too much is undocumented'.
This can be done, and if Apple won't do it then one of us had better.
If nothing else, knowing that there are 'bad' FSTs out there might kick
Apple into releasing full-blown ones.
Seeing how the things are implemented, I know I could get a fully
working FST out in the order of a couple of weeks full time (given
some minimal documentation).
You would think Apple could find the resources ....
I am also interested in the AE 3.5" drive. Does anyone have the 1.44 Meg
upgrade or have any knowledge of the driver/software provided?
If they provide a driver, a MS_DOS FST would be just as easy now as well.
When we have MS_DOS, DOS 3.3, ProDOS, HS, MFS, AppleShare, and HFS FSTs,
we will all have a pretty awsome OS.
I bet you could sell GSs just as file transfer machines, running the finder.
I estimate that one person could probably get all of these going in a
couple of months.
I have written file readers for DOS, MFS, and HFS, and know MS_DOS
structures, and there is NO reason for not implementing these FSTs.
John MacLean
--
This net: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999
That net: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072
Snail: Tower Technology, Unit D 31-33 Sirius Rd, Home: +61 2 960 1453
Lane Cove, NSW 2066, Australia.mattd@Apple.COM (Matt Deatherage) (07/04/90)
In article <218@fawlty.towers.oz> johnmac@fawlty.towers.oz (John MacLean) writes: >More importantly, I have worked out the calling protocols etc, so >it now seems quite likely that I could get the thing fully functional, >given enough time, even without any documentation. >A read only, single file open at a time, limited FST seems very likely. > >As I said in a previous post, there are two entry points. >One of these is just a GS/OS call passed on to the FST with the >X register = call number times 2. So for volume calls ($0008) you >get X = $0010. >The most important bit of info to get then becomes the direct page usage. >This info comes from several areas, including the GS/OS reference which >tells you how a driver should be called. >Other stuff, which comes mainly from disassembly includes: >$36 = device number, so this needs to be copied to $00 for the device call. >$32 = address of parms to class 1 call. >I use $80 for my own purposes (should be safe, as PRO.FST uses it). GS/OS direct page is used through FSTs, SCM, and other Apple internal GS/OS components through a series of equates that are used to build the entire OS. We could change one file and do a rebuild of the system and the entire system would continue to work. Your FST, though, would probably eat disks for lunch. Not good. >If anyone out there has any of the Direct Page usage for GS/OS I would >really appreciate some mail. > All this stuff is unguaranteed and dangerous at best. We've just finished internally adding new parameters to some system calls, and all the FSTs had to be revised to take the new parameters accordingly. This is another reason why we keep this stuff in-house. >BTW, I was amazed at the amount of mail I got which had a general theme >of 'This is too difficult' or 'Too much is undocumented'. >This can be done, and if Apple won't do it then one of us had better. "Oh my gosh, the capability has been present for two years and Apple hasn't done it yet. They must not like Apple II people." You know better than this, John. There's a lot more to releasing an FST than throwing some code together and hoping it works in general cases for all users of the OS. This is tricky stuff. >If nothing else, knowing that there are 'bad' FSTs out there might kick >Apple into releasing full-blown ones. Two FSTs for a given file system are worse than none. With two FSTs all of the file-system specific information (including option_list contents, handling of GS/OS abstract file system features that don't fit in a file system, handling of VCRs and FCRs (which the system will use without calling your FST to do it) during block writes, caching capabilities, etc.) is going to be different. This means you can no longer interpret file-system dependencies based on the file_sys_ID field, and this is not acceptable. Some programs would work correctly with one FST and not others; you'd have to reboot to switch programs. This also is not acceptable. >Seeing how the things are implemented, I know I could get a fully >working FST out in the order of a couple of weeks full time (given >some minimal documentation). I'm glad you think so. I wouldn't want to use it on real media. I heard someone tell me once they could write the equivalent of ProDOS 8 in a couple of weeks, also. My comment remains: "Yeah, right." >You would think Apple could find the resources .... Programming resources aren't as tricky as testing resources. If such a critter ever does get released, it has to be perfect the first time or "Apple doesn't care enough about the Apple II to fix the bugs." >If they provide a driver, a MS_DOS FST would be just as easy now as well. >When we have MS_DOS, DOS 3.3, ProDOS, HS, MFS, AppleShare, and HFS FSTs, >we will all have a pretty awsome OS. This assumes the AE 3.5 drive reads MFM-formatted disks, which doesn't seem to be the case. >I bet you could sell GSs just as file transfer machines, running the finder. >I estimate that one person could probably get all of these going in a >couple of months. Nice try, but still wrong. It only seems easy to you because you don't know all the stuff that's going on. I don't mean to sound arrogant, but it's not as easy as disassembly would indicate. >John MacLean -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================