#89247 - loading - Fri Jun 23, 2006 7:44 pm
i am working on a project which relyes on m3 ram (and quite heavily) so i have like 4+ mb in m3 ram and now i want to write that to the flashcard. copying the first 2mb to ds ram works quite nicely and writing to my sdcard works fine too. for the first 2mb if i continue reading from m3 ram its empty.
do you have to lock m3 ram before writing or something? if so how to do it?
#89264 - agentq - Fri Jun 23, 2006 9:58 pm
I would imagine that writing to the SD card is disabling the M3's internal RAM, since it is mapped into the same area of the ARM9's address space.
Beyond that, I haven't a clue.
#89283 - josath - Sat Jun 24, 2006 12:11 am
perhaps try writing it in chunks:
1. copy 1MB from M3RAM to DSRAM
2. switch M3 to SD mode (RAM disabled)
3. write 1MB from DSRAM to SD
4. switch M3 to RAM mode (SD disabled)
Repeat 1-4 until all data is copied (while showing a progress bar or something onscreen)
My guess is the same as agentq: when SD mode is enabled, it intereferes with access to the M3RAM.
#89335 - loading - Sat Jun 24, 2006 9:38 am
| Code: |
bool FatWrite(char *name)
{
FAT_FILE* fp;
FAT_InitFiles();
fp=FAT_fopen(name, "wb+");
FAT_fseek(fp, 0, SEEK_END);
FAT_fwrite(GBA_DATA, 4, GBA_SIZE, fp);
FAT_fclose(fp);
FAT_FreeFiles();
return true;
}
void readGba(u32 data[]) {
int i;
for(i=0; i<GBA_SIZE; i++)
{
GBA_DATA[i] = data[i]; //GBA_DATA is stuff in ds mainram
}
}
...
readGba(GBA_ROM2);
if(!FatWrite("data1.bin"))
iprintf("write 1 failed\n");
iprintf("write part 2\n");
readGba(GBA_ROM);
if(!FatWrite("data2.bin"))
iprintf("write 2 failed\n");
iprintf("done!\n");
...
|
basically this is what i do?
result is data1.bin is fine data2.bin is all zero
[edit] hmm i am getting closer thanks to your hint: running the m3 unlock sequence after the first fat write allows me to access the data again - after that the 2nd fat write does not work anymore (does not write anything) though.
#89355 - Snowy? - Sat Jun 24, 2006 2:24 pm
okay don't shoot me because I understand very little here but googling I found this:
| Quote: |
+FAT_FreeFiles
+Closes all open files then resets the CF card.
+Call this before exiting back to the GBAMP
+bool return OUT: true if successful. |
Is this the same function/lib your using??? Would explain whats happening no?
http://stuartp.commixus.com/nhds/nethack-nds.diff
| Code: |
+bool FAT_FreeFiles (void)
+{
+ int i;
+
+ // Close all open files
+ for (i=0; i < MAX_FILES_OPEN; i++)
+ {
+ if (openFiles[i].inUse == true)
+ {
+ FAT_fclose(&openFiles[i]);
+ }
+ }
+
+ // Flush any sectors in disc cache
+ disc_CacheFlush();
+
+ // Clear card status
+ disc_ClearStatus();
+
+ // Return status of card
+ return disc_IsInserted();
+}
+
+ |
#89397 - loading - Sat Jun 24, 2006 6:18 pm
i got it working by commenting out these lines in disc_init (disc_io.h)
| Code: |
...
if (active_interface != 0) {
return true;
}
...
|
looks like it thought the disc was still active even though running the sequence to be able to acces the m3 ram again disabled the sd access.
maybe setting active_interface=0 in FAT_FreeFiles would be a more elegant solution but i did not try that yet.
thank you guys.
#89702 - pepsiman - Mon Jun 26, 2006 11:39 am
| loading wrote: |
| looks like it thought the disc was still active even though running the sequence to be able to acces the m3 ram again disabled the sd access. |
What is this sequence?
#89758 - loading - Mon Jun 26, 2006 4:50 pm
the normal m3 unlock sequence (with or without write enable does not matter)
what i did was
fat init
fat write file 1
fat free files
m3 unlock (otherwise i read all zero from m3 ram after fat init)
read 0x08000000
read 0x08000002
read 0x0800000E
read 0x08001FFC
read 0x0800104A
read 0x08000612
read 0x08000000
read 0x08001B66
read 0x08000006
read 0x08000000
now after this sequence trying to run
fat init
fails, because read sector returns all zero
but it works again with the the active interface check disabled.
(not calling fat free files before the unlock sequence and then fat_fopen will always return a null pointer)
#89761 - Mighty Max - Mon Jun 26, 2006 5:06 pm
You should think about resetting the mode you left instead of modifying the driver.
_________________
GBAMP Multiboot
#89828 - pepsiman - Mon Jun 26, 2006 8:57 pm
I'm trying to better understand the M3 control sequences.
The NDSTech Wiki (http://www.bottledlight.com/ds/index.php/Hardware/FlashCartridges) has this sequence to map the CF/SD registers into GBA ROM space:
read 0x08000000
read 0x08000002
read 0x0800000E
read 0x08001FFC
read 0x0800104A
read 0x08000612
read 0x08000000
read 0x08001B66
read 0x08000006
read 0x08000000
Chishm's lib and DSLinux have this sequence to map the CF/SD registers into GBA ROM space:
read 0x08000000
read 0x08E00002
read 0x0800000E
read 0x08801FFC
read 0x0800104A
read 0x08800612
read 0x08000000
read 0x08801B66
read 0x08800006
read 0x08000000
You've just come up with this sequence, which matches the NDSTech wiki:
| loading wrote: |
read 0x08000000
read 0x08000002
read 0x0800000E
read 0x08001FFC
read 0x0800104A
read 0x08000612
read 0x08000000
read 0x08001B66
read 0x08000006
read 0x08000000 |
I'll call these sequences E8888 and 00000.
The E8888 sequence maps the CF/SD registers into GBA ROM space.
Does the 00000 sequence map the M3 RAM back into GBA ROM space?
Or something else?
Do you know any other sequences?
There should also be a sequence to bank switch the SRAM, which I haven't seen anywhere.
#89908 - chishm - Tue Jun 27, 2006 8:31 am
I got this function from the M3 SD's firmware:
| Code: |
static u16 M3_readHalfword (u32 addr) {
return *((vu16*)addr);
}
void M3_changeMode (u32 mode) {
M3_readHalfword (0x08e00002);
M3_readHalfword (0x0800000e);
M3_readHalfword (0x08801ffc);
M3_readHalfword (0x0800104a);
M3_readHalfword (0x08800612);
M3_readHalfword (0x08000000);
M3_readHalfword (0x08801b66);
M3_readHalfword (0x08000000 + (mode << 1));
M3_readHalfword (0x0800080e);
M3_readHalfword (0x08000000);
if ((mode & 0x0f) != 4) {
M3_readHalfword (0x09000000);
} else {
M3_readHalfword (0x080001e4);
M3_readHalfword (0x080001e4);
M3_readHalfword (0x08000188);
M3_readHalfword (0x08000188);
}
}
// Values for changing mode
#define M3_MODE_ROM 0x00400004
#define M3_MODE_MEDIA 0x00400003 |
I assume M3_MODE_ROM switches to the M3's firmware, since the M3 uses this constant before loading the main part of the firmware.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com