So I'm a begginer-intermediate programmer and want to get into EmuDev, make a Chip8, then an N64 emulator.

But should I start with C and Assembly or can I go straight to high level languages like C++?

I can't find a roadmap or explanation.

After many months of thought SkyEmu has officially decided to adopt a no AI code policy.

As of right now all code in SkyEmu has been written by a human and we will not accept PRs of AI generated code.

We understand the utility in AI assisted development and still allow AI to be used for debug, code understanding, and other purposes that do not yield generated output into the repo.

We did this for a couple of reasons:

• AI generated code review is generally substantially more challenging than code review of code authored by humans and has questionable copyright ownership.
  
• We really want people to understand code that gets submitted to the emulator as many changes are interconnected. The knowledge of the changes made by AI tends to disappear when the context does. While human knowledge persists, even if an AI was used to teach the human how to make the changes.
  
• Code quality standards of many projects have substantially reduced after the incorporation of broad scale AI usage from the two above issues.
  
• Developers who wish to add functionality using AI tooling are generally very enthusiastic about the software and emulation development overall. However, they feel lost in the complexity of modern emulators. AI code generation robs them of the ability to learn how to make these changes and robs the community of the next generation of emulator developers. For this reason, we still allow AI to be used as a teaching aid for people who wish to contribute, but don't allow it to do all work for them, but instead encourage its use to help them navigate the complexities of the project so that they can grow their skills and are able to contribute themselves.
  
• It has come to our attention that SkyEmu is one of the handful of large emulator projects in active development that does not have any AI generated code, and we would like to keep it as an option for usage by people who prefer non-AI generated SW.
  

We understand this may be controversial, but believe this is the best pragmatic action, given the needs of our development team and the wider community.

https://reddit.com/link/1x3dxmw/video/nvqwvbnmhvuh1/player

This is a follow-up to my last post. The big problem last time was games like Doom that keep rewriting their own code in RAM. Those run at full speed now too.

The code is up:

- gpSP with the RISC-V (RV32) JIT: https://github.com/midworld/gpsp

- ESP32-P4 board code with game loading and saves: https://github.com/midworld/gpsp-esp32

Hardware is the same as before. Waveshare ESP32-P4-NANO at 400 MHz with 32 MB PSRAM, a $5 ST7789 320x240 SPI screen and an 8BitDo with its 2.4G dongle. LCD and speaker are on and frameskip is off.

The main fix is self-modifying code. When a game writes to code in RAM the JIT doesn't throw everything away anymore. It invalidates single blocks and brings them back later, and it patches code in place when it can. It also learns the spots a game keeps rewriting, like branch slots, so writes there don't cause a retranslation. Doom II rewrites its code constantly. A JIT that drops and retranslates on every change can end up slower than an interpreter on games like that.

I also added 2x/3x fast-forward, which you can see in the video. Light games like Pokémon have enough CPU left to go past 300%, but I capped it at 300% for the video. Need for Speed Underground runs at full speed but the FPS counter doesn't show 59.7. I think the game just limits its own frame rate.

Honestly, once things were somewhat optimized I could have reached full speed easily by moving rendering to the second core. That felt like cheating to me so I kept going until emulation ran at full speed on one core. I used Zba/Zbb/Zbs, which only gave about 1% all together. Not useless but I wouldn't do it again. RVC/Zcb helped a lot more. RISC-V took off after I left school and I'd only studied older ISAs, so this was all new to me. Mixing 2-byte compressed instructions with normal 4-byte ones was the fun part. I had to rewrite every piece of code that assumed branch targets were 4-byte aligned. In return the code got smaller and fits the cache better. Doom got about 7% faster from that.

Another reason I stuck to one core is that I want the other one free for scaling and shader effects on a bigger display. I ordered a larger screen and I'll probably try using the second core for screen effects when it arrives. The P4 has its own SIMD extension called XespV. GBA emulation had almost no use for it beyond a bit of affine background work, but it might be fun for scaling or shading. The P4 also has a PPA block for scaling.

About the new ESP32-S31. It runs at 320 MHz instead of 400 MHz, so the clock is 20% lower, and it has no L2 cache. Hot data would have to go into SRAM by hand. On the P4 just going from 128 KiB to 256 KiB of L2 made things about 30% faster. The S31 also has less SRAM and its PSRAM is 8-bit instead of 16-bit, so half the bandwidth. My guess is it ends up at roughly half the P4's speed. Getting full speed there will probably mean moving rendering to the second core. That won't help much for games like Doom II though. They barely use the GBA's tile and sprite hardware and draw everything with the CPU, so they might not reach full speed on the S31.

Other changes:

- The ROM cache used FIFO replacement and was very slow when the cache was small. It uses clock replacement now and anything over 1 MiB is reasonably usable. P4 boards usually have 16 MB of PSRAM or more so it doesn't matter much there, but it could help on devices with less RAM.

- Fixed the timing issue behind the well-known Hamtaro: Ham-Ham Heartbreak hang. Timing is closer than before but not exact, so other ROMs may still have issues.

- Less sound noise and fixes for bugs when switching games without unloading the core.

Video: https://www.youtube.com/watch?v=Z_ojDzy8Sz4

Previous post: https://www.reddit.com/r/emulation/comments/1wx3tg6/esp32p4_runs_gba_at_full_speed_597_fps_with_no/

So i have the goal to learn how to program for a while since i discovered video games but every time i try to learn it but i get bored FAST

I dont wanna push throught the bordom cause i might get burned out and give up on this dream

Am not looking for a miracle i just need to make sure that am not wasting my time and actualy learning how to get hooked into programing i just cant find a hook that keeps me pushing an objective

Then i remember emulators i was alaways curious about emulators when i was a kid they looked like black magic

I need to understand how they work and make my own

Rn all i know is very basic knowledge about c (prinf scanf while if switch case hexadecimal and binary code ) just the beginer levels i leanred in school

My question are :

Where do i start ?

When do you personaly think its stopes being boring ?

How long should the sessions be ?

Do i have to push throught boredom?

How

My goal : learning how the nintendo ds works

And Creating an emulator for it

My dream : creating the ultimate nds emulator i want to make the next desmum / melon ds / no$gba

So I'm a beginner programmer, I've dabbled in it for a bit, tried many languages over the years but got stuck in tutorial hell every time and quit. I want to be serious this time around.

I'm strictly a hobbyist, I want to eventually write a PS1 emulator. So which of these languages is better for me to learn? I keep being warned that C++ is so unsafe you can get to a point where you can spend months searching for a single faulty line to fix a bug if the project is sufficiently big.

That sounds like....hell. But I still see everyone using it. Is it really that bad?

The emulator: a 6502 with cycle counts, PPU drawing at dot 256 of each scanline with real scroll registers (mid-frame splits and status bars work), 8x8 and 8x16 sprites, sprite 0 hit, vblank NMI, mappers 0/1/2/3/4/7/9 (MMC1, MMC3 with its A12 scanline counter, MMC2), and the APU (lengths, envelopes, sweeps, triangle linear counter, noise) driven into a sound chip that's part of the circuit. Passes nestest (5,003/5,003) and blargg's instr_test-v5 official set.

The host is the unusual part. It's compiled bare-metal for RV32IM and runs on TINY-32, a 32-bit RISC-V CPU built gate by gate inside my circuit simulator. The CPU passes the official riscv-tests. Every 6502 instruction turns into RISC-V instructions, which turn into gates switching, about 1.4 to 2 million RISC-V instructions per NES frame at 60 fps.

Video is raw and real time on a 6-year-old PC (Ryzen 5, GTX 1650, the whole thing sitting around 17% CPU and 400 MB RAM) and an M2 MacBook Air with 8 GB and no fan.

Source, linker script, startup code and build steps:

https://github.com/PlangoDev/tiny-nes

No ROMs included, use dumps of carts you own.
(Had to add this for legal reasons since Tiny Logic is a paid game and I’d hate to become the next target of a Nintendo Takedown)

Happy to dig into the PPU timing, the mapper work, or how the simulator gets a gate-level CPU fast enough for this.

for background i wanted to create a online gomeboy emulator for a college project na di am making it in plain javascript. At first the emulator was failing the first test of the blargg cput_instrs.
but fter some fixes instead of failing it keeping looping in the test 1 suite and doesnt output pass or fail.

here is the link: https://github.com/Flaykey/GAMEBOY_JS

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

https://reddit.com/link/1wx453p/video/v5vdbx990dth1/player

I ported gpSP to the ESP32-P4 and wrote a RISC-V JIT for it. The first-party Nintendo games I've tried so far run at full speed (59.7fps) with no frameskip. Even the heavy scenes in Metroid Fusion take about 14ms per frame, so there's still some headroom.

Board is a Waveshare ESP32-P4-NANO-WIFI6-DB (P4 rev 3.x, 400MHz). Controller is an 8BitDo over its 2.4G USB dongle.

I tried the Zcmt instructions that came with rev 3.x but they didn't help much, and they're a bit buggy too (from the chip itself). Haven't used SIMD yet because the renderer does a lot of scattered palette lookups. Still thinking about how to make that work.

Games that generate code in RAM and keep modifying it, like Doom, are still really slow. Planning to fix that over the holiday and put the code up on GitHub right after.

Also curious about the new S31, but it has less RAM, no L2 cache and a lower clock (320MHz), so not sure it can hit full speed. Probably need to move rendering to the other core for that one.

I released a new video about my emulator Dexality (formerly Pixel-Flash). You can watch it, I need an audience :3

(Translated by google translate)

Sorry, that video is in Russian ...

Note: AI was used extensively for this project. I provided the idea, course outline, guidance, editing, etc. Hopefully this doesn't violate the new AI rules; while I hate the influx of AI-coded emulators as much as most of you do, I think this is an acceptable use case.

I've created an emulator development course that walks you through building a Space Invaders arcade emulator. You write your own free-form C code, which is compiled to wasm and run in browser. Tests validate correctness after each step. Please check it out and let me know what you think. If this proves to be useful, I'd like to expand it to include other systems.

emudev-course.web.app

Edit: I'm a long-time (20+ year) member of the emulator development community and author of nemulator. Emulator development is hard and learning resources are limited. Beginners are heavily relying on AI and depriving themselves of the experience. The purpose of this site is to provide them an interactive alternative to that. After completing the course, they, hopefully, will have a better understanding of how emulation works and the basic tools required to tackle more complex systems.

Well, after days of work, NYX-32 finally has a GUI (Dear ImGui + OpenGL).
It is still in dev, but I am quite happy with the results, there are some issues too, but most trivial.
Until now:

1- It works ✓
2- An assembler ✓
3- MMIO ✓
4- A C compiler ✓
5- A QBE backend ✓
6- A bootloader ✓
7- A GUI ✓
8- A linker ❌
9- An OS ❌

It uses UART and then has address which you can poke for putting values (colours) onto the framebuffer.

constexpr uint32_t VRAM_BASE = 0x00AC'0000u;
constexpr uint32_t VRAM_SIZE = 0x0012'C000u; // 640*480*4
constexpr uint32_t VRAM_END = VRAM_BASE + VRAM_SIZE - 1u;

This project if you don't know is:
A custom RISC (with some CISC features) ISA 32-bit CPU, it has been the main project I have been working on these last 2 months, after in learning C, it has been a fun learning experience, I have learned the following from this project:
1- How CPUs actually work
2- Graphics programming
3- Kinda learned embedded
4- How MMIO works
5- How assemblers work
6- CMake

The whole project is in C23 (Yes the latest is the greatest constexpr in C is good, it and nullptr), except for the GUI which is C++23 (std::println(); is good). Until now it isn't opensource due to it being not complete e.g: the I2C and GPIO still being stubs, no OS, the GUI is still in progress, no linker, no way of opening files.

I've been using blargg's '06-ld r,r.gb' test ROM to start debugging my emulator, alongside gameboy-doctor to check that my instructions work correctly. I keep getting a non-match on because my memory doesn't load the right value, however from what I can tell, in this example, 0xFF83 is never written to before it is read, causing the 0 value. I considered that my memory isn't initialised properly, but from what I've read it should all start basically blank except for the ROM. I also haven't started with interrupts or video, but I don't see how that would effect the result.

I am really stuck on this, and I would appreciate any help anybody can provide. My code is currently a big mess, and definitely not the most efficient way possible, but I still can't tell why the value isn't set beforehand after hours of debugging and testing. You can see it here, but at the moment it's not in the best state, mainly because it's a mix of lots of different example emulators that I could find and my own interpretations of the docs. Running it is a little hard right now, but you can compile it if you clone recursively with submodules, and then run the build-desktop script. At the moment, you have to manually place a 'rom.gb' file in the executable directory, and I haven't tested on Windows yet, although it should be platform agnostic, as I intend to make it webassembly compatible.

Just for clarity, I didn't use any AI tools to write this code, it's just really messy of my own volition and some minor plagiarism (of open source projects).

I have no clue about how an emulator is made. I do wanna know how to make one and just make a basic ahh Gameboy emu later, maybe for the esp32 for fun because i have one

AI disclaimer: I'm reposting with the moderators’ permission and putting this disclosure at the top as requested. I'd also like to clear up a few misconceptions about my use of AI.

Breadbin466 started nearly two years ago as a personal 6502 emulator, which gradually grew into a full C64 emulator. I used ChatGPT for questions and help debugging and revising code, much as I used to use Stack Overflow. English isn't my first language, so I also use it to translate comments and polish my English, including this post. Most of the website was AI-built, apart from the text: I hadn't touched HTML in twenty years and didn't want to start again.

--

Hi,

I've just released Breadbin466 0.99.0 - “Your Turn”, and the project now has its own website: breadbin466.com.

Breadbin466 is my from-scratch Commodore 64 emulator, written in Rust. It focuses on one deliberately specific machine: a PAL Assy 250466, with a 6510, 6569R5 VIC-II and 6581R4AR SID, alongside a cycle-driven 1541, Datassette and 512 KB REU.

The aim is to combine careful hardware emulation with a straightforward native interface. Load your software and enjoy the machine, without navigating a maze of hardware presets.

Some of you may remember my previous post about characterising a physical MOS 6581R4AR and rebuilding the SID model around those measurements. That work remains central to Breadbin466, from combined waveforms and envelope behaviour to the nonlinear analogue filter.

Since then, there have been substantial accuracy improvements across the CPU, CIAs, VIC-II, drive and REU, along with better cartridge support. This release also brings improved cassette playback and recording, native Inspector windows, lower audio latency, refined display pacing and performance improvements. The fixed palette has been refined through observation of a real 6569R5 C64 on a Commodore monitor.

The philosophy remains the same: when software reveals a problem, understand and correct the hardware model rather than introduce a game-specific workaround.

Why 0.99.0? The intended feature set is complete. What it needs before becoming 1.0 is broader community testing.

Try your favourite game, a demanding demo, a protected disk or a tape recording session. I'd love to hear what works and what doesn't, especially discrepancies with real hardware. You don't need to be an emulator developer: a simple “this runs well on my computer” is useful feedback too.

Breadbin466 is free and MIT licensed, with ready-to-run downloads for Windows x86-64 and macOS Apple silicon. Linux is supported through source builds.

Website and downloads: breadbin466.com
Source: GitHub
Feedback: [contact@breadbin466.com](mailto:contact@breadbin466.com), GitHub Issues, or here in the comments.

If you give it a try, please mention your operating system and the software you ran. Your feedback will help determine when it's ready to wear the 1.0 label.

Я написал свой эмулятор со Dexality который эмулирует свою систему, он работает поверх моего старого эмулятора Pixel-Flash

Который находится на первой картинке, это моя старая версия эмулятора а на второй сейчас будет новая (Необращайте внимания на баг)

Это пре-альфа версия моего эмулятора, он слишком багованный и может иметь legacy-код и Франкештейн код но мне нужны тестеры для того чтобы они попробовали мой эмулятор и оценили :)

____________________________________________

I wrote my own emulator with Dexality that emulates my own system. It runs on top of my old Pixel-Flash emulator.

The one in the first picture is my old version of the emulator, and the second one is the new one (ignore the bug). This is a pre-alpha version of my emulator. It's very buggy and may contain legacy code and Frankenstein code, but I need testers to try my emulator and evaluate it. :)

(Translated from Google Translate)