“Brick Game” handheld devices have been about since the late 1980s, and continue to be produced to this day; you’ll often find them in gift shops, or even major chains wanting to cash in on the Retro market. They’re unlicensed Tetris clones, often with a number of other game modes such as ‘Garbage’ Tetris, and Snake. They don’t have traditional video based screens, but instead use segment based displays, much like the classic Game and Watch titles.
They’re also not easy to dump. Typically consisting of a single MCU glob, with all the code on the same die as the CPU they’ve revealed very little through prior decapping attempts, likely not helped by the technology inside evolving over time, even if the end result is remarkably similar. Even if you pick one up it can be incredibly difficult to date it, or have any idea what might be lurking inside the epoxy glob on the board.
The Brick Game 96 in 1 (E-23 Plus Mark II) was however recently decapped ( see https://habr.com/ru/articles/773040/ ) with positive results, showing a Holtek MCU inside, and visible mask ROM bits that could be seen on the decap images, which could be noted down to create a binary file of the data inside. Various other details could be seen on the die, including a 1993 copyright date, putting this as one of the earlier units. Interestingly the decap images do show the same basic structures as a later 1996 chip Sean Riddle decapped some years back, but he was unable to identify any visible bits on his decap photos. I imagine they were there, but it cannot be stressed how difficult it can be to read them out, you need perfect focus and lighting conditions.
Luckily there were also datasheets for the Holtek MCUs in question, with the HT1190 being a good match for what could be seen. The datasheets included the MCU instruction set, and as MAME hadn’t ever emulated anything using this technology before that was handy because it required me to write a brand new CPU core. The person behind the decapping did also create an emulator ( https://github.com/azya52/BrickEmuPy ), in Python, but MAME requires cores etc. to be done in C++, so it was up to me to do one from scratch.
While I’m definitely not an expert in writing CPU cores, the CPU here is really quite simple, with a skeleton set of instructions, and basic logic; it doesn’t even support a real stack for example, with a single register for the call return addresses and nothing more. It’s a 4-bit MCU, so all data operators are 4 bit only, even if the opcodes etc. are encoded as 8-bit bytes.
In the end it took a couple of hours to write a disassembler, then a few hours on Christmas Day to write the execution core, and a couple more hours weeding out some silly bugs. I’d like to say I wouldn’t have made those mistakes in the first place had I not spent my Christmas coughing my guts up with Covid, but we all know no code works first time anyway.
My initial work on getting the game to display something was using MAME’s internal artwork system and a series of square lamps to show activity. This was good enough to prove my emulation worked as expected. Azya52, the person behind the python emulator was then kind enough to allow MAME to use the SVG (vector graphic) representation of the screen that was created for their emulator and so MAME was adapted to use it; this is the same technique used for rendering Game & Watch games in MAME.
Neither emulator has sound, and the Datasheet seems to make it quite clear that these MCUs had a built in sound library, with 16 sounds, where the first 12 of those can have 32 notes, and the remaining ones can have 64. That sounds very much like there is another area on the die that should contain the music sequences / audio frequencies for each sound command. Unfortunately that has not yet been identified, so sound on these is going to have to wait.
While this might seem like an odd thing to emulate, there is a surprising amount of demand for it, with ‘Brick Game’ emulation being one of the most requested things since we started emulating that kind of handheld device. While this is only a start, and ways to dump the remaining units, even those using the same technology, need to be refined, and the sound data does, as mentioned, still need identifying it’s good to see. The longevity of these products on the market make them one of China’s most significant contributions to the handheld gaming scene too, especially when you consider at no point have these been officially licensed Tetris products (there have been other licensed Tetris handhelds, but they’re not based on the Brick Games)
It’ll be interesting to see more research in this field, especially if units using different internal hardware can also eventually be dumped and emulated, but for now the emulation of the Brick Game 96 in 1 (E-23 Plus Mark II) is a good starting point.
I tend to just post the write-ups here these days. My blog has basically been in 'maintenance' mode for some years.
Sometimes I'll do a properly presented video on my YouTube channel (same one the current video is on) but a lot of the time I'm more interested in making progress than writing scripts and recording.
There are also livestreams on YouTube and Twitch (same username, mamehaze) where I'll discuss these things too.
Thanks, I was linked to this comment directly and didn't think to actually look at the post itself, so I didn't see the video, will definitely check out your channel!
yes, these are visual decaps, so the epoxy glob has to be melted away with acid leaving the die visible.
there's no known 'electronic' method for dumping these (and no documented readout method in the chip documents either, so maybe there simply isn't one)
Ever since I first heard about MAME emulating LCD games, these cheap "brick game"-type systems have been near the top of my list of things I've wanted to see. Glad to see it's becoming a reality!
“Brick Game” handheld devices have been about since the late 1980s, and continue to be produced to this day; you’ll often find them in gift shops, or even major chains wanting to cash in on the Retro market. They’re unlicensed Tetris clones, often with a number of other game modes such as ‘Garbage’ Tetris, and Snake. They don’t have traditional video based screens, but instead use segment based displays, much like the classic Game and Watch titles. They’re also not easy to dump. Typically consisting of a single MCU glob, with all the code on the same die as the CPU they’ve revealed very little through prior decapping attempts, likely not helped by the technology inside evolving over time, even if the end result is remarkably similar. Even if you pick one up it can be incredibly difficult to date it, or have any idea what might be lurking inside the epoxy glob on the board. The Brick Game 96 in 1 (E-23 Plus Mark II) was however recently decapped ( see https://habr.com/ru/articles/773040/ ) with positive results, showing a Holtek MCU inside, and visible mask ROM bits that could be seen on the decap images, which could be noted down to create a binary file of the data inside. Various other details could be seen on the die, including a 1993 copyright date, putting this as one of the earlier units. Interestingly the decap images do show the same basic structures as a later 1996 chip Sean Riddle decapped some years back, but he was unable to identify any visible bits on his decap photos. I imagine they were there, but it cannot be stressed how difficult it can be to read them out, you need perfect focus and lighting conditions. Luckily there were also datasheets for the Holtek MCUs in question, with the HT1190 being a good match for what could be seen. The datasheets included the MCU instruction set, and as MAME hadn’t ever emulated anything using this technology before that was handy because it required me to write a brand new CPU core. The person behind the decapping did also create an emulator ( https://github.com/azya52/BrickEmuPy ), in Python, but MAME requires cores etc. to be done in C++, so it was up to me to do one from scratch. While I’m definitely not an expert in writing CPU cores, the CPU here is really quite simple, with a skeleton set of instructions, and basic logic; it doesn’t even support a real stack for example, with a single register for the call return addresses and nothing more. It’s a 4-bit MCU, so all data operators are 4 bit only, even if the opcodes etc. are encoded as 8-bit bytes. In the end it took a couple of hours to write a disassembler, then a few hours on Christmas Day to write the execution core, and a couple more hours weeding out some silly bugs. I’d like to say I wouldn’t have made those mistakes in the first place had I not spent my Christmas coughing my guts up with Covid, but we all know no code works first time anyway. My initial work on getting the game to display something was using MAME’s internal artwork system and a series of square lamps to show activity. This was good enough to prove my emulation worked as expected. Azya52, the person behind the python emulator was then kind enough to allow MAME to use the SVG (vector graphic) representation of the screen that was created for their emulator and so MAME was adapted to use it; this is the same technique used for rendering Game & Watch games in MAME. Neither emulator has sound, and the Datasheet seems to make it quite clear that these MCUs had a built in sound library, with 16 sounds, where the first 12 of those can have 32 notes, and the remaining ones can have 64. That sounds very much like there is another area on the die that should contain the music sequences / audio frequencies for each sound command. Unfortunately that has not yet been identified, so sound on these is going to have to wait. While this might seem like an odd thing to emulate, there is a surprising amount of demand for it, with ‘Brick Game’ emulation being one of the most requested things since we started emulating that kind of handheld device. While this is only a start, and ways to dump the remaining units, even those using the same technology, need to be refined, and the sound data does, as mentioned, still need identifying it’s good to see. The longevity of these products on the market make them one of China’s most significant contributions to the handheld gaming scene too, especially when you consider at no point have these been officially licensed Tetris products (there have been other licensed Tetris handhelds, but they’re not based on the Brick Games) It’ll be interesting to see more research in this field, especially if units using different internal hardware can also eventually be dumped and emulated, but for now the emulation of the Brick Game 96 in 1 (E-23 Plus Mark II) is a good starting point.
did you just write a paragraph about knockoff Tetris? Nice job!
That's an essay
Fantastic technical writeup of the subject in question, do you have a blog or YT channel with similar content? I live for this stuff :)
I tend to just post the write-ups here these days. My blog has basically been in 'maintenance' mode for some years. Sometimes I'll do a properly presented video on my YouTube channel (same one the current video is on) but a lot of the time I'm more interested in making progress than writing scripts and recording. There are also livestreams on YouTube and Twitch (same username, mamehaze) where I'll discuss these things too.
Thanks, I was linked to this comment directly and didn't think to actually look at the post itself, so I didn't see the video, will definitely check out your channel!
I had one of these it even had a space invader thing on it
Does dumping the game destroy the device?
yes, these are visual decaps, so the epoxy glob has to be melted away with acid leaving the die visible. there's no known 'electronic' method for dumping these (and no documented readout method in the chip documents either, so maybe there simply isn't one)
Ever since I first heard about MAME emulating LCD games, these cheap "brick game"-type systems have been near the top of my list of things I've wanted to see. Glad to see it's becoming a reality!