Well, you can modify it in any way you want...add, move, copy, delete, inject, encrypt, decrypt, hash, dump, calculate, trim, etc.Still want to know how the NAND is modified by GodMode9. I have not found any source yet.
Hello so i just did a transfer to emumnand to sysnad the things is i dont want to format to get rid of emumand i just want that extra space, if i go to G9-> emunand virtual and delete all the contents in there will i screwed up the console or something?
Essential backup starts at sector 1 (= byte 512) in your SysNAND. And no, there really is no good reason to remove that. If you want to clean your NAND from any 'suspicious' data (I have already explained why I don't think that's really needed), ask around in a scripting thread for a more thorough 'hack removal script'.Still want to know how the NAND is modified by GodMode9. I have not found any source yet.
Why can't we edit [V:] VRAM VIRTUAL? I mean, you can edit [M]:/vram.mem, so why not VRAM? It could be useful if you could edit it..it could be like a very tiny bonus drive!
CIAs are always 'trimmed'. Try to add padding to a CIA file, you will no more be able to install it via FBI or handle it in GM9. As for .3DS files... there are really faster tools available for this. We should not forget about the 3DS card reader hardware limited speed.@d0k3 Can you add the ability to trim .3ds and .cia files? I know GM9 will show a trim.3ds file in the [G:] Drive, even though it's not truly there, so GM9 must be able to trim roms?
It'd be a nice feature so you could trim your Gateway roms or trim CIAs to save space before installation. Just a thought.
I see. Yeah, I know what's stored in there, as of post-1.5.1 commits it's the ReadMe, the splash, and the font. I embed an aeskeydb.bin and a file with how to do some less common things.VRAM *already is* a ramdisk. It's loaded on boot as a FIRM section and serves as a sort of initial ramdisk for GM9, where you can embed resources and other files you want to be available on that GM9 build.
Right now it's only used to store the default boot splashes and the README (plus some other data), but it could be used to store FIRMs (your favorite CFW, etc etc) or custom scripts.
However, to make building this ramdisk easy on all platforms, it was decided to use a tape archive (TAR), and GM9 has read-only support for it. if you ever used *nix loopback mount or ImDisk/OSFMount on Windows, this is sort of similar.
if you want a fast-but-volatile drive, you could always use the real ramdisk which has way more available space than VRAM (I think it was 80MB?), otherwise you could use the extra space that GM9 can format within your NAND (pretty sweet on 1.8GB N3DS consoles).
the ramdrive is already there as 9:I see. Yeah, I know what's stored in there, as of post-1.5.1 commits it's the ReadMe, the splash, and the font. I embed an aeskeydb.bin and a file with how to do some less common things.
Thanks for all the info about the ramdisk. How can I use the 80MB ramdisk?
I love bonus drives too, have a 1.8GB N2DSXL w/ 620 MB bonus.
Oh, oops, I thought that was different from the ramdrive. I also thought it was 49.7 MB? Or perhaps that's on the o3DS.the ramdrive is already there as 9:
Also, my H&S is now permanently stuck with the FBI icon after injecting. It loads up as H&S, except the icon is FBI. No idea what the problem is. Is there a difference between the Old and New 3DS H&S? Because then I would dump a working H&S from my o3DSXL and inject the H&S into the N2DSXL.
As far as I know, attempting to unmount the SD card from elsewhere will simply bring you back to [root] but not unmount the SD. Useful so you don't have to spam B to get back to [root].Okay, I got an idea... You know that you can only unmount the SD card in the root directory? Did you try from somewhere else? A defective SD card or SD card reader is a possibility, too, of course.
I'll think about it. Being able to go without a config file is good, of course, but we now have customizability stuff that may even be interesting to the common user.@d0k3
I think we need settings menu in GM9.
There are too many compile flags now and it should be more user-friendly.
Some items that I want :
panel brightness
contents colors(dirs, files, hex editor, text viewer)
font path
@d0k3 After getting a new N2DSXL (accidentally broke internal LCD on other, but luckily bought an extra warranty package), I cannot do anything with TMD's and APP's. Just gives me the standard Hexedit, calculate SHA, file info, etc. I have no idea why. These are the files from the new console, not the old one, I can't figure out what the problem is. It works on CTRNAND, but not from SD files. I repeat, they ARE from the NEW system, not the old one.
Didn't figure it out. I'll try again, I'll admit that when I found the problem, I'm not sure if I'd booted the titles yet. The ones I've tried work fine. I'll see if I can test it later.I'll think about it. Being able to go without a config file is good, of course, but we now have customizability stuff that may even be interesting to the common user.
Did you figure that one out? Only reason I can think of is you copied stuff somewhere you shouldn't have. Do the titles you're having trouble with boot from homemenu?
I'll think about it. Being able to go without a config file is good, of course, but we now have customizability stuff that may even be interesting to the common user.
Well, then find out. Maybe it's possible you tried the '0:/Nintendo 3DS' folder instead of the 'A:' / 'B:' drives? Stuff on the SD card has an additional crypto layer that is only removed on 'A:' / 'B:'. Also - did we have a fire drill a few hours ago?Didn't figure it out. I'll try again, I'll admit that when I found the problem, I'm not sure if I'd booted the titles yet. The ones I've tried work fine. I'll see if I can test it later.
Never - flash memory such as the NAND memory (and SD cards, too) has a limited number of writing cycles. Go over that, and it's game over for at least the part of flash you have written to. Yes, NAND is made for writing, but I do so only for one time stuff (essential.exefs, aeskeydb.bin). A config on the other hand can be frequently changed. Besides, the problem is not where to put it, it's that a config file would make it somewhat impossible to run GM9 without leaving something behind.Maybe use NAND sectors again ?
Ah, like SSD. I forgot that.Never - flash memory such as the NAND memory (and SD cards, too) has a limited number of writing cycles. Go over that, and it's game over for at least the part of flash you have written to. Yes, NAND is made for writing, but I do so only for one time stuff (essential.exefs, aeskeydb.bin). A config on the other hand can be frequently changed. Besides, the problem is not where to put it, it's that a config file would make it somewhat impossible to run GM9 without leaving something behind.
Right now you can still run GM9 without leaving any traces on the system. A config file would change that.Ah, like SSD. I forgot that.
Something behind ? What's that?