8 years of Game Boy tweets

Mooneye GB: A Gameboy emulator written in Rust link

Mooneye GB: Gameboy cartridge types link

Mooneye GB: Cartridge analysis - Tetris (no MBC) link

Mooneye GB: Cartridge analysis - Wizards & Warriors X: Fortress of Fear (MBC1) link

Mooneye GB: Cartridge analysis - three games with DMG-BEAN-02 boards link

Dumping the Super Game Boy 2 boot ROM link
Attached photo

Mooneye GB 0.1.0 released link

Game Boy cartridge PCB photos link

My rapid Game Boy development cartridge works! <1 s save-compile-flash-reboot-observe cycle on real hardware
Attached photo 1
Attached photo 2

Here's a (low-quality gif) video of the rapid development cart https://gfycat.com/EquatorialCavernousFish No touching of cables or power switches

Game Boy test ROM do's and don'ts link

Finally found a Game Boy with the elusive DMG-CPU C. Just one more CGB CPU version and I have all the GB CPUs for research and testing

Got the CPU CGB A as well, so I now have a full set of 18 Game Boy CPUs (I don't care about OXY so CPU AGB E is not included)

Current status: finally working Game Boy hw tools: hw breakpoints, clock edge counts, full signal traces. A treasure trove for research!

Signal trace of running Game Boy Tetris for two seconds...16 million samples, 300 MB Value Change Dump. This is the "light" version :)
Attached screenshot

Let's zoom in until we can see the single byte read from $0040 when the CPU reads the first instruction of the vblank routine
Attached video

Current status: my new hardware setup can trace all 73 digital signals of Game Boy CPU chips. Full tracing@30 kHz, run+trigger@3 MHz

Brace yourselves...more GB test ROMs are coming. VRAM/OAM accessibility timing for read and write can differ! And it makes sense from hw POV

Like taking candy from a baby
Attached screenshot

HW is blocking my research progress ATM...Who knew a system with ~200 loose wires and 5 boards could have noise issues? :P ;) Time for KiCad

Hmm...using a slow slew rate for the GB clock has fixed my HW issues. I hate magic like this but I'll use this as long as things work :P

Joined the Rigol DS1000Z owner club. Here's the clock signal from my CPLD to the Game Boy CPU (divided to 1MHz because of noise issues)
Attached picture

Time to start doing preliminary routing of this monster
Attached screenshot

Very happy with my first 4-layer board :) (manufactured by Elecrow) Soldering took almost 4 hours (hot air + drag soldering)
Attached photo

Added Lisp scripting to my GB testbench :) I don't even like lisps but it works quite nicely here. Dialect is Ketos: https://github.com/murarth/ketos

Published sources for my GB breakout board v3.0. This version was designed with KiCad https://github.com/Gekkio/gb-hardware
Attached photo

Problem? My problem is that I still don't have all the Game Boys I need ;)
Attached photo

Oh dear, I've done it again...another test that passes on real hardware but fails on emulators 😈
Attached screenshot

New GB hardware test: ei_sequence https://github.com/Gekkio/mooneye-gb/commit/b61f9c6e8b3d809957846cd932760aa0398e0a3b

Another new GB hardware test: mbc1/bits_ram_en https://github.com/Gekkio/mooneye-gb/commit/7e34ea3bde5b1192ee2d6d51b2704764785d60dc

It's been on Github for quite some time already, but I think it's time to start actively telling people about the existence of my WIP reference documentation of all GB things: https://github.com/Gekkio/gb-ctr

Instead of being copy-paste of existing GB docs, my focus is on accurate and deep technical documentation, especially stuff that can't be found elsewhere. For example, complete documentation of MBC1 that covers edge cases as well.

Looks like either A) GB uses simple pipelining or B) my M-cycle boundaries are wrong. An M-cycle is 4 T-cycles, but I have evidence that opcode decoding happens 3.5 T-cycles after PC is put on the address bus. That would leave only one T-clock edge for the actual instruction

Published sources for my 2015 Game Boy bus conflict test ROM called "naughtyemu.gb": https://github.com/Gekkio/naughtyemu. Basic explanation is in this forum post: https://forums.nesdev.org/viewtopic.php?f=20&t=16796&p=209596#p209596

Going to talk at @Disobey_fi about Game Boy reverse engineering. The original GB launched in 1989 (almost 30 years ago) and a lot of RE work has been done, but we still keep finding behaviour and edge cases not covered by existing docs or emulators. disobey.fi/#program

Finished tracing all the signal pins in this DMG-CPU B decap photo. Yes, there will eventually be an interactive viewer with toggling/coloring of signals ;)

(Decap photo CC BY 4.0 digshadow / https://siliconpr0n.org)
Attached picture 1
Attached picture 2
Attached picture 3

Here's a version of the earlier picture with pin labels added
Attached picture

Looks like info about "corrupted STOP" on GB is nonsense. The next byte is simply skipped instead of some values being "corrupted". Yes, it still makes sense to put a NOP there, but the justification in current docs for this seems wrong

"A wild STOPHALT bug appeared!"...so it turns out that executing STOP while already pressing a button doesn't do STOP but a different version of HALT. And yes, the HALT bugs are also present here but in a weird way

Ugh... GB bench v1 has 3 separate power rails and it wasn't easy to design the board and route it. In v2 I've got 6 power rails so far in the design from just following datasheet recommendations :O challenge accepted :)

Here's my GB talk from Disobey :D the fine details section has some errors, but I'll write an errata blog post soon to point out the errors

The full video of my GB talk from Disobey 2018 is now available :) the last 10 minutes were missing in the earlier upload. Remember that the "fine details" part has some errors, so wait for my errata blog post before fixing your emulator ;) https://twitter.com/Disobey_fi/status/960221371619045377

Errata blog post for my GB talk is now available. The last section (="fine details") had some wrong clock edges, although the main points are still valid and remain the same link

THE TIME FOR HIDE AND SEEK IS OVER, MR CHIP. I FOUND YOU!

Soooo, once again I can say that I've got all the known GB CPU versions :)
Attached photo

Discovered a new hw technique yesterday: I can now read/write GB hw registers freely in my test bench, so I can read stuff like PPU registers at one clock edge accuracy. This is huge!!

Screenshot 1: scanline LY + modes
Screenshot 2: mode 1 / line 144
Attached screenshot 1
Attached screenshot 2

New GB test ROM: acceptance/ppu/stat_lyc_onoff

You know the drill...it passes on all real hardware versions and fails in every emulator I tested (including mine) :)
Attached screenshot

GB research is on hold for this weekend because I'm looking for secret lost GB hardware documents in the Alps. Haven't found any yet but I'll keep looking! 😜 next week: PPU interrupt and OAM DMA conflict tests + docs in gbctr
Attached photo

I'll be doing an updated version of my recent talk about GB reverse engineering at the next Reaktor Meetup.

There's still a couple of spots left, so enroll now if you are in Helsinki next Tuesday and are interested in three hardware-focused talks:

https://www.meetup.com/reaktor-events-helsinki/events/248991039

Now I'm pretty sure the glop top DMG CPU is the B version.

Left: DMG-CPU B (© Digshadow/siliconpr0n.org)
Right: glop top decap by me

The die took a lot of damage, but the "L20A" part of "CESL20A" is IMHO clearly visible.
Attached photo

I'll be speaking about Game Boy reverse engineering at @ReaktorBP on May 24th. My talk includes live hw demos and some newly discovered hw details :D

There's a lot of exciting talks at the event, so check out the program and get your tickets here: reaktorbreakpoint.com

Finally received my shipment of 50 Game Boy link ports. Gonna use several for, uh, a project ;) Now I just need to create a couple of new KiCad symbols+footprints, design a PCB and write some VHDL...

Another day, another board :) This is just an update to my old GB-LIVE32 board, but it's an important stepping stone to something bigger...
Attached screenshot

Finally found hard evidence that the GB CPU has a 2-stage pipeline (or "prefetch"). An important find for understanding true timing of hardware traces and some behaviours. I'll present some details and consequences in my Reaktor Breakpoint presentation in two weeks :)

It's going to require a lot of effort to have Game Boy Pocket and Game Boy Color CPU support in my test bench system, but this is how it starts: desoldering CPU chips for upcoming test bench boards. (also in picture: various support chips)
Attached photo

Spent a lot of time today desoldering and measuring all components from this poor corroded Game Boy Pocket board. Loose 0603s are a pain to probe, but I only managed to lose one component. Goodbye C35, you will be missed.

Same unit before desoldering: https://gbhwdb.gekkio.fi/consoles/mgb/MH12129596.html
Attached photo

10+ hours of USB debugging has finally paid off: my GB-LIVE32 rapid development cart v2.0 is now much more reliable than its predecessor. This time I've polished things a lot, so everything will be open sourced (KiCad design, PIC18F firmware, Rust lib+CLI app).
Attached photo

Getting ready to start routing this little guy...if this works out, it means I can create a working MAX 10 FPGA design with some high speed IO included. And that is the road to GB-BENCH v2 with new stuff like audio capture and Game Boy Color CPU support
Attached photo

Here's a (very) rough demo video of my GB-LIVE32 v2.0 rapid development cartridge:

https://www.youtube.com/watch?v=GCIcgmga9Mo

Now fully open source!

KiCad/gerbers: https://github.com/gekkio/gb-hardware
Firmware/software: https://github.com/gekkio/gb-live32

I've got two valid excuses for doing slightly less GB things recently:

1. The parcel with new GB-BENCH control PCBs still hasn't arrived and tracking says it's been stuck at the Helsinki airport for two weeks now 😢
   
2. I started playing Danganronpa and am completely hooked 😇

Ok looks like I've managed to confirm my first finding of temperature-dependent behaviour on Game Boy hardware :D now emulators just need to add support for temperature sensors and/or a temperature slider in the UI.......

TIL: a Game Boy and 2 games in hand luggage is normal.
3 Game Boys and 6 games in hand luggage gets you "Sir, you've got a lot of electronics in your bag" and a bag search at the airport security :D

(not complaining...I'm sure it looks a bit unusual :P)

Current status: experimenting with different approaches to writing a parser that can identify chips on GB cartridge boards based on the chip labels
Attached video

I'm entirely convinced that the original GB CPU chip uses a Sharp SM83 CPU core. And there are public datasheets of some chips that use the same core....😍

One more thing about SM83 CPU core: it's possible GB is not exactly SM83 but just SM83-compatible...there might be an older ancestor (a bit like 6502 vs 65C02). In 1986 data book there's SM-812/SM-813 with the same reported instruction count as SM8311/SM8320...but no details

Not looking forward to soldering this beast 😓 the schematic isn't even ready yet, so there will be more capacitors
Attached screenshot

Internal primary 8-bit data bus of the Game Boy DMG-CPU B chip visualized
Attached screenshot

Time to write some VHDL for this monster :D
Attached photo

Experimenting with Ghidra and Game Boy ROM reverse engineering...there's no official support for GB but my custom language support files work already surprisingly well
Attached screenshot

I shall call this "art piece" The Twins

Got some soldering to do during the holidays 😁
Attached screenshot

My FPGA-based GB cartridge dumper can now dump a Tetris cart ROM in ~40 ms. It's overkill, but I'm practicing using FT232H USB chip's FT245 sync mode (~40 MB/s half-duplex, but limited here to ~15 MB/s at the moment, because pipelining in my VHDL code isn't yet perfect)

Time required to dump Densha De Go 2 ROM (largest Game Boy game, 8MB ROM):

GB01 (a polished-looking cartridge reader you can buy): 5 min 30 s
GB-CARTPP (my not-so-beautiful device): 10 s

And I still have two performance tricks left that I can do with the FPGA 😊 target is <5 s

Improved the hardware timings, so now I can dump Densha De Go 2 in 2.1s. However, this is with "overdriven" timings so it's not a good idea in normal use. Perfectly compatible timings give 5.1s, which is still a good result
Attached screenshot

Published my Game Boy extension for the Ghidra reverse engineering framework:

https://github.com/Gekkio/GhidraBoy

It can be used for both cartridge ROM and boot ROM disassembly / reverse engineering

Prebuilt GhidraBoy release zips are now available for both Ghidra 9.0.4 and 9.1-DEV (latest Ghidra git master) https://github.com/Gekkio/GhidraBoy

I've been working tirelessly to go through and fully understand the recently released amazing Game Boy schematics by @Furrtek. Still got plenty of work, but here's simulation results of some bus accesses that match real hardware. Automatic VHDL generation from KiCad helps 😀
Attached screenshot

I've released GhidraBoy 20191104, which has been tested to work with the recently released Ghidra 9.1 release

https://github.com/Gekkio/GhidraBoy/releases/tag/20191104_ghidra_9.1

It's just Tetris, right?

...this image was generated by a low-level 11kloc VHDL simulation model consisting of 1200+ DMG-CPU B standard cells almost entirely generated from KiCad schematics.

Simulating ~20ms took ~40s of real time and generated a 250MB signal dump file.
Attached screenshot

SM83 CPU core tracing progress...unfortunately currently available decap photos are not good enough for much more. But I'm surprised how much one can learn from just looking at how things are connected. For example, the register file has more buses than one might expect.
Attached screenshot

GhidraBoy has been updated and the latest release is compatible with Ghidra 9.1.2 🎉

https://github.com/Gekkio/GhidraBoy/releases/tag/20200219_ghidra_9.1.2

Here's DMG-AMP IR3R40 (manufactured by Sharp), the amplifier chip from the original Game Boy
Attached photo

Here's DMG-AMP and F411A under higher magnification. I don't have a motorized XY stage so everything was done manually. Luckily Microsoft ICE worked much better than I expected and managed to stitch the photos fairly well.
Attached photo

Max resolution photos are here:
https://gekkio.fi/files/decapped-chips/AM4515ZT4/

Better tools -> better chip decap photos.
This is the same magnified part of the DMG-AMP chip die taken with my old tools and new tools for comparison.
Attached photo 1
Attached photo 2

This cell is my reverse engineering mystery of today...behaviour suggests it could be AND gate. But note how In2 only goes to a gnd-side NMOS, so the input side looks almost like Pseudo-NMOS NAND with 2x NMOS in series. But In1 also has the complementary PMOS near vdd-side (?!)
Attached photo

Here's how I see it at the moment...black rectangles are the transistors. Seems like an AND gate but In2 PMOS is missing. The yellow signal also has one unexplained via that seems to be connected to diffusion area going up towards gnd, but obscured by the green signal metal
Attached photo

Abstract art, or fully traced Game Boy SM83 CPU core instruction decoding 1st stage? You decide...

In: 8-bit instruction register + 3-bit seq counter + "in CB mode" flag + "in interrupt dispatch" flag
Out: 107 control signals, 3 seem to be always low
Uses dynamic domino logic Attached photo

This is what a fully traced Game Boy Pocket mainboard looks like :D
...
...
...
And here are the schematics!
https://github.com/gekkio/gb-schematics
Attached photo

GB SM83 CPU core I/O cell reverse engineered. One surprise about the CPU core is how much dynamic logic and precharging it uses. Even the main SoC data bus (EXT_DATA) has precharge circuitry and the CPU core only uses a low-side driver (but SoC peripherals are proper push/pull)
Attached screenshot

Some more info and the Inkscape SVG is now here: https://github.com/Gekkio/sm83-research

I've got a lot more details about SM83 coming soon™, including new info about the register file and the various (and plentiful) 8-bit buses internal to the CPU core.
Also: simulation-tested HDL code

Ummm...yeah sure, Microsoft Image Composite Editor, that's exactly what the chip die looks like. Good job! Well stitched!
Attached screenshot

It managed to stitch this 10x objective photo correctly, but at 40x there seems to be too much repetition and not enough information for it to infer the layout correctly :(
Attached screenshot

Here's a "handy" guide to some Game Boy MBC3B memory bank controller chip standard cells
Attached screenshot

And no, there's no ARM microcontroller on the chip

What exactly are you implying, FJWC?? 🤨🧐
...
FJWC=(NOT nSHDN) OR (nWR)
In other words, FJWC=nWR when nSHDN=1, and FJWC=1 when nSHDN=0. Turns out nSHDN isolates pins (like Lattice Power Guard / Xilinx DataGATE), so this extra gating is needed to keep nWR safely deasserted
Attached screenshot

Aaaaand nope, I don't think I'll capture a full set of photos of a decapped CPU CGB B chip die, since stitching is a nightmare as usual and I'll go mad before getting it to work with a chip this large. People with motorized XY(Z) stages don't know how lucky they are
Attached screenshot 1
Attached screenshot 2

Decapped an SGB-CPU 01 chip to capture some Game Boy SM83 CPU core photos with 40x magnification + EDF. Can you tell the difference between left (from siliconpr0n.org, 20x I think?) and right (mine, 40x + EDF)? 😎
Attached screenshot

The previous photos were of an IO cell. Here's a piece of the ALU
Attached screenshot

Finally figured out this mystery cell used in the Game Boy SM83 CPU core link to tweet

It's just an SR latch (with reset signal prioritized) but unusual because S and R have opposite polarities.

Truth table:
nR S Q
0 0 0
0 1 0
1 0 held
1 1 1

I almost had it figured out here: link to tweet

Yellow is inverted and output to green, but the previously missing part is another inverter (2 transistors)! Green is also inverted and output to yellow, creating a cross-coupled inverter loop that makes the cell a latch

Here's a higher resolution photo of the damn thing...

"bastard_gate.jpg"
Attached photo

Here's something I started writing 4 years ago...I wrote it because most reviews of Game Boy mods/parts focus on ease of installation and not on the technical side

"HHL Bivert Module V2 - technical review" a.k.a "how hard can it be to invert two signals"
link

After another evening of lovely reverse engineering work, I proudly present the first publicly available schematics of Game Boy Advance SP console.

(this is for AGS-001 mainboard revision AGS-CPU-11...other versions have some differences)

https://github.com/Gekkio/gb-schematics#game-boy-advance-sp-ags-001-mainboard-ags-cpu-11
Attached screenshot

Earlier this year I reverse-engineered stage 1 of the Game Boy SM83 CPU core decoding logic. I think it's time to start working on stage 2 😎
Not really looking forward to stage 3, which is the largest one.
Attached screenshot

The goal is to generate a lot of control signals depending on the opcode in the IR register and a couple of system state signals.
Instead of simple and clean grid-like structure, all stages use pass transistors and surprisingly complicated diffusion layer to do both AND/OR logic.

For example, this blue column is a stage 1 output I call OP_NOP_STOP_S0XX. Purple "taps" are pass transistor gate inputs, horizontal lines are the inputs. If all pass transistors conduct, an electrical path is formed between top and bottom ends of the column (ground and output).
Attached screenshot

Dynamic logic is used, so in one clock phase, the ground in the top end is always disconnected and the output is precharged to 1. In the other clock phase, the ground is available and the column may pull its output low.

Here's a VHDL implementation of this column.
Attached screenshot

Doesn't look that bad, right? Well, that was a simple case 😏
The blue "column" can be much more complex, and multiple outputs share some parts.

Here's 3 outputs based on a complicated shared diffusion layer structure with branching:
OP_LD_X_N
OP_LD_X_N_SX00
OP_LD_R_N_SX01
Attached screenshot

Remember, all that matters is creating a path to ground! So the three parallel mini columns basically form a NOR3.
Here's the VHDL 😅
Note that this code intentionally matches the original structure, and the same logic could be written in a simpler way without branching/sharing.
Attached screenshot

Ghidra 9.2 has finally been released and I've also released a new version of GhidraBoy freshly built for Ghidra 9.2 🎉

https://github.com/Gekkio/GhidraBoy/releases/tag/20201113_ghidra_9.2

Took me more than 30 minutes to spot one error in the traced blue areas in Game Boy SM83 CPU core stage 1 decoder. Can you spot the mistake?😏

One challenge with stage 2 RE is that even small mistakes in stage 1 propagate and lead to great chaos and confusion in stage 2
Attached screenshot

All done with Game Boy SM83 CPU core decoder stage 2! Simple simulation gave sensible control signals, although there's definitely some mistakes left here (and in stage 1 too!). More CPU core areas are needed for thorough testing...

Photo shows stage 2 before vs after tracing
Attached screenhot

I've published the Inkscape SVG here:

https://github.com/Gekkio/sm83-research

Note that the signal names are still based on "educated guesswork" and might be incorrect and/or misleading.

...and yes, I know stage 1 is still missing from the repository 😅

Game Boy SM83 CPU core RE status: since finishing decoder stage 2 and tracing its outputs, I've noticed how we've got a "everything is connected to everything" -type of situation...
So now I'm doing the ALU, the register file, and decoder stage 3 at the same time. 😅

Back when I started this RE work, I imagined a decoder connected like this:
opcode + CPU state -> stage1 -> stage2 -> stage3 -> various places like ALU and reg file

Reality:
stage1 -> stage2 -> stage3 -> places
stage1 -> places
stage2 -> places
ALU has extra local decoding logic

It's interesting to watch the value of my stock market investments go down, and the value of the 60+ Game Boys I bought 4-7 years ago to go up 😅
Maybe one day I'll actually sell some on Ebay for profit

Writing a blog post about Game Boy flash cartridge power consumption. Pretty interesting measurement results!

It makes me wonder how optimized existing designs are, and what are the practical limitations in designing low power carts...

Blog post will be available soon™
Attached screenshot

TIL: A 30-year old Game Boy cartridge can still have a battery in a very healthy condition. I just measured 3.257V battery voltage on a cart from 1991.

I initially didn't believe it, but datasheets confirm 10-80 times difference in data retention current specs between RAM chips.

https://gbhwdb.gekkio.fi/cartridges/DMG-GWJ-0/gekkio-1.html The cart in question uses Sharp LH5168 with 0.6 uA MAX spec. Carts sometimes use chips which have 10uA or 50 uA MAX specs. Conditions may vary slightly, but even if the difference in reality is something like 1:5, it can mean 50 vs 10 year data retention.

New blog post: Power Consumption of Game Boy Flash Cartridges

link

Short summary:
Everdrive GB X5 beats other SD-card flash cartridges. Genuine carts beat Everdrive GB X5. My designs usually beat genuine carts

It's been a while since I've done any work on this, but I finally have a rough but working MVP of this "magic" tool useful for chip reverse engineering.

Current focus is Game Boy DMG-CPU B simulation and testing, but I plan to use the same approach on other chips as well.
Attached screenshot

I already have a tool that generates a flat VHDL model from a KiCad netlist. But this is better, because I can isolate and test any part of the hierarchy separately.

For example, I can write a VHDL testbench just for the "System clocks" module which is defined in clock_gen.vhd

And it turns out testing is crucial when dealing with a model of a large chip.
Maybe some cell has been misidentified or signal polarity is wrong in some cell model. A simple mistake can ruin the entire model, so I find testing and building trust piece by piece very important

GhidraBoy for Ghidra 9.2.4 has been released 🎉

Developing new GhidraBoy features is not on top of my list at the moment, but I do try to keep up with Ghidra releases so you should never find yourself unable to upgrade Ghidra just because GhidraBoy is holding you back.

GhidraBoy for Ghidra 10.0 has been released 🎉

As usual, a prebuilt binary package is available on the releases page:

https://github.com/Gekkio/GhidraBoy/releases/tag/20210630_ghidra_10.0

Fairly quick'n'dirty decap of Nintendo Game Boy Advance SP SoC chip (CPU AGB B) with 4x microscope magnification.

Way too modern for detailed RE work, but some info can be collected from this photo.
Chip die labeled as "CBUG04". Package is QFP-156, die has 156 pads so no unused
Attached photo

Max quality stitched photo is available here:

https://gekkio.fi/files/decapped-chips/Frankenscope/CPU-AGB-B/

I've released the schematic for the original Game Boy LCD board (version DMG-LCD-06)

Not terribly exciting, but these are (hopefully) accurate unlike the older schematics you can find online.

https://github.com/Gekkio/gb-schematics#original-game-boy-lcd-board-dmg-lcd-06

The test ROMs bundled with Mooneye GB emulator are now known as "Mooneye Test Suite", and are now in a separate repository: https://github.com/Gekkio/mooneye-test-suite/

I'm still sorting out some practical things and the mooneye-gb repository hasn't been cleaned up yet, but this is a first step.

GhidraBoy for Ghidra 10.1 has been released, so you no longer need to fear Java logging library CVEs when doing Game Boy ROM reverse engineering :)

https://github.com/Gekkio/GhidraBoy/releases/tag/20211211_ghidra_10.1

I've just released schematics for the first two Original Game Boy (DMG) power board revisions (unofficially known as type A / B) 🎉

https://github.com/Gekkio/gb-schematics/blob/main/DC-CONV-DMG-AB/schematic/DC-CONV-DMG-AB.pdf

Type C and D will be released later after I clean them a bit.

Other schematics in the repo also got some minor updates 🙂

As promised earlier, I've released the schematics for the remaining original Game Boy (DMG) power boards (type C / D) 😃

I've also documented known differences and added visual component references since the boards have no component reference designators

https://github.com/Gekkio/gb-schematics#original-game-boy-dcdc-power-board-dc-conv-dmg--dc-conv2-dmg

🎶
Might as well jump
Go ahead and jump
Get it in, jump
Go ahead and jump
🎶

For some strange reason I sometimes think about this song whenever I install more than 1 of these things...
Attached photo 1
Attached photo 2

Here's a sneak peek of my next Game Boy schematics project. I've already desoldered and characterized all components and am now doing tracing. After that it's time for schematics...

This time the trace SVG is also nicer since I have two separate but aligned BG layers
Attached screenshot

My current chip decap project: Game Boy MBC1B memory bank controller chip found on many cartridges. This chip is already well understood, but decided to RE it thoroughly anyway.

I've already traced everything and just need to finish the schematics...
Attached screenshot 1
Attached screenshot 2

Image quality is pretty bad since I used a low-quality 20x objective 😅 lots of optical aberrations...

It's good enough to identify cells and connections, but I took some extra photos with a good 40x objective to study internal cell structures.

Just look at the difference 😻
Attached screenshot

"I didn't do anything! I'm sure it was like this when I found it!"
😐

Turns out I was a bit careless with decapping and the die took some damage. Luckily the connections were obvious and easy to guess...
Attached screenshot

I've just released my Game Boy MBC1B chip research 🎉

https://github.com/Gekkio/gb-research/tree/main/mbc1b

• fully traced SVG file based on decapped chip photo
  
• KiCad schematics
  
• automatically generated VHDL model
  
• VHDL testbench, also verified on real HW

Let's take a look at what's in the repo 🧵

Firstly we have the SVG file using a decapped die photo as a background.

All connections are traced and cells are identified. I've even added start/end markers to connections: for example, "FE" OAI21 cell has one output (top left) and three inputs (2x top right, and 1x bottom)
Attached screenshot

Then we have the KiCad schematics (top level sheet in the screenshot). I've tried to make them as readable as possible, but this is still a 1:1 cell-level mapping to the SVG so nothing should be missing.
Attached screenshot

Then we have a VHDL model generated from the schematics using my Kingfish KiCad-to-HDL generator.
Not very readable since this is a raw mapping from the KiCad netlist, but the main point is to run a VHDL testbench "against the schematics" without error-prone manual work.
Attached screenshot

Finally, a VHDL testbench tests and describes the expected behaviour of the generated model. These tests were taken from my old "gpio-bench" hardware system which ran peek/poke -style tests on a real MBC1 chip, so the tests have been previously verified on real hw.
Attached screenshot

Having a way to "test the schematics" has been invaluable...even on a simple chip like this I had one misidentified cell, which was only caught once I started running tests. Staring at schematics and trying to reason about them is way too slow and error-prone for me 😅

I proudly present the schematics of Game Boy Light (a.k.a MGL) 🎉

https://github.com/Gekkio/gb-schematics/blob/main/MGL-CPU-01/schematic/MGL-CPU-01.pdf

As expected, it's 95% identical to Game Boy Pocket (a.k.a MGB), but that 5% includes some important differences that are now documented.

Only one MGL was harmed to make these 😅

My gb-hardware repo now has a "naughty list" of people who violated the very liberal CC BY 4.0 license of my designs.

License summary: just don't erase my name and claim you made the design 100% yourself. That's all. You can modify and/or sell freely.

https://github.com/gekkio/gb-hardware#license-violations-aka-naughty-list

Time for another Game Boy -related schematics release: I've RE'd 2 types of Game Boy Pocket DC/DC conversion boards! AFAIK there are no others.

LSEP01088A1 (a.k.a. type A):

https://github.com/Gekkio/gb-schematics/blob/main/LSEP01088A1/schematic/LSEP01088A1.pdf

A different one with the text "MGB" (a.k.a. type B):

https://github.com/Gekkio/gb-schematics/blob/main/MGB-DCDC-B/schematic/MGB-DCDC-B.pdf

When I woke up yesterday, I had no idea I'd end up reverse engineering the Game Boy MBC2A mapper chip 😅

Yesterday was spent on tracing, so now I just need to do schematics and simulation.

Original background microscope photo by Raphael Boichot: https://github.com/Raphael-Boichot/Game-Boy-chips-decapping-project/
Attached screenshot

The main motivation was two pins: "VCC_RAM" and "GND_RAM". I realized I never questioned previous research which claimed these to be supply pins for embedded RAM. A quick look at the decap photo made it clear that they are I/O pins! I had to RE the whole chip to understand them

"GND_RAM" seems to be an active-low global output enable pin. On PCBs it's always tied low, so all outputs are enabled.

"VCC_RAM" seems to be an active-low async clear pin, which resets all flip-flops. On PCBs it's always tied high, so it's deasserted.

The chip also has an active-low RESET pin, which is actually used on PCBs and it too resets all flip-flops.

Why two pins for reset? RESET also gates inputs, so it does more than the other pin. Perhaps the CLEAR pin was used for testing, or is just an unused leftover feature.

Getting ready to release my Game Boy SM83 CPU core research I started more than 2 years ago. I have a complete HDL model (written in VHDL), understand pretty much all the signals and have assigned good names for them.

Here's a screenshot of the huge manually traced SVG file 😅
Attached screenshot

Here's a zoomed in section of the ALU. The background is a massive stitched photo taken with my microscope using a 40x objective. Some educated guesswork based on my understanding of the chip was needed, because I can't see what's under the top metal layer.
Attached screenshot

I originally started this work using a stitched microscope photo from siliconpr0n.org. Here's one section as an example.

This was sufficient for a lot of things, but some fine structures were a bit too difficult to figure out, so I started building my own microscope.
Attached photo

Using a microscope with a 40x objective, I was able to selectively capture some areas with finer details. Without a motorized stage this was a lot of work, and as a result I had several photos and had to switch back-and-forth between them when tracing common signals
Attached photo

The solution: capture the whole CPU core at 40x and make one big photo. This summer after a lot of work, I finally had a motorized scope and was able to do it. I've moved most of my previous work to this new single photo, fixed mistakes, and worked on the last ~10% I was missing
Attached photo

This turned out to be very useful 😄 As an example, here's one output from decoder stage 1, used by stage 2 and 3 and also the ALU. Previously I had 4 separate SVG files and had to jump between them to understand the whole signal. Now it's enough to look at one trace in one file
Attached photo

After 2+ years of research, it's time to release my Game Boy SM83 CPU core RE work!

https://github.com/Gekkio/gb-research/tree/main/sm83-cpu-core

Includes non-synthesizable HDL model and an SVG with almost all important stuff traced.

Passes Blargg's cpu_instrs tests, except "02 interrupts" which needs a full SoC
Attached screenshot

Let's take a tour! 😄

Here's the register file: you can see all main registers, including the WZ temporary register, which is not directly visible to programmers. 8 "rows" where each row contains everything to handle one bit. 16-bit regs are built as 2x 8-bit adjacent regs
Attached screenshot

Next to the reg file we have the Increment/Decrement Unit (IDU) and some interrupt handling logic. The IDU is a separate unit from ALU, and does 16-bit increment/decrement/load operations, and also outputs the 16-bit address to the rest of the SoC.
Attached screenshot

The interrupt logic block contains e.g. interrupt priority and address handling and also the IE (Interrupt Enable) register. The IF (Interrupt Flag) register is not in the CPU but elsewhere in the SoC!

The CPU core supports 8 interrupts + NMI, but some are disabled in the GB SoC

Next we have a massive 3-stage instruction decoder using dynamic logic. The decoder takes the current opcode and a bunch of other state as input, and outputs a lot of control signals to various parts of the CPU core.
Attached screenshot

Next to the decoder we have the control unit, which consists of a lot of logic cells. It contains some CPU state such as the IME register, and control various parts of the system while taking inputs from the decoder and other areas.
Attached screenshot

A very important part of the system is the 8-bit Arithmetic and Logic Unit (ALU), which handles 8-bit calculations (the IDU does some 16-bit stuff instead). I've also included the flag registers here, but it's debatable whether they are truly part of the ALU or not.
Attached screenshot

What about the HDL?

Non-synthesizable HDL = you can't just put this on an FPGA and expect it to work. Why not? The core uses dynamic logic and other ASIC stuff that FPGAs simply can't do and need to emulate instead.

The main goal here is to support simulation and understanding

What we can do is use this HDL as a reference model to build a more FPGA-friendly model. Many things can be simplified and improved, and the result can be compared to the reference.

No plans to do this myself (for now), but I hope the HDL helps other people 😄

It's also important to understand that this is not a HDL model of a Game Boy...it's just the CPU core, so it can't run any games.

A full and accurate HDL model of the whole Game Boy SoC is a separate thing, and there are multiple projects attempting it (yes I have one too).