Date: 2007-08-28 09:07:23
Hallo Ethan, > The reason for bringing this up is that you mentioned using > a different scheme than an embedded track-and-sector forward > pointer. Unfortunately I have to disappoint you. This 4-byte pointer of mine is simply the LBA pointer to the sector on the harddisk; in effect an upgrade of this track-and-sector pointer. Load this vector directly into the registers of the HD and you are already there; no more stepping of the head and no more reading of the header needed anymore. > I'd love to be able to _efficiently_ calculate the location > of arbitrary blocks on the mounted medium, and getting away > from track-and-sector forward pointers seems like a great > time to consider it. That is where unfragmenting of the file comes in view. Knowing the LBA code of the first sector, knowing the offset of what your are looking for, given the fact that a sector holds 252 data bytes, LBAx = LBA0 + offset/252 + 1*(offset mod 252 > 0). Hallo allemaal, One idea I like to discuss. Now a sector only contains the pointer to the next sector. What about adding a vector that points to the previous sector? Disadvantage: 8/256 = 3% is lost (FYI: BAM costs 0.05%). Advantages: 1) in case of a crash it is much easier to repair the file system (FS), 2) for example, it is much easier to "go back 2 sectors" in a fragmented sequntial file. Another idea. The LBA pointers I am familiar with uses 4 bytes. But only 4 bits of the last byte is used: 3.5 bytes -> 128 GB. The other 4 bits have no use as two bits are always 1 in the according register of the harddisk, one tells wether the master disk or the slave disk is selected and one bit tells the HD to use the LBA method or the old track/sector/head method. The idea is to use bit 7 to tell the FS that this sector is free. Not needed when you have a good BAM but comes in handy in case of a crash. Disadvantage: the FS has more work to do. Advantage: can be implemented later, downwards compatible. Then another idea that just popped up: as said above, one bit tells the HD wether the master or slave disk is selected. Using this enables us to see two harddisk as one. Disadvantage: it is more difficult to back-up the system. I think I won't implement this idea but wanted to share it with you in case someone has some ideas to make more of it. Last question. I have an Hires CD that contains several image programs. But they only want to make an image of a known FS, they don't recognise my 1541 HD :( I'm familiair with FAT16 but that one is already to old to use. A friend of mine tried to implement FAT32 on IEC-AT but said it was quite difficult and kept on having problems. Who has experience with implemmenting a known FS from scratch on a self built system and wants to share this with me? But using this FS means that we loose all compatability with the original Commodore FS. Do we want that/is this acceptable? Thanks for any help/info/advise !!! -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| URL: Ruud.C64.org De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. Stichting Pensioenfonds ABP is gevestigd te Heerlen en ingeschreven bij de Kamer van Koophandel Zuid Limburg onder nummer: 41074000 The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. Stichting Pensioenfonds ABP, having its registered office at Heerlen, is registered in the Traderegister of the Chamber of Commerce Zuid Limburg (Maastricht), the Netherlands, registration number: 41074000 Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.