The-Homebrew-Cloud/N64FlashcartMenu
2
0
Fork 0
mirror of https://github.com/Polprzewodnikowy/N64FlashcartMenu.git synced 2025-02-22 12:47:15 +01:00
Code Issues Packages Projects Releases Wiki Activity
N64FlashcartMenu/README.md

149 lines
6.6 KiB
Markdown
Raw Normal View History

Add build badge
2023-11-01 18:47:08 +00:00
![Build](https://github.com/polprzewodnikowy/N64FlashcartMenu/actions/workflows/build.yml/badge.svg)
Improve readme (#29) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> ## 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) - [ ] 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>
2023-07-30 20:30:19 +01:00
# N64 Flashcart Menu
Add features to readme. (#41) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> * Add notable features. * Add check for latest SC64 firmware. ## 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) - [ ] 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>
2023-08-18 00:20:53 +01:00
An open source menu for N64 flashcarts.
Documentation improvements (#6) * Adds templates for PR's and issues. * Adds some basic documentation to get people up and running (although it will change very quickly).
2023-02-22 18:11:49 +00:00
Update README.md Improve supported carts
2024-01-10 17:20:50 +00:00
## Supported Flashcarts
### Fully supported
* SummerCart64
* 64Drive
Fix link by removing it
2024-01-10 17:42:54 +00:00
### Work in Progress
Update README.md Improve supported carts
2024-01-10 17:20:50 +00:00
* ED64
* ED64P
Documentation improvements (#6) * Adds templates for PR's and issues. * Adds some basic documentation to get people up and running (although it will change very quickly).
2023-02-22 18:11:49 +00:00
Add features to readme. (#41) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> * Add notable features. * Add check for latest SC64 firmware. ## 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) - [ ] 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>
2023-08-18 00:20:53 +01:00
## Current (notable) menu features
* Fully Open Source.
Update README.md (#182) 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>
2025-01-04 15:16:31 -03:00
* Loads all known N64 games (including iQue and Aleck64 ROMs), even if they are byteswapped.
Improve readme.
2023-10-10 20:52:19 +01:00
* Fully emulates the 64DD and loads 64DD disks (SummerCart64 only).
Add Fairchild Channel F emulator support (#166) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Adds the required changes for supporting the Fairchild Channel F emulator. ## 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 --> Support more emulators. ## 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. --> Still required. ## 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. - [ ] 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>
2024-12-04 12:30:38 +00:00
* Emulator support (NES, SNES, GB, GBC, SMS, GG, CHF) ROMs.
Add features to readme. (#41) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> * Add notable features. * Add check for latest SC64 firmware. ## 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) - [ ] 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>
2023-08-18 00:20:53 +01:00
* N64 ROM box image support.
* Background image (PNG) support.
Update README.md (#182) 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>
2025-01-04 15:16:31 -03:00
* Comprehensive ROM save database (including homebrew headers).
Add features to readme. (#41) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> * Add notable features. * Add check for latest SC64 firmware. ## 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) - [ ] 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>
2023-08-18 00:20:53 +01:00
* Comprehensive ROM information display.
* Real Time Clock support.
* Music playback (MP3).
Add sound effects (#108) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Adding sound for make the navigation not so borring. ## 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 --> This [issue](https://github.com/Polprzewodnikowy/N64FlashcartMenu/issues/89) ## 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://github.com/Polprzewodnikowy/N64FlashcartMenu/assets/111246491/0f8086f6-16b3-4adb-a925-afbfc9fa6ba9 ## 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. - [ ] 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>
2024-06-05 22:04:25 +02:00
* Menu sound effects.
N64 Rom autoload (#150) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Allows the ability to autoload a specified ROM instead of the menu, taking into account the ROM database. If enabled, you can currently fallback to the menu by holding joypad start on console reset. ## 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 --> This is a better implementation of #140. ## 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 ## Release Notes - **New Features** - Introduced ROM autoloading functionality, allowing users to enable automatic loading of ROMs with specified paths and filenames. - Added a settings option for managing ROM autoload preferences in the menu. - **User Interface Enhancements** - Updated settings menu to display the state of the "Autoload ROM" setting. - Improved context menus for toggling various settings. - **Bug Fixes** - Enhanced memory management by ensuring proper resource deallocation for settings. - **Documentation** - Added documentation for new functions and settings related to ROM autoloading. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
2024-11-05 09:27:44 +00:00
* N64 ROM autoload.
Update readme Add changelog for rolling releases (on main)
2025-01-04 23:16:56 +00:00
* ROM information descriptions.
* ROM history and favorites.
Add features to readme. (#41) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> * Add notable features. * Add check for latest SC64 firmware. ## 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) - [ ] 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>
2023-08-18 00:20:53 +01:00
Documentation improvements (#6) * Adds templates for PR's and issues. * Adds some basic documentation to get people up and running (although it will change very quickly).
2023-02-22 18:11:49 +00:00
Improve documentation (#128) <!--- 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>
2024-08-04 17:56:54 +01:00
## Documentation
* [Getting started guide](./docs/00_getting_started_sd.md)
* [Menu controls](./docs/01_menu_controls.md)
Improve documentation
2024-12-28 16:04:09 +00:00
* [Menu customization](./docs/07_menu_customization.md)
Improve documentation (#128) <!--- 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>
2024-08-04 17:56:54 +01:00
* [Developer guide](./docs/99_developer_guide.md)
## Video showcase (as of Oct 12 2023)
64drive support (#27) <!--- Provide a general summary of your changes in the Title above --> ## Description This PR implements 64drive support ## Motivation and Context Goal of this PR is to support more devices <!--- 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? Not tested at all <!-- (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! --> - [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>
2023-09-08 21:49:50 +02:00
Improve readme
2023-11-01 18:33:25 +00:00
[![N64FlashcartMenu Showcase](http://img.youtube.com/vi/6CKImHTifDA/0.jpg)](http://www.youtube.com/watch?v=6CKImHTifDA "N64FlashcartMenu Showcase (Oct 12 2023)")
64DD disk loading support for SummerCart64 (#49) (and other fixes/improvements) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> ## 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) - [ ] 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> --------- Signed-off-by: Polprzewodnikowy <sc@mateuszfaderewski.pl> Co-authored-by: Robin Jones <networkfusion@users.noreply.github.com>
2023-10-10 21:12:53 +02:00
Improve readme for DD expansions
2023-10-14 23:08:26 +01:00
Improve readme
2023-11-01 18:33:25 +00:00
## Aims
* Support as many N64 FlashCarts as possible.
Update README.md (#182) 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>
2025-01-04 15:16:31 -03:00
* Be open source, using permissively licensed third-party libraries.
Improve readme
2023-11-01 18:33:25 +00:00
* Be testable, using unit and smoke tests in ares emulated environment.
* Encourage active development from community members and N64 FlashCart owners.
* Support as many common mods and features as possible.
Improve readme.
2023-10-10 20:52:19 +01:00
Improve readme (#29) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> ## 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) - [ ] 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>
2023-07-30 20:30:19 +01:00
Improve documentation (#128) <!--- 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>
2024-08-04 17:56:54 +01:00
## Experimental features
These features are subject to change:
Fix readme content Emulation header
2023-08-07 23:15:42 +01:00
[develop] Improve rom info (#146) <!--- 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): --> ![image](https://github.com/user-attachments/assets/5257d624-acc8-40d4-bbc2-e0c3996a6962) ![image](https://github.com/user-attachments/assets/31caa489-1558-432c-976d-7090935e57e1) ![image](https://github.com/user-attachments/assets/a419ce5b-a00b-4360-9887-6a6e27b9ffbf) ## 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 -->
2025-01-02 20:24:03 +00:00
### ROM Info descriptions
To add a ROM description (shown when loading a ROM), add a file with the content
```
[metadata]
Update README.md
2025-01-02 21:23:58 +00:00
description=This is the ROM description that does X Y Z.
[develop] Improve rom info (#146) <!--- 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): --> ![image](https://github.com/user-attachments/assets/5257d624-acc8-40d4-bbc2-e0c3996a6962) ![image](https://github.com/user-attachments/assets/31caa489-1558-432c-976d-7090935e57e1) ![image](https://github.com/user-attachments/assets/a419ce5b-a00b-4360-9887-6a6e27b9ffbf) ## 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 -->
2025-01-02 20:24:03 +00:00
```
Update README.md Remove deprecated support as want people to use the new functionality.
2025-01-04 23:24:29 +00:00
The file line endings must use the linux `LF` endings only (CRLF is not supported) and is limited to 300 characters.
[develop] Improve rom info (#146) <!--- 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): --> ![image](https://github.com/user-attachments/assets/5257d624-acc8-40d4-bbc2-e0c3996a6962) ![image](https://github.com/user-attachments/assets/31caa489-1558-432c-976d-7090935e57e1) ![image](https://github.com/user-attachments/assets/a419ce5b-a00b-4360-9887-6a6e27b9ffbf) ## 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 -->
2025-01-02 20:24:03 +00:00
N64 Rom autoload (#150) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Allows the ability to autoload a specified ROM instead of the menu, taking into account the ROM database. If enabled, you can currently fallback to the menu by holding joypad start on console reset. ## 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 --> This is a better implementation of #140. ## 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 ## Release Notes - **New Features** - Introduced ROM autoloading functionality, allowing users to enable automatic loading of ROMs with specified paths and filenames. - Added a settings option for managing ROM autoload preferences in the menu. - **User Interface Enhancements** - Updated settings menu to display the state of the "Autoload ROM" setting. - Improved context menus for toggling various settings. - **Bug Fixes** - Enhanced memory management by ensuring proper resource deallocation for settings. - **Documentation** - Added documentation for new functions and settings related to ROM autoloading. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
2024-11-05 09:27:44 +00:00
### N64 ROM autoload
To use the autoload function, while on the `N64 ROM information` display, press the `R` button on your joypad and select the `Set ROM to autoload` option. When you restart the console, it will now only load the selected ROM rather than the menu.
Improve documentation
2024-12-28 16:04:09 +00:00
The autoload setting is stored in `config.ini` and persists until changed. This feature may slightly increase boot time as the menu needs to check for the Start button state.
NOTE: To return to the menu, hold the joypad `Start` button while powering on the console.
Optimize boxart image load (#130) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Improves boxart image loading by using directory file paths. It also adds matching by full game ID's (for compatibility), but notes in the readme that it is slow. ## 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 --> Loading boxart was slow in certain circumstances. ## 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) - [ ] 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** - Introduced a new image type enumeration for boxart components, enhancing image management. - Updated boxart initialization to allow for specific image views, improving flexibility in image retrieval. - Enhanced instructions for setting up boxart images with clearer directory structures and simplified naming conventions. - **Bug Fixes** - Improved the logic for loading boxart images, enabling better fallback options in case of missing files. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
2024-09-28 20:47:53 +01:00
### GamePak sprites
Improve documentation
2024-12-28 16:04:09 +00:00
To use N64 GamePak sprites, place PNG files within the `sd:/menu/boxart/` folder.
Optimize boxart image load (#130) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Improves boxart image loading by using directory file paths. It also adds matching by full game ID's (for compatibility), but notes in the readme that it is slow. ## 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 --> Loading boxart was slow in certain circumstances. ## 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) - [ ] 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** - Introduced a new image type enumeration for boxart components, enhancing image management. - Updated boxart initialization to allow for specific image views, improving flexibility in image retrieval. - Enhanced instructions for setting up boxart images with clearer directory structures and simplified naming conventions. - **Bug Fixes** - Improved the logic for loading boxart images, enabling better fallback options in case of missing files. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
2024-09-28 20:47:53 +01:00
#### Supported sprites
These must be `PNG` files that use the following dimensions:
* Standard N64 GamePak boxart sprites: 158x112
* Japanese N64 GamePak boxart sprites: 112x158
* 64DD boxart sprites: 129x112
Update README.md Improve Gamepak sprite info
2024-10-25 23:00:55 +01:00
They will be loaded by directories using each character (case-sensitive) of the full 4 character Game Code (as identified in the menu ROM information).
Optimize boxart image load (#130) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Improves boxart image loading by using directory file paths. It also adds matching by full game ID's (for compatibility), but notes in the readme that it is slow. ## 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 --> Loading boxart was slow in certain circumstances. ## 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) - [ ] 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** - Introduced a new image type enumeration for boxart components, enhancing image management. - Updated boxart initialization to allow for specific image views, improving flexibility in image retrieval. - Enhanced instructions for setting up boxart images with clearer directory structures and simplified naming conventions. - **Bug Fixes** - Improved the logic for loading boxart images, enabling better fallback options in case of missing files. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
2024-09-28 20:47:53 +01:00
i.e. for GoldenEye NTSC USA (NGEE), this would be `sd:/menu/boxart/N/G/E/E/boxart_front.png`.
i.e. for GoldenEye PAL (NGEP), this would be `sd:/menu/boxart/N/G/E/P/boxart_front.png`.
To improve compatibility between regions (as a fallback), you may exclude the region ID (last matched directory) for GamePaks to match with 3 letter IDs instead:
i.e. for GoldenEye, this would be `sd:/menu/boxart/N/G/E/boxart_front.png`.
Improve documentation
2024-12-28 16:04:09 +00:00
**Warning**: Excluding the region ID may show the wrong boxart.
**Note**: For future support, boxart sprites should also include:
* `boxart_back.png`
* `boxart_top.png`
* `boxart_bottom.png`
* `boxart_left.png`
* `boxart_right.png`
Update README.md Remove deprecated support as want people to use the new functionality.
2025-01-04 23:24:29 +00:00
* `gamepak_front.png`
* `gamepak_back.png`
Optimize boxart image load (#130) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Improves boxart image loading by using directory file paths. It also adds matching by full game ID's (for compatibility), but notes in the readme that it is slow. ## 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 --> Loading boxart was slow in certain circumstances. ## 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) - [ ] 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** - Introduced a new image type enumeration for boxart components, enhancing image management. - Updated boxart initialization to allow for specific image views, improving flexibility in image retrieval. - Enhanced instructions for setting up boxart images with clearer directory structures and simplified naming conventions. - **Bug Fixes** - Improved the logic for loading boxart images, enabling better fallback options in case of missing files. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
2024-09-28 20:47:53 +01:00
Update README.md Remove deprecated support as want people to use the new functionality.
2025-01-04 23:24:29 +00:00
As a starting point, here is a link to a boxart pack, that has `boxart_front.png`:
* [boxart](https://drive.google.com/file/d/1IpCmFqmGgGwKKmlRBxYObfFR9XywaC6n/view?usp=drive_link)
Add N64 ROM boxart capability (#16) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Adds the ability to show ROM boxart in the FileInfo menu. Although later we may decide to convert PNG's or BMP's on the fly, to start with, we only use sprite files created with mksprite (see readme). It required an update to the libdragon submodule due to very recent sprite functionality changes. ## 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 --> Work towards a pretty menu. ## 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. --> As shown in the screenshots, ~~however there is an issue when the info screen displays for more than 30 seconds with a sprite loaded (help required).~~ ## Screenshots <!-- (if appropriate): --> Example Goldeneye ROM loaded: ![image](https://github.com/Polprzewodnikowy/N64FlashcartMenu/assets/11439699/65f03a06-9463-4519-a94e-00c38bf1c409) ~~Known issue (when staying on the information screen with a sprite loaded for over 30 seconds)~~ ![image](https://github.com/Polprzewodnikowy/N64FlashcartMenu/assets/11439699/fd98b39c-9534-4794-bcd5-d598f18bfd63) ## 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. - [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>
2023-07-26 16:55:23 +01:00
Improve readme
2023-11-01 18:33:25 +00:00
Update README.md
2023-12-17 20:57:45 +00:00
### Menu Settings
Update README.md Remove deprecated support as want people to use the new functionality.
2025-01-04 23:24:29 +00:00
The Menu creates a `config.ini` file in `sd:/menu/` which contains various settings that are used and can be set within the menu.
Update README.md
2023-12-17 20:57:45 +00:00
If required, you can manually adjust the file on the SD card using your computer.
Documentation improvements (#6) * Adds templates for PR's and issues. * Adds some basic documentation to get people up and running (although it will change very quickly).
2023-02-22 18:11:49 +00:00
Update README.md Remove deprecated support as want people to use the new functionality.
2025-01-04 23:24:29 +00:00
### Datel cheats
(Action Replay and GameShark codes)
Supported, but no GUI available (yet) to edit them.
Improve readme
2023-11-01 18:33:25 +00:00
Improve documentation (#128) <!--- 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>
2024-08-04 17:56:54 +01:00
## Flashcart specific
Improve readme
2023-11-01 18:33:25 +00:00
Improve documentation (#128) <!--- 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>
2024-08-04 17:56:54 +01:00
### SC64
* Ensure the cart has the latest [firmware](https://github.com/Polprzewodnikowy/SummerCart64/releases/latest) installed.
Improve docs (#131) <!--- 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 -->
2024-08-04 19:50:12 +01:00
* Download the latest `sc64menu.n64` file from the [releases](https://github.com/Polprzewodnikowy/N64FlashcartMenu/releases/) page, then put it in the root directory of your SD card.
Improve readme
2023-11-01 18:33:25 +00:00
Improve documentation (#128) <!--- 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>
2024-08-04 17:56:54 +01:00
### 64drive
* Ensure the cart has the latest [firmware](https://64drive.retroactive.be/support.php) installed.
Improve docs (#131) <!--- 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 -->
2024-08-04 19:50:12 +01:00
* Download the latest `menu.bin` file from the [releases](https://github.com/Polprzewodnikowy/N64FlashcartMenu/releases/) page, then put it in the root directory of your SD card.
Improve readme
2023-11-01 18:33:25 +00:00
Add basic flashcart support for V-Series ED64 limited to loading ROM's.
2024-11-07 22:31:01 +00:00
### ED64 - WIP - UNTESTED AND UNSUPPORTED - USE AT OWN RISK
Update README.md (#182) 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>
2025-01-04 15:16:31 -03:00
Currently not supported, but work is in progress (See [PRs](https://github.com/Polprzewodnikowy/N64FlashcartMenu/pulls)).
Improve documentation
2024-12-28 16:04:09 +00:00
**Warning**: The menu may be able to load ROMs but cannot guarantee save functionality. Existing saves may be corrupted.
Improve readme
2023-11-01 18:33:25 +00:00
Add basic flashcart support for V-Series ED64 limited to loading ROM's.
2024-11-07 22:31:01 +00:00
#### ED64 (Vseries)
The aim is to reach feature parity with [ED64-UnofficialOS](https://github.com/n64-tools/ED64-UnofficialOS-binaries) / [ED64-OfficialOS](https://krikzz.com/pub/support/everdrive-64/v2x-v3x/os-bin/).
Download the `OS64.v64` ROM from the latest [action run - assets] and place it in the `/ED64` folder.
#### ED64 (X series)
Improve documentation
2024-12-28 16:04:09 +00:00
X Series support is currently awaiting fixes. Please use the official [OS](https://krikzz.com/pub/support/everdrive-64/x-series/OS/) for now.
Add basic flashcart support for V-Series ED64 limited to loading ROM's.
2024-11-07 22:31:01 +00:00
#### ED64 (P clone)
Download the `OS64P.v64` ROM from the latest [action run - assets] and place it in the `/ED64P` folder.
The aim is to reach feature parity with [Altra64](https://github.com/networkfusion/altra64)
Improve readme
2023-11-01 18:33:25 +00:00
Added SNES emulator + changed emulator names to default
2023-08-20 20:58:34 +02:00
# Open source software and licenses used
Merge remote-tracking branch 'upstream/main' into develop
2024-08-04 23:21:43 +01:00
Improve documentation (#128) <!--- 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>
2024-08-04 17:56:54 +01:00
* [libdragon](https://github.com/DragonMinded/libdragon) (UNLICENSE License)
* [libspng](https://github.com/randy408/libspng) (BSD 2-Clause License)
* [mini.c](https://github.com/univrsal/mini.c) (BSD 2-Clause License)
* [minimp3](https://github.com/lieff/minimp3) (CC0 1.0 Universal)
* [miniz](https://github.com/richgel999/miniz) (MIT License)
Add sound effects (#108) <!--- Provide a general summary of your changes in the Title above --> ## Description <!--- Describe your changes in detail --> Adding sound for make the navigation not so borring. ## 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 --> This [issue](https://github.com/Polprzewodnikowy/N64FlashcartMenu/issues/89) ## 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://github.com/Polprzewodnikowy/N64FlashcartMenu/assets/111246491/0f8086f6-16b3-4adb-a925-afbfc9fa6ba9 ## 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. - [ ] 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>
2024-06-05 22:04:25 +02:00
## Sounds
See [License](https://pixabay.com/en/service/license-summary/) for the following sounds:
Merge remote-tracking branch 'upstream/main' into develop
2024-08-04 23:21:43 +01:00
* [Cursor sound](https://pixabay.com/en/sound-effects/click-buttons-ui-menu-sounds-effects-button-7-203601/) by Skyscraper_seven (Free to use)
Update README.md (#182) 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>
2025-01-04 15:16:31 -03:00
* [Actions (Enter, Back) sound](https://pixabay.com/en/sound-effects/menu-button-user-interface-pack-190041/) by Liecio (Free to use)
Merge remote-tracking branch 'upstream/main' into develop
2024-08-04 23:21:43 +01:00
* [Error sound](https://pixabay.com/en/sound-effects/error-call-to-attention-129258/) by Universfield (Free to use)
Reference in New Issue Copy Permalink