Views: 6,693,298 | Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 03-28-24 08:10 AM |
Guest: |
0 users reading GBAtek addendum/errata | 1 bot |
Main - Development - GBAtek addendum/errata | Hide post layouts | New reply |
Arisotura |
| ||
Big fire melon magical melon girl Level: 55 Posts: 801/875 EXP: 1308871 Next: 5318 Since: 03-28-17 From: France Last post: 36 days ago Last view: 8 days ago |
I'm letting the DSi discharge, while running a test program that keeps track of change in the battery register
so far: when charging: 8F full -> empty: 0F 0B 07 03 (light red) 01 (light red, blinking) so bit0 = not-critical bit? bit1 = 'power good' bit, in the sense of the old DS bit2-3: level from 0 to 3 ---- DSi BPTWL Battery Level register and DS Powerman Battery Status 0F, 0B, 07 (full, three bars, two bars) = 0 (okay) 03, 01 (one red bar, one flashing red bar) = 1 (low) ____________________ Kuribo64 |
Rayyan |
| ||
Big melon Administrator Level: 29 Posts: 208/237 EXP: 135143 Next: 12742 Since: 06-25-20 From: UK Last post: 288 days ago Last view: 9 hours ago |
GBATEK seems to have info on this: 0x20 1 Battery flags. When zero the battery is at critical level, arm7 does a shutdown. Bit7 is set when the battery is charging. Battery levels in the low 4-bits: battery icon bars full 0xF, 3 bars 0xB, 2 bars 0x7, one solid red bar 0x3, and one blinking red bar 0x1. When plugging in or removing recharge cord, this value increases/decreases between the real battery level and 0xF, thus the battery level while bit7 is set is useless. ____________________
How to write an emulator
1. throw code to be emulated somewhere 2. make memory system that allows accessing that code 3. emulate CPU 4. have fun implementing all the other hardware -- Arisotura, Tuesday 5th January 2021, 22:00:17 |
Generic aka RSDuck |
| ||
Big fire melon Administrator Level: 44 Posts: 508/589 EXP: 576890 Next: 34395 Since: 10-12-19 Last post: 47 days ago Last view: 9 days ago |
DSlite specific registers, provided by Gericom:
#pragma once //As far as I know these registers should only exist on a DSLite //On boot, the firmware writes 0xFFFF to REG_REGCNT, locking both //reading and writing of the registers below, and making them //impossible to be used (since REG_REGCNT is write-once) //In order to prevent this flashme can be used. When the direct-boot //keycombo A+B+START+SELECT is held while booting the lock write //will not happen, and as such the registers remain usable //Lockout register for nitro2 features, WRITE-ONLY and WRITE-ONCE!! #define REG_REGCNT (*(vu16*)0x04001080) #define REGCNT_WE0 (1 << 0) //disables writing to REG_DISPCNT2 #define REGCNT_WE1 (1 << 1) //disables writing to REG_DISPSW #define REGCNT_WE2 (1 << 2) //disables writing to REG_CLK11M #define REGCNT_RE0 (1 << 8) //disables reading from REG_DISPCNT2 #define REGCNT_RE1 (1 << 9) //disables reading from REG_DISPSW #define REGCNT_RE2 (1 << 10) //disables reading from REG_CLK11M //Selects dual or single screen mode #define REG_DISPCNT2 (*(vu16*)0x04001090) #define DISPCNT2_MOD_DUAL_SCREEN 0 //default mode with 2 screens #define DISPCNT2_MOD_SINGLE_SCREEN 1 //disables the top screen and enables some special features //Configures single screen mode //Note that main and sub here refer to the main and sub screens as configurable in this register //and NOT the main and sub engines #define REG_DISPSW (*(vu16*)0x040010A0) //Selects the display mode #define DISPSW_WIN_SHIFT 0 #define DISPSW_WIN_MASK (3 << DISPSW_WIN_SHIFT) #define DISPSW_WIN(x) ((x) << DISPSW_WIN_SHIFT) #define DISPSW_WIN_MAIN_ONLY 0 //displays only the main screen #define DISPSW_WIN_MAIN_FULL_SUB 1 //blends the main screen with the sub screen #define DISPSW_WIN_MAIN_HALF_SUB_BOTTOM_LEFT 2 //displays the sub screen at 128x96 in the bottom-left corner with optional blending #define DISPSW_WIN_MAIN_HALF_SUB_BOTTOM_RIGHT 3 //displays the sub screen at 128x96 in the bottom-right corner with optional blending #define DISPSW_A_SHIFT 4 #define DISPSW_A_MASK (3 << DISPSW_A_SHIFT) #define DISPSW_A(x) ((x) << DISPSW_A_SHIFT) //Blending for DISPSW_WIN_MAIN_FULL_SUB mode #define DISPSW_A_FULL_7_1 0 //main 7/8, sub 1/8 #define DISPSW_A_FULL_6_2 1 //main 6/8, sub 2/8 #define DISPSW_A_FULL_5_3 2 //main 5/8, sub 3/8 #define DISPSW_A_FULL_4_4 3 //main 4/8, sub 4/8 //Blending for DISPSW_WIN_MAIN_HALF_SUB modes #define DISPSW_A_HALF_3_1 0 //main 3/4, sub 1/4 #define DISPSW_A_HALF_2_2 1 //main 2/4, sub 2/4 #define DISPSW_A_HALF_1_3 2 //main 1/4, sub 3/4 #define DISPSW_A_HALF_0_4 3 //main 0/4, sub 4/4 //select the screen to output on tv when tv-out is on #define DISPSW_M0_SHIFT 8 #define DISPSW_M0_MASK (1 << DISPSW_M0_SHIFT) #define DISPSW_M0(x) ((x) << DISPSW_M0_SHIFT) #define DISPSW_M0_TV_SUB 0 //output the sub screen to tv-out #define DISPSW_M0_TV_MAIN 1 //output the main screen to tv-out //select which screens picture is main and which is sub #define DISPSW_M1_SHIFT 9 #define DISPSW_M1_MASK (1 << DISPSW_M1_SHIFT) #define DISPSW_M1(x) ((x) << DISPSW_M1_SHIFT) #define DISPSW_M1_MAIN_BOTTOM_SUB_TOP 0 //main = bottom screen, sub = top screen #define DISPSW_M1_MAIN_TOP_SUB_BOTTOM 1 //main = top screen, sub = bottom screen //tv-out enable/disable #define DISPSW_TVOUT_SHIFT 14 #define DISPSW_TVOUT_MASK (1 << DISPSW_TVOUT_SHIFT) #define DISPSW_TVOUT(x) ((x) << DISPSW_TVOUT_SHIFT) #define DISPSW_TVOUT_DISABLED 0 //disables tv-out, top screen will be white #define DISPSW_TVOUT_ENABLED 1 //enabled tv-out, top screen signals are used to output 10 bit digital NTSC //key input enable/disable //in single screen mode three of the top screen signals are used as button inputs to configure the output //the hardware will change the register values of WIN, A and M01 when the buttons are pressed //this feature can be disabled by setting this bit #define DISPSW_KEYLOCK_SHIFT 15 #define DISPSW_KEYLOCK_MASK (1 << DISPSW_KEYLOCK_SHIFT) #define DISPSW_KEYLOCK(x) ((x) << DISPSW_KEYLOCK_SHIFT) #define DISPSW_KEYLOCK_DISABLED 0 //allow configuring the display mode using the buttons #define DISPSW_KEYLOCK_ENABLED 1 //the buttons will do nothing //Enables/disables outputting an 11MHz clock on the CLK11M pin of the SOC //I believe this signal is not actually connected to anything #define REG_CLK11M (*(vu16*)0x040010B0) #define CLK11M_CK11_LOW 0 #define CLK11M_CK11_ACTIVE 1 ____________________ Take me to your heart / never let me go! "clearly you need to mow more lawns and buy a better pc" - Hydr8gon |
StrikerX3 |
| ||
Newcomer Normal user Level: 2 Posts: 1/1 EXP: 18 Next: 28 Since: 04-22-23 Last post: 338 days ago Last view: 5 days ago |
Recently I've been implementing the ARM9 cache on my NDS emulator and made several tests on real hardware (a 3DS) to figure out how exactly it works, because the ARM manuals are as unhelpful as ever. My emulator fully implements the instruction and data caches (minus the lockdown feature), actually storing and retrieving data from a separate block of memory and having the cache do line fetches and flushes, and partially implements the write buffer -- the FIFO exists, but is drained as soon as anything goes into it. All ROMs I tested seem to run normally, with around 5-40% performance loss depending on the title compared to no cache emulation. The larger losses happen on titles that already ran crazy fast (500+ fps), so they're still very much playable in real time.
Shoutouts to Gericom, Generic, asie and AntonioND on the gbadev Discord, they gave great feedback, suggestions, insights and coding help on this research. So, here are my findings on the ARM9 cache. NDS ARM9 cache inner workingsThe basics
Write buffer
Replacement strategiesNOTE: research is ongoing on this subject. This is a summary of the behavior I observed from collected data. Data was collected from my 3DS with a test program that:
Known facts
Here are a few hypotheses on how the replacement counter(s) might be implemented. Hypothesis 1: one shared counter for both strategies
Hypothesis 2: separate counters for each strategy
Here's the messy code of the test ROM I used if you want to play around. Can be compiled with devkitPro using the Makefile (dkp), or BlocksDS with the regular Makefile + Makefile.include. main.cpp must be in a folder called source. The replacement strategy tests mess with the PU table and assume region 3 is the GBA cart area or the DSi switchable IWRAM; I haven't checked if the PU regions are the same when compiled with dkP, so it might not work. |
Arisotura |
| ||
Big fire melon magical melon girl Level: 55 Posts: 862/875 EXP: 1308871 Next: 5318 Since: 03-28-17 From: France Last post: 36 days ago Last view: 8 days ago |
PoroCYon |
| ||
Half-eaten melon Normal user Level: 11 Posts: 23/24 EXP: 4671 Next: 1314 Since: 12-01-19 From: .be Last post: 227 days ago Last view: 224 days ago |
I found some more misc stuff, so:
Second NTR cartridge registersGBATEK is right that there's a second cartridge slot at 0x040021Ax (with its own AUXSPICNT/DAT, ROMCTRL, etc, and data-in at 0x04102010), but this has some consequences that are not always listed:
SCFG
CAM_MCNT (A9)
ConsoleID formatThis one seems to be a die/wafer/lot ID number (which you can also see in eg. MSP430 TLV data), with format (from LSB to MSB):
WIFIWAITCNTbit 7: MCLK disable? |
PoroCYon |
| ||
Half-eaten melon Normal user Level: 11 Posts: 24/24 EXP: 4671 Next: 1314 Since: 12-01-19 From: .be Last post: 227 days ago Last view: 224 days ago |
Nintendo DSi XL testpoint namesThe testpoints on the regular DSi mobo (CPU-TWL-01) are named, the one on the DSi XL (CPU-UTL-01) aren't. So I went over them all with a continuity tester to figure it out. Took me ~12h spread across 4 days. |
Arisotura |
| ||
Big fire melon magical melon girl Level: 55 Posts: 867/875 EXP: 1308871 Next: 5318 Since: 03-28-17 From: France Last post: 36 days ago Last view: 8 days ago |
entry 0x67 in firmware user settings
it's the RTC clock adjust value on DSi it is stored at offset 0x88 in HWINFO_N.dat also 2FFFDE8/2FFFDEC aren't specifically the RTC date/time, these addresses are used for RTC IO in general ____________________ Kuribo64 |
AntonioND |
| ||
Newcomer Normal user Level: 1 Posts: 1/1 EXP: 10 Next: 1 Since: 11-29-23 Last post: 120 days ago Last view: 107 days ago |
MMIO[82C0h/82C2h+(0..1)*80h] - BTDMP Receive/Transmit FIFO Status (R)
... 4 FIFO Empty (0=No, 1=Empty, 0x16bit words) This is incorrect. The bit is 0 when the FIFO is empty, 1 when it isn't empty. I would need to verify it more, but I've seen that with a couple of quick tests. |
CasualPokePlayer |
| ||
Member Normal user Level: 8 Posts: 15/16 EXP: 1730 Next: 457 Since: 03-27-22 Last post: 60 days ago Last view: 14 days ago |
075h 1 Extended Language (0..5=Same as Entry 064h, plus 6=Chinese)
Language 7 is Korean. Similar to Chinese this is only represented in the extended language in firmware userdata, the older language field will just be set to 1 (English). This also means the supported language bitmask is another bit large (bit 7 for Korean). Presumably DSi specific settings follow the same rules, although I don't have a Korean NAND to verify that.
(for language 6, entry 064h defaults to english; for compatibility) (for language 0..5, both entries 064h and 075h have same value) 076h 2 Bitmask for Supported Languages (Bit0..6) (007Eh for iQue DS, ie. with chinese, but without japanese) (0042h for iQue DSi, chinese (and english, but only for NDS mode)) (003Eh for DSi/EUR, ie. without chinese, and without japanese) 01Dh 1 Console type
0x35 is the console type for Korean DS Lite, which also has extended user settings. So gbatek's description of bit 6 seems to be wrong? Bit 0 seems to be more indicative of having extended user settings.FFh=Nintendo DS 20h=Nintendo DS-lite 57h=Nintendo DSi (also iQueDSi) 43h=iQueDS 63h=iQueDS-lite The entry was unused (FFh) in older NDS, ie. replace FFh by 00h) Bit0 seems to be DSi/iQue related Bit1 seems to be DSi/iQue related Bit2 seems to be DSi related Bit3 zero Bit4 seems to be DSi related Bit5 seems to be DS-Lite related Bit6 indicates presence of "extended" user settings (DSi/iQue) Bit7 zero |
Mighy Max |
| ||
Member Normal user Level: 7 Posts: 9/10 EXP: 997 Next: 451 Since: 07-08-21 Last post: 70 days ago Last view: 70 days ago |
Posted by StrikerX3 How sure are you about this? I have been busy some days now to measure out memory and instruction timings on the (Phat-)DS, my DSi and the various emulators. Out of curiosity and because I think that this is still a bit poor documented/implemented (yeah its a performance hit without much if any benefit) The thing here is: All my measurements point to 2kB data cache on the DS and only 1kB data cache on the DSi. I checked multiple times if my measurement is off, or some hardware setting (i.e. cache lockdown) is causing this but to no avail. On all emulators (as expected) no cache size can be detrminated and all runs need the same time. Reference clock is the 33MHz timer on the arm9. The result does not match the public info about 4kB data cache. What I do to measure the instruction and data cache sizes: Enabled Instruction cache, disable cache lockdowns
for n in [8..16]: Do 11 runs of the following measurement and take the median time of these measurements: run a loop of (2^n)-3 'mov r8, r8' instructions. together with 3 instruction for the looping If the median divided by the amount of instructions exceeds the double of the previous run Report the previous run length as instruction cache size For the data cache the rise of the execution time is not that sharp because the instruction cache is disabled and results in a larger prefetch time for each instruction. I do this to eleminate the effect of instruction caching on this measurement. Disabled Instruction cache, disable cache lockdowns
Enabled Data cache, disable cache lockdowns for n in [8..16]: Do 11 runs of the following measurement and take the median time of these measurements: run a loop of (2^n)-3 'ldr r2, [pc]' instructions. together with 3 instruction for the looping If the median divided by the amount of instructions exceeds 120% of the previous run Report the previous run length as data cache size I can provide a simple .NDS testing this behaviour, if someone wants to double check. |
Mighy Max |
| ||
Member Normal user Level: 7 Posts: 10/10 EXP: 997 Next: 451 Since: 07-08-21 Last post: 70 days ago Last view: 70 days ago |
Hello again,
I cleaned up and published a little app to measure cache and memory timings. The issue with the cache did not resolve. I'm quite certain that the 4kB data cache are ot present (or at least not effective) on the DS and DSi. The measurements are consistent on the HW between runs and variant of the test, while they are different for the generations (DS vs DSi) You can find the source code to measure and verify yourself at https://github.com/DesperateProgrammer/DSMemoryCycleCounter I hope the data can improve the accuracy of the emulators in the future. I am aware that it has not much benefit at the moment, as implementing the mechanics of a cache would impose a significant performance impact in the emulation. Maybe the timings of the non-cached memory regions can be improved and compatibility increases. The app might provide a benchmark for this. If you happen to find an error in the calculation/measurement of cycles please let me know. There are still a lot of things i want to include into the measurements such as impact of DMA, verification of BUS priority, verification of cache-writeback sizes and much more. Without further ado, the memory timings and cache sizes: DSi Caches ========== Reported Measured ICACHE Size 8192 8192 DCACHE Size 4096 1024 ! Conflict ICACHE Line Size 32 32 DCACHE Line Size 32 32 DS Caches ========== Reported Measured ICACHE Size 8192 8192 DCACHE Size 4096 2048 ! Conflict ICACHE Line Size 32 32 DCACHE Line Size 32 32 DSi Memory Timings ================== In cpu cycles @ 66MHz N16 S16 N32 S32 Main RAM 16 16 18 4 ITCM 2 2 2 2 DTCM 1 1 1 1 WRAM 8 8 8 2 VRAM 8 8 8 2 GBA ROM 26 26 38 24 EXMEMCNT[4..2] = 000 GBA ROM 22 22 34 24 EXMEMCNT[4..2] = 001 GBA ROM 18 18 30 24 EXMEMCNT[4..2] = 010 GBA ROM 42 42 52 24 EXMEMCNT[4..2] = 011 GBA ROM 26 26 34 8 EXMEMCNT[4..2] = 100 GBA ROM 22 22 26 8 EXMEMCNT[4..2] = 101 GBA ROM 18 18 26 8 EXMEMCNT[4..2] = 110 GBA ROM 42 42 50 8 EXMEMCNT[4..2] = 111 GBA RAM 26 26 26 20 EXMEMCNT[1..0] = 00 GBA RAM 22 22 22 16 EXMEMCNT[1..0] = 01 GBA RAM 18 18 18 12 EXMEMCNT[1..0] = 10 GBA RAM 42 42 42 36 EXMEMCNT[1..0] = 11 In cpu cycles @ 133MHz N16 S16 N32 S32 Main RAM 32 32 36 8 ITCM 2 2 2 2 DTCM 1 1 1 1 WRAM 12 12 12 4 VRAM 12 12 12 4 GBA ROM 48 48 72 48 EXMEMCNT[4..2] = 000 GBA ROM 40 40 64 48 EXMEMCNT[4..2] = 001 GBA ROM 32 32 56 48 EXMEMCNT[4..2] = 010 GBA ROM 80 80 104 48 EXMEMCNT[4..2] = 011 GBA ROM 48 48 64 32 EXMEMCNT[4..2] = 100 GBA ROM 40 40 56 32 EXMEMCNT[4..2] = 101 GBA ROM 32 32 48 32 EXMEMCNT[4..2] = 110 GBA ROM 80 80 96 32 EXMEMCNT[4..2] = 111 GBA RAM 48 48 48 40 EXMEMCNT[1..0] = 00 GBA RAM 40 40 40 32 EXMEMCNT[1..0] = 01 GBA RAM 32 32 32 24 EXMEMCNT[1..0] = 10 GBA RAM 80 80 80 72 EXMEMCNT[1..0] = 11 In bus cycles @ 66MHz N16 S16 N32 S32 Main RAM 8 8 9 2 ITCM 1 1 1 1 DTCM 0.5 0.5 0.5 0.5 WRAM 4 4 4 1 VRAM 4 4 4 1 GBA ROM 13 13 19 12 EXMEMCNT[4..2] = 000 GBA ROM 11 11 17 12 EXMEMCNT[4..2] = 001 GBA ROM 9 9 15 12 EXMEMCNT[4..2] = 010 GBA ROM 21 21 27 12 EXMEMCNT[4..2] = 100 GBA ROM 13 13 17 8 EXMEMCNT[4..2] = 100 GBA ROM 11 11 15 8 EXMEMCNT[4..2] = 101 GBA ROM 9 9 13 8 EXMEMCNT[4..2] = 110 GBA ROM 21 21 25 8 EXMEMCNT[4..2] = 111 GBA RAM 13 13 13 10 EXMEMCNT[1..0] = 00 GBA RAM 11 11 11 8 EXMEMCNT[1..0] = 01 GBA RAM 9 9 9 6 EXMEMCNT[1..0] = 10 GBA RAM 21 21 21 18 EXMEMCNT[1..0] = 11 In bus cycles @ 133MHz N16 S16 N32 S32 Main RAM 8 8 9 2 ITCM 0.5 0.5 0.5 0.5 DTCM .25 .25 .25 .25 WRAM 3 3 3 1 VRAM 3 3 3 1 GBA ROM 12 12 18 12 EXMEMCNT[4..2] = 000 GBA ROM 10 10 16 12 EXMEMCNT[4..2] = 001 GBA ROM 8 8 14 12 EXMEMCNT[4..2] = 010 GBA ROM 20 20 26 12 EXMEMCNT[4..2] = 100 GBA ROM 12 12 16 8 EXMEMCNT[4..2] = 100 GBA ROM 10 10 14 8 EXMEMCNT[4..2] = 101 GBA ROM 8 8 12 8 EXMEMCNT[4..2] = 110 GBA ROM 20 20 24 8 EXMEMCNT[4..2] = 111 GBA RAM 12 12 12 10 EXMEMCNT[1..0] = 00 GBA RAM 10 10 10 8 EXMEMCNT[1..0] = 01 GBA RAM 8 8 8 6 EXMEMCNT[1..0] = 10 GBA RAM 20 20 20 18 EXMEMCNT[1..0] = 11 DS Memory Timings ================= In cpu cycles: Main RAM 16 16 18 4 ITCM 2 2 2 2 DTCM 1 1 1 1 VRAM 8 8 8 2 GBA ROM/RAM *problems measuring* In bus cycles: N16 S16 N32 S32 Main RAM 8 8 9 2 ITCM 1 1 1 1 DTCM 0.5 0.5 0.5 0.5 VRAM 4 4 4 1 GBA ROM/RAM *problems measuring* |
Main - Development - GBAtek addendum/errata | Hide post layouts | New reply |
Page rendered in 0.146 seconds. (2048KB of memory used) MySQL - queries: 28, rows: 99/99, time: 0.014 seconds. Acmlmboard 2.064 (2018-07-20) © 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |