I guess that P9 is the firmware's ARM9 code... Hmm, oddly, they are using value 7 as slowest setting in bit24-26 (so values 5 and 6 would be reserved, and 7 being the "offically used" setting for slow clocks) (then on the other hand, I would bet that their hardware designer had intended value 0..5 to be used). The 2Ch in the timeout field is funny, I could see a reason for setting bit5 (to not discard old error bits), but it makes no sense when not even having timeout checks enabled in bit6. Looks like a bug. Unless the old 3DS registers did work differently than my New3DS hardware.profi200 wrote: ↑Sat Mar 14, 2020 5:31 amI looked at P9 (and i really don't like looking at P9 code since it's just disgusting). For ROM read it looks like it's using a faster clock than what i use.
The final CNT value seems to be 0xD104822C. I'm not sure if this was choosen because of data corruption (another long standing issue) or just copy & paste. And not sure if this is actually clock or just a delay.
Going by my comparision of 4-byte reads and 2000h-byte reads, bit24-26 are definetly behaving like a per-byte-clock selection.
The bits don't control a delay before or between data blocks. For those delays it would be interesting if sixteen 200h-byte reads are slower than one 16x200h-byte read (with sixteen blocks selected in CTRCARD_BLKCNT). Quite possible that the latter is faster when reading from sequential addresses.
Thanks, it's been 10 years since I looked at ARM9 specs. I was a bit surprised when realizing that ARM11 could use code cache without PU/MMU (and then I had assumed that ARM9 could do the same). Okay, I've now enabled the PU with a large 4GB dummy region that enables code cache everywhere... and my ARM9 code is now running much faster : )
Yeah, data cache could be nice, but it would require more originazation of what is cached, and what isn't. For my hacky hardware tests, it's more important to be able to access stuff in uncached memory from either CPU. And data caching isn't so important for ASM code anyways (where all critical code is using cpu registers instead of variables).
Mostly common sense: If the power on function is executed after card insert detection, then the power cannot be switched on before card insert detection.
The card VCC pin is switched on (or otherwise, pulled low) by the two transistors seen at the bottom of larger snippet in middle/right of this picture: http://problemkaputt.de/twl-core.jpg (ie. card VCC can be switched by software, it isn't just directly wired to supply VCC, I haven't tested which of the two steps in the power on function is activating VCC though).
That is potentially the only relevant delay (might be needed if a card needs to "boot up" before accepting commands, but I wouldn't spend 270ms on waiting for such crap, too). On the DSi, it was "only" 120ms. But knowing Nintendo, it does make perfect sense that they think that newer hardware must use better and more powerful delays ; )