# PicoCalc GBemu - Yet another GB Emulator

**URL:** <https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350>\
**Category:** PicoCalc\
**Tags:** emulator, firmware\
**Created:** [November 5, 2025, 2:36pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350 "2025-11-05T14:36:23Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![quanliew28](https://avatars.discourse-cdn.com/v4/letter/q/ebca7d/32.png) [@quanliew28](https://forum.clockworkpi.com/u/quanliew28)\
**Post date:** [November 5, 2025, 2:36pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/1 "2025-11-05T14:36:23Z")

</div>

Hi guys. I started tinkering with PicoCalc recently and though why not develop a GB emulator for the Pico Calc and here is it.

It is based on the GBPeanut GB engine. Also credit to BlairLeduc for the drivers library.

So far I just got games running and display only, will continue to add more functionality.

 ![IMG20251105221217](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/7/7678e3c8fc87868bb72170e44c991eb29bdef8b4.jpeg)

Next to implement, keyboard key press state and the audio with SD card and menu support.

Those who are interested may need to supply their own rom and convert gb into romdata.c as shown as SD card support is still on the way.

> **[GitHub - quanliew28/Picocalc\_GBEmu](https://github.com/quanliew28/Picocalc_GBEmu)**
>
> Contribute to quanliew28/Picocalc\_GBEmu development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![jblanked](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/jblanked/32/17438_2.png) [@jblanked](https://forum.clockworkpi.com/u/jblanked)\
**Post date:** [November 5, 2025, 3:07pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/2 "2025-11-05T15:07:40Z")

</div>

Well sorry to ruin your fun, but there’s already a Game Boy Emulator for the PicoCalc:

> **[GitHub - TheKiwil/PocketPico: Game Boy emulation on the Raspberry Pi RP2350 for...](https://github.com/TheKiwil/PocketPico/tree/master)**
>
> master

The forum/thread is below:

> [@GameBoy emulator](https://forum.clockworkpi.com/t/gameboy-emulator/17179):
>
> Hi waving_hand, I’ve ported my first Game Boy emulator to the PicoCalc, currently running on a Raspberry Pi Pico W. The emulator is based on a fork of the PocketPico project. It’s functional, but not yet optimized. Here’s what currently works: Audio Screen Keyboard What still needs to be optimized: Display I suspect there’s an issue with either the display refresh rate, as the performance isn’t very smooth. So I’m reaching out to fellow developers for help with this. There’s a functio…

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.

---

<div class="post-metadata">

**Author:** ![Marsupial](https://avatars.discourse-cdn.com/v4/letter/m/e9bcb4/32.png) [@Marsupial](https://forum.clockworkpi.com/u/Marsupial)\
**Post date:** [November 5, 2025, 3:14pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/3 "2025-11-05T15:14:20Z")

</div>

Interesting work! Thanks for sharing. And welcome to the forums!

Do you currently end up with a different firmware for every game?

---

<div class="post-metadata">

**Author:** ![quanliew28](https://avatars.discourse-cdn.com/v4/letter/q/ebca7d/32.png) [@quanliew28](https://forum.clockworkpi.com/u/quanliew28)\
**Post date:** [November 5, 2025, 3:48pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/4 "2025-11-05T15:48:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![maple](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/maple/32/12677_2.png) [@maple](https://forum.clockworkpi.com/u/maple)\
**Post date:** [November 5, 2025, 4:03pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/5 "2025-11-05T16:03:46Z")

</div>

> [@jblanked](#):
>
> Well sorry to ruin your fun

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!

---

<div class="post-metadata">

**Author:** ![adcockm](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/adcockm/32/1664_2.png) [@adcockm](https://forum.clockworkpi.com/u/adcockm)\
**Post date:** [November 5, 2025, 4:25pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/6 "2025-11-05T16:25:52Z")

</div>

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 .

---

<div class="post-metadata">

**Author:** ![jblanked](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/jblanked/32/17438_2.png) [@jblanked](https://forum.clockworkpi.com/u/jblanked)\
**Post date:** [November 5, 2025, 6:04pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/7 "2025-11-05T18:04:15Z")

</div>

> [@maple](#):
>
> no reason not to make things just because someone else did it different 🙂

I understand the sake of making one for learning, but it slows down community efforts when others make their own versions. Community breeds community.

> [@maple](#):
>
> otherwise we wouldn’t have picoware because there were already other micropython ports before it!

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.

---

<div class="post-metadata">

**Author:** ![maple](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/maple/32/12677_2.png) [@maple](https://forum.clockworkpi.com/u/maple)\
**Post date:** [November 5, 2025, 6:15pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/8 "2025-11-05T18:15:37Z")

</div>

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?

come on. the more the merrier. don’t be a cop

---

<div class="post-metadata">

**Author:** ![jblanked](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/jblanked/32/17438_2.png) [@jblanked](https://forum.clockworkpi.com/u/jblanked)\
**Post date:** [November 5, 2025, 7:12pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/9 "2025-11-05T19:12:32Z")

</div>

It was my intention to put anyone’s “project down”.

> [@maple](#):
>
> “slows down community efforts”?

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.

---

<div class="post-metadata">

**Author:** ![maple](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/maple/32/12677_2.png) [@maple](https://forum.clockworkpi.com/u/maple)\
**Post date:** [November 5, 2025, 7:15pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/10 "2025-11-05T19:15:16Z")

</div>

> [@jblanked](#):
>
> 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.

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.

that’s the last i’ll say on this

---

<div class="post-metadata">

**Author:** ![jblanked](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/jblanked/32/17438_2.png) [@jblanked](https://forum.clockworkpi.com/u/jblanked)\
**Post date:** [November 5, 2025, 7:16pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/11 "2025-11-05T19:16:18Z")

</div>

> [@maple](#):
>
> 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.

Recommending that we keep conversations together is “policing”…?

---

<div class="post-metadata">

**Author:** ![maple](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/maple/32/12677_2.png) [@maple](https://forum.clockworkpi.com/u/maple)\
**Post date:** [November 5, 2025, 7:56pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/12 "2025-11-05T19:56:47Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Marsupial](https://avatars.discourse-cdn.com/v4/letter/m/e9bcb4/32.png) [@Marsupial](https://forum.clockworkpi.com/u/Marsupial)\
**Post date:** [November 6, 2025, 12:41am UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/13 "2025-11-06T00:41:41Z")

</div>

I agree with @adcockm - the “original LCD colours” are great. At least for 1st gen games.

Question regarding keyboard input. Would it be any sort of issue to make it mappable?

---

<div class="post-metadata">

**Author:** ![quanliew28](https://avatars.discourse-cdn.com/v4/letter/q/ebca7d/32.png) [@quanliew28](https://forum.clockworkpi.com/u/quanliew28)\
**Post date:** [November 6, 2025, 1:19pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/14 "2025-11-06T13:19:09Z")

</div>

Its possible to write to the PSRAM and read the ROM from the PSRAM, that i will need to write a PSRAM driver specifically for this task.

---

<div class="post-metadata">

**Author:** ![quanliew28](https://avatars.discourse-cdn.com/v4/letter/q/ebca7d/32.png) [@quanliew28](https://forum.clockworkpi.com/u/quanliew28)\
**Post date:** [November 6, 2025, 1:26pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/15 "2025-11-06T13:26:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![adcockm](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/adcockm/32/1664_2.png) [@adcockm](https://forum.clockworkpi.com/u/adcockm)\
**Post date:** [November 6, 2025, 1:35pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/16 "2025-11-06T13:35:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![BlairLeduc](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/blairleduc/32/11808_2.png) [@BlairLeduc](https://forum.clockworkpi.com/u/BlairLeduc)\
**Post date:** [November 6, 2025, 4:28pm UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/17 "2025-11-06T16:28:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![quanliew28](https://avatars.discourse-cdn.com/v4/letter/q/ebca7d/32.png) [@quanliew28](https://forum.clockworkpi.com/u/quanliew28)\
**Post date:** [November 7, 2025, 2:19am UTC](https://forum.clockworkpi.com/t/picocalc-gbemu-yet-another-gb-emulator/20350/18 "2025-11-07T02:19:37Z")

</div>

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.
