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

GBA hardware extensions #2251

Open
wants to merge 24 commits into
base: master
Choose a base branch
from

Conversation

kaisermg5
Copy link

As we were discussing on discord, here's the draft PR for GBA hardware extensions.
Whats is currently implemented is:

  • Allow games to access functionality not available in a real GBA console, via reading/writing data to non-existant I/O registers.
  • One extension called "More RAM" (subject to change), that allows a game to read/write data to a 1MB long memory.
  • Serialization and deserialization for extensions data.
  • The ability for the user to enable/disable extensions (disabled by default), individually or globally.
  • Command line arguments to enable/disable extensions.
  • Qt ui to enable/disable extensions.

Copy link
Member

@endrift endrift left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of stylistic issues/nitpicks, and some questionable design choices need to be addressed before this is mergeable. I haven't given everything a deep look-over yet as a result.

Comment on lines 64 to 66
// Extensions
bool hwExtensions;
uint16_t hwExtensionsFlags[HWEX_FLAGS_REGISTERS_COUNT];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should not be in the core opts since they're specific to one core.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed them.

Comment on lines 164 to 165
size_t (*hwExtensionsSerialize)(struct mCore*, void** sram);
bool (*hwExtensionsDeserialize)(struct mCore*, const void* sram, size_t size);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would probably make more sense to have a "generic" extdata serialize that you specify via passing in an extdata flag.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@@ -16,6 +16,7 @@ enum mStateExtdataTag {
EXTDATA_SAVEDATA = 2,
EXTDATA_CHEATS = 3,
EXTDATA_RTC = 4,
EXTDATA_HW_EXTENSIONS = 5,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extensions should probably have a larger ID, I'm trying to reserve low IDs for things that are standard on systems. Maybe 0x80.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe 0x1F? To make it consistent with the SAVESTATE_HW_EXTENSIONS define.
Since flags in mCoreLoadStateNamed and mCoreSaveStateNamed are declared as int, so I shouldn't exceed 32 bits.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The SAVESTATE_HW_EXTENSIONS define is fine--note that there's one for metadata already, which is everything over 0x100, so you don't necessarily need to worry about this one exceeding that bit count.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Changed the enum to 0x80 and left the define as it was.

Comment on lines 41 to 42
char hwExtensions;
char hwExtensionsFlags[HWEX_EXTENSIONS_COUNT];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above about configuration. Passing in via a -C flag is probably a better idea, at least for now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also removed this.

@@ -123,6 +124,8 @@ struct GBA {
bool debug;
char debugString[0x100];
GBADebugFlags debugFlags;

struct GBAHardwareExtensions hwExtensions;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would probably group this with the other components closer to the beginning.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Moved it under the SIO.

src/gba/hardware-extensions.c Outdated Show resolved Hide resolved
Comment on lines 89 to 94
case REG_HWEX_ENABLE_FLAGS_0:
case REG_HWEX_ENABLE_FLAGS_1:
case REG_HWEX_ENABLE_FLAGS_2:
case REG_HWEX_ENABLE_FLAGS_3:
case REG_HWEX_ENABLE_FLAGS_4:
case REG_HWEX_ENABLE_FLAGS_5: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the purpose of making these registers generic? Why not just have a fixed address per extension?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No particular reason. This way they occupy 1 bit instead of 16. But yeah, I could change it so it works the same as REG_HWEX_ENABLE.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Comment on lines 85 to 100
case REG_HWEX_ENABLE:
return 0x1DEA;
case REG_HWEX_VERSION:
return REG_HWEX_VERSION_VALUE;
case REG_HWEX_ENABLE_FLAGS_0:
case REG_HWEX_ENABLE_FLAGS_1:
case REG_HWEX_ENABLE_FLAGS_2:
case REG_HWEX_ENABLE_FLAGS_3:
case REG_HWEX_ENABLE_FLAGS_4:
case REG_HWEX_ENABLE_FLAGS_5: {
uint32_t index = (address - REG_HWEX_ENABLE_FLAGS_0) >> 1;
return *GetHwExIOPointer(gba, address) & gba->hwExtensions.userEnabledFlags[index];
}

default:
return *GetHwExIOPointer(gba, address);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

case statements are unintended, only their content.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

src/gba/hardware-extensions.c Outdated Show resolved Hide resolved
src/gba/hardware-extensions.c Outdated Show resolved Hide resolved
@@ -16,6 +16,7 @@ enum mStateExtdataTag {
EXTDATA_SAVEDATA = 2,
EXTDATA_CHEATS = 3,
EXTDATA_RTC = 4,
EXTDATA_HW_EXTENSIONS = 5,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The SAVESTATE_HW_EXTENSIONS define is fine--note that there's one for metadata already, which is everything over 0x100, so you don't necessarily need to worry about this one exceeding that bit count.

@@ -0,0 +1,16 @@
/* Copyright (c) 2013-2021 Jeffrey Pfau
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file should still be merged into extensions.h--there's no strong reason to keep it separate.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@@ -13,6 +13,7 @@ set(SOURCE_FILES
cheats/parv3.c
core.c
dma.c
extra/extensions.c
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extras go in the EXTRA_FILES section below, but the feature will need to be able to be ifdef'd out for that to work.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I ifdef'd under MINIMAL_CORE or do I create a new define?

…from core options. Renamed said options in the gba core. Renamed "More RAM" to "Extra RAM". Removed flags registers and added one register to specifically enable the extra RAM extension.
…sions serialization functions with more generic extdata serialization functions.
…hree more commands to the extra RAM extension: init, resize and destroy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants