![]() Register - Login |
||
| Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
||
| Jul - Posts by MarIO0 |
| Pages: 1 2 3 |
| MarIO0 Member Level: 14 Posts: 1/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Probably not useful, but it may be interesting to test some things.
|
| MarIO0 Member Level: 14 Posts: 2/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
|
Mario Y speed: 0x8033B1BC (IEEE 32-bit float) -> 0x4C inside mario _ obj. Mario X speed: 0x8033B1C4 (IEEE 32-bit float) -> 0x54 inside mario _ obj. Here's a GS code that sets the X speed to 400.0.
(Works best when flying). EDIT: Fix'd |
| MarIO0 Member Level: 14 Posts: 3/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Simple D program that finds SOME Mario actions.
|
| MarIO0 Member Level: 14 Posts: 4/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by VL-Tone The memory address of the table is loaded by the 2 instructions at 0x0x0007C8E0 (ROM). I've tried to change it's location, but the emulator hangs after I break the box, and when I look at the memory in Nemu64, it looks like it didn't load the part of the ROM where I put the table. |
| MarIO0 Member Level: 14 Posts: 5/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by messiaen I did manage to load the table in an unused but loaded part of the ROM shortly after my post. About the ADDIU instruction, I had this problem (I'm very new to MIPS assembly, but fortunately it isn't very hard to learn since I'm already decent with x86 assembly). Also fortunately, ADDIU and ORI take the same parameters, so just changing the opcode works. About the "Extended Memory support", it looks very interesting. I'll have to look at it ![]() Also, what debugger/disassembler do you use? I use Nemu64 and IDA Pro, but Nemu64 can't load "extended" ROMs. |
| MarIO0 Member Level: 14 Posts: 6/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
| Without having looked at the program, I believe that W7 and Vista has restrictions on WriteProcessMemory(), so that may be the problem. |
| MarIO0 Member Level: 14 Posts: 7/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
| Has anyone ever tried to make some kind of program, to try to detect if there are more unknown "hidden" coins, like the ones on SL or THI? I just ask to see if it has been attempted before, if it hasn't, I may try it. |
| MarIO0 Member Level: 14 Posts: 8/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
|
What's the best way to do a 32-bit comparison on GameShark? Here's what I have now, but it requires a lot of codes and a temporal variable:
EDIT: This can also be seen as "what's the best way to implement && and || in GameShark?". The example above can be seen as doing "if LOWORD(speed) == 0 && HIWORD(speed) == 0", just two 16-bit comparisons |
| MarIO0 Member Level: 14 Posts: 9/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by messiaen This is for an experiment I'm working on, to create a really simple programming-like language to create custom Mario 64 GameShark cheats. So I can't use optimized ASM code like this one. I could generate ASM code, but it doesn't give any benefit to the user, the codes would be longer, and it would require restarting the emulator to get it to work. This is the code above in the syntax for that language that I currently have in mind:
This is the syntax I have tought of: Conditional expressions: If, like C, no brackets required: if ((A == B && C != D) || (E == F)) Else, no "else if" allowed: else End: end Assignement:: Simply A = B Values can be either a value that is compatible with the type of the item (e.g. action = 0x12345678, allowed because "action" is of type uint) or a "named value" (e.g. action = flying) (the items, addresses, types and named values would be declared in an external and user-editable file). Implementing everything other than "if" is straightforward. "if" is a bit more complicated because of the difficulty to parse it (everything else can be just parsed by regular expressions) and the difficulty to generate GS codes for it. I don't know if it will be really useful, because it's very limited, but I think it may be useful to make cheats quickly without having to lookup every time an address list, convert the floating point number to bytes, etc. For example, something like a moon jump cheat would be very easy to implement:
(BTW, something like this doesn't already exist... right?) |
| MarIO0 Member Level: 14 Posts: 10/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by messiaen You can do AND and OR operations using the same trick I did above. For example, this code:
Would be equivalent to:
I use the Enhacklopedia as a reference for the Gameshark code types, and it doesn't look like it's possible to do any of those operations directly. One thing I've tought is that if I could create some code that jumps to a section of the RAM every frame, and make the code generator make codes for this RAM section (I haven't tested if it's possible to execute code from the RAM), this would allow implementing a few basic operations and simplify the conditionals code without having to restart the emulator every time. (I don't want to make the language complex... since you can already do complex code using C. The aim is to make something really simple so anyone, even non-programmers, can use it). |
| MarIO0 Member Level: 14 Posts: 11/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by messiaen I didn't remember about self-modifying code (this always gave me problems in Nemu64 while making cheats), so it would be impossible to do this unless emulators don't JIT the code in RAM, or there's some trick to avoid them from JITing, or I use an interpreter (maybe that is a good idea, since it would reduce the size of the code). |
| MarIO0 Member Level: 14 Posts: 12/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by HyperHacker That would be awesome, but the only problem is that I have no idea about how to do it or how it's typically done, plus Project64 is closed source so I wouldn't be able to do it for it. On Mupen64Plus it seems a good idea, since it's open source and it's available for Windows now. I'll look at it anyway ![]() It would also be possible to do it by reading the RDRAM directly with an external program (ReadProcessMemory, etc.) but that's harder. |
| MarIO0 Member Level: 14 Posts: 13/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
| Well I've been trying to add Lua to mupen64plus and I've just got "Hello World" working now, and it wasn't difficult to get it working because FCEUX and Snes9x have Lua (both have the same code) and I basically just copied it. The only thing I don't know is how the licenses for the code work, the Lua engine seems to have been initially added to Snes9x (which has a custom license, I don't know if it's GPL-compatible), but FCEUX is GPL'd and uses it so I guess that it's OK, but I don't know for sure. |
| MarIO0 Member Level: 14 Posts: 14/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
If you can't play using Mupen64 on Windows(The game crashes instantly after booting)Open the ROM in an hexadecimal editor (or a text editor that preserves the binary data), and find near the beginning of the file: M64: TheMissingStars And change the : to any other normal character, like _. (This happens because file names on Windows can't contain the : character, and Mupen64 crashes when trying to save the EEPROM because of no checks to see if the file can be opened). Hopefully this can be fixed in a new release. Dunno if it has been already reported. (I have been able to play using Mupen64 in Windows without doing this, but I don't remember what I did or why it doesn't work for me without this hack now). |
| MarIO0 Member Level: 14 Posts: 15/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
| What kind of Gamesharks can this program patch? Patches to the ROM, patches to the RAM, or both? |
| MarIO0 Member Level: 14 Posts: 16/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by ShenoxVII Mmm, sorry for making you look like a noob, but you absolutely don't need an hex editor to modify a file in any programming language I know. Assuming you're using C# (which is quite probable), it's as easy as:
|
| MarIO0 Member Level: 14 Posts: 17/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by ShenoxVII |
| MarIO0 Member Level: 14 Posts: 18/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
| Thanks! I once attempted to do something similar, but pretty much failed (got the decoding working, though). Did you figure out the decoding code from SRip or from something different? Also, I found in the VGMStream source that there are some Gamecube formats that are a bit similar to the algorithm for the N64 one (the << 0x0b >> 0x0b part), but not equal. Unfortunately VGMStream only has decoders, so it doesn't look like there's a predictor algorithm. Going to look into it. |
| MarIO0 Member Level: 14 Posts: 19/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
BTW, to anyone who's looking at the algorithm, at this part
What it's doing is the following:
Hope it looks more logic now. Still don't understand why it's this way. EDIT: I would rewrite it this way (WARNING: Code untested!)
|
| MarIO0 Member Level: 14 Posts: 20/43 EXP: 12194 For next: 877 Since: 09-03-09 Since last post: 628 days Last activity: 404 days |
|
||
Originally posted by messiaen That would be pretty simple, because each GS code has more-or-less a direct translation to MIPS assembler. It's just a matter of converting the GS codes to MIPS assembler, finding an empty area in the ROM to put them, and adding a call to that area in the game main loop. It requires some MIPS assembler knowledge. < /hint > |
| Pages: 1 2 3 |
| Jul - Posts by MarIO0 |
![]() |
Acmlmboard - 07/23/2013 b378.03 ©2000-2013 Acmlm, Xkeeper, Inuyasha, et al. |
| Query execution time: | 0.047634 seconds |
| Script execution time: | 0.084759 seconds |
| Total render time: | 0.132393 seconds |