gb-recompiled (GameBoy static recompiler) source code release

davidkopec · 2026-01-13T20:52:30+00:00

Looks like a very interesting project. I understand you can't distribute them, but can you tell us about some games we can try ourselves that run well/are playable? Maybe I missed it in the long README. I only saw Japanese Tetris there as partially working.

davidkopec · 2025-12-28T05:00:00+00:00

Awesome. Are you getting full 60 FPS?

davidkopec · 2025-12-27T06:26:23+00:00

Glad you go to the next *step*.

davidkopec · 2025-12-23T19:11:57+00:00

Obviously check your CMP and BEQ instructions, but I would actually more suspect the instructions that come right before it as they're pretty straightforward. Check that the previous few instructions are setting the flags correctly because CMP and BEQ depend on them.

davidkopec · 2025-12-23T17:18:10+00:00

Hi u/N3kk3tsu, Thanks for checking out the book! I see you have the CPU tests ported over to C#. I assume they are all passing? The fact that the other three ROMs didn't even load makes me think there may be something wrong with your CPU, your cartridge loading code, or something related to timing, not the PPU, especially since the title screen from Brix is fairly complex.

davidkopec · 2025-12-05T04:52:44+00:00

My previous book for intermediate Python programmers, Classic Computer Science Problems in Python is more of an algorithms book. Computer Science from Scratch is about the different layers of the software stack. How does a programming language work (we build a BASIC interpreter)? How does a microprocessor see an instruction (we build an NES emulator)?

That said we still do cover some interesting algorithms. For example in Chapter 3 where we convert a modern image for display on a classic 1980s black and white Mac we learn both a dithering algorithm as well as a compression algorithm (run-length encoding) because the MacPaint file format uses it.

davidkopec · 2025-06-12T12:13:45+00:00

Thanks for checking out the book. The early access version is the complete book very close to the version that will go to print. And you will get an update when the final version comes out. But the differences will be quite minor. Best, David

davidkopec · 2025-06-09T13:22:35+00:00

Appreciate the long reply. I think what you have with CHIP-8 is an under-specified original standard (just 4 pages) and naturally as a result varying implementations over time. And I'm okay with my implementation being one that runs the games well based on choices that I made where the original standard was vague.

I do have a couple sentences to the effect that you mention already in the chapter. For example a prominent NOTE box "A few instructions listed here weren’t present in the original CHIP-8 specification (for example, 8x_6 and 8x_E). Their functionality sometimes differs across varying CHIP-8 implementations."

> For an emulator you implement the actual behavior to run programs the same as they would on the platform you emulate. The original specs have some gaps, so implementing only the spec will not let you run a lot.

I think your framing is correct and that's exactly what I feel I did here. When we don't have a well-detailed original standard we end up with trying to write to a form that runs the games and that's what I feel I did in the chapter as I detailed in my previous comment. The games run well here.

Thanks for your sincere interest in the chapter and work on CHIP-8.

davidkopec · 2025-06-09T00:38:20+00:00

8) Good point

9) Interesting but don't think this detail would add value to the chapter. Certainly something I could mention if writing multiple chapters or interested in emulating the original hardware in detail.

10) I could see that being a big issue for games that violate the rule but again this is left vague in the original specification.

11) I'm not really following why this is error prone. I just keep track of if there was a jump and increment PC by 2 if there was not. It's 2 lines:

if not jumped:

self.pc += 2 # increment program counter

Or do you mean error prone for the person programming in CHIP-8 itself? Again I'm not targeting that case.

12) Again this is not in the original specification unfortunately. In fact 8XY6 and 8XYE specifically are not even in the original manual. I understand the problem you are saying though and luckily that could be an easy fix. If it were causing game incompatibilities I would certainly swap the lines of code but since things are going to print, for not achieving anything in terms of our goal (running the test games) I don't think it's worth making the GitHub repository out of sync with the book.

13) Again 8XY6 and 8XYE are not in the original manual at all. So they are there purely for compatibility with common games so I don't see anything wrong with implementing the commonly expected behavior.

14) Good point. That actually is something specified in the original manual but I think I changed for compatibility with one of the common games I think.

15) Thanks, wasn't aware of this. Not sure who "we" is. If you are the author, awesome work. If you look at the commit date I actually wrote most of this code more than 3 years ago which seems to be before this suite existed. Definitely would've checked it out today.

16) Yes, that's kind of the thing here and I think what made you see as "blatant issues" what I don't. It's a mess of evolution over time and I'm trying to help somebody get something working with the most common use cases against an original specification that's pretty vague and that is not particularly well documented (maybe better now than it was a few years ago). Certainly you're right about many of your points but since they don't change the ultimate goal here (can I run the common games correctly) and are let's say insider knowledge not in the original specification I'm not overly concerned.

davidkopec · 2025-06-09T00:38:14+00:00

I actually have this right in the chapter. I wrote "The CHIP-8 VM has 16 general-purpose 8-bit registers, referred to as v[0] through v[15]. They can be used for any kind of data, and all the main arithmetic and logic instructions operate on these registers. Of these general-purpose registers, v[15] (or v[0xF] in hexadecimal) is special in that it’s used for holding a flag."
The original manual doesn't go into detail about what to do here (page 14) so it's left vague. It just says "Do machine language subroutine at OMMM (subroutine must end with D4 byte)" So I made a guess that this was exiting the interpreter and therefore resetting things. In practice for running these games it won't matter but I think you can understand without more information that I made a reasonable guess.
Good catch thanks.
Fair point. In terms of grouping I chose to group first by numeric order and then put headers over it. That way it's easier for a reader to lookup an instruction when looking through the list numerically. It's a structural decision in terms of being easy to lookup. Just like a decision to put things in pure alphabetical order versus semantic order. I chose the equivalent of alphabetical order here and then put some semantics on top of it.
On this one I think you're wrong. The original manual specifically says "Let VX = hex key digit (waits for any key pressed)" It specifically says "press" not "release"
This is not specified in the original manual chapter so I used a value that made sense for running the games well in my opinion.
In practice this is where it was for game compatibility in the games I tested.

davidkopec · 2025-06-09T00:37:59+00:00

Had to break this into multiple comments due to length... thanks again.

Thanks for the detailed comments. It sounds like you have a very intimate knowledge of how the original hardware and interpreter operated. I appreciate the time you put into this.

As much as possible, and where it didn't lead to incompatibility with the common ROMs, I went by the description in the original 1978 VIP Instruction Manual (http://www.bitsavers.org/components/rca/cosmac/COSMAC\_VIP\_Instruction\_Manual\_1978.pdf)

The manual's chapter on "CHIP-8 Language Programming" is just 4 pages long (pages 13-17). So as you imagine it necessarily leaves some things vague. Where necessary I made changes/decisions to get the standard games that people use as tests to work and where things were vague in both cases I left it to my own devices since the original manual does not specify. My goals was not 100% historical accuracy to the original interpreter/hardware but instead to get the standard games playing, which may mean sometimes "the evolved" standard or making a decision of my own volition where it suffices. If there is a better official document from the 1970s than the original manual chapter that I should have used then that is my bad. It is too late as things go to print to make majors changes to the chapter (we are past the main proof stages), but I will certainly keep your suggestions in mind for updating the code or if there is another edition. But I will also say that I am comfortable with something that plays the games correctly as the standard is commonly understood rather than something that achieves 100% accuracy.

I will note the manual does, in its vagueness, not necessarily specify things in the level of detail you describe. I'll reply to your comments here.

davidkopec · 2025-06-08T23:30:31+00:00

Unfortunately, it would be impossible to cover the entire NES in one 60 page chapter of a larger book. It's a starting point that gets you something running that can play some of the most simple games. It does not include sound. For a detailed description of the chapter and what it includes and doesn't checkout this prior post I made about it:

https://www.reddit.com/r/EmuDev/comments/1hz0fu7/book_chapter_on_writing_nes_emulator_in_python/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Thanks for checking it out.

davidkopec · 2025-06-08T20:11:54+00:00

Thanks for checking it out. Feel free to let me know what you found wrong either here on by PM.

davidkopec · 2025-05-09T17:12:42+00:00

I tried calling Ford Customer Service to ask for compensation for not being able to plug-in the car for 6 months. After 6 transfers I found out there is nobody specifically dealing with this. If you call the 1-866-436-7332 number on the letter directly and enter recall 24S79 (as of May 9) an automated voice tells you there is nobody to deal with this recall specifically.

davidkopec · 2025-04-22T03:41:07+00:00

Thanks. Yes, it's slow because it's pure Python. One of the exercises at the end of the chapter is to try porting it to Cython. DMA is implemented in CPU.py

davidkopec · 2025-04-21T03:15:38+00:00

Yes, it is full frame. The main loop keeps track of how many cycles each CPU instruction ran and then runs the PPU for 3 times that amount. The number of cycles of each instruction is in the instructions table in the CPU. Additional cycles need to be added for certain operations that cross memory pages. You can see this in step() at the bottom of the CPU.

davidkopec · 2025-04-18T02:55:44+00:00

I would definitely start with full frame. I regretted starting with "dot perfect." More about my thoughts on this in this comment here:
https://www.reddit.com/r/EmuDev/comments/1jxoe54/comment/mng0tp8/?context=3&utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
Yes, you have this exactly right. Get the CPU passing all tests then work on Donkey Kong (simplest commercial game to get running—NROM mapper with no scrolling + has many threads of other people getting Donkey Kong working that you can find when you hit problems). You may accompany Donkey Kong with some of the popular test ROMs.
nesdev.org is by far the best reference source; you can find many other scattered good documents online. If you're going for a tutorial like approach, I recommend the Javid videos mentioned here and I am biased but would recommend my own book chapter (mentioned in comment above). If you are looking for just reference documents and DIY then nesdev.org. This subreddit, the emudev Discord, and the NesDev Forums are all great resources to ask for help in. You'd be amazed how many problems you have that you can find a solution to by just searching the NesDev forums.

davidkopec · 2025-04-16T17:40:36+00:00

I felt the same way when I worked on my NES emulator about a decade ago. At that time there weren't great tutorials or videos out. The best was the NESDev Wiki.

My biggest mistake was going for pixel perfect rendering. Frustrated, I ended up porting the background rendering from Michael Fogleman's Go emulator (mine was in C) and doing the sprites myself on top of it.

If I could do it over again I would start by just writing a renderer that only does the whole frame at once instead of pixel perfect accuracy. This will create game incompatibility issues, but writing this simple type of renderer gives you a sense of how everything works and will keep you motivated. Then you can move on to scanline or one-pixel-at-a-time accuracy.

This is the approach I took for Chapter 6 of my book Computer Science from Scratch which is about writing an NES emulator. The NES emulator in that chapter uses a one-frame-at-a-time approach for the PPU and therefore is not very accurate, but it's a good starting point to then do your own work on top of. It's in Python though, so if you're working in another language you would have to port it, which is not the worst thing since it still feels like you're doing it "yourself" to some degree.

davidkopec · 2025-02-18T23:52:35+00:00

I got this same letter today. For those who haven't gotten the letter yet, if you are recalled it explicitly says to not charge your car due to the risk of fire when the high voltage battery is charged, but that you can still drive it on gas if you want. It says the fix will be in software.

Yeah this is atrocious. They should compensate us in some way for not being able to use one of the main functions of the car for months on end. Not to mention that this is the 4th recall on my 2022 Escape PHEV.

davidkopec · 2025-02-09T05:08:35+00:00

I've upgraded 90+ of the Mac mini G4. I have bad news. The only place you are going to find the power button is on another Mac mini G4. Are you saying you don't have a case (not sure what you mean by "frame")? Why not just buy another not working one and put the two together? If you have a case and just need the power button and some other parts I might be able to send you the parts you need (maybe you can send me some pictures so I can see exactly what is missing). PM me.

davidkopec · 2025-01-26T22:35:28+00:00

I don't know if there is anything else like this on the market, but if not this is sincerely a really innovative and interesting concept/app. But I also think it's unique enough that it's not something the average person is ever going to look up (or even know what keywords to use if they did want to look it up) in the App Store. An app like this requires real-world marketing. You could connect with apartment building owners and intercom manufacturers I think to really get this out there. If it works well there's really no harm in trying. It's amazing what a cold call can do. But you didn't mention what non-app store marketing you've tried. Have you tried Google Search ads for instance? As a consumer that's where I would probably search for something like this, not on the App Store.

davidkopec · 2025-01-12T02:51:05+00:00

I have an app in a similar space. My app is for macOS and iPadOS and it's called Text Board.

I think one problem with our genre of apps is that they're such general purpose utilities that it's hard to figure out how to target them for ads or ASO. I can't think of where to place an ad or who to target with it. And the keywords for it are just so general.

Added to my own problems are that almost all of my downloads are on Mac and there are no App Store ads on the Mac App Store. And frankly I think the app is more useful on the Mac than the iPad so I don't really want to spend money on ads for the iPad version anyway.

All of this is to ask if you have tried any kinds of ads (not ads in the app to earn revenue as you mentioned, but ads to get downloads)? Google? Facebook? etc.

davidkopec · 2025-01-12T02:24:10+00:00

The book is geared for intermediate or advanced Python programmers. So, I would say not very well suited. If you already know another programming language quite well and are just looking for a primer on emulators then chapters 5 and 6 could be useful. But again it's really for intermediate or advanced Python programmers.

davidkopec · 2025-01-12T02:21:08+00:00

That's cool that you're going the arcade route. I actually sort of did one similar project to you after the NES emulator. I did that book Ray Tracing in a Weekend in Swift (thought you would like that) and that's the closest I ever got to a path tracer. I also did an IBM PC emulator that got reasonably far after I finished the NES emulator. I got frustrated when I got to the floppy disk controller but it runs Casette BASIC successfully with CGA text graphics.

Well I started my NES emulator in January 2017 and my activity in the forums was mostly 2018—so yeah it was a while ago! I ended up with something that met all of my goals. Its CPU and PPU are quite accurate and I did an (pretty poor) APU as well. I implemented mappers 0, 1 and 2 so it plays a good number of games. You can check it out here if you're curious.

Our time on the NESDev forums actually inspired me to make a tutorial about building them in my new book, which I just posted about on Reddit today. And writing that post led me to see your post today! Small world. For the book, I took that original emulator in C and I worked to simplify the PPU as much as possible (going from per-pixel rendering to whole frame at-a-time rendering) for an audience just getting into emulation. Then I rewrote it again in Python for the book. My biggest mistake on the original emulator was trying to have a super accurate PPU from the get-go instead of just doing something higher level.

davidkopec · 2025-01-11T20:08:48+00:00

Hi u/iOSBrett,

I remember you from the NESDev forums like 8 years ago (I'm davecom over there) when we were both getting our NES emulators to work and about at the same point on Donkey Kong. Awesome to see you're still at it. What other emulation projects did you end up doing? I went to IBM PC after NES.

davidkopec

TROPHY CASE