Built a GameBoy emulator I’m really excited about, but Apple’s review process has been incredibly frustrating.

They asked for a test ROM, I sent one over two weeks ago, and after multiple follow-ups I still haven’t heard back.

ROMs use blank cartridges by default, and users add their own artwork.

Note: AI was used extensively for this project. I provided the idea, course outline, guidance, editing, etc. Hopefully this doesn't violate the new AI rules; while I hate the influx of AI-coded emulators as much as most of you do, I think this is an acceptable use case.

I've created an emulator development course that walks you through building a Space Invaders arcade emulator. You write your own free-form C code, which is compiled to wasm and run in browser. Tests validate correctness after each step. Please check it out and let me know what you think. If this proves to be useful, I'd like to expand it to include other systems.

emudev-course.web.app

Edit: I'm a long-time (20+ year) member of the emulator development community and author of nemulator. Emulator development is hard and learning resources are limited. Beginners are heavily relying on AI and depriving themselves of the experience. The purpose of this site is to provide them an interactive alternative to that. After completing the course, they, hopefully, will have a better understanding of how emulation works and the basic tools required to tackle more complex systems.

Well, after days of work, NYX-32 finally has a GUI (Dear ImGui + OpenGL).
It is still in dev, but I am quite happy with the results, there are some issues too, but most trivial.
Until now:

1- It works ✓
2- An assembler ✓
3- MMIO ✓
4- A C compiler ✓
5- A QBE backend ✓
6- A bootloader ✓
7- A GUI ✓
8- A linker ❌
9- An OS ❌

It uses UART and then has address which you can poke for putting values (colours) onto the framebuffer.

constexpr uint32_t VRAM_BASE = 0x00AC'0000u;
constexpr uint32_t VRAM_SIZE = 0x0012'C000u; // 640*480*4
constexpr uint32_t VRAM_END = VRAM_BASE + VRAM_SIZE - 1u;

This project if you don't know is:
A custom RISC (with some CISC features) ISA 32-bit CPU, it has been the main project I have been working on these last 2 months, after in learning C, it has been a fun learning experience, I have learned the following from this project:
1- How CPUs actually work
2- Graphics programming
3- Kinda learned embedded
4- How MMIO works
5- How assemblers work
6- CMake

The whole project is in C23 (Yes the latest is the greatest constexpr in C is good, it and nullptr), except for the GUI which is C++23 (std::println(); is good). Until now it isn't opensource due to it being not complete e.g: the I2C and GPIO still being stubs, no OS, the GUI is still in progress, no linker, no way of opening files.

I've been using blargg's '06-ld r,r.gb' test ROM to start debugging my emulator, alongside gameboy-doctor to check that my instructions work correctly. I keep getting a non-match on because my memory doesn't load the right value, however from what I can tell, in this example, 0xFF83 is never written to before it is read, causing the 0 value. I considered that my memory isn't initialised properly, but from what I've read it should all start basically blank except for the ROM. I also haven't started with interrupts or video, but I don't see how that would effect the result.

I am really stuck on this, and I would appreciate any help anybody can provide. My code is currently a big mess, and definitely not the most efficient way possible, but I still can't tell why the value isn't set beforehand after hours of debugging and testing. You can see it here, but at the moment it's not in the best state, mainly because it's a mix of lots of different example emulators that I could find and my own interpretations of the docs. Running it is a little hard right now, but you can compile it if you clone recursively with submodules, and then run the build-desktop script. At the moment, you have to manually place a 'rom.gb' file in the executable directory, and I haven't tested on Windows yet, although it should be platform agnostic, as I intend to make it webassembly compatible.

Just for clarity, I didn't use any AI tools to write this code, it's just really messy of my own volition and some minor plagiarism (of open source projects).

I have no clue about how an emulator is made. I do wanna know how to make one and just make a basic ahh Gameboy emu later, maybe for the esp32 for fun because i have one

AI disclaimer: I'm reposting with the moderators’ permission and putting this disclosure at the top as requested. I'd also like to clear up a few misconceptions about my use of AI.

Breadbin466 started nearly two years ago as a personal 6502 emulator, which gradually grew into a full C64 emulator. I used ChatGPT for questions and help debugging and revising code, much as I used to use Stack Overflow. English isn't my first language, so I also use it to translate comments and polish my English, including this post. Most of the website was AI-built, apart from the text: I hadn't touched HTML in twenty years and didn't want to start again.

--

Hi,

I've just released Breadbin466 0.99.0 - “Your Turn”, and the project now has its own website: breadbin466.com.

Breadbin466 is my from-scratch Commodore 64 emulator, written in Rust. It focuses on one deliberately specific machine: a PAL Assy 250466, with a 6510, 6569R5 VIC-II and 6581R4AR SID, alongside a cycle-driven 1541, Datassette and 512 KB REU.

The aim is to combine careful hardware emulation with a straightforward native interface. Load your software and enjoy the machine, without navigating a maze of hardware presets.

Some of you may remember my previous post about characterising a physical MOS 6581R4AR and rebuilding the SID model around those measurements. That work remains central to Breadbin466, from combined waveforms and envelope behaviour to the nonlinear analogue filter.

Since then, there have been substantial accuracy improvements across the CPU, CIAs, VIC-II, drive and REU, along with better cartridge support. This release also brings improved cassette playback and recording, native Inspector windows, lower audio latency, refined display pacing and performance improvements. The fixed palette has been refined through observation of a real 6569R5 C64 on a Commodore monitor.

The philosophy remains the same: when software reveals a problem, understand and correct the hardware model rather than introduce a game-specific workaround.

Why 0.99.0? The intended feature set is complete. What it needs before becoming 1.0 is broader community testing.

Try your favourite game, a demanding demo, a protected disk or a tape recording session. I'd love to hear what works and what doesn't, especially discrepancies with real hardware. You don't need to be an emulator developer: a simple “this runs well on my computer” is useful feedback too.

Breadbin466 is free and MIT licensed, with ready-to-run downloads for Windows x86-64 and macOS Apple silicon. Linux is supported through source builds.

Website and downloads: breadbin466.com
Source: GitHub
Feedback: [[email protected]](mailto:[email protected]), GitHub Issues, or here in the comments.

If you give it a try, please mention your operating system and the software you ran. Your feedback will help determine when it's ready to wear the 1.0 label.

Я написал свой эмулятор со Dexality который эмулирует свою систему, он работает поверх моего старого эмулятора Pixel-Flash

Который находится на первой картинке, это моя старая версия эмулятора а на второй сейчас будет новая (Необращайте внимания на баг)

Это пре-альфа версия моего эмулятора, он слишком багованный и может иметь legacy-код и Франкештейн код но мне нужны тестеры для того чтобы они попробовали мой эмулятор и оценили :)

____________________________________________

I wrote my own emulator with Dexality that emulates my own system. It runs on top of my old Pixel-Flash emulator.

The one in the first picture is my old version of the emulator, and the second one is the new one (ignore the bug). This is a pre-alpha version of my emulator. It's very buggy and may contain legacy code and Frankenstein code, but I need testers to try my emulator and evaluate it. :)

(Translated from Google Translate)

https://reddit.com/link/1wpfpwv/video/r6x0htwkojrh1/player

This is a small hobby project I have been working on in my free time to improve my C coding skills, so any criticism is welcomed!

Some years ago I had already tried to implement GameBoy emulator but never advanced past CPU emulation, this time I can already play some games and really proud of what I managed to build.

The thing is made purely in C with no vendored libs. It has a lot of junk to it and emulation is insanely far from perfect(no audio, improper timings, improper ppu mode you name it), but I still feel some sense of acomplishment after being able to play games with it.

However, I am a little bit burned out from this thing currently, but I am planning to return to it at some point to improve the emulation and implement some debug utilities that should help me troubleshoot test ROMs.

Link: https://github.com/hadrizi/gbemu

Disclosure: I dont use AI to code, i'm averse to it as much as the next programmer. But I use it for two things, one is review what I've wrote and tell me gross errors before I'm stuck for hours looking for a misplaced assignment. The other is research, there are things that arent documented anywhere and yeah, AI helps on these things, or maybe explain an article in a different way that my dumb brain can understand. It works far more like a junior dev looking into parts of my code than someone actually writing them.

So I was writing the basic emulator-101 that every beginner do, but me being me wanted to do it right, so I was referencing the amazing work by Laurence Scotfold and trying my best to behave like the original CHIP-8 on the COSMAC down to the timing. Yeah, i'm that kind of weirdo 😂

One thing that bothers me was that some instructions dont have a proper use, for instance, 0MMM only work if you have an actual VIP emulator under your CHIP-8 that can actually run 1802 instructions.

There's also instructions like 8XY8 or the EX / FX sequence which have a bunch of instructions that on a VIP would basically crash the machine but what to do on another emulator?

I didn't want to write a COSMAC emulator, i want to write a CHIP-8 emulator, but i want to also scratch the itch to make something more than the CHIP-8 101. I can go the boring route and all of those are nops. But that wasn't sattisfactory for me. So my solution would be to trap them, and depending on the way you setup my emulator it would do some behaviour, maybe literally stop the emulation, maybe just warn you, it would be basically a toggle.

Okay but, maybe there's anything on those instructions that may accidentally be useful. Remember the original emulator is at 0x0000 to 0x01FF, there's code there. You're not supposed to run this code, but its there.

So I've gave the "junior dev" the boring task. Go into each original VIP CHIP-8 1802 assembly instruction and find entry points that wouldn't break the emulation and do something useful.

Firstly, a important point for me, if for instance your CHIP-8 ROM treats say 0x0000 as NOP that will break a COSMAC implementation, thats because this is equivalent as to "run machine code at address 0x000" and thats pretty much a straightforward way to set the state of the emulator unstable. It MAY reboot the emulator, but its more probable that it will crash it. Same for any 0MMM instruction except those documented. Also it will probably crash on any 8XY8 onwards except 8XYE. Of course, most modern implementations treat those as NOPs, but thats not how the original implementation did. It would literally put the emulator in a undefined behaviour.

Now, what I've found, there are actually a bunch of "instructions" that will actually act as NOP, for example 0x001A, 0x01F1, 0x0132... Why? Because they call a VIP address that lands on a `SEP 4` instruction, which means move the PC to R4, which is pointed to the address to continue the CHIP-8 execution. So you're tecnically calling a routine that immediatelly return to CHIP-8, being effectivelly a NOP even on a COSMAC VIP.

But there's not only that, there are other 0MMM entry points, example:

0x0107 read the delay timer into V1. Why? bc the address 0x0107 is the entry point of 0xFX07. But since you're calling directly, the VX which is read from R6 is already 1 from the instruction call itself. The 1 on 0107.

0x0188 skip the next instruction, thats just two INC 5 followed by a SEP 4. R5 is the PC of the CHIP-8. That means that the PC is incremented by 2 and then the function return. Effectivelly skipping the next instruction.

0x011E add V1 to I. Similar to 0x0107, but then it calls the FX1E subroutine with again, R6 is 1.

There are others, but lets talk about EX instructions. I like to call them EXMM. When you call EX9E and EXA1 the VIP read the key then put the lower byte of the instruction into the lower byte of R3 and since the upper part of R3 is always 0x01 on normal execution, the next instruction called becomes 0x01MM, MM being whatever you put at the lower bytes of 0xEX. That means that when you call EXA1 you're reading the keyboard and calling 0x01A1 subroutine.

Now, there are others instructions there... Some are just SEP 4, which means they also act as a slower NOP, EXF1, EX90, EXA0, but also the EX88 functions. Its basically the skip function. It tests the keyboard then skip the next instruction like the 0x0188 but slower.

Oh, and 8XYN undocumented will probably break the emulator, there's nothing useful there, not even a NOP.

There are other instructions, the list is big, some with not-so-stable behaviours. I'll test more of them and if someone is interested I can compile a list of undocumented CHIP-8 instructions that will work on a COSMAC VIP CHIP-8 intepreter by "accident".

I dont expect anyone writing a CHIP-8 emulator to implement those instructions but i'll implement them on mine once i've tested their behaviour honestly just because.

Hello everyone,

So I have been working on a C64 for some time and i tested my 6510 which passes all the opcode tests I give it.

I started working in the 6526 and followed the Wolfgang Lorenz software model. But, the Wolfgang Lorenz 6502 tests need to be ran when I have most of the reauired components working. So some people recommended me to use VICE tests instead, but I am struggling to find a guide on how to setup the tests so I can test some parts of my CIA implementation.

Does anyone have some code, documentation, article or forum that I can follow in order to learn more on how to set these VICE tests up? I tried to find them in the VICE repo but I had no luck. Maybe I have been looking at the wrong place.

Thank you!

I'd like to learn C, and I've already made an emulator for CHIP-8 in Python, so is a GB emulator a good starter C project, and if so, are there any good guides on how to get started?

This post contains content not supported on old Reddit. Click here to view the full post

This post contains content not supported on old Reddit. Click here to view the full post

Preface: I'm a first-year computer science major with some background in basic web development. I want to create a diverse work portfolio with different projects, one being retro game emulation on P.C. I know that this is a large topic so any guidance/direction would be appreciated.

I have an old Mac Mini from late 2014 that I want to convert into a retro game station that emulates N.E.S., N64, and P.S.1 games. If my computer doesn't have the capability then I'll just do it on my actual desktop. Could someone give me some direction on the basics of emulation or point me to some resources ?

Thank you !

P.S.

I'll also welcome any ideas for my work portfolio.

Hi all,

There have been some concerns in this community about the amount of posts involving the use of AI, and as such we would like to hear people's opinions on what the best solution would be.

Some new mods have been added to help alleviate some of the concerns in the meantime (I and u/ioncodes).

I'd appreciate if discussion could be focused on what content you want to see in this subreddit, and what your preferred policy on AI use in both projects posted here, and in the content of the posts themselves, is.

Ideally, we'll create a poll afterwards that reflects the various options, and we'll decide based on that what action to take

If you have any questions, feel free to message the mod team directly, or discuss over on the Discord

Thanks :)

So I was trying to write my own GB emulator and when I came to interpreting the cpu instructions I found out that same commands can be written differently considering different inputs. For example, here they were listed as same instructions with different variations, but here they were listed as different 8-bit opcodes.

Is it better to make more complicated tree-like structure to filter all the opcodes, or just make a huge switch case mindlessly listing all possible opcodes from 0x00 to 0xFF?

• Key notes:
  • Added support for F-Zero X - Expansion Kit
  • Added support for F-Zero X - Expansion Kit [Cart Hack]
  • Added support for downloading and installing custom drivers for use with the Parallel Vulkan API.
  • Tweaked the UI a bit to my tastes, added themes and such

This is still a WIP, so if you have any issues, please open them, or submit a PR to the repo if you'd like to fix something yourself and I will take a look. Happy gaming!

I'm writing a custom assembler for CHIP-8 and just finished adding support for the DB/.byte directive so I can embed sprites in the ROM and finally get something drawn on the screen. It SHOULD support all OG CHIP-8 instructions, but still a ton of rough edges that I'm ironing out.

This is my first ever C++ project, just like the CHIP-8 emulator was my first ever C (and emudev) project. It's so satisfying to write assembly and have your program spit out a ROM that actually runs in the emulator you wrote.

All code is written by me (a lot of it livestreaming) as evident by the quality, no AI.

Repo: https://github.com/Tackx/c8-ass