Added FAT32 Saving, File creation and deletion, and full-sector writes.

[liaminventions]

This is fully functional and has been tested on my homebrew 6502 laptop (the XPL-32).

It does need another 512-byte buffer for the FAT in the RAM though...
Is this out of the scope of this project?

[liaminventions]

also, the diffs aren't rendering correctly...

[gfoot]

Nice! I'll check it out when I can. I actually recently wrote some FAT32 writing code for a 6502 machine, but in BASIC - it'll be interesting to compare! I think for that I used two 512-byte buffers, mostly for safety reasons so that I could compare the FAT with its backup before writing anything. I can't think of a case where you definitively need more than one buffer though.

[liaminventions]

I can't think of a case where you definitively need more than one buffer though.

Yeah, so what happened was I needed to write the cluster data, and then right after, update the FAT in memory. And at the end, I would update the SD card's FAT from that second buffer. For the most part, it just speeds up the process a ton, instead of having to write the FAT over and over again.

I could compare the FAT with its backup before writing anything.

Awesome! I haven't yet set up the backup table, for now, it just writes to the first one.

[liaminventions]

Actually, should I merge fat32_allocatecluster with fat32_writedirent? I think it may be redundant to need to call it in the high-level API.

[gfoot]

I wouldn't merge them - extending a cluster chain is a useful operation in its own right, e.g. for extending a directory you want to allocate an extra cluster and extend the chain, but you don't update a dirent.

In my implementation I allocate my clusters first (writing the FATs), then update the directory entry to point to the new cluster chain. But my use case is simple as I'm only creating new files, and I know up front how many clusters to allocate.

From what I've seen, Windows seems to silently update the backup FAT(s) without registering any errors or requiring a manual filesystem check/repair. But it's fairly easy to support this - just whenever you're writing a sector to the FAT, if mirroring is enabled, also write it to the backups which are at consistent offsets from the primary FAT.

[liaminventions]

Great Ideas! I'll experiment with those things at some point soon...

[liaminventions]

ok. I'll start experimenting with this now in this file: https://github.com/liaminventions/XPL-32/tree/main/xa/libfat32.a65

[liaminventions]

alright, I added fat mirroring (if numfats=2) and finally got rid of "buffer"!

I just need to change the syntax to match how it is here...

[liaminventions]

OK! That's done. Now I'll update the MD files and restore the example back to how it was before.

[liaminventions]

Done! Should I add a saving/deleting example program?

[liaminventions]

hold on, this may or may not have a bug in it, it seems the SD is not readable by other computers and I cant RM? (one moment)

It was fine yesterday...

[liaminventions]

Thanks!

I was also actually working on a DOS too. (it doesn't have a repo yet, just made for the XPL-32 for now.) its here

[ebadger]

Thanks!

I was also actually working on a DOS too. (it doesn't have a repo yet, just made for the XPL-32 for now.) its here

Cool man, we should chat - the code for my ebadger6502 is here: https://github.com/ebadger/msbasic
dos.s contains the dos code - I'll definitely take a look at your implementation once I've got this thing going.

My project is documented here:
https://www.youtube.com/watch?v=e65qVK7zNGM&t=120s

and here:
https://www.youtube.com/watch?v=UJyYEBcQ2sE&t=22s

@gfoot George, thinking maybe we should make a stand alone SD-DOS for the BE6502

[ebadger]

this block in fat32_allocate_file hits infinite loop if sectors per cluster == 1

; Divide by sectors per cluster (power of 2)
lda fat32_sectorspercluster
lsr
@cl:
lsr fat32_bytesremaining
lsr
bcc @cl

[liaminventions]

whoops! i'll fix that now...

[ebadger]

any idea why the diff is completely broken? Did you change file format or something?

[liaminventions]

I don't know, it must have changed when I pulled to linux (that's what I suspect anyway)

[liaminventions]

yes, that's probably what it is. since this was pulled to ext4 instead of nfts.

[ebadger]

I wonder if it's a utf-8 vs utf-16 thing? Would be nice to fix so we get real diffs. I'm pulling into VScode to diff for my own purposes

[liaminventions]

just checked this, all the files are in utf-8

[liaminventions]

huh, maybe that's not the issue. when I cloned the original repo, it was in utf-8 as well...

[liaminventions]

ah, yes I have figured out why. line endings. these files used to have DOS line endings

[liaminventions]

there is one bug here that I can't quite track down yet. It might be just on the XPL-32, or it might be here.

it seems that if I load this file and then save it, it gets strangly distorted.

as in, 256 bytes were removed at index 0x200-0x2f0, and then 256 0x00s added at the end.

the file after it's saved

i had been investigating this bug all day though, so I'll come back to it soon (gn)

[liaminventions]

I have added a saving example program called test_savefile.s, it works as well and saves subfoldr/SAVETEST.TXT, which contains bytes 0-255.

[liaminventions]

by the way, I'm now sure that that bug (the file-distorting one) is here and not just on the xpl. I wrote a program that uses the libraries from this PR and it fails in the same way...

[liaminventions]

all right! I've fixed the bug! I just forgot a CLC in fat32_file_write! (wow!)

[liaminventions]

sorry for the absence, I've been busy with many other things. hopefully I'll get back to this soon.