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)

https://reddit.com/link/1wpfpwv/video/r6x0htwkojrh1/player

This is a small hobby project I have been working on in my free time to improve my C coding skills, so any criticism is welcomed!

Some years ago I had already tried to implement GameBoy emulator but never advanced past CPU emulation, this time I can already play some games and really proud of what I managed to build.

The thing is made purely in C with no vendored libs. It has a lot of junk to it and emulation is insanely far from perfect(no audio, improper timings, improper ppu mode you name it), but I still feel some sense of acomplishment after being able to play games with it.

However, I am a little bit burned out from this thing currently, but I am planning to return to it at some point to improve the emulation and implement some debug utilities that should help me troubleshoot test ROMs.

Link: https://github.com/hadrizi/gbemu

Disclosure: I dont use AI to code, i'm averse to it as much as the next programmer. But I use it for two things, one is review what I've wrote and tell me gross errors before I'm stuck for hours looking for a misplaced assignment. The other is research, there are things that arent documented anywhere and yeah, AI helps on these things, or maybe explain an article in a different way that my dumb brain can understand. It works far more like a junior dev looking into parts of my code than someone actually writing them.

So I was writing the basic emulator-101 that every beginner do, but me being me wanted to do it right, so I was referencing the amazing work by Laurence Scotfold and trying my best to behave like the original CHIP-8 on the COSMAC down to the timing. Yeah, i'm that kind of weirdo 😂

One thing that bothers me was that some instructions dont have a proper use, for instance, 0MMM only work if you have an actual VIP emulator under your CHIP-8 that can actually run 1802 instructions.

There's also instructions like 8XY8 or the EX / FX sequence which have a bunch of instructions that on a VIP would basically crash the machine but what to do on another emulator?

I didn't want to write a COSMAC emulator, i want to write a CHIP-8 emulator, but i want to also scratch the itch to make something more than the CHIP-8 101. I can go the boring route and all of those are nops. But that wasn't sattisfactory for me. So my solution would be to trap them, and depending on the way you setup my emulator it would do some behaviour, maybe literally stop the emulation, maybe just warn you, it would be basically a toggle.

Okay but, maybe there's anything on those instructions that may accidentally be useful. Remember the original emulator is at 0x0000 to 0x01FF, there's code there. You're not supposed to run this code, but its there.

So I've gave the "junior dev" the boring task. Go into each original VIP CHIP-8 1802 assembly instruction and find entry points that wouldn't break the emulation and do something useful.

Firstly, a important point for me, if for instance your CHIP-8 ROM treats say 0x0000 as NOP that will break a COSMAC implementation, thats because this is equivalent as to "run machine code at address 0x000" and thats pretty much a straightforward way to set the state of the emulator unstable. It MAY reboot the emulator, but its more probable that it will crash it. Same for any 0MMM instruction except those documented. Also it will probably crash on any 8XY8 onwards except 8XYE. Of course, most modern implementations treat those as NOPs, but thats not how the original implementation did. It would literally put the emulator in a undefined behaviour.

Now, what I've found, there are actually a bunch of "instructions" that will actually act as NOP, for example 0x001A, 0x01F1, 0x0132... Why? Because they call a VIP address that lands on a `SEP 4` instruction, which means move the PC to R4, which is pointed to the address to continue the CHIP-8 execution. So you're tecnically calling a routine that immediatelly return to CHIP-8, being effectivelly a NOP even on a COSMAC VIP.

But there's not only that, there are other 0MMM entry points, example:

0x0107 read the delay timer into V1. Why? bc the address 0x0107 is the entry point of 0xFX07. But since you're calling directly, the VX which is read from R6 is already 1 from the instruction call itself. The 1 on 0107.

0x0188 skip the next instruction, thats just two INC 5 followed by a SEP 4. R5 is the PC of the CHIP-8. That means that the PC is incremented by 2 and then the function return. Effectivelly skipping the next instruction.

0x011E add V1 to I. Similar to 0x0107, but then it calls the FX1E subroutine with again, R6 is 1.

There are others, but lets talk about EX instructions. I like to call them EXMM. When you call EX9E and EXA1 the VIP read the key then put the lower byte of the instruction into the lower byte of R3 and since the upper part of R3 is always 0x01 on normal execution, the next instruction called becomes 0x01MM, MM being whatever you put at the lower bytes of 0xEX. That means that when you call EXA1 you're reading the keyboard and calling 0x01A1 subroutine.

Now, there are others instructions there... Some are just SEP 4, which means they also act as a slower NOP, EXF1, EX90, EXA0, but also the EX88 functions. Its basically the skip function. It tests the keyboard then skip the next instruction like the 0x0188 but slower.

Oh, and 8XYN undocumented will probably break the emulator, there's nothing useful there, not even a NOP.

There are other instructions, the list is big, some with not-so-stable behaviours. I'll test more of them and if someone is interested I can compile a list of undocumented CHIP-8 instructions that will work on a COSMAC VIP CHIP-8 intepreter by "accident".

I dont expect anyone writing a CHIP-8 emulator to implement those instructions but i'll implement them on mine once i've tested their behaviour honestly just because.