Hacking Circle Pad patches for Super Mario 64 DS and other games (in TwilightMenu with TWPatcher and RTCom)

shoco

Well-Known Member
OP
Member
Joined
Aug 1, 2019
Messages
110
Trophies
0
XP
476
Country
Russia

TLDR list of mods I've made

a bit more lengthy description is probably somewhere below in the text, in the changelog
  • 3DS-NDS Key Remapper: Patch generator that lets you remap keys in any NDS game. You can also map/remap the CPad, CStick and ZL & ZR buttons. For example, you can assign the CStick to the ABXY buttons to make aiming easier in some FPS games. To use it, visit the page, tick some checkboxes, copy the resulting cheatcode and paste it into your game in R4CCE. Requires the latest version of nds-bootstrap (v70.0 or newer).
  • Animal Crossing: Wild World
  • C.O.P.: The Recruit
    • CPad is also used for steering a vehicle (a little bit)
    • CStick to control the camera
  • Call of Duty: Black Ops (New3DS only)
    • CStick to control the camera
    • ZR to run
  • Call of Duty: Modern Warfare 3 - Defiance (New3DS only)
    • CStick to control the camera
    • ZR to run
  • Call of Duty: World at War (New3DS only)
    • CStick to control the camera
    • ZR to run
  • Chibi-Robo: Clean Sweep! (Okaeri! Chibi-Robo! Happy Rich Oosouji!)
    • `CPad` to run, push, climb, use the Chibi-Vacuum, Chibi-Eyes, &c.
    • `Select` to interact with objects (when a red exclamation mark appears)
    • `Left` to open/close the Chibi-Menu
    • `Down` to equip the Chibi-Vacuum
    • `Up` to pick up, drop, or pull out the Plug from an outlet
    • `A/B` to answer "Yes" or "No" to a question
  • Chibi-Robo: Park Patrol
  • Dementium: The Ward (New3DS only)
    • CStick to control the camera
    • ZR to run
  • Dementium II (New3DS only)
    • CStick to control the camera
    • ZR to run
  • Dragon Ball: Origins
  • Dragon Ball: Origins 2
    • To work, set the input method to "Buttons Only" or "Both", not "Stylus Only"
  • Dragon Quest IX: Sentinels of the Starry Skies
  • Final Fantasy III
  • Final Fantasy IV
  • Flower, Sun and Rain: Murder and Mystery in Paradise
  • Geometry Wars: Galaxies (New3DS only)
    • CPad to move
    • CStick to shoot
    • To swap CPad and CStick, set "Handed" in the Options to "Left"
  • Golden Sun: Dark Dawn
  • GoldenEye 007 (New3DS only)
    • CStick to control the camera
    • ZR to run
  • Grand Theft Auto: Chinatown Wars
  • Harvest Moon DS: Island of Happiness
  • Harvest Moon DS: Sunshine Islands
  • Inazuma Eleven
  • Inazuma Eleven 2
  • Inazuma Eleven 3
  • Kingdom Hearts: 358-2 Days
    • CStick to control the camera
  • Kingdom Hearts: Re-coded
    • CStick to control the camera
  • LEGO Batman: The Videogame
  • LEGO Harry Potter: Years 1-4
  • LEGO Indiana Jones: The Original Adventures
  • LEGO Indiana Jones 2: The Adventure Continues
  • LEGO Star Wars: The Complete Saga
  • Lost in Blue
  • Lost in Blue 2
  • Lost in Blue 3
  • Magician's Quest: Mysterious Times
  • Metroid Prime: Hunters (CPad + CStick + Gyroscope, New 3DS only):
  • Mini Ninjas
  • Moon (New3DS only)
    • CStick to control the camera
  • Nostalgia
  • Okamiden
  • Pac-Man World 3
  • Rayman DS
  • Ridge Racer DS
  • Rune Factory: A Fantasy Harvest Moon
  • Rune Factory 2: A Fantasy Harvest Moon
  • Rune Factory 3: A Fantasy Harvest Moon
  • Solatorobo: Red the Hunter
  • Star Fox Command:
  • Super Mario 64 DS:
  • Super Monkey Ball: Touch & Roll
  • Transformers: Decepticons
  • The Legend of Zelda: Phantom Hourglass and Spirit Tracks:
    • CPad is additionally used to rotate the camera around the train/ship
    • L + R + Down to unmap/map the CPad from the DPad (useful if you're using the DPad mods (i.e. Phantom Hourglass and Spirit Tracks))
  • The Wizard of Oz: Beyond the Yellow Brick Road
    • L/R for camera control
  • The World Ends with You
    • CPad or CStick to move the character
Source Code for most of my mods, all of them are about 95% identical (just a copy/paste). It might be useful if you want to port a mod to another platform (like an emulator or something). Then you only need the Arm9 part and a set of memory offsets (i.e. where to hook the game, etc) depending on the version of the game (and maybe the way it's all combined into one whole AR code), everything else is 3DS-TWPatcher-RTCom specific.



Original message from 2022-12-15:

Hello.
I couldn't find info about whether someone has already done this or not. My searching skills are terrible these days.

Anyway, I made this thing that allows playing sm64ds on 3DS using the Circle Pad like an almost normal human being. It was relatively simple, albeit time consuming. It requires TWPatcher (the last version, preferably) with RTCom enabled (as well as the Luma's config option "Enable loading external FIRMs and modules"), although it's enabled by default and probably impossible to disable at that point. And If it doesn't work, it may help to update the TwilightMenu app to the last version.

The patch is in the form of Action Replay code. It's in the zip file. Just select one text file from it with the cheat code for your rom. Get the cheat database file `usrcheat.dat` from your 3DS. It's supposed to be at `/_nds/TWiLightMenu/extras/usrcheat.dat` . If it's not there, then it can be downloaded somewhere on the internet. After that, open the cheat database in the program "r4cce" (or maybe somewhere else, i don't know), choose or add your game rom, and copy/paste this Action Replay code there. Save it and copy the file back to the device. By the way, there is also an already prepopulated `usrcheat.dat` (useful for quick testing). All what's left is to enable the cheat in the TwilightMenu menu. And it should work. Or maybe it won't, I don't know. It works for me (I've got New 2DS XL, the OS version is 11.12.0). There are too many things that can go wrong.

There are also cheat versions that allow camera rotation with the Nub stick X, ZL and ZR buttons. Nothing fancy here, they are just mapped to the buttons Left arrow / Right arrow on the touchscreen and obviously work only on the New 2DS/New 3DS devices. Plus, it looks like the Nub stick requires some additional preprocessing as its values seem to be rotated 45 degrees, so more chances of not-working, but whatever.



Troubleshooting (in case something doesn't work)

Examples: your game freezes completely at startup (all you see is a white screen), the game in general runs slowly, you can't control the main character, or it feels like all the buttons are being pressed at the same time, etc. The reason for this is most likely that you have not patched the TWL_FIRM (or rather TwlBg in it) properly with TWPatcher. Make sure that you've read its documentation and applied it appropriately. Maybe the following list will help you.
  • Games that don't support widescreen (or just mods for games that otherwise support widescreen) may need a separately patched TwlBg. Make two TwlBg versions in TWPatcher, one with widescreen and one without (both should have RTCom). Put the one with widescreen in "_nds/TWiLightMenu/TwlBg/" and rename it to "Widescreen.cxi" (or whatever the official guides say to enable widescreen). Leave the one without widescreen in "/luma/sysmodules" as "TwlBg.cxi". That way, TwilightMenu should swap them when a game has widescreen support and 16:10 mode is set, and not touch them otherwise.
  • Make sure the "external FIRMs and modules" option is enabled in Luma's configuration screen.
  • Update TWPatcher, TwilightMenu, Luma3DS, ...
  • Get the correct cheatcode .txt file for your version of a game. Just as an example: "ASME-F486F859 (USA v1.1)". "ASME" is a rom code (bytes 0xC-0xF), "F486F859" is a bitwise NOT of CRC32 (aka CRC-32/JAMCRC) of the first 200 bytes of the game's header (the cheat engine uses it to identify a game). "v1.1" means the second revision (aka "Rev 1", byte 0x1E)


Update 2022-12-20:
The current version has a problem with the game's music slowdown by about 10-15%.
I've made an alternative version "v2" that uses slightly different faulty approach. Instead of working with the RTCom to communicate with the Arm11 all the time, it only uses it to upload a piece of code that would overwrite some RTC functionality of TwlBg (not permanently, of course) and would hijack the RTC regs to pass the CPad data instead of actual time.
Although, there are two problems with my implementation.
Firstly, in super rare cases it may (or maybe it can't anymore, I'm not sure) crash the console (because it modifies code at runtime, probably in front of another thread that theoretically can execute it at that moment; and I don't even want to think about caching). But it seems fine for now, I've relaunched the game like 40 times and it was okay.
Secondly, it overwrites part of functionality that may be actually important, but I've never seen this code executed myself (my guess is it has something to do with alarms, but I don't use them). In either way, I think this is an interesting idea when executed properly

Update 2022-12-23:
New version v2.3. This time the patch won't replace any potentially useful functionality of TwlBg (it most likely didn't before anyway). I've also changed a bit the way ZL&ZR work. They are no longer hardcoded to the camera rotation. They can be swapped or remapped to other functions such as crouching or jumping. To remap these two keys (and half of the others), just go here, select your version, set preferred controls, and copy the AR code. Then the code can be added as usual in "r4cce" (as the new one, no need to extend this patch). However, I don't think this feature is very helpful.
In addition, I've added support for the iQue version of the game. And if someone's interested in the "technical" details of this project, there is also a Github page for this whole project. The code may not be exactly understandable, but if one had enough motivation to include CPad, CStick, or Gyroscope support to another game, this part certainly wouldn't be the hardest.

Update 2023-01-03
v2.4. a few mostly cosmetic changes.
- Reduced the cheatcodes' size by half by using the "EXXXXXXX NNNNNNNN" AR instruction to copy bytes in bulk instead of word by word. The speed should also increase similarly. Before, I thought that these codes get somehow optimized or converted into ARM, but it seems like nds-bootstrap has a piece of code that simply interprets them directly at runtime, 60 times per second, over and over again.
- The clock in nds-bootstrap's in-game menu now works properly. Solved by passing the CPad data through other RTC registers (alarm time 2 and DSi's counter).
- Reading RTC regs from NDS usually requires some kind of delay (gbatek says 5us for each bit transferred; nintendo puts a ~40 cycles there). But it looks like it's unnecessary in this case, everything works without them. That's naive, but I'd like to believe the reason for that is, as these legacy RTC registers are emulated, there are no real hardware behind it, thus delays aren't needed (on 3ds). The removal of these delays might be important, because some games (not this one, except for music) are hypersensitive to delays in their VBlank IRQ handlers.
- The problem with the sound distortions that I've mentioned somewhere around here has been finally solved (again). This time I rely on Arm11's RTCom autorelease feature (if I understand it correctly) to asynchronously initialize all the stuff and dynamically patch TwlBg. I think it used to take 20ms which was too much for Arm7 to swallow and so the distortions could pop up. Now Arm7 just sends one command to Arm11 to do all the work and doesn't wait for the answer (that frame).

Update 2023-01-18
I've created patches for several additional games.
Half of the patches are rather dumb and only use the CPad to control the direction of the main character, not their speed. Also, the cheats are mostly untested, I've only checked a few places here and there
  • Metroid Prime: Hunters (New 3DS/New 2DS only) - the CPad controls Samus' movement (in both the morph ball form and the "normal" FPS form). The nub stick controls the camera's left/right and up/down movement. ZR opens/closes the Scan Visor. There is also a gyroscope support for controlling the camera, albeit super awkward. Pressing ZL + Down toggles the gyroscope, but it needs to be calibrated first. To do that, place the console on a flat surface (or just hold it still) and press ZL + Up. Pressing ZL + Left toggles between the gyro axis responsible for the camera's horizontal rotation (Y or Z). Essentially it depends on how you hold the console, probably the right way would be to interpolate between them based on the accelerometer data, but that's too much for a hack. Overall, just a dumb gimmick.
  • Rayman DS - generally meaningless since the 3DS already has a native port that doesn't run in 16 fps (the DSi mode makes things just a little bit better). However, as a 3D platformer, it may be the best use case for such mods
  • The Legend of Zelda: Spirit Tracks - the CPad also controls the rotation of the camera around the train. Additionally, CPad is unmapped from the dpad keys (because by default they open the menu, map, etc). But if you're going to play with the DPad mods (one and two), you'll need to put it back. For that, press the "L+R+Down" combination, it will map or unmap the dpad
  • The Legend of Zelda: Phantom Hourglass - same, but for the ship
  • Grand Theft Auto: Chinatown Wars
  • Dragon Quest IX
  • LEGO Star Wars: The Complete Saga
  • Mini Ninjas
  • Okamiden
  • Animal Crossing: Wild World
Update 2023-01-25
- There was a problem when 3DS could just crash when starting a game (with 3-5% chance). I've fixed it and updated all patches (it's solved by flushing the data cache and invalidating instruction cache after patching the TwlBg at runtime). UPDATED: it's a lie. The crashes still happen.
- In Metroid, the camera could start moving in the opposite direction if you pushed the nub stick too hard. That also is supposed to be fixed now

Update 2023-02-19
- 3DS-NDS Key Remapper is a patch generator that allows you to map/remap any 3DS key to one or a combination of NDS keys. Furthermore, it's possible to map the CPad and CStick with ZL & ZR (for the New 3DS family); essentially, the sticks can behave as four separate keys (like CPad usually does when emulating the DPad). And, most importantly, it should theoretically work with any NDS game.
- To use just visit the page, click some checkboxes to setup mappings, copy the resulting cheatcode, and insert it into your game in R4CCE. Normally, this cheat should get activated after about 20 seconds (to avoid conflicts with my other patches). Due to this "late" initialization, there may be sound distortions (you'll know when you hear them). If this happens, just open and close nds-boostrap's in-game menu several times and the sound should eventually shift back. Or change the sound mode in a game's settings to something other than "Surround" or "Headphones" (if that's possible). Or change the start delay on the generation page to something like 10 if you're not using any CPad patches. Actually, there is another thing where it can interfere with the CPad patches. For simplicity's sake some patches (notably Metroid, Zeldas and Star Fox) unmap the CPad from the DPad (because the DPad isn't responsible for movement in those games and does something else (or it was just easier for me)). This remapper, when enabled, will override those settings.
- The Key Remapper works exactly like my other patches (uploading code to arm11, patching TwlBg at runtime, inserting a hook, etc), except here I don't pass any data to Arm7, but simply use Arm11's LGY_HIDEMU_MASK register to override native NDS keys (normally used to map CPad to DPad). The interesting thing here is that a cheatcode can be executed directly from nds-boostrap's cheat engine. It's useful in this case, because I'm patching TwlBg (that doesn't differ from game to game) rather than a specific game, so I don't need to know its layout. Also not sure about any performance implications. Won't be surprised if there are some timing delays, etc, because each key is funneled through that register.
- This thing requires the latest version of nds-bootstrap (currently v70). Older versions had a bug that didn't allow the C2 instruction to be used (it lets us execute arbitrary ARM code directly from a cheatcode, without uploading it into the game's memory).

Plus some lazy CPad patches:
  • Chibi-Robo! Park Patrol
  • Final Fantasy III
  • Final Fantasy IV
  • Kingdom Hearts: 358-2 Days
  • Kingdom Hearts: Re-coded
  • Magician's Quest: Mysterious Times
  • Nostalgia
  • Rune Factory 3: A Fantasy Harvest Moon
  • Solatorobo: Red the Hunter
  • Star Fox Command - A to boost, B to brake. This one is essentially a dpad patch by Cracker, except that I modified it to use the CPad.

Update 2023-04-16
  • Finally fixed a bug that could rarely crash the console when starting a game (I didn't handle RTCom errors properly)
  • Fixed a bug in Final Fantasy 3 when it would take too long to complete a turn during a battle
  • In SM64DS, the virtual joystick (a target) is now hidden from the bottom screen when the CPad is being used
  • The camera can now be controlled with the CStick in the Kingdom Hearts games in new New3DS-family-only versions
And several new mods for the following games:
  • C.O.P.: The Recruit
    • CPad is also used for steering a vehicle (a little bit)
    • CStick to control the camera
  • Call of Duty: Black Ops (New3DS only)
    • CStick to control the camera
    • ZR to run
    • To modify the sensitivity of the CStick (i.e. to increase the speed of the camera), find the hexadecimal number "00000142" in the cheatcode (it's somewhere near the end) and change it to something else
  • Chibi-Robo: Clean Sweep! (Okaeri! Chibi-Robo! Happy Rich Oosouji!)
    • `CPad` to run, push, climb, use the Chibi-Vacuum, Chibi-Eyes, &c.
    • `Select` to interact with objects (when a red exclamation mark appears)
    • `Left` to open/close the Chibi-Menu
    • `Down` to equip the Chibi-Vacuum
    • `Up` to pick up, drop, or pull out the Plug from an outlet
    • `A/B` to answer "Yes" or "No" to a question
  • Dementium II (New3DS only)
    • CStick to control the camera
    • ZR to run
    • To change the CStick sensitivity, find and modify the hex number "00000011" in the cheatcode
  • Flower, Sun and Rain: Murder and Mystery in Paradise
  • GoldenEye 007 (New3DS only)
    • CStick to control the camera
    • ZR to run
    • To change the CStick sensitivity, find and modify the hex number "00000210" in the cheatcode

Update 2023-04-20
  • LEGO Batman: The Videogame
  • LEGO Harry Potter: Years 1-4
  • LEGO Indiana Jones: The Original Adventures
  • LEGO Indiana Jones 2: The Adventure Continues
Update 2023-04-23
  • Pac-Man World 3
Update 2023-07-30
Fixed a bug in "Kingdom Hearts 358/2 Days" that caused the camera to go up without pressing any key

Update 2023-08-13
  • Rune Factory: A Fantasy Harvest Moon
  • Rune Factory 2: A Fantasy Harvest Moon
  • Transformers: Decepticons
Update 2023-08-21
  • Super Monkey Ball: Touch & Roll
Update 2023-09-13
  • Golden Sun: Dark Dawn
Update 2023-10-05
  • Ridge Racer DS
Update 2023-10-15
  • Dragon Ball: Origins
  • Dragon Ball: Origins 2
  • Lost in Blue
  • Lost in Blue 2
  • Lost in Blue 3
Update 2023-10-16
  • Geometry Wars: Galaxies (New3DS only)
    • CPad to move
    • CStick to shoot
    • To swap CPad and CStick, set "Handed" in the Options to "Left"
Update 2023-10-31
Fixed an issue in LoZ: Spirit Tracks (compatibility with the DPad patch)
  • Call of Duty: World at War (New3DS only)
    • CStick to control the camera
    • ZR to run
    • To change the CStick sensitivity (camera speed) find and change this hex value in the cheat code: 00000020
  • Dementium: The Ward (New3DS only)
    • CStick to control the camera
    • ZR to run
    • To change the CStick sensitivity (camera speed) find and change this hex value in the cheat code: 00000011
  • Harvest Moon DS: Island of Happiness
  • Harvest Moon DS: Sunshine Islands
  • Moon (New3DS only)
    • CStick to control the camera
    • To change the CStick sensitivity (camera speed) find and change this hex value in the cheat code: 00000011
Update 2023-11-12
  • The Wizard of Oz: Beyond the Yellow Brick Road
    • L/R for camera control
Update 2023-11-16
  • Inazuma Eleven
  • Inazuma Eleven 2
  • Inazuma Eleven 3
Update 2023-12-16
Now, In Star Fox, you can do a barrel roll by pressing X
New mods:
  • Call of Duty: Modern Warfare 3 - Defiance (New3DS only)
    • CStick to control the camera
    • ZR to run
    • To change the CStick sensitivity (camera speed) find and change this hex value in the cheat code: 00000152
  • Star Wars: Lethal Alliance
Update 2023-12-19
Fixed a small bug in Star Wars: Lethal Alliance. Now there's a proper 360 movement (previously the game would prioritize the forward direction for the main character)

Update 2023-12-28
  • The World Ends with You
    • CPad or CStick to move the character











Just in case, I did not check all of them. They may not work properly or may be out of date.

I by @Cragdore
II by @The Catboy
III by @Vendicatorealato
IV by @Russ9876
V by @selcuk



xdelta version of the patches for SM64DS by @DeadSkullzJr (Action Replay cheatcodes or usrcheat.dat are not required anymore)
 

Attachments

  • MODS.zip
    717.4 KB · Views: 7
Last edited by shoco,

steval_beaning

Well-Known Member
Newcomer
Joined
Feb 4, 2022
Messages
49
Trophies
0
Age
22
Location
some crap town
XP
477
Country
United Kingdom
seems very very good so far, it's great that someone finally managed to do this! only things i've noticed on twilightmenu on my new 3ds is that the music is slowed down slightly (for some reason) and that if you run, then jump, then press a at the peak of your jump, you'll almost always do a mid-air kick, whereas usually you'd be able to dive. (you can still jump then dive if you use the d-pad and run button) my mistake, it looks like that if you are still holding the jump button and press a you'll always kick. must be an intended mechanic i guess

the music slowdown seemed to be worse on the zl+zr patch

i should add that i'm testing on a european ROM, idk if that makes a difference...
 
Last edited by steval_beaning,

cearp

瓜老外
Developer
Joined
May 26, 2008
Messages
8,714
Trophies
2
XP
8,441
Country
Tuvalu
This reminds me of those patches for psp games that were made (mainly by the_flow) for vita.
Really nice, thanks for the work!
 

Dionicio3

goat
Member
Joined
Feb 26, 2017
Messages
4,046
Trophies
2
Age
20
Location
Hollister, CA
Website
dionicio3.com
XP
7,060
Country
United States
Question about how the cheat works. Does it simply map circlepad inputs to the touchscreen like most "analog mod" solutions? Or does it actually modify how inputs are read to correctly interpret the circlepad
 

shoco

Well-Known Member
OP
Member
Joined
Aug 1, 2019
Messages
110
Trophies
0
XP
476
Country
Russia
I've updated the patch. Unfortunately, I couldn't fix the problem entirely. Previously, CPad caused the music to slowdown by about 20%, and with ZL+ZR by 50%; now it's something like 9% for CPad and 12% for CPad+ZLZR. For some reason, I cannot eliminate it completely. As if the music somehow relied on a hardcoded delay of some sort and whatever I put in the VBlank IRQ handler just makes it longer. Or maybe that VBlank IRQ handler is just not the best place for it.

Now, instead of passing 5 bytes of data (cpad x, cpad y, zlzr, nub x, nub y), I pass only 3 (the nub is merged into zlzr on arm11's side). Plus, I also update the CPad once in 2 frames (it's 30 times per second overall) and the Nub once in 4 frames. Ideally, it should be fine since Arm9 reads the input only 30 times per second. In reality, though, that's not always the case, there may be 1 frame delay in the CPad input, but that's almost unnoticeable. At least, if I haven't messed up the code
Post automatically merged:

Question about how the cheat works. Does it simply map circlepad inputs to the touchscreen like most "analog mod" solutions? Or does it actually modify how inputs are read to correctly interpret the circlepad
Probably the first one? I am not familiar with the analog mod solutions, and I am certainly not an expert in all of this, but it goes something like this. The cheat contains code for all 3 CPUs. Code for Arm7 uploads Arm11's code through RTCom and repeatedly (inside the VBlank IRQ handler) sends a command to Arm11 to execute it. The code for Arm11 reads the CPad data from a certain place in the 3DS ram (where it's already calibrated and clamped into 2 bytes), as well as the Nub data from the corresponding I2C device, and then returns this through RTCom back to Arm7. Arm7 takes this data and saves it into some safe place where Arm9 can get it. The code for Arm9 is hooked into the game's routine that usually does the preprocessing of the touchscreen's input and dpad buttons. If Arm9 sees that the CPad's been touched, it reads the input, preprocesses (calculates the length of the vector, cosine, sine, etc) and saves it where the rest of the game's logic expects it to be
 

Jayro

MediCat USB Dev
Developer
Joined
Jul 23, 2012
Messages
12,843
Trophies
4
Location
WA State
Website
ko-fi.com
XP
16,666
Country
United States
Cool stuff. Now patch it so we can use either L or R to crouch/stomp, and you're the MVP.

Having it on R by default with no way to change it, is just stupid.
 

shoco

Well-Known Member
OP
Member
Joined
Aug 1, 2019
Messages
110
Trophies
0
XP
476
Country
Russia
It certainly sounds nice, but I can't get it to work on My O3DS, all it does is slow the music down by a lot.
I was curious if it would work on the old ones. Maybe it doesn't have enough time to initialize properly. Do you have the latest TwilightMenu and TWPatcher versions? It can be important (especially twpatcher).
Here, I added a significant delay in the RTCom init function. Can you try it? Just launch the game and wait for 1 minute or so until/if something happens. If it won't work, then I probably can't do much, at least without looking into your firmware.
Actually, you could as well try to run this "RtcomTestProject" file. It's just a simple Nds app for testing the cpad via rtcom, but for some reason it has higher chances to work than mario. Launch it in TwilightMenu and wait for a minute. If that works, at least the CPad position found by my code is correct
 

Attachments

  • action_replay_codes_slow.zip
    64.3 KB · Views: 122
  • RtcomTestProject.zip
    56.7 KB · Views: 116
Last edited by shoco,
  • Like
Reactions: Zense

steval_beaning

Well-Known Member
Newcomer
Joined
Feb 4, 2022
Messages
49
Trophies
0
Age
22
Location
some crap town
XP
477
Country
United Kingdom
one other thing I'll say is that it's very hard to do sideflips. it's like you have to put the circle pad in near to the exact opposite direction or otherwise mario will just turn. I'm guessing this is a consequence of how the touch controls work but I wonder if the range of sideflips could be increased?
 

Lemmingscanfly

Member
Newcomer
Joined
Mar 1, 2018
Messages
16
Trophies
0
Age
26
Location
Mount Olympus
Website
dobugsneeddrugs.org
XP
191
Country
Canada
I was curious if it would work on the old ones. Maybe it doesn't have enough time to initialize properly. Do you have the latest TwilightMenu and TWPatcher versions? It can be important (especially twpatcher).
Here, I added a significant delay in the RTCom init function. Can you try it? Just launch the game and wait for 1 minute or so until/if something happens. If it won't work, then I probably can't do much, at least without looking into your firmware.
Actually, you could as well try to run this "RtcomTestProject" file. It's just a simple Nds app for testing the cpad via rtcom, but for some reason it has higher chances to work than mario. Launch it in TwilightMenu and wait for a minute. If that works, at least the CPad position found by my code is correct

I was curious if it would work on the old ones. Maybe it doesn't have enough time to initialize properly. Do you have the latest TwilightMenu and TWPatcher versions? It can be important (especially twpatcher).
Here, I added a significant delay in the RTCom init function. Can you try it? Just launch the game and wait for 1 minute or so until/if something happens. If it won't work, then I probably can't do much, at least without looking into your firmware.
Actually, you could as well try to run this "RtcomTestProject" file. It's just a simple Nds app for testing the cpad via rtcom, but for some reason it has higher chances to work than mario. Launch it in TwilightMenu and wait for a minute. If that works, at least the CPad position found by my code is correct
I updated Twlpatch and Twilight menu and downloaded your fix, and it seems to work fine without the music being messed up.
But now the game crashes if I close my 3DS 😮‍💨
 

Sono

cripple piss
Developer
Joined
Oct 16, 2015
Messages
2,795
Trophies
2
Location
home
XP
9,194
Country
Hungary
Short reply: poggers




Long reply:
Yay, finally someone has did it! :grog:

It requires TWPatcher with RTCom enabled, although it's enabled by default and probably impossible to disable at that point.
I'm not a rich corporate monster, so there is a way to disable it! It just requires two click instead of one, so people don't accidentally untick it, because some patches do rely on rtcom being present (even if it does nothing), and don't want people who can't read be complaining that they get a black screen because they have disabled it.

Plus, it looks like the Nub stick requires some additional preprocessing as its values seem to be rotated 45 degrees, so more chances of not-working, but whatever.
That sounds about right, because they did mount it sideways for easier routing of the analog traces.


As for the slowdown, the timing is very weird. You have to request rtcom for the next frame after releasing it, otherwise you'll have to wait a whole frame to communicate.
There is also an autorelease function in the latest version, so the ARM11 won't get hanged if you forget to release it. I think you could use this to your advantage, to schedule a read from CStick controller, and just return that data instantly, so the ARM7 is hogged down for less time.

Also yes, rtcom init needs around 2-3 VBlanks before it's fully functional.
I can make you a debug build, which has raster bars for debugging timing, if you need it.
Oh also, rtcom doesn't work while any of the display controllers are off. Both screens must have a controller assigned, and after assigning display controller to both, you need to wait 2-3 VBlanks. This is a limitation of Nintendo's code, not mine.

Oh, and those complaining that sleep mode doesn't work, they are correct. Closing the lid wipes parts of VRAM, which is also where the rtcom payload is uploaded to. There is literally no more space to put any data into, so sadly this has to be solved on the DS side, to re-upload the payload.
 

shoco

Well-Known Member
OP
Member
Joined
Aug 1, 2019
Messages
110
Trophies
0
XP
476
Country
Russia
I updated Twlpatch and Twilight menu and downloaded your fix, and it seems to work fine without the music being messed up.
But now the game crashes if I close my 3DS 😮‍💨
I'm glad that it works, at least the arm11 part is fine. Can you also test one of these two, please? If the one with "200delay" won't work then "400delay". I'd like to use one delay value for all console versions.
As for the sleep mode crash, if I find the way to check for the sleeping mod and reupload the code, I'll update the patch. And maybe will do something with the music as well, somehow
Post automatically merged:

Short reply: poggers




That sounds about right, because they did mount it sideways for easier routing of the analog traces.

As for the slowdown, the timing is very weird. You have to request rtcom for the next frame after releasing it, otherwise you'll have to wait a whole frame to communicate.
There is also an autorelease function in the latest version, so the ARM11 won't get hanged if you forget to release it. I think you could use this to your advantage, to schedule a read from CStick controller, and just return that data instantly, so the ARM7 is hogged down for less time.

Also yes, rtcom init needs around 2-3 VBlanks before it's fully functional.
I can make you a debug build, which has raster bars for debugging timing, if you need it.
Oh also, rtcom doesn't work while any of the display controllers are off. Both screens must have a controller assigned, and after assigning display controller to both, you need to wait 2-3 VBlanks. This is a limitation of Nintendo's code, not mine.

Thanks for the info.

The debug version would be nice, I guess, if it's not too much work for you. I am not sure if I can properly utilize it, though

But I have a couple of questions if you don't mind.
1) Are there any detailed description of Rtcom and examples of its proper use? Maybe even with requesting data in one frame and getting in another? I think I tried that yesterday and obviously messed up as the timings were even worse.

Essentially, how I did the RtCom part was to simply get the example Rtc3DS project and throw away a bunch of unnecessary? things. That certainly did not help with understanding. Particularly, what does "rtcom_requestKill" do? Is Arm11 actually waiting until Arm7 will call requestKill or requestAsync(RTCOM_STAT_DONE)?

2) By "rtc init" in "rtcom init needs around 2-3 VBlanks" you mean initially uploading the code? Or beginning to execute it the first time?
Before, I uploaded the code on the first VBlank. But it looks like uploading a little later (5-10 vblanks) helps a little (i.e. further delays don't need to be too big). But when this number gets too high (20+ vblanks) or other delays to low (50-? vblanks), I start hearing strange cracking sounds in the main menu (on the save selection screen). Currenly I'm doing a 5 vblank delay before uploading, 200 delay before and after Nub/Cpad initializing and starting to poll data. It seems to be fine.
Post automatically merged:

Alright, I sort of solved the problem with the sleep mode crash and updated the patch. Now, the game won't use rtcom while the lid is closed and will reupload it when the lid'll be opened. Surprisingly, there are no cracking sounds, which I was expecting, given that the code is reuploaded long after the initial launch
 

Attachments

  • action_replay_codes_200delay.zip
    65.5 KB · Views: 105
  • action_replay_codes_400delay.zip
    65.7 KB · Views: 99
Last edited by shoco,
  • Like
Reactions: Nightcat and Zense

Sono

cripple piss
Developer
Joined
Oct 16, 2015
Messages
2,795
Trophies
2
Location
home
XP
9,194
Country
Hungary
Thanks for the info.

The debug version would be nice, I guess, if it's not too much work for you. I am not sure if I can properly utilize it, though

But I have a couple of questions if you don't mind.
1) Are there any detailed description of Rtcom and examples of its proper use? Maybe even with requesting data in one frame and getting in another? I think I tried that yesterday and obviously messed up as the timings were even worse.

Essentially, how I did the RtCom part was to simply get the example Rtc3DS project and throw away a bunch of unnecessary? things. That certainly did not help with understanding. Particularly, what does "rtcom_requestKill" do? Is Arm11 actually waiting until Arm7 will call requestKill or requestAsync(RTCOM_STAT_DONE)?

2) By "rtc init" in "rtcom init needs around 2-3 VBlanks" you mean initially uploading the code? Or beginning to execute it the first time?
Before, I uploaded the code on the first VBlank. But it looks like uploading a little later (5-10 vblanks) helps a little (i.e. further delays don't need to be too big). But when this number gets too high (20+ vblanks) or other delays to low (50-? vblanks), I start hearing strange cracking sounds in the main menu (on the save selection screen). Currenly I'm doing a 5 vblank delay before uploading, 200 delay before and after Nub/Cpad initializing and starting to poll data. It seems to be fine.

I'll try to dig up the debug scripts, as I don't think they work anymore. It should look like this while in use, except it should only fill up the screen to the point where any "script" is running on the ARM11.
I can put any debug info on the screen as well, as long as it only consists of hexadecimal characters. Please tell me what you need, and I'll make the patch!

Sadly information on rtcom got lost to time, as you're the first known one (besides Gericom and me) to even attempt to make use of this.
I'm reading the code of rtcom (3DS-side), and I'm severely cringing on how bad it is, it's really showing its age >.<
I'll leave a short guide in a spoiler at the end of this post, hopefully it'll be accurate.

Yeah, the very first time you test and init for rtcom, you'll need to turn on the display controller for both displays, write to the RTC, then busyloop for 2-3 VBlanks. If it times out, then rtcom is not installed.

Note: this might be wrong, I haven't touched rtcom in so long that this might be outdated, or just wrong. Please report if it works or doesn't.

Terminology:
- status register: FREE2 (?) or REG_113 (?)
- data register: FREE1 (?) or REG_112 (?)
- command: write to status register in a specific way
- data (byte): optional parameter to command, if the command accepts it
- release: rtcom will not wait for the DS to make a request anymore this frame
- async kill: command 0x00 (default status value), releases rtcom in a way, so the DS side doesn't wait at all for communication this frame
- synchronous kill: command 0xFE (invalid command), instantly releases rtcom back to default state, and writes state 0x00 on completion, so the DS side can detect the release
- request: command 0x01 (used to be valid, but now invalid command), request rtcom communication in a way, so it can be detected by the DS when the requests are ready to send
- autorelease: to prevent ARM11 from hanging indefinitely, there is a timeout to kill rtcom until requested again
- ACK: ACKnowledge, means success or continue (just like in I2C)
- NAK: Not AcKnowledge, means failure, or stop (just like in I2C)

Standardized commands:
- 0x00: no command, rtcom is released (does not wait at all on rtcom tick)
- 0x01: rtcom ping (invalid command), used in place of command 0x83 to request communication from rtcom, by waiting for it to reply with 0x82
- 0x80: ACK from ARM11 (replied by 3DS side on command success)
- 0x81: ACK from ARM7 (replied by DS side to continue streaming a data byte if the command needs a byte stream, because re-running the command again would restart its counter, and would be also slower)
- 0x82: NAK from ARM11 (replied by 3DS side if a command fails, or some cases if an invalid command was requested)
- 0x83: NAK from ARM7 (replied by DS side, used to request the 3DS to reply with 0x82 NAK, usually used for keepalive)
- 0x40: *does not exist anymore* GetProcAddress
- 0x41: UploadCode(u32 executable_size, u8... data), see example usage later. Used to be CPad test in early revisions.
- 0x42: UserCodeRWX(void), makes executable_size sized region of the uploaded code read-write-executable, the rest stays read-write only
- 0x44: UserCodeExecARM(u8 data), calls user code in a certain way, see later how to define user code
- 0xFE: invalid command, but is defined to synchronously release rtcom communication for the current frame
- 0xFF: *I forgot what this does/did, but is an invalid command*

After initing both display controllers, immediately try sending cmd 0x01 (which is an invalid cmd), and 2-3 VBlanks later you should get an RTC IRQ, with the status register being 0x82. If you don't, then rtcom is not present.
If rtcom is present, then you're ready to communicate until a timeout happens, or you manually release rtcom for this frame.

If you need more time before/after acquiring rtcom to process sending or requesting a command, keep rtcom alive by sending it a 0x83 command, and waiting for a 0x82 response. If you don't do this, then it'll time out, and autorelease to status 0x00, and you'll get ignored until next frame.

To use rtcom every frame, release it by writing command 0xFE, waiting for rtcom to synchronously kill itself (status becomes 0x00), then immediately write command 0x01. Next VSync, you should get an interrupt, and the status should be 0x82 (or you can also just busyloop, but that doesn't work too well). After that do your things, then release with 0xFE, [...].

To upload code, here is how your commands should look (> is DS to 3DS, < is 3DS to DS):
> 0x41, (codesize >> 0)
< 0x80
> 0x81, (codesize >> 8)
< 0x80
> 0x81, (codesize >> 16)
< 0x80
> 0x81 (codesize >> 24)
< 0x80

After this, you repeat the code bytes upload like this:
> 0x81, next code byte
< 0x80

Once you have written the last byte, and got a 0x80 response, you finish the code upload like this:
> 0x83
< 0x82

You can't execute the code yet (especially if it's a fresh upload, or you have overwritten it), you must make it executable:
> 0x42
< 0x80

After that, you can call the usercode with command 0x44.
The usercode must have the following signature: u8 usercode(u8 data, u8 iterator);
The usercode entrypoint must be written in ARM mode ARM Assembly, because both r0 and r4 must be modified before you return back to rtcom.
r0 will contain the return data, and r4 will contain if error code or no error.
If r4 is 0, then r0 will be returned as data byte, and return status will be 0x80. If r4 is nonzero, then r0 will be ignored (not written to data byte!), and the return status will be 0x82.

Usercode can be called in two ways:
- repeatedly via command 0x44, the value in data byte register will be passed into r0, and r1 iterator will be 0
- iteratively via command 0x81 after one 0x44 call: r0 will contain the last data byte written (if you did not modify it, then it will be the return value of the last 0x44 or 0x81 call), and iterator will have increased by 1. See example.

First way:
> 0x44, xx (let's assume this means get some status byte)
- yy = usercode(xx, 0)
< 0x80, yy
> 0x44, zz (let's assume this is an invalid data to call the usercode with)
- usercode(zz, 0)
< 0x82

Second way:
> 0x44, xx (let's assume this means to get two status bytes)
- y1 = usercode(xx, 0)
< 0x80, y1
> 0x81 (we did not modify the data byte)
- y2 = usercode(y1, 1)
< 0x80, y2
> 0x81, zz (we did modify the data byte, just for fun)
- usercode(zz, 2)
< 0x82

To execute code asynchronously, you have two options:
- rely on autorelease, which can cause timing issues ARM11-side, and also does not reserve rtcom for the next frame, but it's the easiest to implement if you can race rtcom request faster than the rtcom tick
- use interrupts to manually release rtcom once it has run the slow routines (like CStick reading routine), and read the data next frame

Hopefully the technical garbage is not too long or too overwhelming! Please ask more questions, I want to help :)
 
Last edited by Sono,
  • Like
Reactions: Nightcat and Zense

Lemmingscanfly

Member
Newcomer
Joined
Mar 1, 2018
Messages
16
Trophies
0
Age
26
Location
Mount Olympus
Website
dobugsneeddrugs.org
XP
191
Country
Canada
Wow I'll have to check the update out on my O3ds in a bit.
Post automatically merged:

I'm glad that it works, at least the arm11 part is fine. Can you also test one of these two, please? If the one with "200delay" won't work then "400delay". I'd like to use one delay value for all console versions.
As for the sleep mode crash, if I find the way to check for the sleeping mod and reupload the code, I'll update the patch. And maybe will do something with the music as well, somehow
Post automatically merged:



Thanks for the info.

The debug version would be nice, I guess, if it's not too much work for you. I am not sure if I can properly utilize it, though

But I have a couple of questions if you don't mind.
1) Are there any detailed description of Rtcom and examples of its proper use? Maybe even with requesting data in one frame and getting in another? I think I tried that yesterday and obviously messed up as the timings were even worse.

Essentially, how I did the RtCom part was to simply get the example Rtc3DS project and throw away a bunch of unnecessary? things. That certainly did not help with understanding. Particularly, what does "rtcom_requestKill" do? Is Arm11 actually waiting until Arm7 will call requestKill or requestAsync(RTCOM_STAT_DONE)?

2) By "rtc init" in "rtcom init needs around 2-3 VBlanks" you mean initially uploading the code? Or beginning to execute it the first time?
Before, I uploaded the code on the first VBlank. But it looks like uploading a little later (5-10 vblanks) helps a little (i.e. further delays don't need to be too big). But when this number gets too high (20+ vblanks) or other delays to low (50-? vblanks), I start hearing strange cracking sounds in the main menu (on the save selection screen). Currenly I'm doing a 5 vblank delay before uploading, 200 delay before and after Nub/Cpad initializing and starting to poll data. It seems to be fine.
Post automatically merged:

Alright, I sort of solved the problem with the sleep mode crash and updated the patch. Now, the game won't use rtcom while the lid is closed and will reupload it when the lid'll be opened. Surprisingly, there are no cracking sounds, which I was expecting, given that the code is reuploaded long after the initial launch
The 200 delay seems to work fine, the game comes back when I open my 3DS back up, and then the hack kicks back in after about 5 seconds. :)
 
Last edited by Lemmingscanfly,

shoco

Well-Known Member
OP
Member
Joined
Aug 1, 2019
Messages
110
Trophies
0
XP
476
Country
Russia
Wow I'll have to check the update out on my O3ds in a bit.
Post automatically merged:


The 200 delay seems to work fine, the game comes back when I open my 3DS back up, and then the hack kicks back in after about 5 seconds. :)
Great. Then I'll use this delay from now on. Thanks

I'll try to dig up the debug scripts, as I don't think they work anymore. It should look like this while in use, except it should only fill up the screen to the point where any "script" is running on the ARM11.
I can put any debug info on the screen as well, as long as it only consists of hexadecimal characters. Please tell me what you need, and I'll make the patch! :) ...............

Thank you, it's extremely helpful. I didn't even think about using the rtc interrupt. It'll take a lot of time to digest this. And I'll consider the debug thing too.

By the way, you could attach that RTCom description and link the Rtc3DS project in your TWPatcher topic. Maybe more people would make use of it.
 
  • Like
Reactions: Nightcat

Sono

cripple piss
Developer
Joined
Oct 16, 2015
Messages
2,795
Trophies
2
Location
home
XP
9,194
Country
Hungary
By the way, you could attach that RTCom description and link the Rtc3DS project in your TWPatcher topic. Maybe more people would make use of it.
The problem is that we couldn't find anyone who has enough romhacking knowledge, patching game code knowledge, enough knowledge of the DS to hack in brand new code (DS-side rtcom stub), and also have enough free time to work on it at all.
Also it turns out that rtcom has quite a limited amount of uses, so besides SM64DS, there aren't many more games which would benefit from access to extra hardware, so that's probably also why nobody has requested how to use rtcom.


As for the debug patch, I still need a few days to recover before I could work on it, sorry. It crashes the 3DS with a loud pop, which is rather unexpected...
 
  • Like
Reactions: Nightcat

Sono

cripple piss
Developer
Joined
Oct 16, 2015
Messages
2,795
Trophies
2
Location
home
XP
9,194
Country
Hungary
If there's mario 64 source code, why no one port mario 64ds addition to the 64 game?
Pretty sure SM64DS did not get leaked, so it's not possible, unless it also gets reverse-engineered (which takes a skilled team years), or gets leaked (extremely unlikely at this point).
 
  • Like
Reactions: Nightcat

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    Sicklyboy @ Sicklyboy: *teleports behind you* "Nothing personnel, kiddo" +1