## Description
This allows the menu to boot ROMs with 1 MBit saves.
## Motivation and Context
Without this I get "Error occured during save loading" when trying to
load a ROM using this save type in the header.
## How Has This Been Tested?
From a libdragon install, run `ed64romconfig --savetype sram1m file.z64`
on any ROM to change the header byte, then try to load it in the menu.
With the patch, the ROM should load successfully. Sample using a test
ROM here:
[test_sram1m.zip](https://github.com/user-attachments/files/21261604/test_sram1m.zip)
## Screenshots
None
## Types of changes
- [ ] Improvement (non-breaking change that adds a new feature)
- [X] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
- [X] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [X] All new and existing tests passed.
Signed-off-by: lategator <212063191+lategator@users.noreply.github.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved compatibility for games using the 1Mbit SRAM save type,
ensuring proper save data handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Robin Jones <networkfusion@users.noreply.github.com>
This improves emulation of cold boot, as otherwise the FPU might start
in an unexpected state.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Improved initialization procedures during system boot for enhanced
stability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Fixes the savetypes used by certain emulators and improve documentation.
* Neon64 2.0 Beta 4 (adds note to documentation that v1.2 or v0.3c
should be used).
* GB64 (reverts to using FRAM saves with comment for FRAM_FAKE
requirements.
We may have to wait for
f546e5d17d
or emu creators to correctly implement saves to truely fix this.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
It has been reported that saves were not working with:
* Neon64 2.0 Beta 4.
* GB64
(potentially after SC64 F/W 2.18.1)
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
On a SummerCart 64 with F/W version 2.20.2
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [x] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
You agree with the license terms and that other license types may be
granted with permission of the original `N64FlashcartMenu` project
license holders.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated NES emulator entry with new version, attribution, and official
URL.
- Added warnings about save issues in Neon64 v1.2/v0.3c and neon64v2
beta releases.
- **Bug Fixes**
- Enhanced save compatibility for GameBoy and GameBoy Color emulators to
reduce save-related problems.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
### Release Notes 2025-03-31
- **New Features**
- Introduced tabs in main menu for ROM favorites and recently played ROM
history.
- Introduced first run check to ensure users are aware of latest
changes.
- Introduced ability to turn off GUI loading bar.
- BETA_FEATURE: Introduces ROM descriptions from files.
- BETA_FEATURE: Enabled setting for fast ROM reboots on the SC64.
- Add macOS metadata to hidden files.
- Added settings schema version for future change versioning.
- Added setting for PAL60 compatibility mode (see breaking changes).
- BETA_FEATURE: Added setting for line doublers that need progressive
output, enable using "force_progressive_scan" setting in `config.ini`.
- **Bug Fixes**
- Menu sound FX issues (hissing, popping and white noise).
- RTC not showing or setting correct date parameters in certain
circumstances.
- GB / GBC emulator not saving in certain circumstances.
- **Documentation**
- Re-orginised and improved user documentation.
- Added a lot of doxygen compatible code comments.
- Added project license.
- **Refactor**
- RTC subsystem (align with libDragon improvements).
- Boxart images (Deprecates old boxart image folder layout).
- Settings (PAL60 compatibility, schema version, fast reboot, first run,
progress bar).
- **Other**
- Updated libDragon SDK.
- Updated miniz library.
### Breaking changes
* GB /GBC emulator changed save type to SRAM (from FRAM) to improve
compatibility with Summercart64 (which only uses H/W compatible FRAM),
this may break your ability to load existing saves.
* For similar PAL60 functionality, you may need to also enable the new
"pal60_compatibility_mode" setting in `config.ini`.
### Current known Issues
* The RTC UI requires improvement (awaiting UI developer).
* Menu sound FX may not work properly when a 64 Disk Drive is also
attached (work around: turn sound FX off).
* Fast Rebooting a 64DD disk once will result in a blank screen. Twice
will return to menu. This is expected until disk swapping is
implemented.
* MP3 Player crashes menu if the MP3 file's sample rate is less than
44100 hz.
### Deprecation notices
* Autoload ROM's will be deprecated in favor of Fast Reboot in a future
menu version.
* Old boxart images using filenames for game ID is deprecated and the
compatibility mode will be removed in a future release.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Works towards next release to main.
## How Has This Been Tested?
On a SummerCart64
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Improvement (non-breaking change that adds a new feature)
- [x] Bug fix (fixes an issue)
- [x] Breaking change (breaking change)
- [x] Documentation Improvement
- [x] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features & Enhancements**
- Introduced dynamic history and favorites management for ROM and disk
selections with a new tabbed interface.
- Added support for autoloading ROMs, 64DD disk emulation, emulator
integration, MP3 playback, and custom background images.
- Expanded settings options—including PAL60 compatibility and fast ROM
reboots—and improved startup behavior with an introductory credits
display.
- Added a feature to toggle the loading progress bar and enhanced the
display of ROM information.
- Implemented a bookkeeping system for managing history and favorites,
along with new context menu entries for toggling settings.
- Added a new user guide for N64FlashcartMenu and introduced a FAQ
section addressing common issues.
- Enhanced the user interface with new tabs for managing ROM favorites
and recently played ROMs.
- Introduced first run checks for user awareness of changes.
- **Bug Fixes**
- Resolved issues related to menu sound effects, RTC date parameters,
and saving functionality in the GB/GBC emulator.
- **Documentation**
- Overhauled and expanded user guides, FAQs, and README materials to
provide clearer instructions on ROM configuration, cheats, flashcart
support, and new features.
- Added detailed documentation comments throughout the codebase to
improve clarity and maintainability, including updates to the pull
request template and license information.
- Included a new section in the CHANGELOG detailing various updates and
breaking changes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
Co-authored-by: Suprapote <111246491+Suprapote@users.noreply.github.com>
Co-authored-by: Christopher Bonhage <me@christopherbonhage.com>
Co-authored-by: Mateusz Faderewski <sc@mateuszfaderewski.pl>
Co-authored-by: Fazana <52551480+FazanaJ@users.noreply.github.com>
Co-authored-by: Guillermo Horacio Romero Villa <65469983+E1ite007@users.noreply.github.com>
Co-authored-by: Ross Gouldthorpe <github@thegouldfish.co.uk>
Co-authored-by: Víctor "IlDucci <IlDucci@users.noreply.github.com>
Co-authored-by: XLuma <39510265+XLuma@users.noreply.github.com>
Co-authored-by: thekovic <72971433+thekovic@users.noreply.github.com>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Fixed menu display (PAL60) by reverted libdragon to a known working
point and re-applying old hacks.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Media coverage. #183#184
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
Tested locally on a SC64 on an
* NTSC console (composite only)
* PAL console (composite)
* PAL console (HDMI mod with Pal60 enabled).
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [x] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Add changelog so that rolling release description does not need to be
updated manually.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Hard to maintain.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [x] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
- **New Features**
- Added menu sound effects (default off)
- Introduced N64 ROM autoload functionality
- Implemented a menu boot hotkey
- Added a context menu for settings management
- Enhanced real-time clock (RTC) editing capabilities
- Improved flashcart information display
- Optimized joypad input handling for responsiveness
- Added support for additional ROM types (`SMS`, `GG`, and `CHF`)
- **Improvements**
- Enhanced UI layout with new drawing functions and better organization
- Optimized boxart image loading
- Improved memory management to prevent leaks
- **Bug Fixes**
- Enhanced error handling in save loading and ROM management
- Fixed text flickering issues
- **Documentation**
- Updated CHANGELOG with latest release notes
- Revised README for new features and setup instructions
- Improved clarity regarding RTC settings and menu customization
- **Breaking Changes**
- Loading of disk drive expansion ROMs now requires a different key
combination
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Improve the bug report template.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Recently reported issues lacked the required content for diagnostics.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated GitHub issue bug report template with new optional input
fields
- Added fields for N64 console region and configuration file details to
help improve issue reporting clarity
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Fixes some typos
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Corrected grammatical errors and typos in README.md
- Fixed capitalization and formatting issues
- Improved overall readability of documentation
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Robin Jones <networkfusion@users.noreply.github.com>
## Description
Documentaion has been rewritten/improved/expanded in certain areas
including typo and formatting fixes.
## Motivation and Context
Tidier documentation, to make things a bit more dumb-proof for end
users.
## How Has This Been Tested?
Not applicable.
## Types of changes
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [x] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
Signed-off-by: IlDucci
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **Documentation**
- Updated documentation for initial SD card setup, menu controls, and
menu customization.
- Improved clarity and readability of instructions.
- Refined section headings and formatting across multiple documentation
files.
- Added new sections explaining menu settings, ROM information, and
control details.
- Emphasized warnings regarding filename compatibility and save file
issues.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
This PR merges `develop` and `main` for a tagged release so it can be
used by most users (utilising debug flags where required).
## Release Notes
- **New Features**
- Introduced menu sound effects for enhanced user experience (the
default is off).
- Added N64 ROM autoload functionality, allowing users to set a specific
ROM to load automatically.
- Added menu boot hotkey (hold `start` to return to menu when autoload
is enabled).
- Added context menu and settings management options GUI for managing
various settings in `config.ini`.
- Added functionality for editing the real-time clock (RTC) within the
RTC menu view.
- Improved flashcart info view for showing supported flashcart features
and version.
- Enhanced UI components with new drawing functions and improved
organization.
- Added emulator support for `SMS`, `GG`, and `CHF` ROMs.
- Enhanced joypad input handling for menu actions, improving
responsiveness.
- Optimized boxart image loading from filesystem.
- Improved various text to make the functionality more clear.
- **Bug Fixes**
- Improved error handling in multiple areas, particularly in save
loading and ROM management.
- Enhanced memory management to prevent potential leaks during error
conditions.
- Fixed text flickering in certain circumstances.
- **Documentation**
- Updated README and various documentation files to reflect new features
and usage instructions.
- Added detailed setup instructions for SD cards and menu customization.
- Enhanced clarity in documentation for RTC settings and menu
customization.
- Improved organization and clarity of SD card setup instructions for
various flashcarts.
- **Refactor**
- Standardized naming conventions across UI components for better
organization.
- Restructured sound management and input handling for improved
responsiveness.
- Streamlined the loading state management for ROMs and disks within the
menu system.
- Improved clarity and usability of the developer guide and other
documentation files.
### Current known Issues
* The RTC UI requires improvement (awaiting UI developer).
* BETA_SETTING: PAL60 when using HDMI mods has regressed (awaiting
libdragon fix).
* ALPHA_FEATURE: ED64 X Series detection does not occur properly
(however this is not a problem as not tag released asset).
* ALPHA_FEATURE: ED64 V Series only supports loading ROMs (however this
is not a problem as not tag released asset).
* Menu sound FX may not work properly when a 64 Disk Drive is also
attached (work around: turn sound FX off).
### Breaking changes
* Disk drive expansion ROMs are now loaded with `Z|L` instead of `R` to
align with ROM info context menu (and future functionality).
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Merge the changes:
#110#106#101#89#74
and other improvements.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
Locally on an SC64.
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Improvement (non-breaking change that adds a new feature)
- [x] Bug fix (fixes an issue)
- [x] Breaking change (breaking change)
- [x] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features**
- Enhanced documentation for N64 Flashcart Menu, including new emulator
support and features like menu sound effects and N64 ROM autoload.
- Added support for additional flashcart features and firmware version
retrieval in the flashcart subsystem.
- Introduced new settings for sound effects and ROM autoloading in the
menu system.
- **Bug Fixes**
- Improved error handling in various menu functions to prevent memory
leaks and ensure proper resource management.
- **Refactor**
- Updated naming conventions for UI component functions to improve
clarity and organization.
- Restructured the sound management functionality to enhance user
interaction feedback.
- **Documentation**
- Expanded sections in README and other documentation files for clarity
on emulator support and usage instructions.
- **Chores**
- Updated dependencies and version references in Dockerfile and other
configuration files.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
Co-authored-by: Suprapote <111246491+Suprapote@users.noreply.github.com>
Co-authored-by: Christopher Bonhage <me@christopherbonhage.com>
Co-authored-by: Mateusz Faderewski <sc@mateuszfaderewski.pl>
Co-authored-by: Fazana <52551480+FazanaJ@users.noreply.github.com>
Co-authored-by: Guillermo Horacio Romero Villa <65469983+E1ite007@users.noreply.github.com>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Improve integer type under certain conditions.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
When running the flags `-Wall -Wextra`.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Improved handling of loop variables to prevent negative overflow in
various functions, enhancing stability and reliability when processing
larger values.
- **Refactor**
- Updated loop variable types to `unsigned int` for better performance
and accuracy in ROM data handling across multiple components.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Update the "supported" SC64 firmware version.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Although the latest firmware is not "required", it is best to keep it
aligned.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Updated the supported firmware version for "SummerCart64" to 2.20.0+
in error messages.
- **Documentation**
- Revised developer documentation to reflect the upgrade of the SC64
deployer to v2.20.0, including updated links and compatibility
requirements.
- Clarified instructions for using the dev container and added a
workaround for USB device communication.
- Expanded guidance on generating and serving documentation locally.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Perfect Dark (JP) release.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Database entry (requires Expansion Pak).
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
https://imgur.com/a/perfect-dark-without-expansion-vPOYVMB
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added detailed match information for the game "Perfect Dark,"
enhancing recognition and handling by the system.
- **Improvements**
- Updated the entry for "Perfect Dark" to improve database organization
and clarity.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Remove ED64/ED64P from rolling release.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
It is not ready and causes confusion.
It is still available in the dev release.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Documentation Improvement
- [x] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Chores**
- Updated build workflow to exclude specific output files from
processing, which may impact the overall build process.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Improve documentation.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [x] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated URLs in the README for direct access to firmware downloads for
SC64 and 64drive.
- Enhanced hyperlink for the releases page in the Getting Started guide
for better user accessibility.
- Added a new section with a quickstart video tutorial in the Developer
Guide to assist new developers.
- Improved clarity and formatting in the Developer Guide for
installation prerequisites and webpage serving instructions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Split documentation into chunks that users can understand.
Improve them to be more idiot proof!
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Allows an easier way to point people towards specific documentation.
#127#76
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [x] Documentation Improvement
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
When loading the menu, ensure that any connected rumble paks are not
rumbling.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
It is possible that they would continue to rumble after a ROM has
crashed or the console was reset from a game where the accessory was
currently rumbling.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [x] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!--- Provide a general summary of your changes in the Title above -->
## Description
Prefer `kbit` and `Mbit` instead of ambiguous `K` for save type units
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Reduces confusion, notably the inconsistency between EEPROM using
kilobits and SRAM using kibibytes.
## How Has This Been Tested?
Tested on SummerCart64 with an NTSC console
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [X] Improvement (non-breaking change that adds a new feature)
- [X] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [X] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [X] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: meeq <me@christopherbonhage.com>
<!--- Provide a general summary of your changes in the Title above -->
## Description
Make the root of the SD card a little cleaner by hiding the crap that
macOS puts there.
## Motivation and Context
Whenever an SD card touches macOS, a handful of hidden files get created
that cannot be touched. N64FlashcartMenu has no need for these files, so
they should be hidden.
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
## How Has This Been Tested?
Built and run on SummerCart64 with an NTSC N64
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [X] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [X] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: meeq <me@christopherbonhage.com>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
For ED64 based carts
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
The ROMs are not based in the root path.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Adds a pre-release (dev) release and branch.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
Ensures testing before release to main.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [x] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Building using a dev container broke after the deb package was updated.
## Motivation and Context
Required for GCC 14.
## How Has This Been Tested?
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [x] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: GITHUB_USER <GITHUB_USER_EMAIL>
<!--- Provide a general summary of your changes in the Title above -->
## Description
This PR implements cheat support (patcher + engine) with a simple API to
provide Action Replay/Game Shark compatible cheats (with exception of
cheats that utilize GS button).
API consist of a single pointer to an array of the cheats ended with a
double zero entry,
For example, if you want to pass these cheats to the patcher:
```
D01F9B91 0020 // Majora's Mask (USA) Inventory Editor
803FDA3F 0002
```
Put cheats in a `uint32_t` array as such (notice last two entries are
zeros):
```
uint32_t cheats[] = {
0xD01F9B91,
0x0020,
0x803FDA3F,
0x0002,
0,
0,
};
```
And pass this array as a boot parameter: `menu->boot_params->cheat_list
= cheats;`
<!--- Describe your changes in detail -->
## Motivation and Context
To provide users with ability to run game modifications in a easy way.
<!--- What does this sample do? What problem does it solve? -->
<!--- If it fixes/closes/resolves an open issue, please link to the
issue here -->
## How Has This Been Tested?
On a SummerCart64 flashcart + assembly instructions generation verified
in ares emulator via GDB.
<!-- (if applicable) -->
<!--- Please describe in detail how you tested your sample/changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Screenshots
No screenshots
<!-- (if appropriate): -->
## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Improvement (non-breaking change that adds a new feature)
- [ ] Bug fix (fixes an issue)
- [ ] Breaking change (breaking change)
- [ ] Config and build (change in the configuration and build system,
has no impact on code or features)
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--- It would be nice if you could sign off your contribution by
replacing the name with your GitHub user name and GitHub email contact.
-->
Signed-off-by: Polprzewodnikowy <sc@mateuszfaderewski.pl>
