credits hangs, but it recovers when pressing B button. I assume that it is displaying something on the top screen during the hang? (which could be seen only when having working top screen backlight connector).
Continue booting just hangs. I didn't press HOME at all, but yes, I haven't selected anything, so if it is supposed to boot nothing by default, then the hang might just be the intended effect. For the caches, I am doing this on ARM9 and ARM11 before booting the uploaded .firm file:
Code: Select all
mov r0,p15,0,c1,c0,0 ;\
bic r0,1 shl 12 ;code cache ;
mov p15,0,c1,c0,0,r0 ;/
mov r0,0 ;\
mov p15,0,c7,c5,0,r0 ;=0 ;Invalidate Entire Instruction Cache ;/
I hope that is properly disabling the 3ds code caches? For the data caches, I didn't even try to enable them yet since that would require setting up PU on ARM9, and MMU on ARM11.
registers SAD/DAD/TCNT/WCNT are having a weird effect: They "fail" when doing a R/W test on the I/O area (making it appear as if the registers were read-only, even when the DMA was stopped, but that can't be true).
That odd effect is caused by NDMAGNT.bit0=1, but it works as normal (=as on DSi) when clearing that bit. The bit affects "SAD/DAD/TCNT/WCNT register reading (0=Return written value, 1=Return current value)".
The written values are the "start/reload" values that remain unchanged during/after transfer. The current values are internal registers that get (re-)loaded at transfer start, and increase/decrease during transfer.
I am familar with people saying that I am a non-free coder when not releasing my source code, this was the first time that somebody had objections when I did
release the sources. The difference between bare metal and 100% asm is also new to me. You got me pretty shaken up emotionally yesterday ; )
With my source code with labels & gbatek dsi wifi specs, it might take 1-2 weeks to implement wifi. Without that, I don't know, it took me about 3 years to figure out how to use the sdio stuff, but maybe the workforce of the 3ds community could do it in less time.
Anyways - if there are really those remaining devs that want to use wifi - I could answer questions, and I can also add some comments about the source code structure...
The 3DS related stuff is marked as "target_3ds" (which should be a non-issue), the SDIO stuff is marked "with_dsi_wifi" (that's also pretty simple when knowing how to use which BMI and WMI commands; but it's getting a bit more complex because WPA/WPA2 EAPOL packets must be handled manually, but that's all documented in gbatek).
The source is organized in chapters with ;: markers (eg. load wificore.a22 in No$gba -> Utility -> Edit File, then press F6+C to see what I mean. If they really want to do C coding then they could use existing code for TCP/UDP/ARP/DHCP stuff (eg. use the dswifi arm9 code, or something else), and it appears to be common to use polarssl for MD5/SHA1/AES in dsi/3ds in scene, ie. they could just ignore more than 80% of my asm code. But my best recommendation would be to port their codebase to asm. NDS wifi is marked as "with_nds_wifi" one could omit that on 3DS (and DSi).
Did somebody test the wifiboot.firm file on 3DS? It would be interesting if it's working over there, too, especially the WPA/WPA2 part (in the 3DS version, I've currently tested WEP only).
Of course, feedback on DSi wifiboot would be also nice, ie. feedback if it's working with other access points (other than the ones that I had used at home).
Part of the problem is that it's not just the LED refusing to go off immediatly, it's also the whole screen keeping to display a picture a while after power off. As workaround, I'll clear the framebuffer (or better disable backlights) before power-off, so the user gets some sense that the button was tapped long enough.
Ah, I just noticed that fastboot is using that trick, too. So I guess somebody there must have been struggling with the unresponsive button, too.
Hmmm, for a reboot without power-off, I should probably go into using the HOME button; assuming that it is sorts of intended for such purposes (*). The person who had donated the 3DS said the HOME button was a bit worn out... but it seems to be still working (in a more responsive way than the power button).
(*) as far as I remeber it does bring up a japanese message box (so I am still scared about fiddling with that button).
Architecture is RL78.
Thanks, that's very useful to know! Alright, I've written a disassembler for it yesterday, and found an old message from somebody mentioning where to find the code block in the MCU .app files. The disassembly looks okay... except, there seem to be 1000h bytes missing in the middle of the code block (or is it two blocks?), the reset vector is fine, but the other exception vectors point to 4Axxh (whilst the actual handlers show up at 3Axxh).
The "custom design" thing is for the SFR hardware registers & things like I2C and GPIO bits? Is that part of the hardware already rev-engineered & documented on 3dbrew, or elsewhere?
has two broken links for "RL78 ISA" and "RL78 hardware manual (registers)" are that docs still available somewhere?
If I can brick the console via MCU writes, that might be a nice way to get rid of it ; ) especially as the upper backlight is already broken anyways.
Btw. if somebody wants to donate
a 3DS-console (or New3DS.XL-mainboard with intact top-screen connector): I would be very interested in both (two or three games would be also nice to get an idea about what the console is good for).
Doing rev-engineering with lower-screen-only is possible - but the viewing angle is terrible (I have put the console onto a cardboard box on the floor so I can see something; but with working top-screen I could just have it located in front of me on the table
(and it might also become easier to reach for the power button that way)).