Game Boy SM83 CPU Core | Hacker News Reader

Game Boy SM83 CPU Core

github.com

150 pointsmagnifique27 comments

Yay, the only bit of the die I couldn't transcribe for GateBoy!

Looking forward to integrating this into the big simulator mess. Three frames per second here we come:D.

Raise the roof!

"Game Boy consoles use a custom Sharp CPU core that resembles Z80 and 8080 but is not exactly either." - well said but do know that the Z80 resembles the 8080 and it isn't exactly an 8080. To be fair the SM83 as coined here does have a few Z80 instructions but by and large it is an 8080 clone.

The Z80 fills some redundancies and gaps in the 8080 instruction set and adds the concept of prefixed instructions (via the CB, DD, FD and ED prefix bytes), but is otherwise compatible with the 8080 (it can run 8080 code which doesn't use any of the redundant opcodes which have been repurposed in the Z80).

Looking at the Gameboy CPU instruction matrix (https://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html) versus the 8080 matrix (https://pastraiser.com/cpu/i8080/i8080_opcodes.html), the Gameboy CPU looks a lot more like a Z80 than an 8080. For instance the Gameboy CPU has the conditional relative jump instructions (like JR NZ, JR NC, ...) of the Z80, while the 8080 only has redundant NOPs in those instruction slots.

Also while the Gameboy CPU is missing the DD, FD and ED prefixed instruction ranges, it has the complete CB-prefixed 'bit twiddling' instruction range of the Z80).

So IMHO it's more correct to call the Gameboy CPU a stripped down Z80 than an extended 8080 (but of course the Z80 is also "just" an extended 8080, so it's also not wrong to call the Gameboy CPU an extended 8080, the 8080 is basically the grandfather, and the Z80 the father).

Oh please, the big improvement in the Z80 over the 8080 was the IX and IY instructions plus the alternate register set 'AF etc and that's completely absent in the Gameboy CPU. The Z80 is not the father of the Gameboy CPU. A+B-B = A The Z80 has some influence but it's pretty small.

I wouldn't call the IX/IY instructions an improvement. They were so slow that they've rarely been used in performance-sensitive code (like games), it totally makes sense to drop them in a gaming device.

Same for the block instructions in the ED instruction range, quite convenient, but also very slow. LDI/LDD might have been useful for blitting bytes in unrolled loops, but since (AFAIK) the GB video hardware renders tiles and sprites directly, there's hardly a need for copying lots of bytes around.

The shadow register set wasn't all that useful either except for quickly saving state in interrupt handlers, but the additional registers take up a lot of die space.

On the other hand, the entire block of 256 bit twiddling instructions were obviously deemed important enough to keep them in the Gameboy CPU.

So you're basically saying you use a Z80 like an 8080. That's fine.:) But I will admit that the CB array of instructions are quite useful and Z80 in origin.

But just because you don't like a bunch of the Z80 die doesn't mean that the SM83 is a Z80 though. It's basically just an 8080 + CB and instructions that appear neither in 8080 or Z80

Still - I can see both from both sides now.

I've always liked to think of the SM83 as an 8080 clone that happens to use z80 assembly syntax (and includes a few z80 instructions)

But it's not really accurate to call it a clone of anything. It seems to be more of a unique CPU design that happened to steal opcode and semantics from both the 8080 and z80.

The name didn't get coined here - there are Sharp datasheets documenting this core, and they use the name SM83.

Oh wow it's gekkio. They're still going! I remember downloading everything on their site a decade ago because I wasn't sure if Nintendo would ever shut down such awesome work and the knowledge was simply too cool and useful to risk losing.

Can they shut it down, though? Reverse engineering and emulation are all perectly legal despite Nintendo's claims to the contrary. The inner workings of their consoles are not protected.

They can threaten with legal action which is enough for some people to fold - regardless of whether it would succeed in court.

Defending yourself in court is an expensive affair, unfortunately.

Some states have tried to make this better with anti-SLAPP laws. If the purpose of the litigation is to bankrupt the other party who is doing something legal, then the case can often be dismissed very early, and the plaintiff will have to pay a fine.

I am not sure if reverse engineering video game consoles fits into "a matter of public interest", but if you get nastygrams, it's probably worth talking to a lawyer. This might be something they can deal with in an afternoon and not a multi-year battle that bankrupts you.

https://en.wikipedia.org/wiki/Strategic_lawsuit_against_publ...

How do people learn how to reverse engineer ICs from pictures like this? I can make out the connections for the most part, but I wouldn't know where to begin to glean anything else.

A bachelor level EE curriculum is a good start. There must be open courses for most of this these days (perhaps MIT 6.374). Once you understand some basics of semiconductor physics and integrated circuit design all of this becomes much easier to contextualize.

Check out righto.com - you can start small and work your way up. You can learn to understand transistors from their shapes. There are also automated tools like what was used for Visual6502.org

Pattern matching and comparing to a reference implementation. Think of it like a giant Sudoku crossed with a maze.

I understand that at this point the hdl is only for simulation but could someone at one point run a full gb on an fpga?

Yep, we already do. This is cycle accurate

https://github.com/MiSTer-devel/Gameboy_MiSTer

Edit: We can also do GBA and a lot of other cores, all the way up to Playstation 1.

Could you explain a bit how your project is different from the one in the article? Why did they implement the SM83 in HDL when you already have such an implementation?

Also, I don't see any specific FPGA's mentioned, what sort of constraints do these projects have? Does it run on a 3$ one, or do you need something bigger /fancier?

Edit: oh sorry didn't realize MIST is the device, it's an Altera Cyclone EP3C25

The one in the article is based directly on the die scans, while the MiSTer one is a completely custom implementation.

How is the custom implementation confirmed to be "cycle accurate"?

Not just Game Boy but much much more:

https://www.analogue.co/pocket

I still have that one on my wishlist, there's so much good stuff on the original Gameboy systems that I never could play - our birthday budgets didn't stretch nearly far enough.

There are already products doing just that, the Analogue Pocket comes to mind (https://www.analogue.co/pocket)

GateBoy will eventually do that for the whole reverse-engineered die.

Pretty neat. I remember the Game Boy was alright, even with its blurry screen in four shades of snot, but IMO the Game Boy Advance was when handheld gaming got really interesting and engaging.

Reply on news.ycombinator.com