Screenshots of working (and not quite) emulators.

https://reddit.com/r/EmulatorPorn

ok it's dead

TL;DR: AprVisual simulates the NES at the switch level — it runs the actual 2A03/2C02 transistors from their netlists, not opcodes. It's ~600× too slow for real time (by nature). The interesting part isn't the sim itself; it's that I built all the "obvious" speed-ups (extract an IR, do codegen, throw it on a GPU) and they were all slower than the direct interpreter — and I kept a measured catalogue of ~10 optimizations that failed, and why.

What "switch-level" even means

Most emulators run at the opcode/RTL level — they execute LDA, tick a PPU, etc. AprVisual goes a layer below CPU instructions entirely: it loads the 2A03 (CPU) and 2C02 (PPU) as a graph of ~27,000 transistors + ~15,000 wires (the Visual6502-style netlists), and every half clock cycle it settles that whole network to a fixpoint. There's no "instruction" anywhere in the code — the entire CPU just emerges from transistors conducting. It's bit-exact to real silicon and brutally slow. (Same family as Visual6502 / MetalNES / Sour's Visual NES, if you've seen those.)

It is not a usable emulator — it's a research toy plus an open benchmark. Two engines, C# and Rust, with bit-identical output.

The fun part: the obvious optimizations all lost

Everyone (me included) immediately thinks: lift the logic into an IR, codegen it to native code, or bit-slice it on a GPU. I built and verified all three. Every one was slower than just interpreting the netlist:

• IR + codegen → huge code bloat, lost timing/correctness margins, and batch re-evaluation recomputes ~14,700 nodes when only a few hundred actually changed that half-cycle.

• GPU backend → ~10–18× slower than the CPU interpreter.

The bottleneck is memory latency over a dirty-set of a few hundred tiny nodes (the average graph walk is ~1.4 nodes). None of the "scale it up" techniques fit that shape.

The catalogue of what didn't work (all measured, with root causes)

• per-chip parallelism: ~15× slower — settle waves too small to amortize thread sync

• bit-parallel / Ligra-style dense BFS: ~156× slower — average walk is ~1.4 nodes, the overhead crushes it

• cache-locality renumbering (Reverse Cuthill-McKee): ~1.0× — the hot working set already fits L1d

• "oblivious" full-sweep (drop the dirty-set, recompute everything): ~121× slower

• levelized scheduling: net −15% — the netlist is ~94.5% one giant pass-transistor-coupled SCC, so there's no useful static topological order to exploit

• "observability" node-merging: an early 1.3× that black-screened the PPU (cross-coupled latches have two stable states) and went net-negative on the optimized baseline anyway

• bonus head-scratcher: the same one-line micro-opt was +1% on C#/RyuJIT but −2% on Rust/LLVM, purely from codegen density — so I now measure each engine separately and never sync hot-path changes blindly

What actually worked was boring: shrink the hot per-node data so it fits L1d (byte/ushort fields, hot/cold struct split), an O(1) fast-path for the ~27% of nodes that are provably singletons, merging always-on shorts at load time, and giving the JIT what it needs to inline the group walk. Unglamorous data-shrink + cache-fit beat every clever algorithm.

Numbers (Ryzen 7 3700X, 300k half-cycles of a palette test)

• Rust: ~72K hc/s ≈ 9.9 s/frame

• C#: ~67K hc/s ≈ 10.6 s/frame

• bit-identical checksum; real time needs 42,954,552 hc/s → ~600× short

• screenshot of a run (Rust top, C# bottom, same checksum): https://erspicu.github.io/AprVisual/pic/2026053001.png

Try it / links

There's a portable, self-contained benchmark (Windows x64 + macOS arm64, both engines, no .NET install), a tiny leaderboard where you can upload your run to see how your CPU compares, and a write-up with a plain-language switch-level primer + the full negative-results catalogue with source-line citations.

• Site (primer + lineage + comparison): erspicu.github.io/AprVisual

• Benchmark download: github.com/erspicu/AprVisual/releases

• Leaderboard: baxermux.org/myemu/AprVisual

• Source: https://github.com/erspicu/AprVisual/tree/aot-codegen (latest on the aot-codegen branch)

If you've got a faster CPU, or a switch-level speed-up idea that respects the traps above (cross-coupled-latch stable states; the floating-capacitance tie-break), I'd genuinely love to hear it.

(Method note: a big chunk of the optimization sweep was me directing an AI to implement & benchmark candidate strategies, with the profiler as the referee — which is partly why the failure list is so thorough. Bad ideas were cheap to try, and measurement always had the last word.)

Credit: Visual6502 (the Silvermans, Greg James, et al.), Quietust's Visual 2A03/2C02, Sour's Visual NES, and MetalNES (iaddis). The switch-level model traces to R. E. Bryant (MOSSIM, 1981; IEEE TC, 1984). Bundled netlist data is CC-BY-NC-SA.

GitHub: https://github.com/Jack-IDE/J16-Flow-State

The long-term motivation is to explore whether computation can be modeled from baseline/deviation state fields instead of treating binary Boolean logic as the root substrate.

This repo does **not** prove a replacement for binary hardware. What it demonstrates right now is a concrete mechanism: ternary-squared and ternary-cubed fields can guide local routing in tested 2D/3D maze cases without cursor-side BFS or A\*.

The main executable proof-of-concept is local field routing:
2D ternary-squared uses a 3×3 local directional state field.
3D ternary-cubed uses a 3×3×3 volumetric state field.
The 3D demo routes through a true corner-state like (+1,+1,+1).
The cursor does not run BFS, A\*, path reconstruction, or a came_from table.
The field settles first, then the cursor follows only the local vector.

The part I’m most interested in is treating ternary-squared and ternary-cubed not as “9 values” or “27 values,” but as baseline-centered local state spaces:
ternary-squared: (x, y) → local 2D directional cell
ternary-cubed: (x, y, z) → local 3D volumetric cell

I’m posting it as an experimental emulator/proof-of-concept, not a finished architecture or hardware claim.

Hello everyone,

We are looking for someone to develop a series of emulators, it is a paid job. However we don't know where to start looking. Could someone please help?

The idea is to have one Lead Developer for project with it's own development team. We are looking to emulate the following consoles:

- SNES

- Genesis/Mega Drive

- Neo Geo

- Nintendo 64

Thanks!

Edit: Added more information on the task

I wrote an emulator for the USSR Iskra 226 and brought some software to life
Here is the story, code is on GitHub.

https://elaranovikova.com/projects/iskra-226/

I recently shipped the first emulator for the Iskra-226, the Soviet work-alike of the Wang 2200. Unusual constraints compared to a typical emu project, so I thought the approach might interest people here:
No firmware execution. I don’t have a clean dump and the processor isn’t emulated. Instead I built an interpreter for the machine’s tokenized BASIC dialect, a “reader for a language and something to carry it out.” That was enough to get 23/23 programs on my reference disk loading and running (counted off the catalog status byte, not eyeballed).
Token archaeology. The dialect is Wang-2200-adjacent but not identical. The breakthrough came from staring at the token stream until I stopped asking “which Wang token is this” and started asking what the bytes were doing on their own terms. Once the tokens came apart, the whole dispatcher fell into place in a few hours.

Disk forensics. The boot side isn’t in any catalog I could find, and carries the same firmware image written four times over. Cross-comparing the four copies is how I ended up with a file I trust.
Validation by pencil. My end-to-end test was a 1989 payroll program: I fed it invented numbers I could verify by hand, and the emulator’s printed wage sheet agrees with my paper arithmetic to the kopek.
Ternary bonus round. Next project is a Python port of the Setun (1958), the only ternary computer ever built serially, currently checked against the reference implementation for 550,821 steps without a divergence.

Browser emulator + 14 disk images:

https://elaranovikova.com/projects/iskra-226/index.html

Code:

https://github.com/elaranovikova

AMA about the format, the tokenizer, or reading 8-inch media in 2026.

I just wanted to share all screenshots I have of the emulator! I'll also make a youtube channel and post clips and some documentation on it soon! School starts... In a few hours so the emulator is the least of my worries now... I am not the first teenager to make a PS1 emulator, but I might be the first to make it work!!

If anyone needs anything from me, help or collaboration or anything my discord is Saffyral

That's it!

(Note : All the pictures are from different times and different bugs, its just the collection I have! Some are old some are new, but the most important thing, it now works! Not on all games though... Especially Syphon filter)

I MANAGED TO MAKE A 100% WORKING GAMEBOY PYTHON EMULATOR WITH SOUNDS. I succeeded thanks to some of my friends who found the problem (it was the vram that filled in a loop) i deleted everything, only pieces of code remained that worked in the old project (such as opcodes or keys) and or rewritten the codes from 0 adding ancue the sound and using pypy to speed up the emulator I succeeded

..but man, does it help when creating unit tests! :)

I asked it to create tests for all standard opcodes based on a single test I wrote and it gave me a loop that tests all opcodes (albeit in a trivial matter). Still, it's good enough to parse through to get opcode by opcode going.

All in all, nothing that I couldn't have done, but I got it in 10 seconds instead of spending 60 minutes on it.

Edit: Why the saltiness? Oh, right. It's reddit.

Are there any software (or hardware synthesized on FPGA) that can run the whole OS of the gaming console rather than just running the games ? and if you guys have any files of the Firmware or OS whatever you say, of any gaming console , please link them below !

Hey guys.

I'm a completely blind person and with the help of artificial intelligence, I managed to make a static recompilation of Kingdom Hearts: Chain of Memories from the GBA version.

I'm not sure how good it turned out, nor if it's 100%, since I used AI for most of it.

Could anyone take a look?

I hope you like it.

https://github.com/azurejoga/kh-recomp

I apologize if I got anything wrong... someone who understands could take a look and point out the mistakes.

I recompiled to ensure the executable was actually generated.

Remembering, you need to have the rom, European version and the GBA bios, .bin.

Every other part of the emulator seems to work correctly, except for drawing. Error is probably somewhere here. I can't provide and image, however a vertical rectangle with random pixels missing shows upl

let x_register = (self.opcode & 0x0f00) >> 8;
        let y_register = (self.opcode & 0x00f0) >> 4;
        let n = self.opcode & 0x000f;


        let x_value = self.registers[x_register as usize];
        let y_value = self.registers[y_register as usize];

        println!("{}", x_value);


        for i in 0..n {
            let sprite_line = self.ram[i as usize + self.index_register as usize];

            for bit in 0..8 {
                let x = (x_value + bit) % 63;
                let y = (y_value + i) % 31;
                
                let sprite_bit = (sprite_line >> (7 - bit)) & 1;
                let old_bit: u8 = self.display_buffer[x as usize][y as usize] as u8;
                let new_bit = old_bit ^ sprite_bit;
                self.display_buffer[x as usize][y as usize] = new_bit != 0;

                

            }
        }

My old project AprNes

GitHub: https://github.com/erspicu/AprNes

AprNes website https://baxermux.org/myemu/AprNes/index.html

The AI collaboration model

I didn't just use AI for code generation. The workflow was:

AI reads NESdev Wiki, Mesen2/TriCNES source, and test ROM failure CRCs

AI proposes a hypothesis and fix strategy

I review, approve, and run the test suite

If regression → analyze together, fix the root cause (never patch over correct behavior)

The strict rule: no compensation hacks. No special-casing to make a test pass if it means the underlying hardware behavior is wrong.

---

What was hardest

DMA timing (AccuracyCoin P13/P14):

The key insight was that Load DMA start parity is `(apucycle & 1) != 0 ? 2 : 3` — not a fixed value. Getting `double_2007_read`, `count_errors`, `count_errors_fast`, and the implicit abort behavior all correct simultaneously took several iterations.

PPU sprite evaluation (AccuracyCoin SprSL0):

The secondary OAM clear during dots 1–64 must write `$FF` (not `$00`) into `oamCopyBuffer` on each write cycle, and `$2004` reads during rendering (dots 1–256) must return `oamCopyBuffer` — not the actual secondary OAM data. Getting this right required implementing the full per-dot FSM rather than a simplified model.

---

a guy, like, 3 years ago started coding a ps5 emulator (called kyty), but he dont touch on that code since december 22, Should I try to continue it? i have a ps5, a pc and a dream.

Hello all. I want to preface this by saying I an extremely NEUROTIC person. It’s something I’m trying to work on but it’s gonna take time.

Anyways I am working on a Gameboy Emulator in C. This will be my first full emulator other than a half finished chip-8 emulator. I took a different approach than most people and wrote out functions for every single opcode and implemented every single opcode before I ever tested anything. Well, that didn’t work out well… I ended up trying to run Blarggs test rom for the individual CPU instructions and… well it was kinda working but also kinda not. So I kept track of CPU/Opcode state and went through and tried everything to figure out what was going on and why it wasn’t printing anything. Then I found out from a forum that to actually see the output, you need to check if the serial IO port has been changed by checking 0xFF02. However adter doing this, it still didn’t work and would jump to 0xC000 and then jump to 0xC220 and then would run through a near endless amount of 0x00 operations.

So something was off. I spent an entire week trying everything, tweaking types, rewriting entire functions, doing everything and NOTHING fixed this error! And so I googled something and boom, Gemini popped up.

I have never really used AI for programming, ever. I like to keep AI out of my hobby programming. As I said before I am neurotic and I’ll admit a bit of a Luddite. But I hobby programming because I enjoy the logic and it feels like a puzzle. If it’s industry and youre forced to use it, whatever, but I like to learn and make on my own.

But alas, I fell into the trap. Afrer using Gemini for like 6 straight hours trying to figure out what happened (it fucking sucks btw), it said something that I hadnt thought about. See, I was using the GBZ80 documentation page to write the functions, and it only says “Set carry flag if result is 0”. And so I only set it when the output was 0. The thing I DIDNT know was that when the output was not 0, the zero flag gets set to 0. AI said that and I was like holy shit I gotta try this.

And what do you know, it worked! But even through my ecstasy at a dopamine hit seeing my code work, I had to wonder and in all honesty feel pretty shitty at the fact that had AI not existed, I probably would’ve spent another 2 weeks trying to figure that out.

I’m not shaming anyone that uses AI but it just makes me feel like shit when I use it. Like I didn’t put in the time and effort to actually research.

I don’t know, I know it’s silly and irrational, but then again I am extremely irrational and idk I feel like shit and an idiot now. Just wondering if anyone else can relate or how to get over this dread

Its my semester project. Any roadmap that I should follow?

AprNes home page (with 2026.04.19 download + full mapper table):

https://baxermux.org/myemu/AprNes/

GitHub (main repo):

https://github.com/erspicu/AprNes

Hi all,

Posting a consolidated update on **AprNes** (C# cycle-accurate NES emulator). This is probably the **final .NET Framework 4.8.1 release**. Future development moves to **.NET 10 + Avalonia**, chasing the better JIT, more mature intrinsics, and a real GPU render path via SkiaSharp. That migration is in progress but not yet production-ready — posting here to document where the 4.8.1 side landed.

-----------------------------------------------------------------

Where the 4.8.1 codebase is now

-----------------------------------------------------------------

Performance-wise, **4.8.1 is essentially fully optimised**. On typical modern hardware the analog "Ultra" mode runs comfortably at **6× and even 8×** internal resolution with no FPS pressure for most users. Beyond that, structural optimisations ran into JIT limits; the same code ported to .NET 10 + SIMD intrinsics (which .NET Fx 4.8.1 simply doesn't expose) gets another large chunk of headroom we can't touch on the old runtime.

-----------------------------------------------------------------

Where the .NET 10 + Avalonia port is heading

-----------------------------------------------------------------

In the new stack most rendering moves to the GPU via Avalonia's SkiaSharp runtime-effect API (real D3D11 / OpenGL context, not software rasterisation). Early measurements show **10× internal resolution runs smoothly**, and the target is to exploit **4K output natively** (with letterboxing given the NES aspect ratio). The pipeline is up and producing correct frames — but not yet release-quality for public consumption. Announcement will follow once it's stable.

-----------------------------------------------------------------

What changed since 4.13 on the 4.8.1 side

-----------------------------------------------------------------

About 170 commits since mid-April. Grouped highlights:

**Mapper expansion: 65 → 79**

Added / filled-in: 012 (DBDROM / MMC3-CHR-high-bit), 029, 074, 096 (Bandai Oeka Kids), 112 (Asder), 126 (PowerJoy multicart), 163 (Nanjing), 164 (Waixing), 173 (TXC 22211C), 176 (FK23C, 5/5 multicarts verified), 177 (Henggedianzi), 191/192/194 (MMC3 CHR-RAM variants), 209/210/211 (JY Company / Namco 175/340), 241 (BxROM / Subor). ROM verification details in `MD/Mapper/MAPPER_STATUS.md` in the repo.

**Timing architecture reworked**

My original clock-tick implementation plateaued short of full AccuracyCoin 138/138 — the architecture couldn't hit the sub-PPU-dot precision that certain tests demand. I've since **mostly removed my own timing code** in favour of a port of **TriCNES**'s master-clock model. Credit where due: TriCNES's timing architecture is genuinely excellent, and I've done my best to port it cleanly and then re-optimise around .NET 4.8.1's constraints rather than reinvent something inferior.

The port went through several structural phases:

- Phase 1: NestedTickN variants (de-recursion of PPU register handlers that used to re-enter MasterClockTick)

- Phase 2: structural unroll of the 12-MC NTSC kernel (`MasterClockTickUnrolledNTSC`, +13.1% FPS)

- Phase 2b/c/d: equivalent unrolls for PAL / FDS / Dendy

- Legacy MasterClockTick removed; all regions route via mcTickFn function-pointer dispatch

Result: **AccuracyCoin 138/138 + blargg 184/184 retained**.

**Perf optimisation pass**

About 25 `perf(...)` commits across PPU / APU / NTSC / CRT:

- PPU: branchless flip LUT, SWAR OAM multiplexer (+5% FPS), sprXCounter narrowed to byte with pure-SWAR slow path, TrailingZeroCount sprite decode, cold-path extraction

- APU: function-pointer dispatch for audio output (+1.9% FPS), SWAR-batch the per-cycle lenctrHalt reads, envelope/sweep unroll, sweep-negate bugfix (Pulse1 1's-complement vs Pulse2 2's-complement)

- Mem: unmanaged memory migration, NativeMemory.AlignedAlloc via conditional helpers on .NET 10

- NTSC: parallel frame-end demodulation (+25% FPS at 4×), SIMD 3-tap horizontal blur via row-snapshot, FMA YIQ→RGB matrix + gamma curve (on .NET 10), static unmanaged per-scanline buffers

- Mapper: `% N` → `& mask` in hot read paths for pow2 ROMs

- CRT SIMD: Vector256<uint> for all three ProcessRow*_SWAR variants, GetElement gather optimisation

**Bug fixes**

- APU sweep-negate polarity (Pulse1 vs Pulse2 differ — Pulse2 was being handled as Pulse1)

- NTSC race on scanPhase6 / scanPhaseBase under parallel demod

- FDS: pre-allocate palCache + InitFlipTable in initFDS

- expansionChannels pre-allocation before mapper Reset()

-----------------------------------------------------------------

EnigmaBenchmark — sibling project spun off

-----------------------------------------------------------------

While profiling AprNes's CRT shader pipeline across Scalar / SIMD / GPU backends, I realised the same Scalar vs Parallel vs SIMD vs SkSL-GPU comparison is interesting on **totally non-graphics workloads** too. So I built a sibling project that runs WWII German cipher brute-force attacks across the same four backends.

Six cipher systems, in chronological order:

- 1917 Zimmermann Telegram / Code 0075 (codebook cipher)

- 1918 ADFGVX (Polybius + columnar transposition)

- 1930s Enigma M3 (Wehrmacht)

- 1942 Enigma M4 "Shark" (U-Boat)

- 1941 Lorenz SZ42 "Tunny" (χ-wheel recovery, Colossus stage 1)

- 1943 Siemens T52e "Sturgeon" (Luftwaffe; *never routinely broken during WWII*)

The T52e implementation was interesting — the cipher is obscure enough that Claude Code went and downloaded Donald Davies' 1982 NPL technical memorandum, visually read the figures (Figure 9's 32-row permutation table and Figure 14's H/SR XOR network), wrote bilingual technical reports reconstructing the machine, and then implemented it in C#. The self-written reports are in the repo and are genuinely useful secondary literature on T52e.

Standard benchmark results on my machine (16-core x86 AVX2):

| Cipher | Scalar | Parallel | SIMD | GPU (SkSL) |

| --------- | ------- | -------- | ------ | ---------- |

| Enigma M3 | 11.06 s | 1.59 s | 0.51 s | 0.25 s |

| Lorenz | 90 s+ | 20–40 s | 1–3 s | 0.5–2 s |

| T52e | ~9 min | ~1 min | ~40 s | ~1 s |

Same four backends, one-click benchmark UI. Includes runtime SIMD dispatch (AVX2 on x86, NEON on Apple Silicon / ARM Linux) and bilingual in-app docs with 14 codebreaker biographies from Rejewski and Turing through Beurling and Painvin.

Landing page: https://baxermux.org/myemu/AprNes/EnigmaBenchmarkAvalonia/

GitHub: https://github.com/erspicu/AprNes/tree/master/EnigmaBenchmarkAvalonia

Release: https://github.com/erspicu/AprNes/releases/latest

To be honest here, I still think that the Fusion emulator is the most user-friendly Sega Genesis emulator out there and it such a shame that it still has some flukes in its system. I don't mean the ROMs don't run good; the games on Fusion actually run smoothly and doesn't lag (well... at least for my PC). What I'm actually talking about is the emulator itself and how should it be improved on its inner face. Here are the edits that I would like see for the Fusion emulator for the first time in 11/12 years (the one highlighted in bold is the change that should be the most prioritized):

1. When I was trying to map my Xbox controller to the emulator via. Fusion Configuration, the config wouldn't even pick up my inputs when it asks "Press Button/Direction or Keyboard Key to use for UP". It's not only that the config won't read my input(s), it's that I would also like to see a visual upgrade to see the Genesis controller while mapping it to whatever button the player desires (kind of similar graphic layout to FCEUX NES emulator controller mapping).

(Feel free to not add the other features in for the next [community made] update, for again the one highlighted in bold should be the mandatory focus)

2. For SegaCD emulation, it won't pick up on .chd files, so this should be fixed as well.

3. For Sega 32x, its ROMs should be a separate category from the Genesis ROMs.

4. You know those emulators that allow the user to add in list of ROMs from the folders of their PC as branching paths into the emulator itself (instead of the static shown before you boot up the emulator itself)? Well, that should be added too but as its visual being similar to what the mGBA has for the ROM listing.

Those are all the changes that I would like to see be done. Again, would highly be appreciated if only the one hightlighted in bold was done as an update for Kega Fusion version 3.64.1 or somewhere around those lines. Thank you for taking the time to read this and for someone to hopefully be willing to take action upon the change in bold.

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.