I love it!
billiegoose opened this issue · 6 comments
I saw your SeqBox on /. I think it's great! I am just starting to learn about how filesystems work, because I'm playing around in x86 assembly writing a bootloader (because that's everyone's idea of fun, right?). Right now I only know how to read sectors from a floppy disk into memory, and reading up on FAT12 and even more advanced systems seems overwhelming. (Pretty much anything in assembly seems like an enormous task to me.) But with this, I could easily format the floppy as [whatever] and then use a for loop in my MBR bootloader to:
- read each sector into RAM one by one at a fixed location
P - look for the 'SBx' signature
- then read the sequence number
- multiply the sequence number by 512 to compute an offset
- copy the sector currently located at
Pto some fixed location plus that offset
To start, I would probably not worry about the checksum or even the UID since I only have one file. By the time the for loop has read the entire floppy, the kernel would be in memory!
Then I'd potentially be able to "drag and drop" kernel.bin files onto the floppy drive like a "real" disk! (Currently, I use dd every time to write the MBR+kernel to the floppy, and Windows complains every time I insert it asking to format it.)
In other words... I could write an assembly program that can read SeqBox files from a disk without having to write a file system driver!
That's some creative use! :) You could surely do something like that.
multiply the sequence number by 512 to compute an offset
By 512 - header len, so 496 (that's the size of the useful content in each SBX v1 block).
Damn... I was just about to correct that. :) Yep, that would be 512 - 16.
I'll let you know how it goes!
Cool! Thanks!
It worked! link to SBx file, link to code
But reading x86 assembly code isn't very fun, so here's an animated GIF:
The ASCII art is in an SBx archive spread across 4 sectors. Right now I'm not even parsing the length, just reading each sector of a floppy disk-formatted USB drive one sector at a time. If the UID == 1, I copy the sector to desired location + (sequence number - 1) * 496. The ASCII art file is NULL terminated, so I can get away without knowing the length.
Now, I'm not suggesting that blindly copying things to RAM, skipping the CRC checksum, ignoring the metadata block, etc are good things to do. (It is just trusting that all the blocks are there and it will find them with a dumb linear scan, which would be terribly slow for drives larger than floppy disks!) But pretty amazing for a minimum viable product / proof of concept! In less than a day, I was able to write a routine in x86 assembly to load a file, without having ANY file system code or apriori knowledge of the partition structure, the file system, the name of the file, or how big it is. Very cool!
I have some ideas for how to make the bootloader (much) smarter... but at least now I can copy files normally instead of having to use dd every time I test a change. (Or at least I will as soon as I replace the "print string" command with a "JMP" instruction and compile an actual kernel.bin.sbx to run.)
Very nice!