Micro Arcade Reverse Engineering

I wonder if the Tiny Arcade cabinets have the same display protocol, I think so I think those are a little bigger I wonder if they are easier to identify.

Command: 0x2A
Data: 0x00,0x02,0x00,0x81
Command: 0x2B
Data: 0x00, 0x03, 0x00, 0x82
Command: 0x2C

Looks like it is setting up 128 rows and columns with some kind of offset?

Does this look familiar to anyone?

Figured out the pinouts, pretty sure anyways - updated the post.

It’s not the nokia controller because that uses 9 bit SPI so that’s good.

I hope you figure this out … I would love to program one of these little devices!

Looks like it may be the humble ILI9341 or similar, looks like quite a few LCD use that init sequence.

0x2A looks like column set, and 0x2B looks like page set.

Looks like it’s gonna be an ST7735 (maybe)

Looking at this module, the LCD looks the same, just different ribbon connector.

1 Like

Those commands are not unique to one controller. Try doing a reset and catch the display initialisation commands.

1 Like

That is what I did. That’s all that is init before frame data is sent.

Got it working!

Awesome it is a ST7735 it is the same as:

Here is the pinouts and information needed to replicate, although I cut the lines to the epoxy blob on this so that it wouldn’t interfere with this testing…


Wow these screens are actually quite brilliant and sharp! I always had suspected the highly aliased graphics resources on the MicroArcade where the reason for less than stunning visuals, and I’m happy to share that is true! With better content this display will look much better.


Hey @Mr.Blinky your homemade package has an ST7565, how much different would it be to support the 7735? :slight_smile:

So the same display as is used for the ESPboy.

1 Like

I can hardly believe that. Most display controllers need some initialisation or at least a display on command if the default configuration is enough.

An ST7735 starts with display off. Check page 69 on this datasheet power on/reset values.

ST7735 fastest mode would be using 12-bit color mode. Rendering Arduboys display in an 128x64 window would still be 12 times slower than an Arduboy display update.Most games will have major slowdowns. IMO not worth the trouble (when using Atmega32u4 MCU)


Render from the Arduboy OLED 1-bit screen buffer to ST7735 is possible only due to a powerful ESP8266 microcontroller.

Lol I finally get a color screen working and finally and now they say there isn’t enough performance, after years of arguing that there is.

Isn’t there like an 8 color mode or something for these displays?

Anyways, my plan is to run it from a more powerful processor.

Lots of emulators for the ESP32.

ALSO: working with RGB565 is a pain in the butt and/or I’m an idiot. Just trying to write a basic color cycle is proving to be tough.

HaHaHa :smiley:

Only know of two OLED controllers :slight_smile:

With parallel mode, the right display and a few tricks you can use a color display with 8-bit MCUs though (with a good frame rate)

Do we know what chip is in these under the blob?

If I had to guess it’s probably something loosely related to the NES on a chip. That’s what they found inside other similar systems to this like the oregon trail game.

I do know that they developed the games in ASM. And I also think the factory built all the games, and Super Impulse just tweaked the code to get it to run on the different display etc.

Ah that makes sense, what are you planning to do with it, add more games?

My guess is a chip from General Plus like GPL162XX maybe @bateske could donate one to those chip decap guys to find out?

1 Like

probably not the full-screen refresh and need asm optimization for gfx.
for example, in pacman you have to redraw just a few sprites on the whole screen.

for screen buf you need 128*128 = 16384 kb (for 8bit color) so the only way is a direct draw to the LCD another problem - is the memory to store color gfx.
you need much more than for 1bit.

for example, if you want to use just 4bit color (16 colors) it will take less memory for gfx storage but you have to convert it to RGB565 on the fly and it will take quite a lot of microcontroller’s power to render

1 Like

I “think” that is why they use an NES based chip, the tile based renderer gives you the color without as big a performance hit.

And as far as space, I’m going to try and cram a SD card in here.

1 Like

they could use a custom additional chip with hardware tile and sprite acceleration functions
or the one basic with built-in hardware GPU functions.
it’s easy to deal with any gfx with hardware acceleration.

software render always needs a good performance