-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathmy notes.txt
185 lines (159 loc) · 6.9 KB
/
my notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
sections:
- rom start (02000000~02000800): _secure.s + entry.s
contains both .text and .rodata
- .text (02000800~0203daf4)
- .rodata / .data (0203daf4~02053560)
don't know where the split between those is yet:
- 02045ce4 seems to be right at the end of .rodata, which is weird, since it's referred to
since main.s. maybe data??? but again it's a string so no idea
- 02045d18 is more likely: it's write accessed in main.s too
- .bss (02053560~0227cb20)
uninitialized data
- .itcm (02053560~02053b20)
potentially contains .text, .rodata, and .data
- .dtcm (02053b20~02053b80)
potentially contains .text, .rodata, and .data
- autoload list (02053b80~02053b98)
###########################################################################
overlay memory distribution
overlay mem start - 0227cb20
0227cb20 ~ 02287660 - overlay 0
02287660 ~ 0228fa60 - overlays 1 to 59
0228fa60 ~ 02296f80 - overlays 60 to 164
###########################################################################
splits are not very good right now, this is mostly going to indicate patterns and similarities
main.c(pp)
- NitroMain
initialization + main loop
- func_020010e0 (referred in overlay 0 [code - general])
get table D_02045cc4
- func_020010f0 (called from func_020012cc)
seems to initialize the 2D engine A (and some other stuff)
- func_02001240 (called from NitroMain)
loads three vectors and passes them to func_0202eef0
- func_020012a0 (called from NitroMain)
sets POLYGON_ATTR to "solid rendering of both back and front surfaces",
DIF_AMB and SPE_EMI to colors (TODO)
- func_020012cc (called from NitroMain)
initialize video stuff -- memset palette, LCDC VRAM, OAM
- func_020013fc (called from NitroMain)
bunch of function calls with a bunch of data as arguments
yeah that's it
probably just a lot of initializing ngl
- func_02001498 (called from _entry_arm9)
NitroStartUp, a weak function which any dev could edit
to initialize their own stuff at the game start up
seems to initialize library and heap things here
- func_020014a8 (set to somewhere in func_020012cc)
currently unknown structure reading-setting function
- func_020014e0 (called from func_020139b8)
returns D_02263cd4.unk4
- func_020014f0 (called from NitroMain twice)
loads and stores some stuff from unknown parts of ram
yeah thats it
end of main.c(pp)
string.c(pp)
- 02001524 - strcpy (char* destination, char* source)
- 02001558 - strncpy (char* destination, char* source, int num)
- 02001598 - strcat (char* destination, char* source)
first for loop may be an inlined strlen
update: it is not
- 020015e4 - thunk_SDK_strcpy (char* destination, char* source)
calls 0203b1f8 with a bx r12
- func_020015f0 (char* destination, int num)
prints that number into the destination pointer as a string
- 02001628 - strlen (char* str)
- 0200165c - strncmp (char* str1, char* str2, int num) -> bool
- 020016a0 - strstr (char* haystack, char* needle)
- func_020016f4 - another string function
end string.c(pp)
code_020017b0.c(pp)
- func_020017b0~func_02001c14 control various 2D engine B registers,
referenced in D_02045d20
array accessed at func_02001cc8 - takes a struct/class, calls a function from there
- func_02001c30~func_02001e04 - set some values in (probably) that same struct/class
except the aforementioned func_02001cc8
end code_020017b0.c(pp)
code_02001e1c.c(pp) - yet another struct, seems to be a WININ register controller
- func_02001e1c - constructor
- func_02001e38~func_02001f8c - stuff with that same struct
end code_02001e1c.c(pp)
CDepth2D.cpp (single field: vtable)
- func_02001f94 - constructor
- func_02001fa4~func_02001fa8 - virtual functions
- func_02001fbc ~ func_020020a8 - actual functionality of the class
end CDepth2D.cpp
code_02001fbc.c(pp)
- func_020020d4 ~ func_0200337c - massive struct, reaches up to unk504
func_02002290 runs 020020d4 and returns the arg0
func_02002474 has a couple of switchcases (with jumptables)
end code_02001fbc.c(pp)
code_02003384.c(pp)
- func_02003384 ~ func_02003558 seem to be related to some bitfields/inputs?
KEYINPUT reg checked in a few early functions
end code_02003384.c(pp)
CList.cpp - doubly linked list class
- func_02003568 ~ func_020036a4
end CList.cpp
code_020036e8.cpp - bunch of functions with some overloading?
- func_020036e8 ~ func_02003924
end code_000036e8.cpp?
memory.cpp - probably a bunch of news and deletes, plus other memory stuff. accesses D_MemInfo?
- func_020039a4 - operator new(void*)
- func_020039c4 - operator new[](void*)
- func_020039e4 - operator delete(void*)
- func_02003a04 - operator delete[](void*)
- func_02003a24 ~ func_02003c1c
end memory.cpp
func_02003c94 ~ func_02003cbc
OMObjText.cpp
func_02003e3c - constructor for OMObjText
func_02003fe0 ~ func_0200400c - virtual functions for OMObjText
(probably some more stuff)
end? OMObjText.cpp
func_02004040 ~ func_02004770
it's very likely that some of (if not all) these functions are part of OMObjText.cpp,
but we won't know for certain until we start REing this
func_02004790 - CPageText constructor
func_02004930 ~ func_02004988 - CPageText virtuals
func_020139b8 - CProc constructor
called from overlay_0::func_0227fb30 (entry function for overlay 0, CMultisceneProc constructor)
020178b4 - malloc?
020178e4 - free?
020301dc - snprintf(char* dest, int dest_size, char* format, ...) -> char*
02030204 - thunk to vsnprintf
0203a3bc - vsnprintf
0203b1dc - SDK_strlen
0203b1f8 - SDK_strcpy
0203b2c0 - SDK_strcat
0203b2f0 - SDK_strcmp
func_0203b404 - probably another string operation but [E doesn't] have it labeled
likely the same as func_020016f4
D_02263ce0 - D_MemInfo?
Types with RTTI info: (RTTI positions may be off)
(Each dash is where I estimate a new .cpp file starts)
- CDepth2D (02045da0) - VTable 02045dbc
- CList (02045ddc) - VTable 02045dec
- OMObjText (02045df8) - VTable 02045e14
- CPageText (02045e1c) - VTable 02045e38
- CTRInt (02045e50) - VTable 02045ec0
CTimeRatio (02045e5c) - VTable 02045e8c
CTRVec (02045e68) - VTable 02045ea4
- NPDivLoadSound (02045fe4) - VTable 02045ff4
- TPItem (02046018) - VTable 02046028
- TPIButton (02046048) - VTable 0204605c
- CCacheManager (02046088) - VTable 020460b4
CCacheList (02046090) - VTable 020460c4
- CInput (020460ec)
- CInputBitPad (020460f4) - VTable 02046118
- CInputGtrPad (02046130) - VTable 02046154
- CProcMan (0204616c) - VTable 0205168c
CMainProc (0204618c) - VTable 020461a0
[i'm pretty sure there's more stuff in the middle...??]
- CInputChecker (020512e4) - VTable 022870a8 (overlay0)
- CICTacoPlay (020512ec) - VTable 02051320 // interesting, why are the Octopus Machine classes here?
- CScene (020513fc) - VTable 022871a8 (overlay0)
- CTaco00Scene (0205143c) - VTable 020514a4 // it might be weak data ordering, or they've
- CTptraceScene (02051584) - VTable 020515fc // been implemented near the base classes
- CProc (02051664) - VTable 02051674
[TO BE CONTINUED - TPEffect 02052060]