ROM Hack DS virtual filesystem (discussion on a possible project).

[FAST6191]

I am knee deep in the hacking docs right now so I have no time for actually making this, this is just a feeler post to see what people think.

Cracker and I were having a conversation whereupon the idea of a kind of virtual file system for the DS appeared. I am sure most of you reading are well aware of the file system for the DS and how nice it is for hacking (no space worries, no need to trace the start of the file outside of stuff like NARC files and a few exceptions which again is simple enough).

My main reason is for tracing. For those not aware the GBA had the rom mapped to the memory (08000000 and 09000000 with mirrors at different wait states), this means you can find the text in a game (in the actual memory by whatever method you like) and then look to see where that data was sourced from (often the rom itself or the section it was decompressed to (meaning you just repeat that step with the new memory section)).
Other uses include the potential for a bit of on the fly* editing (or at least dodging the need for a rebuild) and corruption (it is simpler than tracing in some cases).
The DS having a file system means tracing is not quite as easy as it once was (in fact is is nigh on impossible).

*The emulators acting like a DS you may end up editing the file too late and the original data is loaded (something that could hopefully be rectified with a collection of save states) and editing the size of the files is sure to cause headaches as the file table is usually loaded at startup and used from there onwards.

Now I have a whole bunch of tools for video that effectively do just this (and you probably are all familiar with the likes of daemon tools: DS files are not overly different to isos) and are thus able to trick most programs into believing a video is in a given format (usually avi) which would be doubly nice as it means any emulator/other tool could use it.

So discussion, worth attempting? any pitfalls you can see?
DS nitrorom file system specs:
http://nocash.emubase.de/gbatek.htm#dscart...roromfilesystem
ndstool is open source too.

It might also be able to expand this to read individual files but that would likely require linking it more directly to an emulator unless you wish to fiddle with grabbing memory reads with the OS.

 

[playallday]

Great! But this is all to much to know for most of us. Unlike you most of us are happy just playing games and homebrew. Now don't get me wrong I think whatever your trying to do will help us all but don't think many will know what your talking about.

Bottom line: I think you need to PM some long time rom hackers that you know. Posting here won't help.

 

[FAST6191]

Tracing was an incredibly important technique on earlier consoles (today it is a matter of searching the memory for something and then searching back in the iso/rom which is less than brilliant owing to compression and dynamically generated content).
"most of us are happy just playing games and homebrew"
Perhaps but this is the rom hacking section (and perhaps the biggest one catering to the DS) where such discussion.

"long time rom hackers"
A fair few of them frequent these forums, admittedly I picked the wrong time to post it (in the middle of the predictable pokemon spamming sesssion).

I was first thinking of simply making the tracing section using a ram drive (or at worst recompiling the emulator after it having felt my touch forcing the emulator to load the rom into the ram) and then tacking an access logs app onto it and a simple script to convert memory locations to file names which could possibly be done with existing tools. It would lack on the fly editing of course but tracing is my real aim in all this.

 

[DarthNemesis]

So how exactly would this work? I've got a particular image I'm trying to find so that I can edit it.

 

[FAST6191]

Any for want of a better term dynamic building will just be to make a fake file without the hassle of rebuilding the rom for a small change, there are other ways like fiddling with the file name/location table and rom size in the header and just tacking the file on the end but this would be nicer.

Regarding the tracing it would essentially be a low rent version of a classic tracing tool except rather than looking at the source locations from disassembled code you would look at where in the rom is data is being read from by way of the operating system you are running the emulator on (the DS generally has to put things into the ram with them not being able to be read directly from the memory like earlier systems).
Naturally it probably would not be using breakpoints (that halt the emulation) meaning work would have to be done after the fact in most cases (for others you can tell such tools to halt when a given memory section is written and see there and then what caused it as well as logging everything to do with it).

The simple version I spoke of probably using something like DDD ( http://www.gnu.org/software/ddd/#About ) and a basic ramdrive but debugging on operating systems/PCs is not my strongpoint (all languages on the PC I use commonly have such functionality built in) or I would have tried something already.

It probably is possible to do with an emulator enhancement like you can use to detect IRQs ahead of time but it would be a pain to implement properly as there are many ways of doing things: http://nocash.emubase.de/gbatek.htm#dscart...roromfilesystem

Edit: it occured to me that some might appreciate an introduction to tracing
http://www.romhacking.net/docs/361/

 

[cory1492]

As far as I know, DS uses/deals with some mutation of std fopen() to deal with files in the nitro file system (I recall seeing some enum/struct prototypes, IIRC they were from crystaltile's creator) - since it should be relatively standard from game to game these types of accesses could be redirected by an emulator/mod to use plain files instead of accessing the actual/nitro system in the original file (and from there you could hook or watch whatever you wanted to watch for.)

I'd think the first place to look or ask would be emulator authors or current sources... any of them who have tinkered with nitrofs in the emulator should be able to judge how feasible it would be right off.