> True, depends if we hard-code the file-system using assembler and re-assemble > drive parameter changes but addressing 32bit pointers using layered access to > the file-system... can cause it to only ever manage one sector access per > rotation rather than however many the interleve factor allows.. > After all the z80 is an 8/16bit chip 32bit operations can be done but require > a lot of organisation to be both bugless AND fast IMHO whilst 16bit ops can > be > done quite easily and rapidly using right but non-standard methods:-)
I'm still not sure... How about zoning to 16 bits? That way it will *appear* to have 16-bit partitions... I've got to sit down and work out how the MultiROM's BIOS is going to handle this... We've got a drive up and running atm (just connecting it to the SAM's bus), so we'll know more on Saturday. I think, if you use the BIOS to handle stuff it'll be nicer, but as long as accesses follow a few basic ground rules (no treading on other people's partitions, use the MultiROM's RAM to check the config or work it out from the configuration partition (sector 1 of the disk, after the partition table in sector 2)), then it should all be okay. > Cs> Okay, agreed -- I won't use 510 byte sectors, 512 it is. > > Great! that'll improve the random access calculating:-) Heheheh > Cs> Now the question is: In our FAT do we > Cs> want a way of searching <back> > Cs> along the chain as well as forwards? > > Hmm, that's a tricky one! On ProDos due to extensive cache'n ALL > random-access > positioning is calculated from scratch each time its required... > If Cache'n of the FAT and directory is going to be done, then random > positioning on a file can be done in a similar fashion othrwise, PASS! I'm planning to allow large caches -- probably not on floppies until the invisible upgrade occurs, which should allow us to autosense the drive change and basically treat the floppy drives like IDE! > I've not gone into NON-cpm low-level stuff so I don't know how it *can* be > done:-( > > Or is the searching <back> along a chain to do with deleted file recovery? > If so then I guess some form of recovery procedure should be considered, (I > hadn't even thought of looking into UZI to see if that offers anything in > that > department, whoops <G>) It's to do with both -- for quick backwards random access and for file recovery. Out of interest, does *anyone* have any idea how MSDOS undeletes files? I can't see how it's able to do it, unless the second FAT is only updated on a new-file-write... Si Cooke
