It is currently Tue Jul 16, 2019 5:37 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 68 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
PostPosted: Sun Jun 23, 2019 2:58 pm 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
PSI wrote:
Indeed they do. The XDMA functions take a set of parameters and then create the bytecode based upon those parameters.
Oops, okay, I'll need to look closer (I had looked only for "pre-compiled" code blocks, not for on-the-fly generated code).
Apropos: bytecode. ARM11 could also support "Jazelle" bytecode (additionally to ARM/THUMB/THUMB2). I forgot to ask if 3DS is supporting that Jazelle stuff... does it?

PSI wrote:
Something I found completely mystifying is that when decrypting the FIRM, Boot9 sets two NDMA channels to mode 15 (eMMC->AES, AES->SHA). I use a hackish method to handle this, but I don't know how exactly these channels are supposed to be triggered.

Ah, yes, looks as if they are both running in parallel with the same startup mode. To some level that might work if AES is so fast that AES->SHA can be started immediately after eMMC->AES. But that would work only if some priority/ordering stuff would ensure eMMC->AES to be executed first, but the bootrom code is doing it excactly the other way around (starting AES->SHA before eMMC->AES (unless I've missed something that might be manually transferring the first block elsewhere)).

How about this: Bit0-9 in NDMAxCNT registers were unused on DSi. But on 3DS, Bit0-4 are R/W (bit5-9 seem to be always 0). The bootrom is using bit3 and bit4 as so:
Code:
eMMC-->AES with startup=0Fh and bit3=1
AES-->SHA with startup=0Fh and bit4=1
I guess that explains how to distinguish between the two channels with same startup mode. I don't know what the bits are doing exactly though. Maybe some extra startup-condition flags? Or a whole set of further startup modes? Possibly used only when bit24-27 are set to 0Fh? Or whatever generic priority/order settings?

With some luck, there might be also a SDIO Wifi startup mode hidden in bit0-4, for use with my ARM9 wifi code : )

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Tue Jun 25, 2019 5:29 am 
Offline

Joined: Sun May 19, 2019 7:01 am
Posts: 3
re: NDMA startup bits

probably, yeah. I guess this mechanism also allows to easily implement DSi compatibility (by simply disabling/masking out the extra bits). as in DSi mode, neither SD/MMC nor AES would be mapped to the ARM9.


Top
 Profile  
 
PostPosted: Wed Jul 10, 2019 5:34 pm 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
Released wifiboot v2.6 and no$gba v2.9e
http://problemkaputt.de/wifiboot.htm
http://problemkaputt.de/gba.htm
The main news is allowing to upload 3DS .firm files from no$gba utility menu to 3DS consoles.

That is my first 3DS program : )
And it's even a useful one... at least for people whom are coding .firm files.
Which is probably meaning useful to 3-5 people, but anyways.

I've posted that in the wifi thread, too. See there: viewtopic.php?f=23&t=18065&p=240698 for release notes, and some new extra details on the 3DS (and DSi) wifi firmwares.

fastboot
Uploading fastboot via wifi seems to work fine. Maybe that can be useful for testing new fastboot versions.
The first & last fastboot options seem to hang though (continue booting & credits).
What is continue booting supposed to do? Continue where from, and where to?
In the fastboot filemenu I can see lots of eMMC folders, but don't know if there are any bootable files in any of the folders. Is it possible to boot the GBA/DSi firms? Or would that require further code (for selecting a GBA rom-image, or DSiware title before startingt the gba/nds firm).
It would be nice to be able to boot the 3DS native firm, either from firm1 partition, or from the firm folder (or is continue booting supposed to do that)?

profi200 wrote:
Pressing the power button will do nothing but trigger the MCU interrupt notifying the running OS. When you hold it for at least 3 seconds it will force poweroff after another ~7 seconds.
Yes, seems to work like that. But holding 3 seconds is a bit risky in practice (if you hold only 2.99 seconds then you can wait until your face turns blue and then start all over again), so it's better to try to hold 5 seconds.
I've meanwhile also added code for reading the button state via I2C bus from MCU, allow to power-off by tapping the power button. It's working - almost.

The nasty thing is that one must tap for at least 0.25 seconds or so, and, there seems to be a delayed power-led fade-out effect. It's just enough time that you can turn away without ever knowing if you have really successfully switched off the console, unless you take the time to control the result 1-2 seconds later.
I am normally not the kind of person who is returning home several times to double-check if the lights were really turned off. But this nasty nag-nag-nagging nag-nag-nintendo power button is driving me crazy : [ ; /

Reading between the lines on the I2C register page on 3dbrew, it sounds as if it were possible to dump & disassemble the MCU firmware? Is that right? And is it also possible to install a patched MCU firmware?

If yes, then one could adjust the power button tapping delay. I guess that would be the only way to get the undelayed button state (when displaying the MCU registers, there seem to be no bits getting toggled when pressing the button, unless it's pressed & held for about 0.25s).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu Jul 11, 2019 2:08 pm 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 9
Regarding NDMA startup modes: I did a few tests and and these new bits seem to be totally different startup modes probably primarily for device<-->device transfers. Initially i thought maybe they map 1:1 to the regular startup modes + the immediate bit but hey are different. That's all i know.

nocash wrote:
Released wifiboot v2.6 and no$gba v2.9e
http://problemkaputt.de/wifiboot.htm
http://problemkaputt.de/gba.htm
The main news is allowing to upload 3DS .firm files from no$gba utility menu to 3DS consoles.

That's nice. But my primary problem with the code of wifiboot is it's barely useful for the remaining devs working with bare metal since it's 100% asm which is comparable with reverse engineering code (except the symbols are known here) and it's tied to your codebase. So if i wanted to code a bare metal homebrew today that uses WiFi i would look at your code and immediately forget the idea. No offense but that's probably what many will do.


nocash wrote:
fastboot
Uploading fastboot via wifi seems to work fine. Maybe that can be useful for testing new fastboot versions.
The first & last fastboot options seem to hang though (continue booting & credits).
What is continue booting supposed to do? Continue where from, and where to?
In the fastboot filemenu I can see lots of eMMC folders, but don't know if there are any bootable files in any of the folders. Is it possible to boot the GBA/DSi firms? Or would that require further code (for selecting a GBA rom-image, or DSiware title before startingt the gba/nds firm).
It would be nice to be able to boot the 3DS native firm, either from firm1 partition, or from the firm folder (or is continue booting supposed to do that)?

It should not hang at all. Since it's working with every other known chainloader i'ts likely a bug on your end. Do you properly disable and flush caches before jumping to the FIRM entrypoints? Especially the ARM11 needs this since it apparently still has icache hits even after the icache is disabled(?). At least it behaves strangely if you don't do proper cache maintenance which i have seen many times in the past.

Continue is exactly what it says. If the bootloader got interrupted by holding HOME to show the menu it will continue booting the boot slot it would have booted without holding HOME. It will boot nothing by default. You need to configure the boot slots. And it can't boot anything but FIRM files (it can also boot from the second FIRM partition (firm1) but his is not normally enabled to protect noobs (hint: A special key combo on the credits screen)). As said GBA and DS(i) mode has not been looked into much and there is no known open source implementation of AGB/TWL_FIRM.

nocash wrote:
Yes, seems to work like that. But holding 3 seconds is a bit risky in practice (if you hold only 2.99 seconds then you can wait until your face turns blue and then start all over again), so it's better to try to hold 5 seconds.
I've meanwhile also added code for reading the button state via I2C bus from MCU, allow to power-off by tapping the power button. It's working - almost.

I don't understand your problem? Hold the button, slowly count up to 3 and done? Works 95% here.

nocash wrote:
The nasty thing is that one must tap for at least 0.25 seconds or so, and, there seems to be a delayed power-led fade-out effect. It's just enough time that you can turn away without ever knowing if you have really successfully switched off the console, unless you take the time to control the result 1-2 seconds later.
I am normally not the kind of person who is returning home several times to double-check if the lights were really turned off. But this nasty nag-nag-nagging nag-nag-nintendo power button is driving me crazy : [ ; /

???? For real i don't get it.

nocash wrote:
Reading between the lines on the I2C register page on 3dbrew, it sounds as if it were possible to dump & disassemble the MCU firmware? Is that right? And is it also possible to install a patched MCU firmware?

If yes, then one could adjust the power button tapping delay. I guess that would be the only way to get the undelayed button state (when displaying the MCU registers, there seem to be no bits getting toggled when pressing the button, unless it's pressed & held for about 0.25s).

Disclaimer: I'm not responsible if you permanently brick your 3DS. Yes IT IS THAT DANGEROUS! There are no checks whatsoever and if the firmware is bricked to the point the firmware upload fails there is no known way to recover it even externally.

MCU firmware images can be found in the MCU system module code (iirc). Upload is writing a magic value immediately followed by the entire image. I have never done it and you should neither. There is not even an emulator to test the MCU firmware. All the propritary ones are for different MCUs and not this apparently custom design (which is based on some other MCU but it's not the same!). Architecture is RL78.


Top
 Profile  
 
PostPosted: Sat Jul 13, 2019 3:21 pm 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
Fastboot 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:
for3ds_flushdisable_code_cache:
 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 ;/
 bx   lr
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.

NDMA 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.

Source code 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).

Wifiboot binary: 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).

Power button: 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?
EDIT: https://3dbrew.org/wiki/Hardware 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)).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Jul 13, 2019 5:11 pm 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 9
nocash wrote:
Fastboot 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:
for3ds_flushdisable_code_cache:
 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 ;/
 bx   lr
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.

Yeah, duh when the topscreen is broken of course it appears as if it would hang but it's displaying on the topscreen. Continue should display an error (on the topscreen) if there is no slot configured.

On ARM11 there is a bit more to do than on ARM9 because the pipeline and stuff changed: https://github.com/derrekr/fastboot3DS/ ... art.s#L226
At the beginning of that file i embedded a bit of documentation for the control register bits.

nocash wrote:
NDMA 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.

Not tested beyond what i said. The regs seem to be a bit buggy anyway. At least the CNT reg doesn't always keep the exact bits written for some reason. But i'm not sure since it was years ago i noticed this.

nocash wrote:
Source code 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).

I'm not saying you should not release your source code. Rather the opposite. The only problem is it's not compatible with any other existing code which forces us to basically "reverse engineer" your code and write our own version. And bare metal doesn't mean writing everything in asm :wink: I would go as far as saying 95% of bare metal code written after 2000 is C and a little bit of C++. You can see we have only written small parts in asm in fastboot3DS because these parts are better handled that way than a higher level language.

polarssl is not needed. We have a full implementation of all the crypto hardware in https://github.com/derrekr/fastboot3DS/ ... e/crypto.c
For AES there is even DMA support. Software AES and SHA1/256 i tried many years ago and i can tell you you don't want that (it's slower than a slug). Also on a side note SHA combined with NDMA takes twice as long as with CPU for some reason. Possibly SHA has a bug slowing down DMA.

nocash wrote:
Wifiboot binary: 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).

Not tried yet. Personally i wanted to make myself a hardware assisted FIRM uploader/debugger for a while using the SPI interface of the gamecard slot. That thing can go up to 16 MHz with the new "CARDSPI" interface and even supports "quad SPI" so it's plenty fast. CARDSPI has been fully figured out by the way and 3dbrew has been updated with all details including a little bug.

nocash wrote:
Power button: 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).

We always clear all framebuffers before turning on the screens. On poweroff we first turn off the screens because it will shutdown noticeably faster that way. The delay is there to make the screens go black before they turn off because otherwise they seem to show a bit of garbage until all pixels have reset themselfes. This is not a big deal in my opinion but derrek wanted that. It's not visible normally anyway until you shine a flashlight on the screens.

nocash wrote:
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?
EDIT: https://3dbrew.org/wiki/Hardware has two broken links for "RL78ISA" 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)).

There are some different/new hardware blocks/registers from what i heard but i never touched MCU reverse engineering. Only few ever tried to reverse engineer the MCU firmware and these people may still have these pdfs. I could not find them on a quick search.
Bricking to have a reason to throw away electronics. What a waste :roll:


Top
 Profile  
 
PostPosted: Sat Jul 13, 2019 7:28 pm 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
If somebody buys me a new new3dsXL mainboard, then you can get the old one with the broken backlight connector and protect it from getting wasted.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Tue Jul 16, 2019 2:46 am 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
profi200 wrote:
The [NDMA] regs seem to be a bit buggy anyway. At least the CNT reg doesn't always keep the exact bits written for some reason. But i'm not sure since it was years ago i noticed this.
One reason might be that NDMA registers are read-only during transfers (probably including most or all bits in NDMAxCNT register, except bit31). If there are other situations where NDMAxCNT doesn't contain the expected value... would be interesting to know when that happens (if you happen to come across the effect again).

Yes, using hardware for AES/SHA1 should work on 3DS, and it might save 2-3Kbyte code, but it's just needed for the EAPOL handshake so there's little performance gain. MD5 isn't possible via 3DS hardware (as far as I know), if you want to run wifi on ARM11 then you might also dig out your software libraries before tunneling the AES key wrap to the ARM9 hardware. Anyways, first step would be WEP or Open network, so EAPOL doesn't really matter for getting started.

profi200 wrote:
On poweroff we first turn off the screens because it will shutdown noticeably faster that way.
I am not really noticing that... the LED afterglow in fastboot looks about same as in wifiboot (but of course, the screen goes black earlier if you make it black; which is what I wanted to do in next wifiboot update, too).


RL78 SFR's: There are loads of "RL78 hardware manuals", the SFR register list is hidden in the "CPU Architecture, Processor Registers" chapter. The first hardware manual that I came across was "RL78/G13", so I spent a whole night on extracting the register list, converting it to ascii text, and then making the disassembler to display the SFR register descriptions automatically for each opcode.
The result looks more or less correct... but there are some differences: There can be 16 ports (0..15), but RL78/G13 doesn't have all of the corresponding registers defined (and 3DS uses some of the missing ones). And worse, there are registers at FFF3Ch, FFF9Fh, FFFBEh, FFFC0h, FFFC4h, F0017h, F00C0h, F00C4h, F00F2h, F0501h, F0510h-F0512h, F0538h, F0540h-F0542h, F0550h-F0554h, which don't match with RL78/G13 at all.

Searching for FFF3Ch, there are datasheets with various conflicting meanings:
Code:
  FFF3CH Multiplication data register B(L)
  FFF3CH Serial communication pin select register 0
  FFF3CH D/A conversion value setting register
  FFF3CH Input switch control register
Some datasheets have various registers moved to completely different addresses, looks as if I was lucky with RL78/G13, as it does appear to match up (roughly) with 3DS.
The 78K0R/K C3-L E3-L datasheet looks even more promising, as it's containing most of the unknown SFRs (and, btw, has different meaning for FFF90h, and lacks Timers 10-17 and lacks IICA 1 (aka 2nd I2C registers), and has ADPC moved to F0017h, which does all seem to match up with 3DS MCU firmware (it does have a lot of extra registers at F0540h and up, that part doesn't seem to exist on 3DS, fortunately)).

The 3DS special area is a F0501h..F0554h, which doesn't seem to match any datasheets. Of those, F0540h-F0554h appear to be simply the missing 2nd I2C port registers; and the other ones might be also standard registers moved that addresses...?

Comparing all those SFR lists & searching for subtle differences can be terrorizing. But I hope that I do now known the most probable meanings of most SFRs, so I can start with the actual MCU code disassembly.

_________________
homepage - patreon


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 68 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group