From: David Wood (jbevren_at_starbase.globalpc.net)
Date: 2007-12-24 19:09:41
I'm not attempting to be a featurist, but I see no reason why we shouldnt
use a more real FAT filesystem. Compatibility is always a goal, but if we
change the filesystem even in the slightest bit, we lose compatibility with
programs that directly read and write sectors.
IDE64 has done a good job of handling (in the firmware verson on mine) 8G
harddisks. Honestly, I ahve no idea what type of filesystem it uses.
However, FAT shouldn't be too hard to program for if it's kept simple.
Sector-linking is great for small disks and small systems, but if you go
beyond the CBMFS limit of 16MB and create a new filesystems, being able to
directly address a file would be excellent. This is done easiest in i-node
or fat-based filesystems, FAT being the easier of the two evils to program for.
-jbev
(Side note / shameless plug) :
At uhs.c64.org you will find a filesystem draft for a deblocked filesystem
as well as a chat I had with Jolse regarding a potential native FS for
JOS/WiNGS. Feel free to peruse the concepts there if you wish. :)
DebFS uses a 40bit pointer into the whole filesystem on a byte level. This
would require memory expansion on a 1541 like device, and is likely not
suitable for the simple IDE interface. I won't feel at all insulted if the
idea is rejected. :)
40 bits maps 1,099,511,627,776 bytes (1 terabyte) as a maximum, facilitating
the use of the largest available disks I'm aware of (750GB is the last Ive
really looked at).
Note that the deblocked FS draft is fairly sparse and hasn't been written to
cover directory format. When coming up with a filesystem, I work on
allocation tracking first. ;)
Mapping the 40 bits to a sector is easy when the sector size is known. For
512 byte sectors, rotate the 40bit pointer 9 bits to the right to obtain the
sector number, and then strip the high 31 bits to get the pointer within the
sector. Even at 1mhz, it should be plenty fast to find the beginning of a
chunk of data within the disk. Note also that the max chunk size is 16M, so
most any file can be read with a single reference to the FAT.
The only real challenge is, of course, finding an unallocated area to put
new data in. ;)
Meh. I guess my plug is bigger than my post. How rude ;P
On Mon, 24 Dec 2007 ruud.baltissen@abp.nl
wrote:
> Hallo Nicolas,
>
>
> > Adding IDE support to the 8x50 design might be easier than it seems.
>
> I disagree.
>
>
> > So "only" the FDC code needs to be replaced,
>
> One problem is that some FDC code, like the formatting routine, is found
> in the ROM of the Command Controller (CC). So even if the program for
> the CC doesn't change, the contents of the ROM does.
>
>
> > and the DOS2.7 or 3.0 can stay completely unchanged.
>
> Which means we are stuck with a 1/5/7.5 MB harddisk :) To be able to
> handle larger disks we have to:
> - find the location of the drive parameters and to change them.
> - find out how the CC handles the BAM table as this needs to be enlarged
> as well.
>
> But again, the above preperations only provide us with a 16 MB harddisk.
>
>
>
>
> Hallo allemaal,
>
>
> As already known, to solve this 16 MB problem I came with the LBA-link
> soulution, capable of handling up to 128 GB harddisks. But I'm not
> really happy with it. Yesterday an idea popped up in my mind which maybe
> is worth a discussion or can lead to other ideas: clustering, as used in
> FAT and other file systems.
>
> In this case a Commodore sector will in reality be more then one real
> sector. The number of bytes that reside on the last sector can be solved
> by either using the third byte as well or using an unused byte in the
> directory entry. I realise that this idea has a some disadvantages, for
> example clustering 100 sectors to one cluster:
> - we still will only cover a 1.6 GB harddisk
> - every program would occupy at least 100 * 512 = 51 KB disk space, no
> matter its real size
> - the size of almost every known program will show up in the directory
> in the range of 1 or 2 blocks.
>
> As said, just an idea, but hopefully one that triggers some other ideas.
>
>
> --
> ___
> / __|__
> / / |_/ 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
>
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.