Micro Arcade Reverse Engineering

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

definietly needs assembly and some care full hardware mapping full screen would depend on display and haw many colors you want to display.

If you’d want to display 64 primary colors you could take the 2 most significant bits of each color and combine the write strobe into a single 8-bit port. It just takes a few cycles to write a 64-color pixel then.

Yes you’d definetly need a few more Ks for display buffer even if you used (a limited) color palette or tiles

I think you could do some fun things with atmega2560 it has only 8K ram but with a parallel display you could make the display part of the data RAM so read modify write to the display is possible (if display supports it)

Just got blink sketch and serial terminal up on an ESP32, this thing gets quite toasty!

Gonna have lunch then have a go at trying the LCD sketch on the ESP32 to see how much faster it is, should be fun.

By the way, there is something supremely satisfying about getting a new display up and running.

it’s quite slow. SPI bus bandwidth can be a bottleneck

You can’t assign the desired color for every color number.
Every time to select the desired color you have to manually convert the color No to 16bit color definition.
The tricks with significant bits is possible through the conversion table.
But it will take much memory, almost every optimization will take a memory.

I was talking about a display with full parallel bus in parallel mode.

Nope but if the displays databus is connected to GPIO pins. You can control the main colors with a few pins by just changing the most significant bits. You’d do the decoding by wiring the most significant color bits to a specific port. The only decoding/encoding you’d need to do is when a command is written to the display.

1 Like

never played with LCD parallel mode… have to try

Who’s got the GPIO for that? :stuck_out_tongue:

Got it up and running with the ESP32, works just fine with default TFT libraries.

Much faster… :slight_smile:

1 Like

it’s better to use TFT_eSPI lib. connecting to hardware SPI pins and using this lib is about 7-10 times faster than standard ST7735_Adafruit lib (also depends on settings in settings.h of this lib)

Good to know! I’m using hardware SPI already so curious what kind of performance increase. I’m trying to figure out how to continue to do development on this. Deciding what GPIO to use for the buttons and speaker is really all that is left for the circuit design.

Then it’s just sourcing the parts and doing the layout!

Oh and figuring out what to call it!

Mandlebrot set:


The color display really needs a SD card to be very cool… but there is no way to access the SD card once you close the lid.

You could modify the case, which is what I will probably do, but that increases the difficulty level of this mod to include a dremel tool.

I also don’t really know where I would fit it.

probably it’s better to use ST7735 but 128х160. it will allow you to certify the device as microsoft arcade and also allow to do better retro consoles emulation (without or less screen cropping).

esp8266 and esp32 has internal flash you can access as SPIFFS or LITTLE FS
maybe it’s better than SD card )

Internal? I think you mean internal to the module? Don’t these require an external flash chip to hold all the data?

And I am NOT designing a new product, just a fun drop in replacement for the micro-arcade.

some of ESP32 chips has embedded flash but mostly it’s a separate memory chip on the same module near the ESP32 usually 4-16MiB

in ESPboy this flash is used to store lot of games (could be selected through the menu), music to listen or other files with SPIFFS or LITTLE FS file system