#151309 - sowee - Sat Feb 23, 2008 6:35 am
Hello, a program i'm testing currently works on Acekard RPG, M3DS Real, and even slot-2 Supercards. What i don't understand is why it doesn't seem to work on an M3DS Simply, and i'm assuming it also won't work on an R4. I tried dldi patching the binary, because i used libfat fopen and fread methods, but it still hangs up.
#151322 - Jesse - Sat Feb 23, 2008 11:20 am
One tip is to make sure you program is _not_ patched when trying to run them on M3S/R4. Some auto-patching cards have trouble with programs prepatched for other cards.
Also, it's been pointed out that M3S/R4 loaders doesn't clear the memory before launching apps, so make sure you are not using any uninitialized variables.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena
#151327 - Cydrak - Sat Feb 23, 2008 1:52 pm
It's not just RAM... watch out for hardware state. x_@
I make rather heavy use of the IPC. It worked great on my SCLite, but on my friend's M3CF, the message queue had a coronary! Some investigation turned up the apparent cause: data sitting in the FIFO, which I didn't put there. :|
How about an older one: I usually test over wifi. After moving some graphics around, I noticed a garbage layer that wouldn't go away. Quite odd, since I had most blending and BGs disabled. Turned out my downloader didn't clear the VRAM settings--nor did I, so the code blissfully put C right over bank H.
#151347 - simonjhall - Sat Feb 23, 2008 11:12 pm
I've noticed that flash cards seems to initialise the system differently. I've found that on some M3 simplys/R4s (could be firmware version thing) that the FIFO doesn't get set up the same as other cards.
Sticking | Code: |
| REG_IPC_FIFO_CR = IPC_FIFO_ENABLE | IPC_FIFO_SEND_CLEAR; |
at the top of my ARM7 main sorted my baby out.
But yeah there are lots of tiny differences between the flash cards which are super annoying. Luckily now most of these problems have gone away. There are lots of differences between the RAM interface of the slot-2 cards, though.
_________________
Big thanks to everyone who donated for Quake2
#151348 - Cydrak - Sat Feb 23, 2008 11:33 pm
Maybe there's something else I missed... but I had the SEND_CLEAR and it didn't seem to be enough for me. Hard to tell--I don't have access to the card in question. Word-of-mouth debugging. :-)
The solution I ended up with, has me clearing both the send and receive (by SEND_CLEAR, then a FIFO_RX loop), with some syncs to avoid races.
(For maximal hilarity, the RX before TX then gave me problems (endless incoming zeroes) on NO$GBA. So now I kick a single TX through beforehand. Only time and testing will tell if that holds up!)
#151353 - sowee - Sun Feb 24, 2008 2:11 am
Thanks for the tips :D, my program also uses the IPC, although i already have REG_IPC_FIFO_CR = IPC_FIFO_ENABLE | IPC_FIFO_SEND_CLEAR | IPC_FIFO_RECV_IRQ as part of the arm7 main, still checking for what the cause might be, i hope its just some variable i forgot to initialize hehe
#151364 - silent_code - Sun Feb 24, 2008 4:22 pm
it would be nice to have a function like "clear Hardware(void)" that sets the nds in a known and documented state. is there anything like this in libnds (obviously not, ain't it)?
#151373 - tepples - Sun Feb 24, 2008 8:37 pm
| silent_code wrote: |
| it would be nice to have a function like "clear Hardware(void)" that sets the nds in a known and documented state. |
The GBA BIOS had RegisterRamReset(). I can guess that the only reason this was taken out of the DS ARM7 BIOS and DS ARM9 BIOS was to make life more difficult for homebrewers.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#151377 - HyperHacker - Sun Feb 24, 2008 9:26 pm
Or because they decided it wouldn't be necessary and the space would be better used for other functions.
_________________
I'm a PSP hacker now, but I still <3 DS.
#151482 - silent_code - Wed Feb 27, 2008 6:26 pm
<OFFTOPIC>or they were like: "oh, how can we make it print even *MORE* money?"</OT> <goofy/>
well, there sould be something like that in libnds. at least i've made a note on my todo list for my basecode. i'll post it, once i gather enough info about *everything* hw reset related (that should take a while and hopefully someone else will have done that already by the time i get along to it! ;^p )
#151487 - Cydrak - Wed Feb 27, 2008 7:38 pm
I noticed an attempt in CVS:
initSystem.c (r1.5)
I think it's called from the crt0... of course, there is more to clear, but those are the basic things. There's stuff like irqInit() and glInit(), too. And sound doesn't need much help. In my case I have modules handling things on a higher level anyway (sound, power, rtc, fifo, efs, sram, etc). But those go beyond libnds, so it could be seen as an question of time and scope...
The BIOSes seem to have at least half a KB free. However, putting the init in firmware (and/or libs) was probably more flexible. Haven't we seen this with wifi and power chipsets already?
#151493 - Noda - Wed Feb 27, 2008 9:43 pm
Does anyone is aware of some special problems with G6/M3 real cards? because a lot of users are complaining that my homebrew stick on the fat init function on these cards :/ (no dldi patch is applied by default to the binary)