#fat12 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #fat12, aggregated by home.social.
-
#TIL that the #FAT #filesystem doesn't really store anywhere whether it's #FAT12, #FAT16 and #FAT32. What you're supposed to do is to look at the number of clusters, and determine which range it falls into. More specifically, you're supposed to look at the partition size and divide it by the number of sectors per cluster (which is stored in consistent position irrespective of FAT type).
The obvious implication of that is that the volume sizes are limited by possible cluster size ranges. There's some overlap here, though: you get more clusters (and therefore use a "longer" FAT) by using a smaller cluster size, or fewer clusters by using a larger cluster size.
https://elm-chan.org/docs/fat_e.html#fat_determination
However, there's a curious trick: there's a 16-bit "FAT size" field that indicates how many sectors are used for FAT on FAT12/FAT16 filesystems. On FAT32 this field is zero (there is a separate field for 32-bit FAT size there), and apparently some tools recognize the filesystem as FAT32 in that case, irrespective of number of clusters. This is what mkfs.vfat does when you force FAT32 on a small block device.
Why did I learn all this? Because a friend tried to make a very small EFI partition and was surprised it didn't work. I was compelled to get to a bottom of this!
-
#TIL that the #FAT #filesystem doesn't really store anywhere whether it's #FAT12, #FAT16 and #FAT32. What you're supposed to do is to look at the number of clusters, and determine which range it falls into. More specifically, you're supposed to look at the partition size and divide it by the number of sectors per cluster (which is stored in consistent position irrespective of FAT type).
The obvious implication of that is that the volume sizes are limited by possible cluster size ranges. There's some overlap here, though: you get more clusters (and therefore use a "longer" FAT) by using a smaller cluster size, or fewer clusters by using a larger cluster size.
https://elm-chan.org/docs/fat_e.html#fat_determination
However, there's a curious trick: there's a 16-bit "FAT size" field that indicates how many sectors are used for FAT on FAT12/FAT16 filesystems. On FAT32 this field is zero (there is a separate field for 32-bit FAT size there), and apparently some tools recognize the filesystem as FAT32 in that case, irrespective of number of clusters. This is what mkfs.vfat does when you force FAT32 on a small block device.
Why did I learn all this? Because a friend tried to make a very small EFI partition and was surprised it didn't work. I was compelled to get to a bottom of this!
-
#TIL that the #FAT #filesystem doesn't really store anywhere whether it's #FAT12, #FAT16 and #FAT32. What you're supposed to do is to look at the number of clusters, and determine which range it falls into. More specifically, you're supposed to look at the partition size and divide it by the number of sectors per cluster (which is stored in consistent position irrespective of FAT type).
The obvious implication of that is that the volume sizes are limited by possible cluster size ranges. There's some overlap here, though: you get more clusters (and therefore use a "longer" FAT) by using a smaller cluster size, or fewer clusters by using a larger cluster size.
https://elm-chan.org/docs/fat_e.html#fat_determination
However, there's a curious trick: there's a 16-bit "FAT size" field that indicates how many sectors are used for FAT on FAT12/FAT16 filesystems. On FAT32 this field is zero (there is a separate field for 32-bit FAT size there), and apparently some tools recognize the filesystem as FAT32 in that case, irrespective of number of clusters. This is what mkfs.vfat does when you force FAT32 on a small block device.
Why did I learn all this? Because a friend tried to make a very small EFI partition and was surprised it didn't work. I was compelled to get to a bottom of this!
-
#TIL that the #FAT #filesystem doesn't really store anywhere whether it's #FAT12, #FAT16 and #FAT32. What you're supposed to do is to look at the number of clusters, and determine which range it falls into. More specifically, you're supposed to look at the partition size and divide it by the number of sectors per cluster (which is stored in consistent position irrespective of FAT type).
The obvious implication of that is that the volume sizes are limited by possible cluster size ranges. There's some overlap here, though: you get more clusters (and therefore use a "longer" FAT) by using a smaller cluster size, or fewer clusters by using a larger cluster size.
https://elm-chan.org/docs/fat_e.html#fat_determination
However, there's a curious trick: there's a 16-bit "FAT size" field that indicates how many sectors are used for FAT on FAT12/FAT16 filesystems. On FAT32 this field is zero (there is a separate field for 32-bit FAT size there), and apparently some tools recognize the filesystem as FAT32 in that case, irrespective of number of clusters. This is what mkfs.vfat does when you force FAT32 on a small block device.
Why did I learn all this? Because a friend tried to make a very small EFI partition and was surprised it didn't work. I was compelled to get to a bottom of this!
-
#TIL that the #FAT #filesystem doesn't really store anywhere whether it's #FAT12, #FAT16 and #FAT32. What you're supposed to do is to look at the number of clusters, and determine which range it falls into. More specifically, you're supposed to look at the partition size and divide it by the number of sectors per cluster (which is stored in consistent position irrespective of FAT type).
The obvious implication of that is that the volume sizes are limited by possible cluster size ranges. There's some overlap here, though: you get more clusters (and therefore use a "longer" FAT) by using a smaller cluster size, or fewer clusters by using a larger cluster size.
https://elm-chan.org/docs/fat_e.html#fat_determination
However, there's a curious trick: there's a 16-bit "FAT size" field that indicates how many sectors are used for FAT on FAT12/FAT16 filesystems. On FAT32 this field is zero (there is a separate field for 32-bit FAT size there), and apparently some tools recognize the filesystem as FAT32 in that case, irrespective of number of clusters. This is what mkfs.vfat does when you force FAT32 on a small block device.
Why did I learn all this? Because a friend tried to make a very small EFI partition and was surprised it didn't work. I was compelled to get to a bottom of this!
-
*me, staring at a 360KB floppy disk image for a MS-DOS program on archive.org* wtf do i do with this? run an emulator and try and mount it... then copy the file i want?
Wait A Sec...
*macOS* Just Opens and mounts the image in finder. Because of course, it's a FAT12, just like a USB thumb drive.
-
*me, staring at a 360KB floppy disk image for a MS-DOS program on archive.org* wtf do i do with this? run an emulator and try and mount it... then copy the file i want?
Wait A Sec...
*macOS* Just Opens and mounts the image in finder. Because of course, it's a FAT12, just like a USB thumb drive.
-
Thank you, @JennyFluff !
This is really cool! You did an amazing job preserving these disks! Everything installed flawlessly on my virtual WfW 3.11. Appears to be a special "Star Trek" version of AfterDark 3.01. However, there are a several bad sectors on one of the disks' FAT, but these do not interfere with the setup process.
#AfterDark #RetroComputing #86Box #Emulation #DiskImageTool #FAT12 #FloppyDisk
-
Another bad retro diskette! At first glance, this one seemed pretty much gone. None of my disk imaging tools were able to read it. Windows Explorer just crashed.
Only a low level KryoFlux dump managed to uncover the physical cause behind this: A corrupt root directory beyond any chance of repair. Luckily, both the file allocation tables as well as most of the data clusters were still in good shape. I used a hex editor to manually recover all the files from the valid tracks. It worked!
I guess these games are nothing special, but it still made me happy to pull usable data and working files from such a destroyed file system!
#RetroComputing #FloppyDisk #KryoFlux #DataRecovery #MSDOS #86Box #FAT12
-
For anyone woundering "why do you use the latest @linux #Kernel release?"
Well, I want OS/1337 to be basically 'rolling release' in that I can't be bothered #backporting stuff and I just want to pull the #releases straight from said projects.
https://github.com/OS-1337/OS1337/blob/main/build/0.CORE/build/sources.list.tsv
* Okay, I've not listed #syslinux & #mkdosfs and #dd which I used in making the #Floppy image but those basically don't really change much at all. We all know how #FAT12 works...
-
For now I'm only focusing on making something that generates FEFS24 images (24-bit pointers). That covers 99.99% of #Psion Flash and ROM SSDs.
I've only ever seen a handful of very early (1989) Type I Flash SSDs using FEFS32, and they were made by Psion themselves for the #MC200 and #MC400.
Once I've nailed FEFS24, FEFS32 will be much easier.
RAM SSDs use #FAT12, so that's a whole different ballgame. So far I've just used mtools to generate working FAT12 volumes.