Here's the link

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.

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 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.

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

AccuracyCoin is no joke. Man these tests can be absolutely maddening to figure out sometimes, i feel so close but so far sometimes. But man am i excited to see how far i can make it

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!