Well sorry to ruin your fun, but there’s already a Game Boy Emulator for the PicoCalc:
The forum/thread is below:
Also to new forum users, check through the forum for common topics and post there instead of making a brand new forum. It helps keep the conversation together.
Sort of, cause i had not implement the SD reading functionality as ROMS will be hardcoded into the firmware. I will do the basics first such as keyboard input and sound first.
It will not retain any savedata for the time being.
i’m fairly sure that’s why the topic says “yet another”, no reason not to make things just because someone else did it different otherwise we wouldn’t have picoware because there were already other micropython ports before it!
Though it’s still early, I’m looking forward to seeing where this GB emulator goes. While cool to see as an experiment, the other one didn’t run at full speed on my pico2w so I’m hoping this one might end up being a little faster and may be capable of full speed emulation even once it gets the remaining features.
I also like the classic GB color palette used here. The other one seemed to force color emulation even for regular games that weren’t GB Color games.
And it’s always nice to see new active projects being shared! Thanks for sharing this @quanliew28 .
I understand the sake of making one for learning, but it slows down community efforts when others make their own versions. Community breeds community.
Picoware started in Arduino IDE, then the C/C++ SDK, then lastly into MicroPython. There are many things inside of Picoware that aren’t in any of the MicroPython port(s) before it. It’s not even a close comparison to what’s happening here, or with your Lua project.
i’m just saying there’s no reason to put someone’s project down. “slows down community efforts”? like this person would definitely be doing something else if they weren’t making a gameboy emulator?
It was my intention to put anyone’s “project down”.
What I meant is, starting your own version (for the sake of not contributing) slows down the progress of projects. It’s the same reason why the Picomite community is divided, the PicoCalc repositories are thin and scattered, and why the forums aren’t as active.
It’s like if I made and released my own uf2loader instead of contributing to pelrun’s. Putting our efforts together is how a community is built.
you’re policing what others want to do with the product they bought over your own ideal of a “community”. this is not how you build a community.
there’s no reason why, and would only add to confusion, for this thread to have been a reply on the thread for an unrelated firmware made by a different person.
since the emulator will give you ROM offsets to read from, i wonder if it would be feasible to implement SD loading by storing the ROM into the PSRAM, you can’t easily access it as RAM allocation in C but you can read/write at absolute positions within it. this would allow you to play large ROMs (some GBC ones can be 2-4 MiB) without relying on the pico’s limited memory. the PSRAM transfer ought to be fast enough to allow for this, i think
The existing driver provided from pico-text-starter is using polling method with limited keystate support. If without modification of the driver, I had to create artifical delay which makes the controls weirdly unnatural when holding a key. As gb_peanut required key press state for it’s joypad bitwise operation.
In case anyone was wondering, the current version runs under the uf2loader. I also loaded up the same game in a desktop emulator and tried to pause and sync it with the PicoCalc to do a rough speed comparison. It seems a bit slower than full speed, but hopefully it can be optimized in time.
We poll the keyboard since that is how the PicoCalc works internally. A hardware mechanism does not exist for the STM32 to notify the Pico if a key was pressed.
I believe the latest version of the starter kit allows one to poll in the background or the app you are building using the starter kit can manually poll the keyboard.
Yes, direct pixel write to the LCD is slow, with current solution. I only can get 14fps. I tried multicore approach as well but still max 30fps, will implement the DMA write as it will free up the CPU and take lesser frame time.
otherwise we wouldn’t have picoware because there were already other micropython ports before it!