Geoff Winkless wrote... > > 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...
Eeeugh! > (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...) Similar thing happened to me. Moved SP to page C, called rst 10h, WHAM! Fell over quicker than a quick thing. > 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...) Well, yes. But it also provides transparent abstraction from the filing system... > We already have something similar (on a far more primitive scale) in > DOS, with the hook codes provided. But a lot of the hook codes seem to be rather SamDos specific... What I'm saying is that the hook codes (filer) should be non-filing system specific, and then a second layer implements the filing system specific stuff underneath that. Then to read dos disks, all you need is the code to understand dos disks (which already exists in KeDISK...) > 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). That's exactly what happens. Except that the hook codes aren't intercepted, but rather have a more abstract (ie not SamDos specific) layer on top. > Unless you fancy rewriting the entire DOS, of course (And none of us > are thinking of doing _that_, are we Si??? ;-) Give me a C compiler and I'll do it. I'm not too hot on assembly (unless it's ARM assembly...) Rob
