#67262 - linus - Mon Jan 16, 2006 4:44 pm
How would i go about accessing the internal cpu registers (r0 etc) in C? Sorry if this has been covered i couldnt find it anywhere.
Cheers
Last edited by linus on Tue Jan 17, 2006 5:45 pm; edited 1 time in total
#67281 - juhees - Mon Jan 16, 2006 6:37 pm
| linus wrote: |
How would i go about accessing the internal cpu registers (r0 etc) in C? Sorry if this has been covered i couldnt find it anywhere.
Cheers |
You can't. If you want to have access to the registers, you have to use Assembler. Why would you want to read the registers?
#67283 - linus - Mon Jan 16, 2006 6:43 pm
ok didnt know that. im trying to see what values are in the registers when i start a homebrew app from the supercard, so i can possibly see how the restart mechanism works. this may not be possible, i dont know - the main reason im doing it is for experience.
#67286 - tepples - Mon Jan 16, 2006 6:53 pm
Then you'll probably have to customize the startup code on each CPU to dump all registers to an array before it does anything else.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#67328 - linus - Tue Jan 17, 2006 1:35 am
Ah ok so i would need to change the default arm7 and arm9 bins generated when compiling stuff using libnds? - thats probably above my skill level but just for experiences sake how would i copy the stuff to an array?
#67335 - Joat - Tue Jan 17, 2006 2:21 am
You'd replace the crt0 for the arm7 and arm9 with code that copies the registers somewhere safe, before doing the rest of the crt0 setup, and then in your C code, you'd write or display them somewhere. You'll need the source of libnds (anon CVS should do you), which will provide you with the crtls and the build scripts for them. You need to copy the arm7, arm9 .s (crt0 code you'll need to mod) and .spec files for them, then modify the .spec to point to the new .s'es, and in your project makefile, change the line that references a .spec file to refer to your new ones.
It'd probably be a lot easier to disassemble the supercard menu and see what it does with respect to initialization.
Either way, if you don't know any assembly, now is as good a time to learn as any :)
_________________
Joat
http://www.bottledlight.com
#67359 - linus - Tue Jan 17, 2006 12:06 pm
heh well ive done a bit of 68k assembly which helps quite a lot cos i can read other peoples stuff. It doesnt sound to bad. I would dissassemble but i dont really know how and i think the firmware is XOR enrypted, some people over at scdev.org deccrypted it - but i dont know how to do that yet. I think there was 3 different keys or something silly - i may just ask them.
urm just recap if i get my assembly to dump the values to a memory location is all i have to do just read that location in my C program that prints them.
oh and how do i dissassemble a bin is there a good tool?
cheers for this guys it all helps
#67363 - pepsiman - Tue Jan 17, 2006 1:41 pm
| Joat wrote: |
| You'd replace the crt0 for the arm7 and arm9 with code that copies the registers somewhere safe. |
That's too late for arm7, the nds loader has already overwritten the registers.
#67377 - linus - Tue Jan 17, 2006 5:44 pm
ok well, if im really gonna try this i think i need some more info. in my wonderful land of ignorance i would think all you have to do to start a new program is reset the program counter for the arm7 and arm9 to the start address of the new program. the reset function for for the mp is
| Code: |
*((vu32*)0x027FFFFC) = FileCluster; // Start cluster of NDS to load
*((vu32*)0x027FFE04) = (u32)0xE59FF018; // ldr pc, 0x027FFE24
*((vu32*)0x027FFE24) = (u32)0x027FFE04; // Set ARM9 Loop address
swiSoftReset(); // Reset
|
here it looks like the start cluster is going somewhere i dont know, the pc counter is getting a random address i dont know. then theres an arm9 loop - errr what does that do? and then the reset is being called, which i assume resets all the interrupts :S?
as you can see there is much i dont understand. if anyone can explain to me why just reseting the pc doesnt do it that would be great :) - i know i ask a lot, but one day hopefully i can help out somehow :)
#67430 - chishm - Tue Jan 17, 2006 11:46 pm
That's actually used to call the GBAMP's built in loader. The file cluster tells the loader what file to load. The "ldr pc,0x027FFE24 " instruction gets the CPU to keep reading the value at that address and jump to it. The ARM9 loop address tells it to keep jumping back to the ldr instruction, effectively placing it in an infinite loop waiting for the address to change. Finally, the swiSoftReset calls a BIOS function that returns the CPU to it's boot state.
There is code on the ARM7 as well. It basically resets the ARM7 and jumps to 0x080000c0 when the ARM9 sets up the infinite loop.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#67432 - linus - Wed Jan 18, 2006 12:09 am
sorry if this is obvious but what changes 0x027FFE24 to the cluster address, i assume its some part of the gbamp - does that mean its always polling 0x027FFFFC to check for changes? - that seems a bit crazy to me.
this is getting a bit complicated for me but ill stick with it, in the mean time im having great fun with your fat driver chishm!
urm what does a CPU state entail :S
#67435 - chishm - Wed Jan 18, 2006 12:41 am
0x027FFE24 actually gets changed to the start address of the ARM9 binary, after the ARM7 has finished loading it. This makes the game start. The ARM7 loads the file according to the value at 0x027FFFFC. This is done by the GBAMP firmware when it is first booted and when it is called as stated above.
So the GBAMP doesn't keep polling the value at 0x027FFFC for changes, although the ARM7 binary in the menu (like moonshell) will poll 0x027FFE24 for changes, and act accordingly.
A CPU state is just what mode it is in, what flags are set, and what values are in its registers.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#67452 - HyperHacker - Wed Jan 18, 2006 6:20 am
Heh, I was just about to ask about this... this memory map shows nothing mapped to 0x02400000-0x03000000... is this just a mistake? I noticed in ndslib in ipc.h, the IPC struct is located in that range (at 0x027FF000), is this some special area designed for IPC or just general memory? I mainly ask because I want to replace it with my own IPC struct with more info, but I'm not sure if it's safe.
#67454 - chishm - Wed Jan 18, 2006 6:30 am
0x02400000-0x02800000 is an uncached mirror of 0x02000000-0x02400000.
What this means is it will contain the exact same data (it is the same memory), but the CPU will always read and write it, instead of using its own internal copy.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com