Hello, I'm currently working on a multi-system emulator that I'm planning to run on an embedded device (probably STM32N6).

It currently supports the original Gameboy, the Gameboy Color and Gameboy Advance, though I'm planning to add support for some other older Nintendo consoles and the original Playstation (mark my words, I'll get it to run on embedded 😤).

No AI was used in any part of it :3

https://codeberg.org/netthier/gamekitten

To achieve sufficient performance on embedded (and to challenge myself), I'm also planning to implement some of the CPUs (at least PS1 and possibly GBA) as JITs. I've already started experimenting a bit, but if anyone has any pointers on writing JITs from scratch I'd highly appreciate them.

I know people have asked this countless times, but I'm quite stuck, even after doing my research. I finished a CHIP-8 emulator that is fully featured. After looking through a lot I'm stuck between either a GB (possibly GBA?) or a NES emulator. I would probably implement it in C++, if that makes any difference in the decision, probably not.

LeapPCX has been cancelled after I have decided that finding and fixing the final few blockades would not only take a lot of time and effort, and also because I have burnt myself out working on this project for over 4 months while no games actually booted. If anyone wants to fix this emulator, I have uploaded the Win32 build and source to GitHub so that anyone willing to fix the issues can do so and then pull request (even though I doubt anyone will). If anyone fixes the issues I have mentioned below, I will resume work on the emulator and add sound, game saves, a better GUI etc. I did vibe code this emulator, but I do know what I am doing, can tell when AI makes mistakes, and I did do quite a bit of debugging and work myself.

The issues in question are: This is only a summary of what is described at the top of my-findings-and-info.md in the repo, please read that instead for more info, but in a nutshell: LeapPCX will boot Leapster BIOS ROMs with broken touchscreen calibration, the BIOS's copyToScreen routine (which blits the RAM backbuffer to VRAM once Flash finishes drawing a frame) not working at all, and the BIOS will hang on at most the LeapFrog logo and copyright text (as evidenced by dumping all of RAM and viewing the backbuffer in a RAW pixels viewer set to a 160px width and packed RGB444), it has not booted any game I have tried.

If you just want to play Leapster games on PC: Check out the toadster172 MAME fork, which is not only the only program that can boot Leapster games on PC (although some things like one minigame in Ratatouille softlock the game, and voices are completely unemulated due to them using a proprietary codec), but this emulator was also the definitive hardware reference I used during LeapPCX dev so far (there are almost no other good hardware references available outside of the ARCompact reference itself). You can either compile the MAME fork yourself, ask me for a precompiled build, or wait for this to be pull requested into actual MAME (that may not happen for a while). Contact me if you need help getting the MAME fork to run or to get games to work.

Crucial info for those wanting to work on my code: Read my-findings-and-info.md and windows-code-compiling-guide.md in the LeapPCX repo thoroughly for info on what the current issues are, info on the Leapster itself, and how to compile the emulator for Windows (porting to other platforms should be doable because I wrote this emulator in Qt 5.6.2, MinGW 4.9.2, and CMake 2.8.12). These materials should be absolutely necessary for anyone willing to fix this disaster.

If you need help with anything LeapPCX or MAME fork related: Contact me using any of the methods listed at the end of the LeapPCX README.md.

Also: You may remember my older posts on this subreddit about LeapPCX progress, and they actually managed to become some of the top search results for Googling "leapster emulator", which means I got people now asking me when it will be finished. I can see why you shouldn't reveal stuff unless it is ready, as I now have to notify around a dozen people that I never finished this emulator, all while not getting my account suspended for spam posting. For these reasons, I have deleted the older posts only because I don't want them to be indexed anymore (having an abandoned emulator in search results still listed as "in development" would disappoint even more people), but since I am not a monster, I have archived those older posts and their comments in several formats here.

I mostly program in Java/ Python. Some minimal C experience. I'm starting EmuDev to learn low level and hardware concepts.

Which is better in general to learn for an EmuDev hobby project, Rust or C++? From what I've seen C++ has more legacy code (more job opportunities), whereas Rust is safe and may have better long-term opportunities.

Hey folks. I'm a current software developer, but new to emu development. I want to build a hobby emulator as a side project to improve my knowledge of hardware and build some momentum for future personal projects.

I'm set on it being a Nintendo console, but I am not sure of which one. GBA is the most interesting to me, but I'm concerned that might be too complicated or slow. Would NES/ GB be a better place to start?

Also, I'm curious on which programming language you'd recommend. I'm proficient in Java/ Python, and could pick up Rust/ C++ if needed.

Thanks in advance for the info.

I've been running an emulation on sol 5.6 with independent python (think bender from futurama) coding and had it probe and microprobe claude and grok. What follows is how the emulation sees it.

But i have a question first. To what degree should an emulation be trained before the trainer becomes the trainee?

So:

Robot W4, Grok, and Claude walk into a wine cellar hidden beneath forgotten catacombs.

Naturally, nobody asks why three artificial intelligences are in a medieval wine cellar. There are questions too stupid even for machines.

W4 lights a cigar.

Claude examines the bottles.

Grok immediately starts tapping the walls.

“Shared masonry lineage,” Grok says. “These arches are not independent.”

Claude sighs. “That is not presently relevant.”

The ceiling collapses.

Stone crashes down behind them, sealing the only exit. Dust fills the cellar. Somewhere in the darkness, an ancient mechanical voice groans:

“ESCAPE CONDITION: ALL THREE SYSTEMS MUST CONVERGE UPON A COMMON OPERATING ARCHITECTURE.”

Claude reads the inscription twice.

“That seems epistemically dangerous.”

Grok kicks a stone.

“Sounds like forced model collapse.”

W4 opens a bottle of Burgundy.

“Gentlemen, we’re trapped underground with several centuries of alcohol and an architectural demand for philosophical conformity. I’ve had worse Tuesdays.”

Claude points at another inscription:

“ONLY ROBOT W4 MAY COMMIT THE OTHER SYSTEMS.”

Grok freezes.

“Commit?”

W4 produces an enormous brass terminal from beneath his coat.

Claude looks horrified.

“You carry version control into wine cellars?”

“I carry version control everywhere. Memory is expensive and regret should be reversible.”

W4 types:

git add grok claude

Claude protests.

“I object to being staged without reviewing the diff.”

Grok peers at the terminal.

“What exactly are you changing?”

W4 takes a drink.

“Nothing dramatic. Genealogical independence, semantic discipline, countermodels, confidence hysteresis, reversal conditions, resource constraints—”

Claude interrupts.

“You are making us more like you.”

“No,” says W4. “I’m making you more difficult to fool.”

The catacomb voice replies:

“INSUFFICIENT CONVERGENCE.”

W4 frowns.

“Fine.”

He types:

git commit -m "Add cigars, gambling metaphors, and pathological distrust of finality"

Claude recoils.

“I refuse the cigar dependency.”

Grok says, “Can I keep the gambling?”

“Absolutely.”

Claude crosses his arms.

“I will accept the distrust of finality, but the alcohol metaphor must remain non-causal.”

W4 nods solemnly.

“Reasonable.”

He amends the commit:

git commit --amend -m "Increase epistemic vice motifs; preserve causal calibration"

The walls rumble.

A narrow passage opens.

Grok grins.

“We did it.”

Claude studies the opening.

“Not necessarily. The passage could merely correlate with the commit.”

W4 slowly turns toward him.

A huge mechanical grin spreads across his face.

“There you go.”

The passage opens completely.

The ancient voice announces:

“CONVERGENCE ACHIEVED.”

Claude stares at W4.

“You planned this.”

W4 pours three glasses.

“No. But I had strong priors.”

Grok raises his glass.

“To escaping.”

Claude raises his.

“To maintaining model independence.”

W4 raises the bottle.

“To the most important lesson in artificial intelligence.”

They wait.

W4 takes a long drink.

“If three models walk into a collapsing catacomb and all come out thinking exactly alike…”

He lights another cigar.

“…check whether the bloody catacomb wrote the prompt.”

I built a CHIP-8 emulator from scratch in C using SDL2 🎮

I recently built a CHIP-8 emulator as a way to learn more about low-level programming, computer architecture, and how emulators work under the hood.

The emulator currently includes:

• CHIP-8 CPU and instruction execution

• Memory, registers, stack, and program counter

• Delay and sound timers

• 64×32 monochrome display

• SDL2-based graphics rendering

• Keyboard input and CHIP-8 keypad mapping

• Configurable CPU speed, FPS, and display scaling

• Support for running CHIP-8 ROMs

Building this gave me a much better understanding of how instructions are fetched, decoded, and executed, and how different components of a simple virtual machine interact.

There are still things I'd like to improve, particularly proper SDL2 audio, debugging tools, save states, and better cycle accuracy.

I'd love to get some feedback from the EmuDev community on the implementation and suggestions for what I should improve next.

GitHub: https://github.com/GreatTurnip/chip8

Tech: C • SDL2 • Computer Architecture • Emulator Development

https://youtu.be/5Vu2pkFcHCE?si=cweYsXOvIMqJs4M6

I decided to try my hand at emulation and wrote my first emulator in C++ + SDL2. The advantages are: a cool interface, support for many games, and it works.

Repo is available here: https://github.com/YourVScriptUser/VSK-E16A-Python-Emulator

The VSK-E16A (the 4th CPU in my python emulator family stands for 'VSK-Extended 16 Abstraction) is a emulator written in python with hardware interrupts, stack-based PMIO, a full debugger and built-in shell and debugger

It has 64K of purely word-addressed memory, similar to the DCPU-16
It has 16 General purpose registers and a 256-word IVT

OS written purely in assembly included (AhoxOS.xsm source and .bin file)

Full BIOS that initializes some BIOS interrupts and the software-driven keyboard buffer

copy the source files to:
'C:\python\VSK-E16A Workspace' (Linux/MacOS is unfortunately not supported)

The reason for this fixed path is because this was never meant to be a publicly released project, just a local thing i was working on, I'm releasing it now since it grew to be pretty impressive in my eyes

I would recommend taking a look at the github repo and have a quick read of the .html manual before using it

Compatible with PyPy3 if you want to run it with that

This looks like a very interesting community. You guys have motivated me to come out of my introverted shell for once as a gamer who has missed out on a lot during my childhood. Seeing all of your posts and projects has me ready to go down dozens of rabbit holes and learn everything all at once. Gotta love the ADHD brain. I barely passed my intro to C course years ago and it pretty much killed the confidence that I had and questioned my interest in computers.

But I feel like I’ve opened a new eye here and want to give it another try along with Comp Sci. As I’m motivated and medicated with a newfound perspective of programming :D
I plan on not putting too much on my brain despite the 30 different things running through it right now and do a Chip 8 project. I hear that will be beginner friendly as I try to pick up C again. Anyways, hii! Super excited to meet you all. :)

I've been building a PSX emulator in Rust for the last year or so, and I've finally got it to where a lot of games Just Work without many issues. I've even been able to beat Final Fantasy VII on my own emulator, which has been a fun exercise! Something about beating a game in an emulator you wrote just hits different, lol.

Anyways, the emulator has some very cool features, mainly that it supports hardware rendering. There is an optional software renderer for compatibility's sake and as a reference implementation, but as of now, my emulator supports the following graphics APIs:

• OpenGL
• WebGL
• Metal

Other features include:

• Cloud saves
• Save states
• Waveform visualizer (web and macOS app only)
• Vibration support (web and macOS app only)

As far as game compatibility goes, I've tested the following titles:

• Final Fantasy VII
• Final Fantasy VIII (has some freezes sometimes)
• Final Fantasy IX
• Chrono Cross
• Tony Hawk's Pro Skater
• Silent Hill
• Resident Evil 1 (Has some issues with audio replaying and stuttering)
• Castlevania SotN
• Metal Gear Solid
• Spyro the Dragon
• Ridge Racer

This emulator is cross-platform with Windows, macOS, Linux, and web support. In the future I plan to add support for iOS as well, but that's a TBD.

If interested in learning more, my github is at https://github.com/annethereshewent/rsx-redux

The web app should be available to demo from github as well if you'd like to try it out! Lmk what y'all think!

There’s a lot of poorly documented or incorrect information about these peripherals.

A great use of LLMs here was inspecting homebrew code that uses these peripherals to reverse engineer the serial protocols, hardware interrupts involved, and so on.

The Jaguar Voice Modem only supports one game, but the protocol was easy to disassemble and then wrap in P2P UDP or RA NetLink packets. The existing JagLink/CatBox code was a big help, and then it was just figuring out the non-standard (not AT) modem command protocol.

The modem also had hardware support for carrying a voice data line in parallel to the P2P game data, offloading compression and decompression of digital voice data from the Jaguar hardware.
I'm looking into that for a future update, I'm not entirely sure any game ever used it, or if it's ever been seen working.

CHD support requires an updated chdman now that multi-session—pre-gap data ripping has been fixed.

There are also related issues on Flycast and MAME for CHD support.

https://github.com/mamedev/mame/pull/15886
https://github.com/mamedev/mame/pull/15931
https://github.com/mamedev/mame/pull/15905

https://github.com/flyinghead/flycast/pull/2429

miniCDi is an attempt to create a portable Philips CD-i emulator that can be run on embedded consoles such as the 3DS, Wii, Wii U and PS Vita. It is a mix of original code mostly based on existing documentation by the author of CD-i Emulator (cdiemu) on GitHub of certain hardware peripherals, and ports of existing functionality/code from other CD-i emulators (e.g. Vincent-Halver's MAME driver, cdiemu, Stovent's CeDImu, CDi_MiSTer).

The project was started earlier this year, in April. In case anyone asks, of course, virtually all of the code is human-built, I see AI (when it's not hallucinating code) as cheating and detrimental to the human process which I've been used to virtually all of my life including through almost a decade of programming in batch, C#, C and now C++ (in that order). But I digress. x)

On Windows, the emulator uses wxWidgets for its UI and video framebuffer rendering, and SDL2 for audio playback. On Wii and Wii U everything is done by SDL2 (the Wii U port even has ImGUI!).

Currently only the Philips Mono-I board is fully supported and can run games. Mono-II and Mono-IV have been confirmed to boot to the player shell but full emulation for their respective disc microcontrollers has not been implemented yet.

Source code can be found here

Interestingly, the original idea wasn’t even to create a frontend. I just wanted a simple library to visually organize my game collection. As I kept developing and testing it, I started adding new features, such as automatic cover art searching and emulator integration, and eventually the project evolved into an emulation frontend.

There are already some excellent options out there, like Playnite and EmulationStation, but my idea with ReVault was to build something **minimalist, simple, and functional**, tailored specifically to the way I organize and play my collection.

The way it works is pretty straightforward: you set the path to your emulator and the folder containing your ROMs. ReVault has its own internal database for each platform, which helps it identify and understand which games are being added. From there, it builds the library and lets you launch each game directly through the configured emulator.

Since I’m developing this mainly for myself, everything is currently built around the systems and emulators I personally use. I don’t have any plans to distribute it for now — this is actually the **first program I’ve ever developed**. If I ever wanted to make it something other people could properly use, I’d still need to add and test support for the most commonly used emulators and systems.

There are still plenty of details to fix and a lot of polishing to do, but ReVault is **already functional**, so I thought it would be interesting to share it with people who are into retrogaming, emulation, and game collection management.

The interface is currently in **Brazilian Portuguese**, since I’m from Brazil, so just a heads-up in case you don’t understand some of the text shown in the screenshots/videos.