|
| ||
| Views: 1,609,232 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-21-24 11:34 AM |
| Guest: | ||
| Main - Posts by yuriks |
| yuriks |
| ||
|
Newcomer Normal user Level: 7 Posts: 1/8 EXP: 1371 Next: 77 Since: 10-30-14 From: Brazil Last post: 3282 days ago Last view: 3264 days ago |
One thing I noticed while helping neobrain with FIRM REing is that the NATIVE_FIRM ARM11 initial processes are actually loaded into this 0x1FF00000-0x1FF7FFFF memory region. Do they later get relocated at some point in the boot process or is there some funny memory remapping going on? |
| yuriks |
| ||
|
Newcomer Normal user Level: 7 Posts: 2/8 EXP: 1371 Next: 77 Since: 10-30-14 From: Brazil Last post: 3282 days ago Last view: 3264 days ago |
New theme is cute! A lot of the fonts look weirdly bold to me, it's kinda hard to read. |
| yuriks |
| ||
|
Newcomer Normal user Level: 7 Posts: 3/8 EXP: 1371 Next: 77 Since: 10-30-14 From: Brazil Last post: 3282 days ago Last view: 3264 days ago |
As far as I know applications don't have direct access to the NAND filesystem. You can access restricted subsets of data (mostly shared data offered by other applications in the system) but that will require using the FS service functions: http://3dbrew.org/wiki/FS:OpenArchive |
| yuriks |
| ||
|
Newcomer Normal user Level: 7 Posts: 4/8 EXP: 1371 Next: 77 Since: 10-30-14 From: Brazil Last post: 3282 days ago Last view: 3264 days ago |
I'm not sure, but I think that FS permissions might be checked by the ARM9. If that's the case, then even kernelhax won't be enough. |
| yuriks |
| ||
|
Newcomer Normal user Level: 7 Posts: 5/8 EXP: 1371 Next: 77 Since: 10-30-14 From: Brazil Last post: 3282 days ago Last view: 3264 days ago |
I'm starting to reverse engineer the DSP protocol, which games use to communicate with the signed binary running in the DSP. This is interesting to explore a possible HLE implementation in Citra, but more importantly, should hopefully open the way for better and more reliable sound in homebrew.
At least initially I plan to do mostly black-box RE, by taking traces of DSP communication with Citra and trying to decode those and apply them to hardware. Right now I'm examining Bravely Default, but from my analysis of a bunch of DSP bins, they have few differences so this should apply to most games. Hopefully I'll use this thread as a log/dump for any info I discover. Startup Sequence: - WriteProcessPipe: 0000 160C, first number is unknown, second is garbage read from the stack and as such tends to differ from game to game. - WriteReg0x10: 4000, ??? - ReadPipeIfPossible: one u16 is read here, which indicates the number of addresses to read in the next step - ReadPipeIfPossible: N u16 DSP addresses are read here, which point to the location of various control variables within DSP memory. After reading these are passed through ConvertProcessAddressFromDspRam to convert them to ARM11 userspace addesses. An additional copy of these variables is present with offset 0x10000 (in DSP words). - WriteReg0x10: 4000, again In BD the returned addresses and their translations are: - BFFF -> 1FF5 7FFE - 9E8E -> 1FF5 3D1C - 8680 -> 1FF5 0D00 - A78E -> 1FF5 4F1C - 9430 -> 1FF5 2860 - 8400 -> 1FF5 0800 - 8540 -> 1FF5 0A80 - 948E -> 1FF5 291C - 8710 -> 1FF5 0E20 - 8410 -> 1FF5 0820 - A90E -> 1FF5 521C - AA0E -> 1FF5 541C - AACE -> 1FF5 559C - AC4E -> 1FF5 589C - AC58 -> 1FF5 58B0 From here on, when I say "7FFE" for example, I'm referring to the mirror variables at 0x1FF57FFE and 0x1FF77FFE. From here on communication with the DSP is done by directly writing/reading to the DSP RAM areas mapped in the process at 0x1FF5000 and 0x1FF70000. The two areas (each size 0x8000) are used alternately, and at the end an incrementing counter is written to 7FFE. This indicates that a double-buffering scheme is used where the game writes the data to the variables and then increases the counter to let the DSP know to process the new page. The page switch seems to happen once per audio frame (probably around ~4.88ms). |
| yuriks |
| ||
|
Newcomer Normal user Level: 7 Posts: 6/8 EXP: 1371 Next: 77 Since: 10-30-14 From: Brazil Last post: 3282 days ago Last view: 3264 days ago |
After reversing some game init code, I managed to discern a few arrays and sub-structures inside the shared memory areas:
![[image]](https://i.imgur.com/e2dCq8t.png)
My current goal is to figure out how the address of the sound buffers which are cache-flushed are passed to the DSP. |
| yuriks |
| ||
|
Newcomer Normal user Level: 7 Posts: 7/8 EXP: 1371 Next: 77 Since: 10-30-14 From: Brazil Last post: 3282 days ago Last view: 3264 days ago |
I'd do this with a simple sorted array. Your number of outstanding events at any given time is likely to be a small number. Simply give each event entry an auto-incrementing unique id, and insert it into the array mantaining a sorted order. For removing events iterate until you find a matching id.
Since the number of events is small, a linked list or other more complex structure will probably not give you any significant advantage (and could even be slower with a naive implementation.) To optimize for the common case, you could sort the array in reverse order, so that popping the next event just requires decrementing the size. Another option is to use a circular array instead, though the implementation there is slightly more complicated. |
| yuriks |
| ||
|
Newcomer Normal user Level: 7 Posts: 8/8 EXP: 1371 Next: 77 Since: 10-30-14 From: Brazil Last post: 3282 days ago Last view: 3264 days ago |
That's not particularly helpful here, since it's only useful if you need to have a pointer to a window in the buffer that appears contiguous, which isn't the case here. |
| Main - Posts by yuriks |
|
Page rendered in 0.014 seconds. (2048KB of memory used) MySQL - queries: 22, rows: 75/75, time: 0.005 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |