I am having an issue with [GB] when running [tobu.gb]. Git hash of main repo [heads/main-0-g1670080] and submodule [remotes/origin/nintendogw-main2-0-g982dfa1].

When flashing Gameboy roms (I've tried several and they all have issues) the sound does not work correctly. On the same device with NES the sound works perfectly well.

To Reproduce Steps to reproduce the behavior:

1. Flash any GB rom to the device.
2. Start the game and compare the audio to an actual Gameboy (Tetris is one that is immediately obvious).

Expected behavior Sounds would be the same as from the original Gameboy, instead they are nearly unrecognizable from their original.

Desktop (please complete the following information):

• OS: MacOS
• Debugger: ST-Link v2 (original)

Additional context Prior to around December 26th the sound on Gameboy was working perfectly well so something changed between then and around January 9th (I was on holiday so wasn't keeping up with builds).

This is a PoC for long-holding (0.5 seconds) the pause/set button to toggle speedup between 1x and the last non-1x selected speed. If you're fine with this approach, i'll apply the same logic to the other emulators.

Based on https://github.com/kbeckmann/game-and-watch-retro-go/pull/113 since I'm assuming you'll be fine with that PR and didn't want to deal with merge conflicts afterwards.

This is not really a bug, more of a setup problem. I've tried REAL hard to have GCC 10 be detected while compiling the project on a Raspberry Pi 3, but I never get past the compiler check.

More specifically:

Please use GCC Version 10

You are using:
-e

I've tried downloading and setting GCC_PATH manually (to no avail), as described here: https://github.com/kbeckmann/game-and-watch-retro-go/issues/90

Note: the other parse_roms.py related PRs should probably be merged in first, which will make this PR look much smaller.

Summary:

• Added the zopfli compression to parse_roms.py. This is a high compression ratio algorithm that outputs DEFLATE encoded data.
• I added an optional progressbar to parse_roms.py since zopfli takes longer to compress data.
• Updates miniz in retro-go-stm32 via cherry-picks. This originally was primarily used for encoding/decoding save-state screenshots as well as game artwork via lupng. We don't use that at all in this project, so I disabled compilation and linking of lupng.
• Added zlib/DEFLATE decompression support for NES roms. I detect to do this based on the ROM file extension.

Current downside of this PR as is:

• It will also apply zopfli compression to GB/GBC games. While the compression should be correct, I haven't coded up the pairing decoder (however thats my next task).
• Its now pointing retro-go-stm32 to my fork, we should merge in those cherry-picks to your fork

For completeness, here are some comparisons on NES games:

Name          Size (Uncompressed)      Size (lz4)    Size (zopfli)   Ratio (lz4)  Ratio (zopfli)
StarTropics   524,304                  291,322       251,186         55.6%        47.9%
SMB           40,976                   36,248        30,432          88.5%        74.3%
SMB3          393,232                  250,828       220,336         63.8%        56.0%

On some toolchains, GCC will insert bounds checks in memcpy and friends by default which erroneously trip in main() as it loads the contents of flash into ram.

Passing -U_FORTIFY_SOURCE to GCC prevents these checks from being emitted and fixes the issue.

[email protected]:~/game-and-watch-retro-go$ make Cannot find arm-none-eabi-gdb -e

Please use GCC version 10 You are using: gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (15:9-2019-q4-0ubuntu1) -e make: *** [Makefile.common:414: CheckTools] Error 1

How can i fix this issue. Trying for my self, but no success.

HI~ OS:MACOS 11.5 DEBUGGER :ST-LINK arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.07) 10.3.1 20210621 (release)

game-and-watch-retro-go wumengjia$ make -j$(sysctl -n hw.logicalcpu) flash [ WGET ] stm32h7xx.h [ WGET ] stm32h7b0xx.h [ WGET ] system_stm32h7xx.h [ WGET ] cmsis_compiler.h make[1]: *** [Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h7b0xx.h] Error 3 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [Drivers/CMSIS/Device/ST/STM32H7xx/Include/system_stm32h7xx.h] Error 3 make[1]: *** [Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h7xx.h] Error 3 make[1]: *** [Drivers/CMSIS/Include/cmsis_compiler.h] Error 3 make: *** [flash] Error 2 game-and-watch-retro-go wumengjia$ make clean [ RM ] build game-and-watch-retro-go wumengjia$ make LARGE_FLASH=1 flash [ WGET ] stm32h7b0xx.h make[1]: *** [Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h7b0xx.h] Error 3 make: *** [flash] Error 2

Here is an implementation of the STM32 RTC Hardware Support for the retro-go Game and Watch fork. The time can be viewed when pressing the "TIME" button on the main retro-go menu and by selecting Time or Date the aforementioned can be adjusted.

Main things:

• uses pathlib.Path instead of os.path
• No longer shells out to split/gsplit
• Adds easy future expandability for different compression algorithms
• attempts to use python's lz4. If unavailable, fallsback to shelling it out
• change all subprocess.run to subprocess.check_output

I tested this on 34 GB/GBC and 31 NES games and the files produces by the python lz4 bindings are identical to the files produces by the lz4 CLI.

Current drawbacks:

• Due to the restructuring, if python lz4 isn't installed, then each individual gameboy bank is being shelled out to lz4, which is significantly slower when compared to passing all the banks into a single lz4 command. Across those 34 GB/GBC games, this takes ~35s (as opposed to near-instantaneous). If we feel like this is too long, I can make a workaround, but then the code will be less clean

This PR fixes the speedup option in the gameboy emulator and adds both 1.25x and 1.5x options. #110

Looking to see if you like this approach before I propagate it to the other emulators. They should all be done at once since they share the same speedup attribute.

In the retro-go-stm32 submodule I add the following enum in components/odroid/odroid_system.h, pasted here to avoid all the submodule hassle:

enum
{
    SPEEDUP_1x,
    SPEEDUP_1_25x,
    SPEEDUP_1_5x,
    SPEEDUP_2x,
    SPEEDUP_3x,
    SPEEDUP_MAX,
};
typedef int32_t emu_speedup_t;

Converting the rom files to .c files with char arrays is very heavy on the memory usage of the compiler. By converting them directly to .o files this step is no longer needed.

The Makefile dependencies of generating the rom files has been fixed. Parsing the rom files will now only happen once when -j is used.

Please don't attach or link to game ROMs and similar files unless the license explicitly allows this.

Please include the following:

• Which console (NES, GB, ...) NES

• The full name of the ROM you are running, e.g. "Super_Tilt_Bro_(E).nes" Guardian Legend, The (USA).nes, Guardian Legend, The (Europe).nes MD5 43cce874046a0850bf62eb6452e89e6b

• The git hash of this repo and the submodule. Run the following: git describe --all --long --dirty=-dirty; cd retro-go-stm32; git describe --all --long --dirty=-dirty Can't do this for now, hope it's not required. I have problems even with olderzeus's fork as well Edit:

heads/main-0-ga5a9b8b
heads/main-0-g5f1dd2b

Describe the bug When a lot of enemies are on screen (which on this game happens most of the time), the performance tanks a lot, until they go away. This does not happen on real hardware (proof: https://www.youtube.com/watch?v=ImwZBSo8Rvo)

To Reproduce Simply boot up the game and start a new game, in less than a minute, when the blue meteorites start appearing and then chasing you, the framerate drops tremendously, while the audio is virtually unchanged.

Expected behavior It should not slow down, like the real NES

Screenshots I'm not really sure how to export a performance graph, so I can't help here

Desktop environment:

• Host device OS: Artix Linux
• Debugger: ST-Link v2 clone

Additional context Clearly a nofrendo problem, probably with the mappers (or with the rendering)?

Add Game Genie support for NES

To add Game Genie codes, create a .ggcodes file next to the .nes you want to add game genie codes for. The file is a simple CSV with each line containing "code(s), comment", like this example for Super Mario Bros 1:

SXIOPO, Inf lives APZLGG+APZLTG+GAZUAG, Mega jump YAZULG+YAZUIG+YAZUYG, Moon Gravity OZTLLX+AATLGZ+SZLIVO, Always fire YSAOPE+YEAOZA+YEAPYA, World 8-1 YSAOPE+YEAOZA+AOAPYA, World H-1 YSAOPE+YEAOZA+LXAPYA, World -1 TVVOAE, Circus music PIGPOG, All sorts of fun GOZSXX, Invincibility NPEPNY, Bullet bills 1-1 PINAOO, Cool colors

You can also comment out a line by putting // or # in front of a line.

These codes are collected by parse_roms and put in a static array in nes_roms.c. You can have a max of 16 codes (triple codes, like the World 8-1 code above, count as 1). Each rom is assigned a unique monotonically increasing id which references a rom structure in persistent_config_ram containing a 16 bit variable, each bit identifying which codes is currently active.

Before loading a rom, the user can select which game genie codes are active. When the rom is started, the set of game genie codes are converted into a list of addresses, values, and compares stored statically in game_genie.c. When a new PRG ROM bank is loaded into memory (in mmc_bankrom), the memory in that space is patched by calling into gameGeniePatchRom. A special function was added in nes_mem.c to allow writes to PRG memory.

To compile with game-genie support, add GAME_GENIE=1 to your make line.

Depends on https://github.com/kbeckmann/retro-go-stm32/pull/17

A suggestion for swapping select / start to be turbo buttons for B / A. Could also be put behind a compile flag. Or, I also have a patch that's part-way complete that would put it behind a menu option.

is it possibe use START and SELECT button as extra one instead of mapped to GAME and TIME buttons respectively?¿.
It could be used to correctly emulate those games that have 4 actions

Thanks in advance.

When INTFLASH_BANK=2 is set, we need the second bank which requires a patched openocd. If not, it will work just fine with an unmodified openocd build.