RE: Checking syntax for 1541 and more...

ruud.baltissen_at_abp.nl
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.