It is currently Sat Oct 21, 2017 7:58 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: NES file system
PostPosted: Wed Feb 15, 2006 6:49 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
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?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 15, 2006 12:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
How long would this "cleaning" operation take, while the user can't see anything because the VRAM is full of data being rewritten to flash? If it's longer than two seconds, you run the risk of the player turning the power off and corrupting everything.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 15, 2006 5:06 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
True, yeah there should be something to show activity. It could mess with the greyscale bit maybe. Or a scanline IRQ could turn the screen on for a row of tiles to show what's going on.


Top
 Profile  
 
 Post subject: Re: NES file system
PostPosted: Tue Feb 21, 2006 3:29 pm 
Offline

Joined: Tue Feb 21, 2006 3:03 pm
Posts: 3
Memblers wrote:
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.


Flash devices with little RAM to work with often reserve a full sector as a swap area for GC. You also need to watch out for power outages in the middle of writing a file (brownout, blackout, power surge, player getting pissed-off and kicking unit), and ending up with a corrupted FS.


Top
 Profile  
 
 Post subject: Re: NES file system
PostPosted: Wed Feb 22, 2006 6:32 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
zx-1 wrote:
Flash devices with little RAM to work with often reserve a full sector as a swap area for GC. You also need to watch out for power outages in the middle of writing a file (brownout, blackout, power surge, player getting pissed-off and kicking unit), and ending up with a corrupted FS.


Ah, that's smart and would really make things much simpler, heheh. Only bad thing is that it would the memory use would be minimum 192kB for the BIOS and max 320kB for user program ("ought to be enough for anybody" - unattributed ;)). I guess that's not so bad, it's an optional feature and the files can transfer to the PC if they need to get out of the way, anyways.

Thanks for the power outage warning, yeah with errors/corruption what we don't want is ones that can persist and accumulate. So maybe the last byte of each block I'd write should complete an ID (part 1 of 4, etc.), so during clean-up it can find any incomplete/corrupt files/blocks and drop them. That'd be faster than dealing with checksums and stuff.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group