You can find attached the cart template updated by karri on Jan 21, 2019 (here) with some addons by me:
1) Input handling
in resident.c I added a function checkInput() to be used instead of joy_read(JOY_1). This function returns the value of joy_read(JOY_1), but it handles OPT1, OPT2, Pause keys (and their combination) with standard features.
The features in the template are:
- Pause: code execution is paused and the screen content is turned in grayscale. Music is paused too. Pressing Pause again revert everythig to the original state.
- Op2 + Pause: Flip the screeen
- Opt1 + Pause: Trigger a Reset event. Reset event can be handled by game code reading a global variable 'reset' that needs to be checked in every long run loop cycle, so to skip it's execution and make the code run fast to the end of the while(1) cycle usually defined in main. Remember that in every loop there must be a call to checkInput().
2) Game saves
The template supports Eeprom saves and SD saves without the need of two separate builds.
This has been achieved adding to LynxSD.c a custom function LynxSD_OpenFileTimeout(void *pBuffer) that has a trival timeout to avod to lock the code if there isn't an SD cart ready to answer to the OpenFile call.
In case of timeout the function returns FR_DISK_ERR that can be used to to decide if every next read/write to saved data have to be done on SD cart or EEPROM chip.
Trying to access an EEPROM chip on emulators not supporting it (or phisical cart not supporting it) is not blocking, so this is the default choice on FR_DISK_ERR. If the function returns FR_OK the sav file on SD can be accessed. Every other error returned by the SD meas that the SD is answering but the sav file can't be accessed. In this case both SD and EEPROM saves are disabled.
The data to be saved are stored in an array of 128 bytes that is the most common size for saves. In the first 3-5 bytes of this array is a good coding practice to put some character used to check if the content of the save is valid. Organizing in the array the game data to be saved is up to you.
Writing to the EEPROM is performed value by value (2 bytes lenght at a time), but only after checking if the value to be witten is different from that already stored in the EEPROM. This is a little slower (not noticeable in the game) but saves the life of the EEPROM.
To enable both SD and Eeprom use, in lnxhdr.s the eeprom value is set to 65 (1 for standard 128 bytes eeprom + 64 for SD access use)
That's all for now, if I find something useful to speedup the developement of a new game I'll add it to the template.
I used this code to make Xump for Lynx. Can't share the code of Xump because is Copyrighted, but can share all the lynx specific parts that I added to the code base.
Almost everything in this template is not my own work but has been collected lurking in this forum. I only mixed the ingredients to cook my recipe. Fell free to do the same changing the template as you like, but remeber to share it
The help of karri was absolutely precious for finding informations and code snippets, fixing bugs and testing everything on SD and real carts
Thanks to necrocia too, that helped me testing the Xump build and contributed to fix some things in this template.
And thanks to Sage, that seems to be tired to explain step by step all the lynx internals at avery noob that arrives on this forum, but he shared an invaluale amount of information in so many years of Lynx coding. You rocks guy.
Edited by Nop90, Fri Apr 12, 2019 8:09 AM.