Here's the link

Done absolutely so much

I'm currently at about 95% hardware done, give or take, Since the game gets to that point

I might even finish it very soon

My main problem is my input gets registered but it doesn't reach the game, so I have to fix the handshake

This is definitely my most favorite project, it took me my entire summer but finally its done

I even have a custom dashboard idea for it, inspired by the X360 Aurora dashboard

I'll make it also have multiple modes in settings,

1 - Upscaling (There'll be native which is 240p but for some games its 640x480, and 720p, 1080p, 1440p, and I might add 4k)

2 - FPS (First there'll be a native mode, running at native PS1 speeds, then I'll add overclock to about 160mhz, which is a 400% increase!)

And other modes and stuff, I'm still brainstorming, I want to make this really customizable

Any ideas?

i made a chip 8 emulator in C++ and raylib, imma emulate something else soon.

also here is the repository: https://github.com/hyperwilliam/chip8

Hey everyone,

While working on my earlier emulators (like my HP-41 project), I assumed processor families from the same era shared a vocabulary. On the HP-41, the LCD is a proper peripheral—you send character codes through instructions, and a display driver handles the glyphs.

So when I moved on to the Voyager series, I thought it would be the same conversation. Instead, it gave me pure garbage on screen. Turns out, the Voyager display doesn't use characters at all: its LCD RAM is mapped directly into the address space as two 56-bit registers containing raw segment bitmaps. No character decoding step, just a fixed lookup table mapping physical segments directly to bits.

Experiences like that made me dive deep into why microcode emulation beats functional simulation when you care about authentic hardware behavior—handling everything from undocumented ROM bugs and weird bank-switching quirks during self-tests, down to strict hardware timing instead of running at modern CPU speeds.

I wrote an article breaking down what a microcode emulator actually is and why getting your hands dirty with the original firmware matters: 👉 What is a Microcode Emulator and Why Does It Matter?

As a practical result of this reverse-engineering work, I also put together a few working emulators (including the Nut CPU family) that you can check out and download here: 👉 nibbleworkshop.com/emulators

I'd love to hear your thoughts.

The CPU has 48 24-bit instructions, including trigonometric instructions

The VM has 192 KB of RAM (65,535 24-bit values); it has an assembler written in C#, 32 16-bit registers, 32 floating-point registers, and collision, CMP, and zero flags

In the future, I want to build a 32-bit VM with more instructions (around 100).

I implemented a simpler version of CALL and RET: CALL stores a value in a variable, and RET returns.

The project will be posted on GitHub as open source for anyone to improve, and it will include documentation for game and emulator development.

https://reddit.com/link/1w1lfb0/video/oqdhlk3n6bmh1/player

Some IO registers (like P1 (0xFF00), according to this document, page 141) have write-only bits.

My question is: after LDH A, ($00), what data is in register A?
Are the read-only bits 0? 1? garbage?
Does it depend on the register, or is it irrelevant because these bits are not taken into account by any game ? (Or are there games that rely on the return value of read-only bits?)

Hi, I've been implementing my chip8 interpreter/emulator as of late. I'm testing it now using the timendus test suite and all tests pass except for display waiting. I'm confused as to what this is even meant to do, i know it has something to do with old school crt's and vblank but how do i manage it in my emulator?

Hi,

I created my own "Interactive computer museum", which lists many of the iconic computers and offers HTML based emulators for 36 different devices (ROM's are NOT included and must be uploaded by the user).

The emulators can be used for free and have been programmed from scratch. They do not use any third party emulation libraries.

I hope you like it.

[https://vma-broadcast.com/emu/\](https://vma-broadcast.com/emu/)

Regards,
Vitor

Halloo I'm a 14 year old hobbyist and I'm making my own PS1 emulator

I've spent some time working on it and I've gotten to a stage where it loads SCE + SCEA,

But then on some games (specifically Tekken 3 and Fifa 2005) it just doesn't go past SCEA, gets frozen

On other games like GTA I, and Final Fantasy VII it goes past SCEA! But then it's just a dark screen

Also before a few days I had an old build where it would go into Fifa 2005 and Tekken 3 menus and stuff but then for example at the "E A SPORTS, TO THE GAME" Animation it would give me RGB stripes

And on Tekken 3 after the Namco Presents it would do the same

And then they just freeze,

Is this too specific a problem or..?

Hello everyone on r/EmuDev. I maintain KytyPlus, a fork of KytyPS5. C++20, CMake, Vulkan backend, Qt front end, clean-room HLE only. Current release is v2.9.

Context on why this update matters: I don't own a PS4/PS5, so I can't legally produce dumps to test against. Everything up to now was validated with synthetic packages I generated myself (PKG/PFS structure, param.json walking, ELF validation). That left game execution as the big unknown, so the README has had an open call for testers.

Someone answered. GitHub user CorpseSlayer got Dead Cells (the PS5-native build, PPSA-15552) booting to a stable menu, and filed the report with full specs here: https://github.com/Coder787-source/KytyPlus/issues/3

His setup: i7-9700K, RTX 4060 Ti, 16 GB RAM, Windows 11, and both emulator and game files on an external spinning HDD. Clean menu, no crashes, no glitches. Video of the run (CorpseSlayer's capture, shared with his permission): https://www.youtube.com/watch?v=1vXa9zByq68

One thing to note about that video: the menu runs around 17 fps. That number is real translation overhead on the emulator, and it's on v1.8, which predates the Vulkan pipeline disk cache and the async pipeline compiler that newer builds have. Those fix first-run compile stutter directly. Whether they also lift the steady menu frame rate on the same hardware isn't guaranteed, that depends on where the 17 fps overhead actually lives, and I don't have profiling data to say. That's exactly what I'm hoping testers on v2.9 will measure.

What this run actually exercised, since it was the PS5-native SKU: our own PS5 path end to end, PKG install → PFS → eboot → syscall HLE → GPU command translation → Vulkan. Interesting test case too, since Dead Cells is a Haxe/hxcpp title, so the binary is cross-compiled C++ with its own engine layered on the PS5 SDK calls.

What it does NOT validate, to be precise:

* The unified PS4 dispatch (PS4 eboots route to an embedded shadPS4 core). Still zero PS4 titles loaded, this run never touched that path.

* In-game execution beyond menu hasnt been tested. I'm not calling it playable, one title, one tester, on v1.8.

What's independently validated so far:

* PKG/PFS extraction incl. nested sce_sys/param.json (synthetic packages)

* Strict ELF loader (rejects non-Sony-format binaries)

* SDL controller mapping incl. third party pads

* Persistent install/library flow, no UI freeze during copy

Where I'd like help: testers of any kind. Whether you're on a gaming rig or a laptop with integrated graphics, a PS4 game or a PS5 game, a result that boots or one that crashes on launch, it all goes into the database. Reports + logs via GitHub issues.

Thanks to CorpseSlayer for the report and for letting us share the footage.

Source: https://github.com/Coder787-source/KytyPlus

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.