This PR adds a setting to the config that allows users with TVs,
scalers, and other devices that struggle with interlaced video input to
force progressive scan to the menu.
## Description
This PR implements the aforementioned new setting my changing
libdragon's display module setting from `INTERLACE_HALF` to
`INTERLACE_OFF` if the newly added `force_progressive_scan` setting bool
is set. This tells the display module to not set the serrate bit in the
VI configuration registers and in effect forces "artificial" progressive
scan at 240p by dropping one field, without having to modify the menu's
rendering resolution of 640x480.
## Motivation and Context
Motivated by currently open issues #59 and #82 as well as Discord
comments from some menu users:
-
https://discord.com/channels/205520502922543113/1262536014623146125/1349024387721986061
-
https://discord.com/channels/205520502922543113/1262536014623146125/1349025967351271445
-
https://discord.com/channels/205520502922543113/1262536014623146125/1349030951585579058
## How Has This Been Tested?
Tested in ares. Testing on real devices by affected users would be
appreciated.
## Types of changes
- [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:
- [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.
Signed-off-by: thekovic 72971433+thekovic@users.noreply.github.com
Co-authored-by: Robin Jones <networkfusion@users.noreply.github.com>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
In this PR I have added the global setting, flashcart feature support
and implementation of extra bootmodes (specifically fast reboot).
Although technically supported, the 64drive implementation is currently
commented out.
## 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 -->
#75
## 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 summercart64.
Having the USB cable inserted, the hard power ON/OFF contines to use the
fast reboot ROM (expected).
Having no USB cable inserted , the hard power ON/OFF loads the menu
(expected).
## 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>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Update miniz submodule but uses `-Wno-unused-function` as a work around
for warnings (probably a better way),
## 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 -->
Update miniz submodule
## 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**
- Refined the build configuration to better manage compiler warnings.
- Updated an external library dependency to its latest version.
<!-- 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 -->
Most hardware mods have issues with PAL60 when outputing on displays
when using libDragon Preview branch (e.g. PixelFX and UltraHDMI).
This is a workaround until libDragon can deal with them.
The settings are not exposed through the menu (by default) as can lead
to no video output.
## 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 -->
#163https://discordapp.com/channels/205520502922543113/1310357756091437086
## 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. -->
* Ultra HDMI modded PAL console using both HDMI and its analogue output
[pal60 + pal60 compat].
* ----- HDMI output ....
* ----- analog output only when compat mode off = out of screen
vertical.
## 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>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Update the libdragon submodule which includes changes to RTC
## 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 -->
linked to #207
## 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
- [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
Hides:
* `desktop.ini` - Windows Explorer directory settings
* `Thumbs.db` - Windows Explorer image thumbnails
* `.DS_Store` - macOS Finder directory settings
* `._`-prefixed files - macOS "AppleDouble" metadata
## Motivation and Context
[N64brew sc64-forum post: File list shows 4096 B "Dummy
Files"?](https://discord.com/channels/205520502922543113/1337028964606283806)
## How Has This Been Tested?
On SC64 with an SD card containing all of the offending files in the
root and in subdirectories.
## Screenshots
Tough to prove a negative here with a screenshot; here's a video:
https://github.com/user-attachments/assets/f1843b29-dee0-442f-bf9a-897a69c39169
## 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)
- [ ] 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.
- [ ] 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: meeq <me@christopherbonhage.com>
Co-authored-by: Robin Jones <networkfusion@users.noreply.github.com>
Fix for crashing when deleting a favorite
## Description
Fixed a bounds check that allowed the copy loop to go out of bounds.
## 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)
- [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! -->
- [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.
- [ ] 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>
## Description
This pull request adds a file parser for cheat code support.
If a file named the same as the selected rom with the extension .cht is
found, it will attempt to parse the file for cheat codes and place them
in `menu->boot_params->cheat_list` per the cheat backend API.
Cheat files should be formatted this way:
```
# Super mario 64 infinite lives
8033B21D 0064
# 120 stars
80207723 0001
8020770B 00C7
50001101 0000
8020770C 00FF
```
The parser ignores lines that start with a '#', are under 12 characters
or over 15 characters. Every other line should be valid cheat code
inputs with the code on the left, and the value on the right separated
by a space.
## Motivation and Context
<!--- What does this sample do? What problem does it solve? -->
Adds some initial cheat support in the frontend to allow users to modify
their games more easily, and take advantage of the backend API.
## How Has This Been Tested?
Tested on real hardware with a Summercart64 and Super Mario 64.
## 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)
- [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: XLuma
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added support for loading and managing cheat codes for N64 ROMs
- Introduced ability to enable/disable cheats for specific ROMs
- Added file type recognition for `.cht` cheat files
- **Documentation**
- Updated documentation with details about cheat code support, including
Datel cart compatibility and supported code types
- **Bug Fixes**
- Implemented comprehensive error handling for cheat file loading
- Added file parsing support for cheat codes
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Robin Jones <networkfusion@users.noreply.github.com>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Adds settings for:
* Schema version
* First Run
* ROM loading progress bar
## 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 -->
They will be required in the near future.
Certain users want to turn the ROM loading progress bar off (for some
reason).
## 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>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Reworks and splits the 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 -->
Improves documentation to be more readable.
## 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
Based on the comprehensive summary, here are the release notes:
- **New Features**
- Added ROM history and favorites functionality
- Introduced tabbed interface for file browsing
- Implemented ROM information descriptions
- Added support for ROM configuration overrides
- Enhanced menu settings management
- **Documentation**
- Expanded user guide and documentation
- Added sections on ROM patches, controller PAKs, and emulator support
- Improved flashcart and menu customization instructions
- **Chores**
- Updated documentation structure
- Refined code organization and naming conventions
- Updated subproject references
<!-- 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 -->
Add basic support for ED64 X series
Only loads ROM's (no save support)
## 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: -->
- [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 support for the ED64 Xseries flashcart, including initialization
and file management capabilities.
- **Bug Fixes**
- Improved clarity in flashcart initialization logic, ensuring accurate
handling of different flashcart types.
- **Documentation**
- Enhanced documentation comments across the codebase for better clarity
on functionalities and features.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Contains the code required for showing history and favourites.
There are now 3 tabs at the top of the browser display: Files, History,
Favorites.
When you launch a game, either rom or disk, the file path for those will
be written out to an ini file called `history.ini`,
which can then be reloaded quickly from the History tab
Roms and Disks can be added as favorites.
Select the rom or Disk as normal, then bring up the options menu (R).
an option to "add to favorites" will be on the new list.
Those can then be selected from the favorites tab.
Currently there are limits to the number of history and favorites and
that is set to 8.
## Motivation and Context
Issue request for last game history and favorites from the menu GUI.
## How Has This Been Tested?
Tested locally on Supercart 64 & SummerCart64,
Tested last loading just a rom, just a disk and a disk and rom
Tested History, loading rom, disk and rom and disk.
Tested favorites using F-Zero X and expansion.
## 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! -->
- [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: GITHUB_USER <GITHUB_USER_EMAIL>
---------
Co-authored-by: Robin Jones <networkfusion@users.noreply.github.com>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Changed the ROM file that provides the "override" settings to be a more
generic file that is able to handle more situations related to the ROM
information.
The file can now contain the ROM description, and also contains whether
the ROM enables GS and patch support (for future use).
To use it, a "group name" needs adding to the ROM specific `ini`:
```
[metadata]
desscription=This is the description of the ROM I wish to load.
```
which if availiable, is added to the ROM load screen.
NOTE: the underlying file parser only supports `LF` line endings. `CRLF`
line endings will not work.
Old ROM ini files will probably be broken as the `override` parameters
have also been added to a "group name" `[custom_boot]`, so you would
either need to manually adjust the file or re 'set' the overridden
parameters in the menu.
## 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 a "descriptive" ROM load system.
## 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)
- [ ] Bug fix (fixes an issue)
- [x] 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**
- Enhanced ROM information handling with new metadata fields including
description, cheats enabled, and patches enabled.
- Improved display of ROM metadata in the user interface, showing
dynamic descriptions and the status of cheats and patches.
- **Bug Fixes**
- Resolved issues with displaying static ROM descriptions by
implementing dynamic formatting.
- **Documentation**
- Updated comments and structure definitions to clarify the purpose of
new fields and functions.
<!-- 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 -->
Changes the button context from `R` to `L|Z` and moves the `move
load_disk_with_rom` to `menu_state` so that it can be used for things
like autoload.
## 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 -->
Aligns the button context with the ROM info menu.
Makes it easier to set and re-use expansion ROM's.
## 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)
- [x] 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 detection for the flashcart firmware version and show it within the
Flashcart Info view.
## 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 feature was incomplete.
## 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>
<!--- Provide a general summary of your changes in the Title above -->
## Description
<!--- Describe your changes in detail -->
Update libdragon and miniz to latest.
## 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 -->
Keeps submodules up-to-date.
potential fixes for RDPQ text flicker.
## 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. -->
SC64
## 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>
