[Tool]Pokitto Emulator



I’m not saying TCP doesn’t provide a useful facility, but I’m saying that ideally GDB data’s format should be independent of how it’s transmitted.

TCP is supposed to be the transport layer though - a container for the data that can be replaced by another container.
GDB should be the presentation layer - a data format that overall doesn’t care how it’s sent.

Ideally GDB shouldn’t care if it’s going over TCP or over stdin/stdout.

Have you been able to compile @FManga’s emulator with that setup?

The current setup I’m using is quite similar, but it’s SDL2_net that’s causing issues, not SDL itself (as far as I can tell).

I’ll make some screenshots tomorrow to show you.

In fact I might try getting a separate program up and running with SDL to see if I can narrow down the issue.


Flashing over J-Link is FAST! :open_mouth:

I might’ve missed it, but there’s no indication of which way to connect the cable on the other end. I kept checking my connections while I had it flipped all along. :laughing:


You mean on the J-Link side? That’s true. There is a “1” marked. Its kind of sloppy from Segger. Since it is an “edu” product, I would have used a shrouded (with a collar) header there.

But, the good thing is you can’t break it by putting it backwards.

Edit: pin numbers are indicated in the picture of swd->pokitto pex … there is (1) 3V3. But yes, I could add a picture of the J-Link EDU to make it clearer.


I noticed the “1”… thought it was a board rev number or something. :stuck_out_tongue:


I compiled the latest release for macOS. When I try to run any of the examples (eg. Buttons), I get the following error:

UNKNOWN OP bf00@ PC=b34

Not really sure where to start; anyone have any ides?


GNU/Linux here – I get that for some things too, but e.g. this works for me.


@aus Please post binary you are trying to run


Sorry, I can’t post the bin at the moment. It was a bin created in the Mbed Compiler from the code available here:



I think I’ve fixed this problem. If someone could attach a bin+elf file where this can be observed I’ll confirm and push the patch.


For me it happens for example with the game I’ve made:

UNKNOWN OP bf00@ PC=b70


OK, thanks. That bin shows another, unrelated problem, but the “unknown op” has been fixed so at least it runs. Not sure what’s going on with the text here. :thinking:


What was the problem with the wrong opcode? wrong jump at init?


Here’s my bin
buttons.bin (31.2 KB)


VBA core didn’t have an implementation for NOP, it was set to “undefined instruction”.


Added a new release build for windows/linux (see link in first post).

sampling profiler

Use it like this: PokittoEmu path/to/file.bin -p
Then use this to get the source lines: addr2line -e path/to/file.elf address1 address2 address3...
While the emulator is running it will randomly sample the current instruction to detect hotspots. After shutdown it prints addresses of the top 10 hottest spots in the code, in descending order. These are probably the performance bottlenecks of your game. addr2line is a tool that comes with gcc.

gif recorder

Press F3 to start/stop recording a gif. It will be saved in the same path as the bin that is currently running.
Example gif of a Pokitto bicycle odometer I’m working on:

bug fixes

Implemented missing NOP instruction.


I really would like to put my binary somewhere so that people could try it with the emulator. How to do it? Just put the binary to google drive (or even GitHub?) and provide a link to start it in the emulator?


Do you want people to play in the browser or do you want to package the bin with the offline emulator?


Whatever have your latest fixes :slight_smile:


That’ll be the offline one, at the moment. Steps for linux and windows:

  • Download a build from the releases page and extract it somewhere
  • Put file.bin in the same folder. Double-clicking the build should run your game.
  • Rename the executable, if you want. Zip the files together and upload.

I don’t know how to do this for Mac, yet.


Works, thanks!