Kodewerx :: View topic - [N64] Jet Force Gemini [U] [GS]

[afb4:0024] 80058F08: SW s4[00000000],0024h(sp[800F8DD0])
[afb1:0018] 80058F0C: SW s1[801BD7DC],0018h(sp[800F8DD0])

Offsets F8A0C and F8DE8 may contain, but will not always contain, player data block base pointer (+0x0BC)

S1=Player data base pointer + 0x0BC; add the following to S1 to acquire the addresses represented by these offsets' labels
+0x03A Byte that is set to 1 when an S.S. Anubis cell switch is destroyed
+0x11C Angle facing halfword; usually equal to horizontal aim halfword
+0x130 Vector added X?
+0x1A4 Pointer to data of enemy that has been targeted
+0x1C6/*1CA*/1CE/1DE Aim offsets (halfwords) - 1CA is horizontal aim and 1CE is gun's facing angle player-relative
+0x250 Vector added X?
+0x538 Timer that counts to 0 before the next bullet can be fired; set to 0 for ceaseless rapid fire for all guns
+0x53F Gun fuel byte; set to 0xA0-0xFF for infinite
+0x542 Pistol fuel byte; set to 0 for ceaseless rapid fire
+0x58C Jet pack fuel halfword; set to 0xDD0 for infinite
+0x7FA True health value; set to 0x40 for infinite

S1-0x0BC relative:
+0x00C/0x014 Horizontal position floats
+0x010 Vertical Position float
+0x020 Falling Speed
+0x09B Green flash from lock on when this byte < 4

Multiplayer

-0x7F0 Data Start
-0x7E4 X
-0x7E0 Z
-0x7DC Y
-0x618 Angle facing halfword
-0x1FC Timer that counts to 0 before the next bullet can be fired; set to 0 for ceaseless rapid fire for all guns
-0x1F5 Gun fuel byte; set to 0xA0-0xFF for infinite
-0x1F2 Pistol fuel byte; set to 0 for ceaseless rapid fire
-0x1A8 Jet pack fuel halfword; set to 0xDD0 for infinite
+0x006 Health byte

lui a0, 0x8006
addui a1, r0, 0x0001
sb a1, 0x5535(a0)

D1105304 0200
814017D2 0001
D1105304 0100
814017D2 0000

Code at 0x80000180 in RAM (interrupt handler) jumps to
0x80075030, the code of which is stored at 0xB0075C30 (ROM address)
Word from RAM to be added to checksum is loaded by instruction at 0x80000114
Checksum stored at 0xB0000014 is verified at 0x80000238
Putting 0 at 0xB0000788 (ROM) nops the branch at 0x80000238 that sends the game
into an infinite loop (when the checksum fails, anyway) (doesn't work)
Changing 0xB0000798 from 0x0411FFFF to 0x04110001 causes the infinite loop branch
to branch where the code would normally go (works in Nemu)
The above doesn't work in Mupen++; recalculating the checksums does
Changing 0xB0075C64 to 0x37480000 should change the checksum without modifying the code behavior
This also screws up the checksum stored at 0xB0000010 which is checked by 0x8000022C
New checksums for 10 and 14 are 0x6A7009EE and 0x27941788
This hack
   0xB0000010 = 0x6A7009EE
   0xB0000014 = 0x27941788
   0xB0075C64 = 0x37480000
Runs in Nemu, PJ 64 1.6 and Mupen64++
   (although, Nemu eventually fails to run the game and ignores checksums anyway)

Author:	Hextator [ Tue Mar 27, 2007 11:06 am ]
Post subject:	[N64] Jet Force Gemini [U] [GS]
snipped to other topics. - dlong First I'm going to post remakes of the old codes that needed some work. Example: The all guns codes required you to collect a gun before activating the codes on pain of not being able to switch weapons. Well, that's not a problem anymore. All guns for all characters in single player: 801E6251 0002 811E61EC FFFF 801E62C7 0002 811E6262 FFFF 801E61DB 0002 811E6176 FFFF and in Multiplayer: 800FEDD5 0002 810FED70 FFFF 800FEE75 0002 810FEE10 FFFF 800FEF15 0002 810FEEB0 FFFF 800FEFB5 0002 810FEF50 FFFF I spiffed up the infinite ammo codes so that they would put ammo into the kick ass beta weapon that apparently nobody knew about: Single player: 50001002 0000 811E626C 03E7 50001002 0000 811E61F6 03E7 50001002 0000 811E6180 03E7 Multiplayer: 50001002 0000 810FED7A 03E7 50001002 0000 810FEE1A 03E7 50001002 0000 810FEEBA 03E7 50001002 0000 810FEF5A 03E7 Now for the good stuff. Shoot through walls: 81018DC4 2400 81018DC8 2400 AUTOAIM: 8103A548 2400 8103A5B0 2400 8103A5B8 2400 8103A5C8 2400 8103A5EC 2400 8103A614 2400 8103A650 2400 8103A660 2400 8103A6B0 2400 8103A6B8 2400 8103A714 2400 8103A720 2400 8103A75C 2400 8103A788 2400 8103A790 2400 8103A7C4 2400 8103A7DC 2400 8103A7F8 2400 and a code to make the autoaim not shoot at your teammates ("Teammates? What teammates?" Um, yeah, teammates...I'll keep that a surprise for now :3) or the cell switches in S.S. Anubis (unless the switch has yet to be shot): 8103A80C 0810 8103A80E 0200 81400800 81CF 81400802 003A 81400804 55E0 81400806 0001 81400808 240E 8140080A 0000 8140080C 3C0F 8140080E 800A 81400810 81EF 81400812 5060 81400814 11E0 81400816 000D 81400818 3C0F 8140081A 800A 8140081C 81E8 8140081E 325D 81400820 3C0F 81400822 8040 81400824 25EF 81400826 17F0 81400828 8DF8 8140082A 0000 8140082C 2718 8140082E F810 81400830 530E 81400832 0001 81400834 240E 81400836 0000 81400838 2508 8140083A FFFF 8140083C 1100 8140083E 0003 81400840 25EF 81400842 0004 81400844 0810 81400846 020A 81400848 2400 8140084C 0800 8140084E EA05 81400850 2400 Yes. 1080 degree auto aim, but it tends to have better luck locking onto things in front of you, after which you can turn and face the other direction and fire at things you can't see with dead on accuracy. Works great with a rapid fire sniper rifle. Of which I have. Single player "Uber" Code: This code does a lot of shit. Infinite Health, Infinite Jet Pack Fuel, Rapid Fire, Instant and full charged gun meter, and even a nifty pointer dumping sequence that places the pointer to your dynamically allocated data in a static location, after which my other codes can use that pointer for various nifty effects. Keep in mind the original codes that did what this code does only worked in certain rooms, because they didn't use assembly editing to take care of the nasty dynamic allocation. But wait, there's a MULTIPLAYER version of this code! YAY 81011C4C 0810 81011C4E 0400 81401000 2442 81401002 0001 81401004 8DC1 81401006 004C 81401008 A020 8140100A FE04 8140100C A020 8140100E FE0E 81401010 2404 81401012 00FF 81401014 A024 81401016 FE0B 81401018 2404 8140101A 0DD0 8140101C A424 8140101E FE58 81401020 2404 81401022 0040 81401024 A024 81401026 0006 81401028 3C04 8140102A 8040 8140102C AC85 8140102E 0FFC 81401030 2484 81401032 17F0 81401034 8C85 81401036 0000 81401038 1025 8140103A 000D 8140103C 2484 8140103E 0004 81401040 3C05 81401042 8040 81401044 24A5 81401046 1800 81401048 1485 8140104A FFFA 8140104C 3C05 8140104E 8040 81401050 00A0 81401052 2025 81401054 8CA5 81401056 0FF8 81401058 30A5 8140105A 000F 8140105C 0085 8140105E 2021 81401060 AC81 81401062 17F0 81401064 24A5 81401066 0004 81401068 3C04 8140106A 8040 8140106C AC85 8140106E 0FF8 81401070 3C05 81401072 800A 81401074 80A5 81401076 325D 81401078 0005 8140107A 2880 8140107C 3C04 8140107E 8040 81401080 8C81 81401082 0FF8 81401084 5025 81401086 0001 81401088 0025 8140108A 0823 8140108C AC9A 8140108E 17D4 81401090 AC9B 81401092 17D8 81401094 AC81 81401096 17DC 81401098 AC82 8140109A 17E0 8140109C AC83 8140109E 17E4 814010A0 3C1A 814010A2 800A 814010A4 835B 814010A6 5060 814010A8 1360 814010AA 0018 814010AC 3C01 814010AE 8010 814010B0 8421 814010B2 5304 814010B4 3821 814010B6 0030 814010B8 1420 814010BA 0014 814010BC 3C1B 814010BE 8040 814010C0 8342 814010C2 325D 814010C4 2442 814010C6 FFFF 814010C8 277B 814010CA 17F0 814010CC 8F61 814010CE 0000 814010D0 1040 814010D2 000E 814010D4 2400 814010D8 8F7A 814010DA 0004 814010DC 277B 814010DE 0004 814010E0 2442 814010E2 FFFF 814010E4 8C23 814010E6 F81C 814010E8 AF43 814010EA F81C 814010EC 8C23 814010EE F820 814010F0 AF43 814010F2 F820 814010F4 8C23 814010F6 F824 814010F8 AF43 814010FA F824 814010FC 8423 814010FE F9E8 81401100 A743 81401102 F9E8 81401104 0810 81401106 0434 81401108 2400 8140110C 8C9A 8140110E 17D4 81401110 8C9B 81401112 17D8 81401114 8C81 81401116 17DC 81401118 8C82 8140111A 17E0 8140111C 8C83 8140111E 17E4 81401120 AC81 81401122 0FF8 81401124 8C85 81401126 0FFC 81401128 0800 8140112A 4715 8140112C 8DC4 8140112E 0068 "Why in the HELL is that so long?!" Well, the actual invincibility/rapid fire/jet pack fuel (yes, jet pack fuel in multiplayer :3) business only takes up a small chunk of code. The rest is dedicated to using logical checks to systematically dump the pointers of to each player's data into static addresses that are ordered based on which player is which. VERY useful for things such as player specific codes. Right, now, a code that makes use of those pointer dumps. The SPEED code. Makes you run insanely fast. 81009A48 0810 81009A4A 0300 81400C00 3C04 81400C02 8040 81400C04 8C84 81400C06 17EC 81400C08 2484 81400C0A FF44 81400C0C 10E4 81400C0E 0017 81400C10 2401 81400C12 0000 81400C14 3C04 81400C16 8040 81400C18 8C84 81400C1A 17F0 81400C1C 2484 81400C1E F810 81400C20 10E4 81400C22 0012 81400C24 2401 81400C26 0000 81400C28 3C04 81400C2A 8040 81400C2C 8C84 81400C2E 17F4 81400C30 2484 81400C32 F810 81400C34 10E4 81400C36 000D 81400C38 2421 81400C3A 0008 81400C3C 3C04 81400C3E 8040 81400C40 8C84 81400C42 17F8 81400C44 2484 81400C46 F810 81400C48 10E4 81400C4A 0008 81400C4C 2421 81400C4E 0008 81400C50 3C04 81400C52 8040 81400C54 8C84 81400C56 17FC 81400C58 2484 81400C5A F810 81400C5C 10E4 81400C5E 0003 81400C60 2421 81400C62 0008 81400C64 2400 81400C68 0810 81400C6A 032D 81400C6C 0020 81400C6E 2025 81400C70 3C01 81400C72 8010 81400C74 0024 81400C76 0825 81400C78 8021 81400C7A 5307 81400C7C 3C04 81400C7E 40A0 81400C80 4484 81400C82 9000 81400C84 5020 81400C86 0001 81400C88 2421 81400C8A FFFF 81400C8C 0020 81400C8E 082A 81400C90 5020 81400C92 0001 81400C94 4612 81400C96 2102 81400C98 4604 81400C9A 1480 81400C9C 4484 81400C9E 2000 81400CA0 5020 81400CA2 0001 81400CA4 4604 81400CA6 5282 81400CA8 460A 81400CAA 7100 81400CAC 0800 81400CAE 2695 81400CB0 3C04 81400CB2 800A 81400CB4 0800 81400CB6 2693 81400CB8 4604 81400CBA 1480 Works for each individual player. And now, an all purpose escape-the-map code for getting past ANY, and I mean ANY obstacle: Press Left and Right C to escape the map (player 1's controller only) 81016AB4 0C10 81016AB6 0100 81016AD8 0C10 81016ADA 0100 81400400 3C18 81400402 8010 81400404 8718 81400406 5304 81400408 3318 8140040A 0003 8140040C 3B18 8140040E 0003 81400410 1700 81400412 0004 81400414 2400 81400418 3C18 8140041A 42C8 8140041C 4498 8140041E 3000 81400420 03E0 81400422 0008 81400424 2400 81400428 33F8 8140042A 000C 8140042C 1300 8140042E 0003 81400430 C4C6 81400432 0000 81400434 03E0 81400436 0008 81400438 2400 8140043C C4C6 8140043E 0008 81400440 03E0 81400442 0008 81400444 2400 And a quick code to make the machine gun shoot in a STRAIGHT LINE, which is just...sweet. Except the rapid fire sniper rifle with auto aim and shoot through walls makes it pointless. 81038748 2400 81038764 2400 And now for the best part of my JFG hacking. I was able to bring the start menu of single player into multiplayer, which allows you to access the MAP menu and select a single player level. This effectively means 4 PLAYER CO-OP MODE, of which there are tons of pictures of on my photobucket. :3 This code could use some work, though. A much better version of this hack in the form of a ROM patch is mentioned later in the thread. D00A5060 0001 80403FF7 0001 D00A5060 0000 80403FF7 0000 D0403FF7 0001 800A4FC4 0001 D0105304 0010 800A4FC4 0000 D00A4FC4 0001 800A325D 000? D00A4FC4 0000 800A325D 0001 Where "?" is the number of players you will be playing with. Most of that code is just there to disable the split screen when in single player mode. In co-op mode, entering a single player level will turn off the split screen, so you have to force it to stay on or else the other players will be playing but unable to see what they're doing Now, lots of co-op mode bugs and issues revolve around the odd spawn points for the unaccounted players. Players 2, 3, and 4 have no business being in story mode, so the game just kinda puts them places. Well, here's a code that will fix that by warping them to wherever player 1 is, and facing the same direction, once player 1 presses L and R: No wait. I just remembered. This code was merged into the same hook as the multiplayer "Uber" Code, so scroll back up to that and you'll see that the code is so long because it dumps the pointers dynamically, makes the players brokenly powerful, AND warps them to wherever player 1 is when player 1 presses L and R. But really, that code is only my second longest code. :3 Before I post my LONGEST and possible my best code, I'll post the layout for multiplayer and single player player data in case anyone else wants to hack this game too. But first I'm gonna hit submit again and make sure this all processes X_x Okay, cool. Now, the long code. Why is it long? Because it's a completely custom save and load routine that allows you to save and load files in co-op mode! All of your files will be completely interchangeable between single player mode and co-op mode, but you may need to have at least two friends so that player 3 can load Lupus's data...Lupus tends to freeze co-op mode because his data structure is too weird (in fact, the infinite health part of my uber code doesn't work on him, but the rest of it does). 81075030 0810 81075032 0800 81075034 3C1A 81075036 8010 81075038 2400 81402000 FF41 81402002 57B0 81402004 3C1A 81402006 800A 81402008 835B 8140200A 5060 8140200C 1760 8140200E 0018 81402010 3C1A 81402012 8010 81402014 875B 81402016 5304 81402018 3B7B 8140201A 0020 8140201C 1760 8140201E 001D 81402020 3C1A 81402022 801E 81402024 275A 81402026 6010 81402028 3C1B 8140202A 8040 8140202C 277B 8140202E 4000 81402030 AF60 81402032 FFF8 81402034 AF60 81402036 FFFC 81402038 8F41 8140203A 0000 8140203C AF61 8140203E 0000 81402040 275A 81402042 0004 81402044 277B 81402046 0004 81402048 3C01 8140204A 801E 8140204C 2421 8140204E 6580 81402050 103A 81402052 0010 81402054 2400 81402058 3C01 8140205A 8040 8140205C 2421 8140205E 4570 81402060 103A 81402062 000C 81402064 2400 81402068 0810 8140206A 080E 8140206C 2400 81402070 3C1A 81402072 8040 81402074 8F5B 81402076 3FFC 81402078 1760 8140207A 0006 8140207C 275A 8140207E 4000 81402080 3C1B 81402082 801E 81402084 277B 81402086 6010 81402088 AF5B 8140208A FFFC 8140208C 0810 8140208E 080E 81402090 2400 81402094 3C1A 81402096 800A 81402098 835B 8140209A 5060 8140209C 1360 8140209E 0043 814020A0 3C1A 814020A2 8040 814020A4 8F5B 814020A6 3FF8 814020A8 1760 814020AA 0024 814020AC 3C1A 814020AE 8010 814020B0 875B 814020B2 5304 814020B4 3B7B 814020B6 0020 814020B8 1760 814020BA 003C 814020BC 3C1B 814020BE 8040 814020C0 AF7B 814020C2 3FF8 814020C4 3C1B 814020C6 8010 814020C8 277B 814020CA ED66 814020CC 3C1A 814020CE 8040 814020D0 275A 814020D2 415C 814020D4 8741 814020D6 0000 814020D8 A761 814020DA 0000 814020DC 275A 814020DE 0002 814020E0 277B 814020E2 0002 814020E4 3C01 814020E6 8040 814020E8 2421 814020EA 41D2 814020EC 503A 814020EE FFF9 814020F0 277B 814020F2 002A 814020F4 3C01 814020F6 8040 814020F8 2421 814020FA 4248 814020FC 503A 814020FE FFF5 81402100 277B 81402102 002A 81402104 3C01 81402106 8040 81402108 2421 8140210A 42BE 8140210C 143A 8140210E 0005 81402110 2400 81402114 277B 81402116 002A 81402118 275A 8140211A FE28 8140211C 0810 8140211E 0835 81402120 2400 81402124 3C01 81402126 8040 81402128 2421 8140212A 415C 8140212C 143A 8140212E FFE9 81402130 2400 81402134 0810 81402136 086B 81402138 2400 8140213C 3C1B 8140213E 8010 81402140 277B 81402142 ED66 81402144 3C1A 81402146 801E 81402148 275A 8140214A 616C 8140214C 8761 8140214E 0000 81402150 A741 81402152 0000 81402154 275A 81402156 0002 81402158 277B 8140215A 0002 8140215C 3C01 8140215E 801E 81402160 2421 81402162 61E2 81402164 503A 81402166 FFF9 81402168 277B 8140216A 002A 8140216C 3C01 8140216E 801E 81402170 2421 81402172 6258 81402174 503A 81402176 FFF5 81402178 277B 8140217A 002A 8140217C 3C01 8140217E 801E 81402180 2421 81402182 62CE 81402184 143A 81402186 0005 81402188 2400 8140218C 277B 8140218E 002A 81402190 275A 81402192 FE28 81402194 0810 81402196 0853 81402198 2400 8140219C 3C01 8140219E 801E 814021A0 2421 814021A2 616C 814021A4 143A 814021A6 FFE9 814021A8 2400 814021AC 3C1A 814021AE 8010 814021B0 0801 814021B2 D40E 814021B4 275A 814021B6 5790 Yes. I know. Terrible. But it works, so whatever, you know? Here's how you use it. First, you go into the single player file load menu. You copy the file you want to load to the slot you want to save in; this selects the slot you'll be saving in and loads the data of the file into the RAM. If you want to start a new game, do this anyway, because starting a new game still requires this unless you don't care where you save. Now, press L to copy the save data that was loaded into the RAM to a new place in the expansion pak area. (Oh, by the way, all my assembly editing codes require the expansion pak. I'm just that lazy. Speaking in retrospect several years later, I'd like to comment that pretty much none of the RAM in the lower 4 megabytes seems to be safe to use...even unused memory will be used eventually due to dynamic allocation.) Press B and select multiplayer mode and get a game going with the co-op menu code active. Now, either press L to load your save file, or pause and press Z to save your game, effectively starting a new file and skipping that over long intro cut-scene. Because of the nature of the code, I advise resetting after saving a new game and then loading that new game file normally, because the L button will load the file you didn't want to load and overwrite your new game if you haven't pressed it while in multiplayer. It only stops overwriting after the first press, after which it starts copying multiplayer data back to save RAM. Because of this, until you load a co-op game normally you won't be able to save most things. Because the code now fully loads and saves all save data and has allocated space in the save data for a fourth player, it can load and save everything now (at least, it should). As far as I can tell you can play through the whole game in co-op mode, except for the rooms that still seem to freeze the game (which is every single room if someone is playing as Lupus, apparently). Certain levels like Water Ruin will spawn the extra players on top of the ship, finishing a level prematurely and preventing play. To avoid this, hold L and R with the multiplayer uber code on as the landing cut-scene ends. The game won't load the screen until you release the buttons, so while you're sitting in darkness waiting for the level to load, count to like 5 before releasing L and R and it should finally load the level with all four players in player one's spawn position. "What if I want to play the Water Ruin by using the code to place all players in player one's position, but don't want to cheat by having the invincibility and rapid fire effects, etc.?" I'll work on some guide on which codes to NOP to deactivate specific parts of the code. Sure, you can disassemble the code and see the writes and nop them yourself, but you'd have to know which write is which to NOP specific cheats. Oh, I forgot to post that data structure, huh? Silly me. Here it is: Single Player Code: [afb4:0024] 80058F08: SW s4[00000000],0024h(sp[800F8DD0]) [afb1:0018] 80058F0C: SW s1[801BD7DC],0018h(sp[800F8DD0]) Offsets F8A0C and F8DE8 may contain, but will not always contain, player data block base pointer (+0x0BC) S1=Player data base pointer + 0x0BC; add the following to S1 to acquire the addresses represented by these offsets' labels +0x03A Byte that is set to 1 when an S.S. Anubis cell switch is destroyed +0x11C Angle facing halfword; usually equal to horizontal aim halfword +0x130 Vector added X? +0x1A4 Pointer to data of enemy that has been targeted +0x1C6/1CA/1CE/1DE Aim offsets (halfwords) - 1CA is horizontal aim and 1CE is gun's facing angle player-relative +0x250 Vector added X? +0x538 Timer that counts to 0 before the next bullet can be fired; set to 0 for ceaseless rapid fire for all guns +0x53F Gun fuel byte; set to 0xA0-0xFF for infinite +0x542 Pistol fuel byte; set to 0 for ceaseless rapid fire +0x58C Jet pack fuel halfword; set to 0xDD0 for infinite +0x7FA True health value; set to 0x40 for infinite S1-0x0BC relative: +0x00C/0x014 Horizontal position floats +0x010 Vertical Position float +0x020 Falling Speed +0x09B Green flash from lock on when this byte < 4 Multiplayer -0x7F0 Data Start -0x7E4 X -0x7E0 Z -0x7DC Y -0x618 Angle facing halfword -0x1FC Timer that counts to 0 before the next bullet can be fired; set to 0 for ceaseless rapid fire for all guns -0x1F5 Gun fuel byte; set to 0xA0-0xFF for infinite -0x1F2 Pistol fuel byte; set to 0 for ceaseless rapid fire -0x1A8 Jet pack fuel halfword; set to 0xDD0 for infinite +0x006 Health byte And last and possibly least, the first code I made for this game. Have All Ship Parts: 811E6044 FFFF Edit: Let it be noted that the bits for the ship parts are 1111 1111 ???? 1111. That is, bits 7-4 aren't related to the ship parts (there's only 12 ship parts, see). I don't know why there's a gap there or what those 4 bits are for but setting the halfword to 0xFFFF doesn't seem to hurt anything anyway. That ought to cover my currently short and still sweet N64 hacking career. No wait, I'm not getting paid for this (I ought to be!), so I guess it's not a career. Blast.

Author:	Dualscreenman [ Tue Mar 27, 2007 11:50 am ]
Post subject:
Wow... nice codes... And welcome.

Author:	Hextator [ Tue Mar 27, 2007 12:19 pm ]
Post subject:
Thanks Here's my photobucket. Lots of co-op mode screenshots and other showcasing of Jet Force Gemini codes. I also have a YouTube account (user "7eld") with at least one Jet Force Gemini video on it. Edit: Say, how would I go about getting my codes onto BSFree? I looked around for a way to submit there and found nothing. Will some kindly admin or mod come by, see this thread, and upload my beans? I dunno how that works. :\ 'nother Edit: Might as well get as much noob out of me in this post as possible. Who or what is Rune and why is s/he/it so shunned?

Author:	Parasyte [ Tue Mar 27, 2007 1:47 pm ]
Post subject:
Some information regarding Rune can be found here: http://kodewerx.net/forum/viewtopic.php?t=994, and even more within the Debate Klub and The Office forums.

Author:	smk [ Tue Mar 27, 2007 2:13 pm ]
Post subject:
Hah, some nice codes there. If my N64 was working still in good shape and all (and if I had a working GameShark) I'd so use the co-op mode with friends. Too bad though, my GS is broken for it and my N64 isn't in good shape as it used to be. Regardless, some nice codes here, it'd be even cooler if you did codes like these for GCN games!

Kodewerx https://www.kodewerx.org/forum/

[N64] Jet Force Gemini [U] [GS] https://www.kodewerx.org/forum/viewtopic.php?f=18&t=1170	Page 1 of 2

Author:	Hextator [ Tue Mar 27, 2007 2:25 pm ]
Post subject:
Wouldn't I need a much faster computer for that? This computer runs 4 player co op at 12 fps. Now, my mom's computer can clock 210 fps for single player mode, but I only get access to that computer 2 of every 14 days. Another obvious obstacle might be my disinterest in spending any money on hacking. Maybe I should, though; I'd say I've mastered most Thumb aspects and could really get into NDS hacking. I'm getting kind of tired of hacking stuff that's not on the cutting edge. By the choice of the games I've hacked it hasn't really been a problem though. Jet Force Gemini is timeless. And apparently so is GoldenEye; that new level editor looks sweet. If I WERE to get into GCN hacking, how would I go about doing so? Or should I say...how much $$ is involved, factoring in my need of a faster computer? :\ One last question: There's an N64 GameShark that supports connecting to your computer and copying and pasting codes directly onto the device, right? Because I worked hard to make sure those codes were real-hardware-friendly (as in don't require the player to turn the system on and off too much), and it would be a shame if all that effort led to them entering that 213 line save/load routine. :\ I totally need to by more USB controllers so my friends can come over and hit up some bosses with me :3 Edit: Read that thread by DSMan. Interesting rebellion stuff there.

Author:	Arcane [ Tue Mar 27, 2007 11:53 pm ]
Post subject:
Zeld wrote: One last question: There's an N64 gameshark that supports connecting to your computer and copying and pasting codes directly onto the device, right? Because I worked hard to make sure those codes were real-hardware-friendly (as in don't require the player to turn the system on and off too much), and it would be a shame if all that effort led to them entering that 213 line save/load routine. :\ I totally need to by more USB controllers so my friends can come over and hit up some bosses with me :3 Edit: Read that thread by DSMan. Wicked rebellion stuff there. Epic, even. I love this site even more now (I was really giddy when Arcane linked me here even though HyperHacker was the one who told me about it in the first place...) Clipped down to what I'm going to address... Yes, there's a port on the back of the Gameshark. I believe it's something along the lines of a printer port, oddly enough. if you want a high quality USB 2.0 controller for about $23 each, go for standard Xbox Controller Ses. Just clip the breakaway cable and add a USB male plug, then send me all the Xbox male plugs you're tossing. >:O And.. I had to link you here the second I saw the unhackable codes threads. You're the best person I know.

Author:	Parasyte [ Wed Mar 28, 2007 2:47 am ]
Post subject:
I believe the N64 GS was only capable of using about 100 lines of code in total. The Game Shark version with the LPT port is v3.1 - v3.3. For GCN hacking, you will need a broadband adapter ($35), an Action Replay ($30), a Game Cube SD adapter (You will probably have to build one yourself using an old memory card and a $10 SD card slot), an SD card ($5-50), and an SD card reader ($5). So it's about $100 to get started if you do not already have the equipment. There is more information available in the SDload readme and here: http://www.gc-linux.org/wiki/SDload

Author:	Mewy [ Wed Mar 28, 2007 5:11 am ]
Post subject:
Well, here it is: BB Adapter: No longer in shops. AR: € 39,99. Game Cube SD adapter: Look at CodeJunkies, Datel has a adapter. SD Card: € 10-20. Reader: € 10-30.

Author:	lemmayoshi [ Wed Mar 28, 2007 6:14 am ]
Post subject:
You can buy the broadband adapter from Nintendo's online store, IIRC.

Author:	Mewy [ Wed Mar 28, 2007 7:40 am ]
Post subject:
We don't have that.

Author:	Hextator [ Wed Mar 28, 2007 11:31 am ]
Post subject:
Arcane wrote: If you want a high quality USB 2.0 controller for about $23 each, go for standard Xbox Controller Ses. Just clip the breakaway cable and add a USB male plug, then send me all the Xbox male plugs you're tossing. >:O I don't play X Box anymore, but when I did, I figured out two things. The male console plugs are crap and break too damn easily, and the controller itself was only comfortable because I had to get used to it to sustain my Halo addiction (it was like a drug addiction with just as many bad side effects, really). Now that my XBL account has expired I see no point in playing X Box anymore, so I could probably afford tossing those plugs and using my controllers as USB controllers. But, as I said, the controllers themselves are clunky, so I'd rather just stick with the Logitech series. Same price, better comfort and reliability, and I'm guessing that there's more features... Arcane wrote: And.. I had to link you here the second I saw the unhackable codes threads. You're the best person I know. Don't be ridiculous, this entire forum has me trumped all over the place. One of the admins is freaking Parasyte. In fact, I can quote him (:shock:): Parasyte wrote: I believe the N64 GS was only capable of using about 100 lines of code in total. That is so fail >_< Parasyte wrote: So it's about $100 to get started if you do not already have the equipment. I could afford that but my parents would never allow me to spend more than like $20-50 on game stuff at once. I suppose I could just spend my money discreetly, but my lazy parents are always borrowing my money and they'll wonder where their loan office went to. Maybe I ought to trade my X Box and games in. I can always go to a friend's house to play X Box...oh wait, it's an X Box. It's worthless now.

Author:	Hextator [ Fri Mar 30, 2007 8:02 pm ]
Post subject:
I don't like double posting but I don't suppose this will be bumped by an edit. :\ ;Selective shoot through walls ;D Pad Left to activate ;D Pad Right to deactivate 80018D54 J 80401800 80401800 LUI S3, $8040 LW S3, $17D0 (S3) BNEZ S3, ShootThrough OR S3, R0, R0 BLEZ A1, ShootThrough NOP J 80018D5C NOP ShootThrough: J 80019014 NOP D1105304 0200 814017D2 0001 D1105304 0100 814017D2 0000 81018D54 0810 81018D56 0600 81401800 3C13 81401802 8040 81401804 8E73 81401806 17D0 81401808 1660 8140180A 0005 8140180C 0000 8140180E 9825 81401810 18A0 81401812 0003 81401814 2400 81401818 0800 8140181A 6357 8140181C 2400 81401820 0800 81401822 6405 81401824 2400 I just can't get this code to work 100%. I've looked at the ASM from all sorts of aspects and tried all kinds of versions of this code and the game just refuses to either make me always shoot through walls or never shoot through walls. It either lets me always shoot through walls or let me only shoot through certain walls, but it never goes back to making the level completely solid again. What a dumbtarded game. :\ adds dumbtarded to fire fux's becktionary Edit: I just realized that this code doesn't preserve the replaced instruction. I remade the code to take care of that and it made it to where you would always shoot through certain walls and never shoot through certain others regardless of the D Pad Left/Right avtivators. First of all, I see no programmable possibility for that to occur. Second, since fixing the replaced instruction only screws the code up, I decided to leave the NOPs I originally had and just say "screw it". Game's a bitch; not gonna take care of it if it's gonna be that way. What the hell kind of routine loads a byte into the return register, anyway? Edit again: This is really pissing me off. Can someone who gives a damn about N64 hacking check and see if I programmed that right? I swear I did but it's still not acting anything like I tell it to. I bet if I told it to jump to the replaced instruction and return with nothing else changed that it would make me shoot through walls at random anyhow. I can hand out an RDRAM dump for use by LemAsm if the person who's nice enough to verify my code needs to view the game's source. If you want to call it source. I call it retarded since it doesn't even know what it's doing... Edit again: I think I got it this time...I tried a completely different hook and made a similar "skip projectile X, Y, Z loads if in shoot through walls mode" routine, but for some reason the activators are backwards now. I don't care if the activators are backwards as long as it freaking works.

Author:	HyperHacker [ Sat Mar 31, 2007 12:00 am ]
Post subject:
Can I have your Xbox? :3 Also I'm pretty sure I've used >100-line codes before. If the game isn't using the Expansion Pak, try throwing the line FF480000 0000 in. If I understand correctly this will relocate the code handler to expanded RAM (while still leaving 512K for your added routines), giving tons of space. Speed could be an issue though. Also consider using the F0/F1 code types, which write once at boot and then are removed from the code list. These might get around the size limit, and if a game isn't using the Expansion Pak, it probably won't clear that area either, so you could use these to dump your routines into memory at startup and then have only a few active lines to hook the code to use them.

Page 1 of 2	All times are UTC - 8 hours [ DST ]
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Author:	Parasyte [ Sat Mar 31, 2007 8:34 am ]
Post subject:
I'm not sure if relocating the code engine will actually allow it to use more memory, but if Datel had the foresight to do so, that is good news. The problem with determining the maximum number of lines on N64 is that each line is compiled into an equivalent set of instructions. For example, a code like "80065535 0001" is compiled into something like: Code: lui a0, 0x8006 addui a1, r0, 0x0001 sb a1, 0x5535(a0) And conditionals are compiled into branches, etc. etc. Not all lines are compiled into three instructions, some are two, or four... Zeld, the problem you are having with your Shoot Through Walls code could very well be due to the emulator's dynamic recompiler. We've seen similar trouble throughout the years, and I've always considered it a fault of emulation, at its very core. When a dynarec is compiling the instructions it encounters, it will do so in blocks. Each block is a few KB in size, depending on the dynarec core. After the block is compiled, it is essentially static and will not be read or recompiled again (refreshed) until the block is labeled dirty. Blocks are only labeled dirty when some other block (or the code within this block) writes to any part of the block. At the point that an instruction in a dirty block needs to be executed, the core will fully recompile the block and label it clean (until the next 'dirty write'). That said, I'm fairly sure the problem is occurring from using this: Code: D1105304 0200 814017D2 0001 D1105304 0100 814017D2 0000 Which could be changing a halfword within a dynarec block (due to having instructions so close by in memory). But because it's a cheat engine doing the writing instead of emulated instructions, the block will not be labeled dirty when either of these writes occur. And so the dynarec will not see the change in that halfword at all! Of course, this is an oversimplified explanation. A lot of dynarec cores do a lot of weird things to help improve accuracy (while keeping speed up), including pseudo-random 'dirty guessing' where it will assume that certain blocks may be dirty, without being entirely sure. With this kind of work, it can recompile blocks seemingly at random and cause strange effects similar to your "programmable impossibility." For the record, similar things can also happen on consoles thanks to instruction and data caching algorithms in modern CPUs. If you attempt to overwrite an instruction, there is no guarantee that the new instruction will be executed until the data cache is flushed (all writes occur to the data cache, initially; to be placed in physical memory, the data cache must be flushed to physical memory) and the instruction cache is invalidated (labeled dirty so the CPU can refill the instruction cache from physical memory). Things things can be a very big pain in the ass to work with, so the knowledge is invaluable for any kind of low level programming or hacking. So there you have it. This is one of the reasons I have been peeved with N64 emulation for so many years. It obviously sucks, and it's not getting much better. GameCube, and I think NDS, are going down the same path.

Author:	Viper [ Sat Mar 31, 2007 8:45 am ]
Post subject:
Parasyte wrote: Zeld, the problem you are having with your Shoot Through Walls code could very well be due to the emulator's dynamic recompiler. We've seen similar trouble throughout the years, and I've always considered it a fault of emulation, at its very core. When a dynarec is compiling the instructions it encounters, it will do so in blocks. Each block is a few KB in size, depending on the dynarec core. After the block is compiled, it is essentially static and will not be read or recompiled again (refreshed) until the block is labeled dirty. Blocks are only labeled dirty when some other block (or the code within this block) writes to any part of the block. At the point that an instruction in a dirty block needs to be executed, the core will fully recompile the block and label it clean (until the next 'dirty write'). That said, I'm fairly sure the problem is occurring from using this: Code: D1105304 0200 814017D2 0001 D1105304 0100 814017D2 0000 Which could be changing a halfword within a dynarec block (due to having instructions so close by in memory). But because it's a cheat engine doing the writing instead of emulated instructions, the block will not be labeled dirty when either of these writes occur. And so the dynarec will not see the change in that halfword at all! I don't think dynarec is the issue here though. Far as I can tell, the ASM is loading a word from that address, NOT executing. I thought dynarec was only an issue on code that's executing. Maybe the rest of the routine was edited since you posted that. BTW, how the hell did you get JFG to run in Nemu anyway? I get access violation errors and shit.

Author:	Parasyte [ Sat Mar 31, 2007 8:49 am ]
Post subject:
The recompiled code is probably reading from its own block within the dynarec, though. Or some other stupid problem.

Author:	Hextator [ Sat Mar 31, 2007 10:08 am ]
Post subject:
Viper wrote: I don't think dynarec is the issue here though. Far as I can tell, the ASM is loading a word from that address, NOT executing. I thought dynarec was only an issue on code that's executing. Maybe the rest of the routine was edited since you posted that. My thoughts exactly. Viper wrote: BTW, how the hell did you get JFG to run in Nemu anyway? I get access violation errors and shit. Aha, that's where I get my excuse to self proclaim genius. I'm not using Nemu, I'm using Project 64. "Project 64 doesn't have debugging capabilities" No, but Cheat Engine does, and I've done enough reading through Project 64's own assembly to learn where it stores the current MIPS PC. Odd thing is it only refreshes the PC each time it reaches a branch or jump (I imagine it only even keeps the PC there to use it for the block matching thing I read about that supposedly makes the emulator run faster?), so I only get the general area of the instruction I'm looking for, and it's usually simple enough to find. I use Cheat Engine to dump the RDRAM and view it using LemAsm after fixing it from little endian to big endian and there's your ASM hack. Lastly, because I'm using cheat engine for all of this, I can read the instructions step by step to see if it's working the way it's supposed to. It's a little hazy since I wrote it in MIPS and I'm debugging it in x86, but for the most part it says it's working fine even when it isn't. In fact, my speed code doesn't seem to work in single player anymore; I read the x86 recompile disassembly and it did everything correctly, and yet I still wasn't blazing around the map at insane speeds. Really annoying. Edit: In case you guys missed it, I DID fix that code. It's edited in my previous post. Also, here's some addresses for the PJ64 application to help out anyone using cheat engine in hacking games on PJ64: RDRAM is stored at 0x3AD70000 PC is stored at 0x4D5280 General Purpose registers are stored at 0x4D52E8 SP is stored at 0x4D53D0 RA is stored at 0x4D53E0 Um...that's about it. :\ Edit: I found the problem with my speed code and fixed it. It's edited in the first post of this thread.

Author:	HyperHacker [ Sat Mar 31, 2007 11:53 am ]
Post subject:
You'd think they would just mark a block dirty any time a GS code modifies it. >_>

Author:	Parasyte [ Sat Mar 31, 2007 2:22 pm ]
Post subject:
Yes, but it would cause massive slowdowns. The only thing the stupid emulator authors care about is speed. Accuracy is the least of their worries. "As long as it works."

Author:	Hextator [ Tue Mar 09, 2010 4:29 pm ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
I've gathered this information concerning patching GS codes into the ROM: Code: Code at 0x80000180 in RAM (interrupt handler) jumps to 0x80075030, the code of which is stored at 0xB0075C30 (ROM address) Word from RAM to be added to checksum is loaded by instruction at 0x80000114 Checksum stored at 0xB0000014 is verified at 0x80000238 Putting 0 at 0xB0000788 (ROM) nops the branch at 0x80000238 that sends the game into an infinite loop (when the checksum fails, anyway) (doesn't work) Changing 0xB0000798 from 0x0411FFFF to 0x04110001 causes the infinite loop branch to branch where the code would normally go (works in Nemu) The above doesn't work in Mupen++; recalculating the checksums does Changing 0xB0075C64 to 0x37480000 should change the checksum without modifying the code behavior This also screws up the checksum stored at 0xB0000010 which is checked by 0x8000022C New checksums for 10 and 14 are 0x6A7009EE and 0x27941788 This hack 0xB0000010 = 0x6A7009EE 0xB0000014 = 0x27941788 0xB0075C64 = 0x37480000 Runs in Nemu, PJ 64 1.6 and Mupen64++ (although, Nemu eventually fails to run the game and ignores checksums anyway) I'm curious about how I should properly detect the expansion pak (I intend to put my code there instead of wasting time looking for free space in the RAM and don't want to actually do anything if there's no expansion pak). I'm also curious if there's a simpler way to get around the checksum issue in a way that both works for at least Mupen++ and doesn't require so much checksum recalculation. I'm out of ideas of what to change in the boot code to make the damn thing run. It feels like Mupen is just HLE'ing the boot code. Anyway, my plan was to simply check if 0x80000318 is >= 0x00400000 and then change it to 0x00400000 if it is (as well as enabling the code patching). For the actual code patching I was going to make it nice and GameShark compliant by loading a bit of code from some unused, non-checksum-protected area of the ROM into the expanded RAM and linking it to the code called by the interrupt handler. The code in the expanded RAM would, using a boolean to only do this once, clear the code that loads it the expanded RAM code where it is (why leave it there if it's no longer necessary?) and then proceed to interpret some GameShark codes that would be at a fixed location relative to the start of the code loaded into expanded RAM (they would be loaded with the code). This way it'd be easy to make GameShark codes and then allow them to be patched into the ROM, or make "ROM hacks" and then use them as GameShark codes, by simply appending new GS formatted code onto the bit of data being loaded to expanded RAM. Is any of this sane? Should I invent a different format for the "code types" that does block copying instead? Maybe I shouldn't load the GS codes to RAM at all. They can just stay in the ROM. The code in the RAM will know where to find them. I'd rather not need to re-assemble anything should I change my mind about what to patch into the ROM, so I'm pretty stubborn about interpreting "code types" instead of simply hard coding the patching. Any other suggestions however are welcome.

Author:	Parasyte [ Tue Mar 09, 2010 9:26 pm ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
You're talking about patching the CIC bootcode? Why not just patch the ROM the way you want and recalculate the CRCs with uCON64?

Author:	Viper [ Tue Mar 09, 2010 9:45 pm ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
Yeah, most of what you'd want to accomplish with applying normal codes could be done with direct ASM hacks if you're inclined. Problem is getting games like that to actually run on something you can breakpoint, which I why I can see a use for your method. I had wanted to add some functionality for patching codes to ROM that way in Renegade before, but I never got around to it.

Author:	Hextator [ Wed Mar 10, 2010 12:21 am ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
Parasyte wrote: You're talking about patching the CIC bootcode? Why not just patch the ROM the way you want and recalculate the CRCs with uCON64? Is that not basically what I'm doing? I'm editing the lowest megabyte of the ROM and recalc'ing the CRCs at 0x10 and 0x14. Except I'm using Nemu breaks to get the new CRCs. Viper wrote: Yeah, most of what you'd want to accomplish with applying normal codes could be done with direct ASM hacks if you're inclined. Problem is getting games like that to actually run on something you can breakpoint, which I why I can see a use for your method. I had wanted to add some functionality for patching codes to ROM that way in Renegade before, but I never got around to it. The code I want to modify is in the checksum protected area anyway. Also the other code I want to patch into the ROM is not an ASM hack. It is a straight GS code and if I did write it as an assembly hack to make it more robust it would still need a constantly executed hook, like the one I'm using. And yes, JFG doesn't work in Nemu after it tries to load the title screen, so any in game debugging must be done another way (I had been using CE to debug the emulated data and not the data it represented).

Author:	Parasyte [ Thu Mar 11, 2010 4:06 pm ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
Zeld wrote: Except I'm using Nemu breaks to get the new CRCs. No wonder you were trying to hack the bootcode! Why not walk the easy path?

Author:	Hextator [ Thu Mar 11, 2010 4:57 pm ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
Hm? Everything's easy enough. I just wish ucon64 would not freeze or whatever it's doing and actually update the checksums instead of just saying what they should be. Anyway I'm done screwing with the checksum. I have a bit of code in the CRC'd area that loads code outside of it, with the CRCs already recalculated. Now I just have to code the...code...handler. Here is the spec I have implemented so far for the code types. Thoughtopinions?

Author:	Hextator [ Thu Mar 25, 2010 3:22 am ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
Here is the hack I turned up. It is a training system that lets you execute codes that meet the above specification when placed in the ROM at 0xB1FFF000. So long as you comfort the dynarec system of mupen64++ by wrapping assembly modifying codes with conditionals, you can use the system with that emulator to have cheat support for online games...at least, I'm pretty sure...and at the same time, this game in particular becomes an option for a hacked game to play online with your friends as mupen64++ is the only emulator that both has online support and support for this game. First, the assembly that loads the codes/trainer: http://pastebin.com/zVha2KYV The code at the above link goes at 0xB0075CC4. It has comments explaining what to update the checksums to. No more updating checksums from here on, ideally. Now, the trainer assembly itself: http://pastebin.com/KETt6vVg The code at the above link goes at 0xB1FFE000. Finally, some sample codes in a form that can be assembled into raw binary to locate at 0xB1FFF000: http://pastebin.com/zZ5fh0R9 If you need that stuff and it's not on pastebin, get 7zip, extract this archive, then navigate to /Jet Force Gemini/Training/ and have a look. Enjoy. I'll work on spiffing up my co-op hack codes to function better/work with this trainer. As well as making new codes to handle co-op issues I hadn't yet handled back when I first made the hack years ago.

Author:	Hextator [ Sun Apr 04, 2010 10:32 pm ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
Co-op mode ROM hack has been released; it's a beta release in that it's not really fully functional, but it should be functional enough to play most of the game with your friends and, if you get stuck, you should be able to get unstuck by playing the game in single player until you can get further in multiplayer again. The hack allows you to save and load progress you make in the multiplayer mode of the game, effectively allowing you to play through the campaign with your friends without forcing them to be that stupid robot like in normal co-op. Aside from managing save information for you, this hack also gives you access to the single player menu, which, once I fix some bugs, will let you choose which level you would like to play on. In the mean time you're stuck playing the levels in order until you're stuck completely. To use the hack, download my doc, then navigate to this directory: Hextator's Doc/Jet Force Gemini/Training/Co-Op Hack/Patch and How to Use/ and follow the instructions. Have fun~ Note: This hack works in mupen64++. You theoretically can use the emulator's online features to play co-op online! However, if you dig around in the directories nearby a bit, you can find info on GameShark codes that will enable usage of a mostly similar form of this hack for Project 64. Project 64 emulates the game better and one of the issues the hack has in Mupen is absent from Project 64; however, Project 64 does not have online support! The version that does is too old and does not get around the copy protection that keeps you from firing your weapons. Also note, the ROM hack is tailored to Mupen with online play in mind, and for some reason crashes Project 64. The GameShark codes for Project 64 would crash Mupen even if Mupen had cheat support (which I didn't find) because of another emulation bug in Mupen that is only resolved in the ROM hack version of the hack.

Author:	James0x57 [ Tue Apr 06, 2010 3:45 am ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
That's really cool man, nice work.

Author:	Hextator [ Wed Apr 07, 2010 2:44 pm ]
Post subject:	Re: [N64] Jet Force Gemini [U] [GS]
I've been busting my balls to get it playing online, but the only person willing to try so far can't seem to get by without a desynch occurring. I'm fairly certain it's not the hack because his connection has about twice my ping and his save isn't loading when we go to the single player menu. Not to mention I've played multiplayer online in the original game just fine, and this other guy can't even get to multiplayer even if we both delete our saves and skip the single player menu. Edit: My buddy and I appear to be in sync now. The hack seemed to be working as well. Have fun I guess!