On Oct 10, 12:36pm in "Not very controversial, but the best I can do...", you warbled: ] I've _NO_ idea how easy this would be to do on the SAM, but it would ] make things like the KEDISK transferer a thing of the past. Then ] support for hard disks etc. is simply a matter of upgrading the ] FileCore to support HD's as well.
Well... making KEdisk work via filecore (ie using Hook codes, for people in the know of how dos works) slows it down by about 50%. Not worth it, in my humble opinion... (Of course the real reason KEDisk had its own code was because I couldn't work out why the Hook Codes just weren't working -- of course it was because I was putting the bloody code in page D, which then got paged out by DOS... or something along those lines...) ] I can do more `research' on how Acorn do it if people think this is a ] good idea (courtesy of the #99 manuals... :) Hmm. I don't think the Acorn way of doing things would really help much. As you say, it basically provides a level of abstraction from the hardware, thus of keeping the software compatible with just about anything (ie one sector editor works for DOS, Mac, RAM, Archives etc...) We already have something similar (on a far more primitive scale) in DOS, with the hook codes provided. The only thing that would need to be added would be a bit to intercept the hook codes before DOS gets them, something to work out which file system is actually relavent to the drive you're working with, and then pass the hook codes to that file system (which would then have to call DOS hook codes with a special bit set somewhere, perhaps, not sure). Unless you fancy rewriting the entire DOS, of course (And none of us are thinking of doing _that_, are we Si??? ;-) Geoff --
