Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GameShark and Game Booster emulation #1916

Draft
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

Jhynjhiruu
Copy link

@Jhynjhiruu Jhynjhiruu commented Apr 3, 2025

This pull request adds emulation for the Datel REF1329 and REF1256 PCBs, used in the GameShark Pro/Action Replay Professional cheat devices and Game Booster emulation device, respectively.

As a means to that end, it also adds PCB emulation in general to the N64 core, and introduces a ROM database with the intent to move to it over time.

Tasks remaining before merging:

  • Figure out UI/UX challenges
    • GameShark button
    • Ergonomic interface for loading ROMs
      • Good opportunity to clean up the experience for GB ROMs using a SGB
    • Parallel port?
      • TCP socket?
    • 7-segment display
      • Combine with infrastructure for the power button LED in the iQue Player PR?
    • Reset button
  • Confirm accuracy
    • Fix evil demon EEPROMs
      • Sort out the clock nightmare
    • Implement watchpoint exception properly
    • Check memory ranges to make sure I got them right
    • Fix open-bus behaviour
  • Finish implementation
    • Add remaining EEPROM scrambling quirks
    • Add registers for parallel port data and 7-segment display shift register
  • Code cleanup
    • General style
    • Board components
    • Deduplicate GAL code (between GameShark and Game Booster boards)
  • Finalise database infrastructure
    • Fix flash emulation
    • Add remaining board types
    • Fill in at least one example game with each board type
    • Decide on a style for game information

@jcm93
Copy link
Contributor

jcm93 commented Apr 6, 2025

Just some non-exhaustive UI thoughts:

  • Ergonomic interface for loading ROMs

    • Good opportunity to clean up the experience for GB ROMs using a SGB

I browsed the discussions off-thread about making GameShark use a checkbox in the UI, with perhaps a file selector button in the Configuration window allowing you to pick a GameShark firmware up front. I agree that that would be a superior UI to the existing experience of "Load the SGB ROM, then be prompted for a second Game Boy ROM". However, I don't think we necessarily need to do the same thing for the Super Game Boy that we want to do for the GameShark; the SGB is more niche than the GameShark on N64, and unlike the GameShark the SGB can't be used with any ROM in that system's library. The existing flow there makes sense to me in a way that the potential GameShark one does not.

GameShark button

What is the specific challenge here? Is there anything preventing us from making this similar to any other system-specific menu item with an associated action? I suppose we would also want to expose it as a bindable input, or hotkey? Similar question re: the Reset button.

  • 7-segment display

This seems like an interesting challenge. I think one thing that might be nice to start with is to expose its data in the memory editor/viewer.

@Jhynjhiruu
Copy link
Author

However, I don't think we necessarily need to do the same thing for the Super Game Boy that we want to do for the GameShark; the SGB is more niche than the GameShark on N64, and unlike the GameShark the SGB can't be used with any ROM in that system's library.

That's true, but also consider that other emulators expose SGB mode as if it were an option for GB games (e.g. they let you select between DMG, CGB, AGB and SGB), and something like that could make using the SGB in ares very easy and pleasant. Not necessary at all, but nice to have.

The other thing to consider is that the GameShark firmware runs from EEPROM and is writeable. I don't think it'll be hard to solve, since my code ought to handle that already, but worth bearing in mind.

I suppose we would also want to expose it as a bindable input, or hotkey?

Yeah, that's the main challenge - I don't know how to do that.

Also consider (eventual) integration with other forms of cheats; e.g. Project64 has a menu item for its built-in GS button, and I think other cheat systems in other cores need their own equivalent. Ideally, what we want is a robust system for different emulated PCBs to expose their own inputs/outputs. See also here.

I think one thing that might be nice to start with is to expose its data in the memory editor/viewer.

When experimenting with emulating GameShark firmwares in the past, I've logged the 7-segment display rendered to ASCII, which shouldn't be that hard. Ideally, we'd use the system mentioned here, but that doesn't exist yet (@LukeUsher bump?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants