On <03 Nov 94 10:42> [EMAIL PROTECTED] wrote: >> 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:-)
Cs> I'm still not sure... How about zoning Cs> to 16 bits? That way it will Cs> *appear* to have 16-bit partitions... Not sure about the terminology, so I daren't comment;-) 24bit maths using A and HL can be pretty simple and Fast would that be an acceptable compromise ie pretend were using 32bit pointers but really only use the 24bits that should allow more blocks than the current HD's allow:-) ADC, SBC and the various rotates and shift via carry flag can link them quite well without all the hassle of usin the alternate regs or too many other regs. Cs> I've got to sit down and work out how Cs> the MultiROM's BIOS is going to Cs> handle this... We've got a drive up Cs> and running atm (just connecting Cs> it to the SAM's bus), so we'll know Cs> more on Saturday. I think, if you Cs> use the BIOS to handle stuff it'll be Hmm. regarding CP/M+ sector access to be simple and not concered about stacks and sam<->cp/m+ page number translations I'd prefer to keep my own low-level sector routines in its designed place within the common portion of the bios, at least for now anyway. Also becuase although I'll want to be compatable with your system, for some time I'll not have one to use the bios in it;-) Cs> nicer, but as long as accesses Cs> follow a few basic ground rules (no Cs> treading on other people's Cs> partitions, use the MultiROM's RAM to Cs> check the config or work it out Cs> from the configuration partition Cs> (sector 1 of the disk, after the Cs> partition table in sector 2)), then it should all be okay. >From my cp/m+ bios point of view<grin> as long as the partition table is in a fixed location on the drive that'll be constant regardless of drive geometry or translated translation in progress ie the first side of the first cylinder then and the multi-rom knows to recognise the first pre-defined cp/m partition as the cp/m boot partition and simply loads the first sector into ram-bank zero and then jump to location zero with that cylinder number in say IXreg then I can write a boot loader that can load the system loader-proper directly from the remaining sectors on that cylinder and setup which can then read the partition table proper and decide how big and how many drives to give itself without stepping upon other filesystems:-) If all the data structures of the partition table are well defined and publicised and Assured to be constant by the time I get to putting the BOOT'able version on a HD then even though the Multi-ROM may not be in production it'll be quite easy to write a small AUTO run code file that'll perform the partition friendly cold boot for me until I get the real thing;-) As long as I write a native util to create the table and save my boot stuff in the right places.... oooo-heck! Cs> I'm planning to allow large caches -- Cs> probably not on floppies until Cs> the invisible upgrade occurs, which Cs> should allow us to autosense the Cs> drive change and basically treat the Cs> floppy drives like IDE! See my posting badly explaining prodos cache'n and a uninformed guess at a possible mechanism of dealing with FAT cache'n.... probably totally wrong but as you probably have the details to hand and I know next to nowt on FAT I'll leave it totally upto your judgment:-) Cs> It's to do with both -- for quick Cs> backwards random access and for Cs> file recovery. Hmm, I think trying to trace backwards could be more problem than its worth just for faster backwards relative positioning, but as I'm no expert.... feel free to ignore:-) Regards. Johnathan. PS Does this posting look better than the old method with the dodgy subject:? ___ Olms 1.60 [Evaluation] +-------------------------------------------------------------------+ | Standard disclaimer: The views of this user are strictly his own | | ===> Gated @ Centronics BBS [centron.com] +44-1473-273246] <=== | +-------------------------------------------------------------------+
