I'm designing a file system. If anyone has been wanting to write a program that it could be useful for, or just any general comments, I'd been interested in hearing it. I'll probably implement it first in the editor for my speech synth.
If anyone here is knowledable about C libraries, I'd like to know how or if it could be worked into cc65 also (it's NES library).
Note this is useless if all you want to do is load data. This stuff is for saving, loading, and deleting data in FlashROM (or anything writable I suppose) from within your own NES program. I would put it in Squeedo's BIOS bank.
I haven't decided on a block size. Probably 256 bytes would be good, with 8 or 16 of those having info about the block. No directories, no FAT, just little filenames possibly. It's good for saving small files on the Flash because it doesn't delete anything until the sector is full. Then it rewrites the whole sector, minus the blocks marked as deleted. Pretty simple stuff.
The downside is that it needs to trash nearly 32kB of RAM when the sector needs to be cleaned. So I'd probably do that in CHR-RAM, trashing the gfx in the process. So any program using this would have to be prepared to reload several (or all) of it's CHR-RAM banks.
Does this sound interesting, useless, or like anything to anyone?
If anyone here is knowledable about C libraries, I'd like to know how or if it could be worked into cc65 also (it's NES library).
Note this is useless if all you want to do is load data. This stuff is for saving, loading, and deleting data in FlashROM (or anything writable I suppose) from within your own NES program. I would put it in Squeedo's BIOS bank.
I haven't decided on a block size. Probably 256 bytes would be good, with 8 or 16 of those having info about the block. No directories, no FAT, just little filenames possibly. It's good for saving small files on the Flash because it doesn't delete anything until the sector is full. Then it rewrites the whole sector, minus the blocks marked as deleted. Pretty simple stuff.
The downside is that it needs to trash nearly 32kB of RAM when the sector needs to be cleaned. So I'd probably do that in CHR-RAM, trashing the gfx in the process. So any program using this would have to be prepared to reload several (or all) of it's CHR-RAM banks.
Does this sound interesting, useless, or like anything to anyone?