> The ONLY thing I'd like to see on ALL the various file-systems is the > facility > to Partition a BIG HD so we can run the several different types of file > system > on the same HD, eg. CP/M defines in it,s DPB a reserved number of tracks as a > 16bit value so it can be placed virtually anywhere on a large HD and take up > as much space as defined in the dsm field... Any unix style system should > also > be made to do this as well IMHO:-) > I've mentioned this elsewhere before... a small unix style pd filesystem is > available in C source form inside the UZI package on oak.oakland.edu It > doesn't use 32bit values just 16bit for speed and ease of z80 implementation > so each mounted logical drive is restricted to 32Meg in size. > > With some extensive editing it'll probably even compile under small-C v2! > though I think the resultant assembler source would need extensive > hand-optimisation as Small-C is not a very clever code generator;-)
Brilliant! Should be good :) > As we're dealing with a fixed drive we can theoretically do what ever we like > as it doesn't need to be compatable with ANY other platforms physical format.. > So just use the good features of the various systems, make the nesesary > comporimises needed to allow acceptable performance on a z80 machine ie if > 32bit values slow it down use 16bit pointers and partition large HD's it > smaller logical units, after all who needs to process more than 32Meg items > on > a z80? Hmmmmm... not sure. The 32bit values will perform pretty much no slow down if done right -- the drive itself will take the most time. > Si> I'm currently thinking of 64 chars per > Si> directory entry, allowing 20 > Si> character (or so) filenames, with > Si> possibly a quick-to-access file system > Si> (ie one that is a combination of FAT and > Si> sector/head/track at the end of each > Si> logical sector (ala SAM)). > > 510byte sectors again Si!?! Makes for crappy random-access file performance! > ProDos random access is much better than master-dos, not that I'd suggest > doing a CP/M style directory structure... I've noticed on this pc1512 running > pcrr1.60a olr that it is damned sloooow at random-reading the prior message > don't know if that's an MS-DOS problem or somthing to do with the MS-DOS TP > runtime package... > > Plus 510 byte isn't binary maths friendly but 512 is, obviously;-) Okay, agreed -- I won't use 510 byte sectors, 512 it is. Now the question is: In our FAT do we want a way of searching <back> along the chain as well as forwards? Si Cooke
