Author Topic: Improving the Gameshark implementation  (Read 28427 times)

0 Members and 1 Guest are viewing this topic.

Online Kerr Avon

  • Hero Member
  • *****
  • Posts: 1651
  • Karma: +166/-3
    • View Profile
Re: Improving the Gameshark implementation
« Reply #15 on: August 23, 2014, 06:02 PM »
We had some success today. Still a few bugs to iron out...

That sounds brilliant! Can you go into detail about what you've done, or do you prefer to wait and make more formal announcements?

Either way, it's really great for us N64 fans!

Offline Modman

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +7/-0
    • View Profile
    • Kodewerx
Re: Improving the Gameshark implementation
« Reply #16 on: August 25, 2014, 07:56 AM »
We are in the testing phase. Catching bugs with certain games and Parasyte is fixing them as we go. Most games work fine.

Offline Kodewerx

  • Newbie
  • *
  • Posts: 29
  • Karma: +4/-0
    • View Profile
    • Kodewerx
Re: Improving the Gameshark implementation
« Reply #17 on: August 25, 2014, 12:21 PM »
I can provide some detail about what's happened in the past month with the project!

As you know, I'm working on saturnu's alt64 menu as a starting point. What I've done can roughly be described like this:

  • Replaced the cheat file parser with libyaml (cheat-files are now in YAML format)
  • Rewrote the simulate_boot() function
  • Wrote a brand new code engine
  • Formatting/whitespace fixes

The first point is really nice, IMHO. The cheat file format is now YAML! If you're not familiar with YAML, here's a sample:

Code: [Select]
---
# Super Mario 64 (U) [!]
Infinite Energy/Breath:
  - 8133B21E 08FF

L Button For Moon Jump:
  # With this code, you need to press and hold the 'L' button to rise up in the
  # air, and then let go when you are at your desired height to fall.
  - D033AFA1 0020
  - 8133B1BC 4220
  - D033AFA1 0020
  - 8133B17C 0300
  - D033AFA1 0020
  - 8133B17E 0880

Debug Mode: !off
  - A032D598 0001

Level Select: !off
  - A032D58C 0001

Improved Walk Up Hills: !off
  - 81253BF0 2400
  - 81264BBC 1000

The file starts with the optional header "---", can have comments starting with "#", each cheat name ends with a colon ":", each line of a cheat starts with indentation and a hyphen "-". And finally, you can tag the cheat names with "!off" if you want to turn the cheat off.

Second, the simulate_boot() function has been entirely stripped and rewritten, mostly in assembly. Assembly was required for a few reasons; I decided to use the CIC boot code to start the games, even when cheats are enabled. This is because some games cannot boot (or have problems) when the CIC boot code is skipped. I tried for *days* to get F-Zero X working properly with the CIC boot code skipped. Then I gave up and let the boot code do its thing. All CIC boot codes expect the CPU to be in specific states to work correctly. They all rely on certain information to be stored in registers s3-s7, CIC-NUS-6105 further relies on the state of the t3 and sp registers for decrypting stuff (along with part of the PIF boot code to be resident in RCP IMEM). The last part that's needed is the memory size variable stored at a different address for 6105... With this small state configured correctly, all CIC boot codes will work.

There are further interesting requirements for getting cheats to work while using the CIC boot codes. The first point is to copy the patcher/code engine into a location of memory where the CIC boot code won't touch it (mostly it just loads 1MB from ROM into some part of the first 4MB of RAM, but it does a lot of system configuration stuff, too). This is easy with an expansion pak! 4MB of extra RAM to play with... For those without an expansion pak, I'm considering trying to store the code engine in ROM space (there is plenty). The only trouble is that it might be too slow to work well. This deserves investigation... but I digress. After the patcher/code engine is stored where it will be safe, the CIC boot code is loaded and patched. The patch is typically very simple: replace the final jump instruction with a jump to the patcher. (6105 requires an extra patch to disable the checksum failure halt, because the first patch will cause checksum failures. 6106 requires encrypting the patched instruction.)

The patcher's job is to process the "master code" code types, which do things like disable the expansion pak (set the memory size to 4MB), set the code engine's destination memory address, and apply patches before starting the game. Obviously, the patcher is also responsible for relocating the code engine to its final location, since it's the only piece of code that knows where the master code wants it placed. Then the patcher installs a general exception handler, and protects it with a watchpoint (status quo for GS Pro-like behavior). Finally, it starts the game!

The code engine does a bunch of stuff. First, it handles watchpoint exceptions, to reroute the game's exception handler to an unused location (I use 0x80000120, the same as GS Pro). It also catches Pre-NMI interrupts to disable the watchpoint protection. This is needed because pressing the reset button doesn't clear the watchpoint, so it will break the menu's own exception handler when you reset! Pre-NMI occurs before reset, so it's the perfect place to uninstall the exception handler protection. And finally, the code engine does the grunt work of processing the code list. This is a REAL code engine, like Datel started doing with GBA; it's a loop that reads and executes one line of code at a time. It isn't pre-compiled into a giant assembly function like with GS Pro.

And that's about it! There are tons and tons of subtle details that are easy to miss, causing all kinds of unexpected crashes and even cheats to just not work. These kinds of bugs have taken the majority of my time on this project. I didn't have an ideal debugging environment setup for this work. My next N64 project will grant me one, however. That will be much nicer. On the bright side, I was able to patch several of the trouble games to spit out their exception context to USB. This made tracking some issues much easier, but it's not fool proof. This debugging code will not be included in the release. It's not as useful as it could be... But it sure is cool to watch!

TL;DR: Lots of codes work! All the codes? Almost. Most codes? YOU BET!
« Last Edit: August 25, 2014, 12:23 PM by Kodewerx »

Offline saturnu

  • ヽ(^o^)丿
  • Hero Member
  • *****
  • Posts: 1182
  • Karma: +156/-0
    • View Profile
    • :D
Re: Improving the Gameshark implementation
« Reply #18 on: August 25, 2014, 01:28 PM »
Greato! ^__^


Online Kerr Avon

  • Hero Member
  • *****
  • Posts: 1651
  • Karma: +166/-3
    • View Profile
Re: Improving the Gameshark implementation
« Reply #19 on: August 25, 2014, 08:27 PM »
Thanks for the detailed update, mate! This project is sounding better and better.

Offline Kodewerx

  • Newbie
  • *
  • Posts: 29
  • Karma: +4/-0
    • View Profile
    • Kodewerx
Re: Improving the Gameshark implementation
« Reply #20 on: August 26, 2014, 09:31 PM »
At this point, we believe it's stable enough for an initial release.

Download: https://s3.amazonaws.com/alt64-builds/alt64-0.1.8.6-cheat.zip
Source code: https://github.com/parasyte/alt64

Nothing has changed in the user interface. Same steps to enable cheats. The biggest difference is that you must convert your cheat-files to YAML. We've included a lot of example YAML cheat files that you can use as a template for formatting.

Happy cheating!

Offline lee4

  • codetype specialist
  • Hero Member
  • *****
  • Posts: 959
  • Karma: +55/-0
    • View Profile
    • gamehacking.org
Re: Improving the Gameshark implementation
« Reply #21 on: August 27, 2014, 12:31 AM »
At this point, we believe it's stable enough for an initial release.

Download: https://s3.amazonaws.com/alt64-builds/alt64-0.1.8.6-cheat.zip
Source code: https://github.com/parasyte/alt64

Nothing has changed in the user interface. Same steps to enable cheats. The biggest difference is that you must convert your cheat-files to YAML. We've included a lot of example YAML cheat files that you can use as a template for formatting.

Happy cheating!
Finally, I can cheat and save at same time  :D

Thank you very much, Parasyte    8)

Tested with Resident Evil 2  :)
ED64 v2.0, 3.0 & X7 | EDMD v3 | MEGAED X7 M15 v2.01 & PRO rev B | TED v2.4 | EDN8 v1.2N & Pro M19 N1 | SED v2.1 | SD2SNES rev E1 & PRO rev.B | EDGB v1.1 & X7 M17 rev B | EDGBA X5 M16 rev A & Mini M19 Rev B
RetroUSB AVS | Super NT | Mega SG | Super Retro Advance |  16bitPocket GBC | PCE+SSD3

Offline manorock850

  • Full Member
  • ***
  • Posts: 125
  • Karma: +1/-0
    • View Profile
Re: Improving the Gameshark implementation
« Reply #22 on: September 01, 2014, 12:14 PM »
I haven't bought in n 64 ever drive yet because of the lack of gameshark support.I was wondering should I wait for the new version of the N 64 to come out ?or is this just going to be fixed with an update? I'm not too technical on this stuff sorry guys.I know one thing I can't express how happy this makes me.blessings.I never in my wildest dreams imagine being able to play ROM sets use the actual hardware to cheat and play other regions Exedra on these amazing products this is just great!!

Offline saturnu

  • ヽ(^o^)丿
  • Hero Member
  • *****
  • Posts: 1182
  • Karma: +156/-0
    • View Profile
    • :D
Re: Improving the Gameshark implementation
« Reply #23 on: September 01, 2014, 01:17 PM »
i think ed64v2 and ed64v3 are both getting the same OS2.05? ^^
so it looks like an update to me.

Offline Mickkn

  • Full Member
  • ***
  • Posts: 179
  • Karma: +5/-0
    • View Profile
Re: Improving the Gameshark implementation
« Reply #24 on: September 02, 2014, 12:03 AM »
Any date for 2.05? :)

Offline manorock850

  • Full Member
  • ***
  • Posts: 125
  • Karma: +1/-0
    • View Profile
Re: Improving the Gameshark implementation
« Reply #25 on: September 02, 2014, 12:13 AM »
 thanks for the info I'm very excited.

Offline saturnu

  • ヽ(^o^)丿
  • Hero Member
  • *****
  • Posts: 1182
  • Karma: +156/-0
    • View Profile
    • :D
Re: Improving the Gameshark implementation
« Reply #26 on: September 02, 2014, 12:30 AM »
this is just based on speculation :D

Offline Modman

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +7/-0
    • View Profile
    • Kodewerx
Re: Improving the Gameshark implementation
« Reply #27 on: September 02, 2014, 02:00 AM »
Manorock, I've looked into all of the N64 carts available, and it was the simple fact that No One had a fully functional GameShark that sparked this project. I suspect the creator of the other carts will follow suit in implementing Paradyte's code engine in their menu, but, until they do, the EverDrive 64 is the only cart that has one. :) It was here first, thanks to Parasyte, and of course we couldn't have done it without Krikzz' awesome EverDrive, and Saturnu's open source menu as a starting point. Saturnu also helped out in other ways that helped speed development up a LOT. But the engine itself is all Parasyte's work. So, thank you Parasyte (Kodewerx), Krikzz, and Saturnu for each of your parts in getting this timeless project to completion. I hope nobody forgets how each of these people made this whole thing possible. :)

Offline saturnu

  • ヽ(^o^)丿
  • Hero Member
  • *****
  • Posts: 1182
  • Karma: +156/-0
    • View Profile
    • :D
Re: Improving the Gameshark implementation
« Reply #28 on: September 02, 2014, 04:43 PM »
it was my pleasure :3

Offline manorock850

  • Full Member
  • ***
  • Posts: 125
  • Karma: +1/-0
    • View Profile
Re: Improving the Gameshark implementation
« Reply #29 on: September 02, 2014, 05:20 PM »
I definitely won't forget guys god bless you guys for making an awesome project happen.I even sent krikzz the maker of the ever drives a message asking for this.I don't care who really knows it I love to cheat and cheating is fun for me I enjoy doing things with the game and the hackers and the programers of cheating devices make this possible for me.I've even offered to pay people for codes made for me and the generous people on here don't accept donations. Hackers just love helping others and supporting the hobby we love so much!! if it wasn't for you guys I wouldn't be able to have a chance with some games that I broke controllers over trying to beat it ha! I am very thankful for the project which means less frustration and less :P broken controllers.