Strange, because I don’t have this problem. During a game, I press Select + Start, which saves the current state of the game onto the SD card (and ram). If I turn off the PicoCalc and then turn it back on, I just have to press Start to resume the game from where I left off.
that is a savestate, whereas i believe jblanked is asking for SRAM (“battery save”) feature
Yes or maybe even to flash
The save state would work I think too, but it’s not working for me either. I can hit Select + Start but even when rebooting a pressing Start, it still starts the game over
Just to be clear:
]is A[is B=is Start-is Select
Correct?
Yes, that’s right. Do you get back to the menu by pressing Start + Select?
I also tested with Pokémon Blue without any issues.
Could you try the latest build of my bootloader-compatible version (https://github.com/TheKiwil/PocketPico/tree/bootloader/prebuild)?
Ahh I see the trick now (I also just tried your latest RP2350 build)
For me, inside of the game, I had to hold - then click =, to get to the on-boot menu. From there, I’m able to turn off the PicoCalc and the state will save. Now when I reboot and then press - + = on the on-boot menu, it brings me get back to my game state
Great work on this!!
I tried your build for RP2040 too! Great job getting to build (I tried for a couple hours the other day and decided to move on). However, none of my roms are working with it (it says loading, then it freezes after it loads)
Hi @jblanked, I reconnected my Pico1 to the PicoCalc and was able to identify the source of the issue.
If a save file (.bin on the SD card) was created with a Pico2, the program crashes because the memory layout is different (the Pico2 has more memory than the Pico1). I made a few optimizations for the RP2040 and tested them.
However, you need to make sure that no save file created with an RP2350 is present before starting the game. I believe this specific case (going from a Pico2 to a Pico1) will be very rare and doesn’t require further attention.
The new RP2040 prebuild is available in the repository.
Amazing work!
What’s the ram usage on something like this, as I want to make this an available app for Astralixi OS in the future if possible.
It’s working now!! GREAT job. The Save State feature works with the RP2040 too ![]()
The emulator is loaded into RAM (compiled with the copy_to_ram option). On the RP2040, it uses 93% of the memory, which is 243 KB, while on the RP2350, it uses 44.73%, which is 234 KB of RAM.
Any limitations for the ROMs? The NES emulator, as far as I understood, can run ROMs up to ~41k
Limitation related to the Pico’s memory size (2 MB for Pico 1 and 4 MB for Pico 2). For example, Pokemon is one of the largest games and takes up 1 MB.
Any reason the 2040 version is slow? I ran pokemon on it and it’s snailing. Any way to boost that?
Hello everyone,
After a few months’ break, I decided to get back to working on my Game Boy emulator for Picocalc. The initial goal was to try Little Sound Dj (for those unfamiliar: Little Sound Dj ), and I quickly realized that this recent ROM was not working on the current version of the emulator.
After some debugging and research, I identified the root of the issue: the version of peanut-gb used in this fork did not properly support the MBC5 type. Unfortunately, recent updates to peanut-gb removed Game Boy Color support, which I rely on heavily.
So I needed to find an alternative. I ended up switching to a fork called Walnut-CGB ( GitHub - Mr-PauI/Walnut-CGB: A extremely portable Gameboy Color emulator all contained in one header. This is a performance oriented rewrite of Peanut-GB, with all DMG updates and CGB support. Execution model makes use of 16-bit and 32-bit paths when possible(optional) and fetches multiple instructions at once for a dual-fetch chained architecture(optional also). · GitHub ), which brings several improvements: better optimizations (dualfetch …), full Game Boy Color support, and compatibility with cartridge types MBC1 through MBC5 — all without requiring major changes on the implementation side.
Using LSDJ also helped me uncover some limitations, especially regarding save handling due to the fixed RAM size allocated in the current version. I have now addressed this by introducing dynamic RAM management based on the Pico model being used.
I now strongly recommend using a Pico 2, especially for Game Boy Color ROMs.
Changes in this version:
-
Replaced peanut-gb with Walnut-CGB
-
RAM size now adapts to the Pico model
-
Added function keys (no more combo keys needed) :
- F1: save RAM and return to the game selection menu
- F2 (+ up/down): adjust sound volume
- F3 (+ up/down): manual color palette selection
- F4: enable/disable frame skip (fast-forward)
-
Added Enter key support in the game selection menu
-
Directional controls, A, B, Start, and Select remain unchanged
-
Introduced versioning system
Currently available on the “Move-To-Walnut-CGB” branch (Will eventually replace the “master” branch), with a precompiled version : GitHub - TheKiwil/PocketPico at Move-to-Walnut-CGB · GitHub
Enjoy!
Welcome back, great work, and amazing timing!
I was bout to submit a pull request that allows multi-platform support, but I think I’ll merge your latest edits and test a few roms first.
Thanks to your commit history, I was able to add in Walnut-CGB. I just need to add in your updated buttons and it should work exactly like yours.
What I basically did was move all of the functionality out of main.c into separate files and created a config header that other projects can edit to get this working in their own projects (or on other devices).
I have a rp2350 and rp2040 build available here:
From there, I was able to create a micropython version of the emulator and add it into Picoware (at 60 fps using only PSRAM)
Thanks to TheKiwil and JBlanked! I loaded up Picoware and ran a couple of game boy games from 40+ years ago that I played back in the day (Tetris obv. And various Mario/Wario games). It works great. The sound is a bit rusty, so I’ve had to turn down the volume, but I’ve enjoyed several hours of fun overnight!
Very happy to see that Walnut-CGB was helpful. If you’re interested, I’d like to add examples of existing implementations(with an upcoming update) to the readme and your and TheKiwil’s projects caught my attention.