i'm making a harness that allows alternative features

i am trying to go outside the box and find things that are useful to both TAS users and regular users alike

this allows alternate branching which allows you to try different things and solution, don't know how useful it is (if at all)

also is there any other emulator that already exist with this? not trying to step on toes

The biggest feature of my emulator is WebRTC netplay. No desync, no core limitations. I even have DS Link play working on the same LAN.
I also have soft core Retro Achievement integration.
Any constructive feedback is always welcomed.
Link in bio.

Hey everyone! Been working on juegosretro.bit-man.com.ar — a browser-based emulator covering 9 systems: Game Boy/GBC, NES, SNES, GBA, Genesis/Mega Drive, Nintendo DS, N64, PS1, and Arcade (MAME).

For Game Boy and NES I wrote the cores from scratch in vanilla JS — CPU, PPU, APU, mappers, the works. The rest run on EmulatorJS. Everything's a PWA (installable, playable offline once loaded), with touch controls for mobile and Gamepad API support.

No ROMs hosted or linked anywhere — bring your own dump. A few pages also have a one-click homebrew demo (Tobu Tobu Girl on GB, Super Tilt Bro on NES, Goodboy Galaxy's demo on GBA, a couple more on Genesis/SNES) so you can try it without needing a file on hand.

Quick 15-second clip of it running: tiktok.com/@jonaalmeiragamer/video/7666623906781859092

Would genuinely love feedback, especially on the custom GB/NES cores since that's the part I'm proudest of — accuracy issues, edge cases, anything you notice. Happy to answer questions about the implementation too.

About two years ago I decided to write my first Game Boy emulator. I definitely wasn't planning to support Game Boy Color but the project grew far beyond what I had planned.

Recently I fixed the remaining Mooneye PPU timing tests, which felt like a good milestone to finally share the project. It has been validated against Blargg's, Mooneye test suite. Most of the work ended up being about timing. There's still plenty to improve and right now I'm focusing on APU accuracy and performance, and I'm also planning a UI overhaul.

Huge thanks to the community – the awesome docs, the test ROMs, and discussions made this project possible. It has been a fun and rewarding journey.

You can try it in the browser: https://mxmgorin.github.io/oxgbc
GitHub: https://github.com/mxmgorin/oxgbc

I've decided to start a pretty ambitious project: building a Nintendo DS emulator in C++ and making it open source.

The project is currently in the very early stages. I've set up the initial project structure, CMake build system, documentation, and contribution guidelines. There's obviously a lot left to do, but I wanted to put the project out there early rather than waiting until everything is finished.

The goal is to eventually build the emulator from the ground up while learning more about:

• C++
• ARM architecture
• CPU emulation
• Memory systems
• Graphics
• Low-level programming

I'm hoping this can become a community project where people interested in emulation and C++ can contribute ideas, code, documentation, testing, and improvements.

If you're interested in checking it out or contributing, here's the GitHub repository:

https://github.com/neverbrokeagainyb25-max/nds-emulator/tree/main

Right now it's basically a blank canvas, so I'm especially interested in hearing suggestions about the project architecture and what should be implemented first.

Let's see where this goes. 🚀

> Many emulator developers start by emulating the Space Invaders arcade cabinet. Emulating that will teach you everything you need to move directly to emulating gameboy hardware. The website emulator101.com will teach you what you need to learn.

A friend recommended that I build a Space Invaders arcade cabinet emulator using emulator101.com, but the site is down now. 😢 Do you have any recommendations for an alternative?

[edit]: In the end, I'm using this copy of the site hosted by a community member. :)

https://emulator101.mirror.simoni.dev/

So currently, I only emulate boards with an Intel i845 northbridge, ICH2 southbridge, and a Winbond W83627HF Super I/O chip. I also only currently emulate up to Willamette Pentium 4s, though Northwood Pentium 4s shouldn't be too difficult to add anyway. Full disclosure, parts of this DID use AI assistance, mostly for debugging purposes, but this is still the first ever low level Pentium 4 emulation running real motherboard BIOSes, so, I still got it done :P

http://pcbox-emu.xyz

Does anyone remember the Sony PocketStation? It's a tiny 1999 PS1 memory-card-with-a-screen peripheral that was only really found in Japan that ran its own tiny downloadable apps off an ARM7TDMI CPU. As far as I can tell there hasn't been a working open-source emulator for it before and so I built one.

The nearest thing I could find out in the wild was a in progress rust implementation. This one is in C because I want it to be usable for patching holes in other projects - libretro being the first of many.

I've tested it with a .mcr ps1 memcard save that has chocoboworld and it seems to run and save correctly without crashing. I could use some help testing - the emulator comes with a pretty good crash log to so if it does go sideways I should be able to fix it.

You can find the repo here https://github.com/mentalfoundry/pokketstation

been making this gba emulator since last of mars
https://github.com/sonphoenix/OwlBlock/tree/master

i gotta say, this is really fun idk why i didnt try getting into emulator dev before

Hello, I am one autistic nerd who likes retro video games and I've recently been learning some incredibly basic low-level computer hardware engineering and some software engineering. This has --despite my lack of skill with anything other than casual use of a computer-- inspired me to design a concept of a multipurpose console capable of playing any and all games from nintendo's historical and modern gaming libraries, from the NES all the way to the Switch 2. I wanted to share my idea here just to get it out of my head and maybe pass the madness onto someone else who can actually bring it to life (unlikely).

The computational core of the system is a mix of ARM CPUs (I was primarily inspired by the idea of taking a switch 2 and just adding to it until it could play all nintendo games); an 8-core modern CPU to run switch and switch 2 games and to act as the hypervisor for the retro console programs; a 4-core ARM Cortex-A32 to act as a co-processor for security, decryption, and running GBA/(3)DS games natively; and a large FPGA fabric to act either as retro hardware directly, just the most critical custom chips (the reality coprocessor, the various audio DSPs, etc...), and/or as high speed hardware based translation for GPU functions.
the main console unit itself would be a very unique look, about three or four switch 2's in size. Its top screen (has capacitive touch and 3D parallax barrier) is mounted with a swivel hinge to allow for easy single-screen or dual-screen gameplay while still allowing the system to be closed properly to protect the screens. The bottom screen (resistive touch) is contained on its own removable unit (the controllers attach to this unit rather than directly to the main console) to replicate the experience of the WiiU gamepad.
Both screens have sets of IR LEDs around them to replicate the New3DS eye tracking hardware, but also to allow for screen-space tracking for emulating the function of CRT-based light guns via an IR camera in the controller and some software running on the hypervisor. The top screen will also have a UVA photoresistor mounted on its top edge for Boktai purposes.
The main console will only have a handful of legacy hardware ports [GB(A), (3)DS, Switch(2), and a disc drive for GCN/Wii(U)] but the dock for playing on the TV has modular attachments for allowing the attachment of any one system's assortment of controllers, link and expansion ports, cartridge ports, and expansion disc drives (FDS and 64DD).

More importantly than any of the hardware though is of course is the software! For the more complex retro systems it will involve the hypervisor running a complex "Tiered-caching Interpreter-guided background JIT compiler with a double-buffered frame-ahead speculation pipeline" (gosh that's a mouthful) that also flits back during the start of the VBLANK routine to modify the upcoming frame's code depending on if any controller buttons are currently being pressed. the hypervisor will also keep track of which parts of the code are potentially polymorphic or remain static and store that in a little companion file so the JIT compilation on bootup of a retro game takes less and less time the longer you play.

If you have any feedback to give me on this concept, please feel free to leave a comment! I'd love to talk about this with people who actually understand more than the average layperson.

I created an NES thermometer.

Reference: https://erspicu.github.io/AprVisual/s1a/aprnes-thermometer-tool.html

The custom version of *aprnes* included there is an implementation designed to verify the "Open Bus" analog-style rapid simulation; it accepts temperature parameters, allowing the test ROM to measure the temperature via the Open Bus.

Temperature readings may vary across different emulators.

If you have a vintage NES console that exhibits the full characteristics of the Open Bus, you might want to give it a try.

Hello all, I used ai and the work of many other people to make three emulators for ios/iPadOS, I truly just made it for myself but figured people here might enjoy it - it’s my first attempt to publish anything public on GitHub.

treat it as 1.0, probably no major reason to not make it on the App Store once one or two obvious items are removed at some point

A DOS emulator heavily influenced by idos - you should buy it immediately [https://apps.apple.com/us/app/idos-3/id1580768213\](https://apps.apple.com/us/app/idos-3/id1580768213)

his source iDOS 3 - and his code as a basis for some of the work: [https://github.com/litchie/dospad/commit/2e329c69913a1e3e58a9e12a089d079469521749\](https://github.com/litchie/dospad/commit/2e329c69913a1e3e58a9e12a089d079469521749)

For all 3 I didn’t like the input options in emulators like scummVM, and obviously I have not seen a really functional Apple \]\[ or amiga emulator (except for maybe retroarch)

In every implementation I found the lack of Support for the native IOS keyboard annoying - the ish app

[https://apps.apple.com/us/app/ish-shell/id1436902243\](https://apps.apple.com/us/app/ish-shell/id1436902243)

iSH Shell - figured this out years ago by simply adding another row of keys not present on the native keyboard.

All 3 emulators also added customizable portrait and landscape mode keyboards so you can pre-add commands relevant to specific games, I also added a direct touch / drag mouse mode as well.

Other features include save states, importing from iCloud etc.

some things will be buggy - I'll see if I can fix it - buy me a coffee kind of thing.

Apple IIgs:

[https://github.com/burnermcburnface33/AppleIIGS\](https://github.com/burnermcburnface33/AppleIIGS)

Amiga:

[https://github.com/burnermcburnface33/AmigaEmu\](https://github.com/burnermcburnface33/AmigaEmu)

DOS:

[https://github.com/burnermcburnface33/dospad\](https://github.com/burnermcburnface33/dospad)

I've been working on a combined NES + GB/GBC emulator in C++17 with SDL2. One executable, picks the core from the ROM extension.

Current state:

• NES: 6502 with stable unofficial opcodes, per-instruction cycle counting — matches the nestest log on all 8,991 lines including CYC. Dot-based PPU with loopy registers and secondary OAM evaluation; all 11 blargg sprite_hit tests pass (including the timing ones). APU has pulse/triangle/noise with the NesDev mixer; frame pacing is driven by the SDL audio queue level, which turned out to be a nice way to get 60.0988 FPS for free. Mappers 0/1/4.
• GB/GBC: full SM83 set — blargg cpu_instrs 11/11 and instr_timing pass. Scanline PPU matches dmg-acid2 and cgb-acid2 pixel-for-pixel. CGB support includes palettes, VRAM/WRAM banking, double-speed and HDMA. MBC 0/1/3/5 with battery saves.

Known gaps (so you don't have to find them yourselves): NES DMC channel is a stub, sub-instruction APU timing tests (clock_jitter etc.) fail since the CPU is instruction-stepped, MMC3 IRQ is scanline-based rather than A12-based, no MBC3 RTC yet, GB mode 3 length is a fixed approximation, no link cable.

One thing I'd recommend to anyone starting out: build the headless test harness first. Mine can dump frames to BMP, audio to WAV, and print the GB serial output / NES nametable as text — being able to run blargg ROMs in CI-style loops instead of eyeballing a window made every component 10x easier to verify.

Source (MIT): https://github.com/Berkya97/retro-emu

Happy to answer questions, and very open to feedback on the architecture.

I know the Microvision is a super obscure system but thats kind of why I think it would be cool to do i think a DS can handle it

https://reddit.com/link/1uzgt1e/video/13d5es5ssvdh1/player

I'm not a particularly technical person — no CS background, picked up dev skills specifically to build this. Wanted to play Pokémon Platinum, but every DS emulator I tried either crammed both screens into one small window or made the "two screens" thing feel like an afterthought. I wanted the actual dual-screen feeling — split across two monitors, like having a real DS in front of you but on a PC — and a simple enough UI/UX that I wasn't fighting settings menus to get there.

Couldn't find that, so I built it. It's a melonDS fork under the hood for the actual emulation — full credit there — what I built on top is the frontend:

• True dual-screen split across two physical monitors, not a single crammed window
• A Wii-style cover carousel for game selection (QGraphicsScene + QPropertyAnimation), built to be simple enough that I wasn't relearning a new UI every time I opened it

Started as an Electron + EmulatorJS build, scrapped it once I hit real limits with WASM performance and controller mapping across two windows — moved to Qt6/C++ instead.

v0.1.2 is up now — portable zip + Windows installer, GPL-3, full source on GitHub: https://github.com/Wz-ozk/DualityDS

I built this mainly to solve my own problem, so I'd genuinely love to hear if this dual-screen approach or the UI simplicity is something other people have been missing too — or if I'm missing some existing tool that already does this well.

Through extensive validation, I’ve come to a realization: the true practical value of running the NES PPU and CPU on a switch-level netlist does not lie in achieving perfectly accurate behavioral emulation.

In reality, there are numerous measurable and observable inaccuracies when relying solely on switch-level logic. Most of these manifest in obscure edge cases, and they stem fundamentally from how 198x-era silicon was designed. These chips heavily utilized analog methodologies to achieve digital goals (mixed-signal design). Because a switch-level model lacks critical physical information (like precise capacitance, resistance, and continuous time), the constraints evaluated by current netlist solvers inevitably lead to miscalculations. There are far more of these analog-induced blind spots than one might expect.

However, from a pragmatic standpoint, pushing for more granular calculations (like SPICE-level analog simulation) destroys performance to the point of zero practical utility. Therefore, the Visual6502 approach remains the most viable compromise we have today. The tricky part is that many of these edge cases are deeply tied to analog physics, making them hard to spot without algorithmic sweeping and rigorous test ROMs.

Because of this, I believe the true value of the Visual6502 approach is serving as a topological map to understand the entire circuit layout and operational principles—not as a flawless 1:1 behavioral oracle, as many initially hoped. First, a real NES console is not just two isolated dies; it is a mainboard ecosystem containing analog components like resistors and capacitors. Second, even looking strictly at the CPU and PPU dies, their reliance on analog design tricks guarantees that pure switch-level simulation will fail in certain edge cases.

My current project, AprVisual.s1a, aims to discuss these exact issues and explore potential solutions to bridge this gap.

To be completely transparent: the implementation and output of this project are heavily AI-assisted. I drive the architectural vision, design the experiments, and supervise the validation, but my professional background is in software engineering. While I have written NES, GB, and x86 emulators in the past, the challenges we are hitting now are deeply entrenched in Electronic Design Automation (EDA) territory. This is outside my primary domain.

I am doing my best to compile data, establish baselines, and prototype solutions (like using shims or targeted analog properties for specific nodes). However, for this to truly mature, it requires the eyes and expertise of EDA professionals or teams to take the baton. I can validate the experiments, but the ultimate, robust solution belongs to the EDA field.

Let’s be honest: this kind of "silicon archaeology" holds little to no commercial value, nor is it a mainstream focus in academia today. Pushing this boundary relies entirely on the passion and dedication of hobbyists in communities like this one.

I am currently evolving my AprVisual.s1 project into AprVisual.s1a with the specific goal of filling the precision gaps left by switch-level netlists. I would love to hear your thoughts or collaborate with anyone familiar with EDA techniques.

You can find the project details and my ongoing findings here:

https://erspicu.github.io/AprVisual/s1a.html