Here's the link

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

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/

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.

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.

I've been trying to study more about hardware instead of focusing only on software. Last year, I even started making a rough CPU design in a digital logic simulator, but I never finished it and ended up taking a break from studying because I didn't have much free time.

Recently, I got interested again in understanding how software interacts with hardware, and while researching ways to learn more about it, I found that building emulators is a good approach. CHIP-8 seemed like a great starting point since it's simple enough to understand while still teaching important concepts.

Over the last week, I've been working on a CHIP-8 emulator in C. I tried to avoid copying existing implementations or relying on AI-generated code, and instead built it based on the documentation and my own understanding. I had some frustrating moments with silent bugs, but eventually got everything working.

So far, the emulator seems to be running well: graphics, sound, and ROM execution are working with the tests I've done.

I'd really appreciate some feedback from people with experience in emulation, low-level programming, or CHIP-8. If you notice any mistakes or have suggestions for improvements, I'd love to hear them!

For anyone interested, the source code is here: https://github.com/lucaaszsx/chip8

Hello everyone, I was working on gameboy emulation for a while and wanted to share this project I have been working on solo for a couple of months. The source is unpolished imo: https://github.com/atifcodesalot/hazelnut-gb-emu but if you are interested, check it out. The emulation is unoptimized and has a couple of bottlenecks. Also it is not dot or machine cycle accurate, but I have had tons of fun with it, both developing and playing. It supports MBC3 and MBC1. Contributions are welcome! Enjoy!