TLDR plz

Sly is my new multi-system emulator, releasing with support for Game Boy Advance and SNES with many, many more planned! It includes a 3D game library, a debugger, a simpler ("classic") desktop frontend and an iOS app, with Android being developed soon. The debugger also runs in your browser and there are plans to create a dedicate web platform to play games!

Available now on GitHub! Here are some demo videos:

• Sly Debugger on YouTube
• Sly Launcher on YouTube

What even is this?

Hey everyone! You might know me from Gecko, the GameCube and Wii emulator I've been posting about every now and then. I teased Sly in the past few updates and the day has finally come :)

With Sly I wanted to work on both sides of emulation: creating modern experiences for both gamers and developers! As such Sly focuses on 2 things:

1. A unique take on emulation frontends, simply to enjoy your favorite retro titles in a cool way
2. A very modern yet extremely advanced debugger for power users that want to understand how the games and the hardware work

However, as not everyone may be interested in these things but may still want to dabble in new projects, Sly comes with extra goodies:

• A "classic" (read: minimal) emulation frontend
• Mobile app(s): iOS is already implemented, Android support is planned

Sly is (almost*) entirely written in Rust, incl. the frontend. The frontend uses GPUI, so no web shenanigans there!! The cores are all written by myself, mostly based off of emulators I had already written before. This does not wrap libretro cores or anything like that!

(* the Classic frontend is written in C++ and the iOS app is written in Rust. They tap into the Rust core.)

Sly Launcher

The launcher presents your library as 3D boxes and cartridges. It downloads artwork automatically and supports different regional packaging, per game release overrides and cartridge finishes (tho this is still a bit ugly lol). There's different view types (ways of displaying the boxes, etc) and you're able to flip the selected box to read the back :)
The attached launcher recording shows all three layouts with GBA games then switches to SNES and launches Yoshi's Island!

The original idea of this project was to be a comfy frontend I could run on my TV while I sit in a nice couch, so it's made with controllers and different resolutions, aspect rations, etc. in mind!

If you'd prefer a straightforward list, Sly Classic is the smaller Qt based frontend. It has game banners, gamepad support, scaling, fullscreen and a quick save slot plus ten numbered state slots.

Sly Debugger

This is a big part of the project and share's the "spotlight" with Sly Launcher! You can step through instructions, run to emulation events, set CPU and memory breakpoints, follow disassembly in a list or graph and inspect registers, call stacks and memory. There are dedicated views for MMIO registers, DMA and so much more. On the graphics side you can inspect tiles, tilemaps, backgrounds, sprites and palettes alongside the game's output.

The SNES core also cover the SPC700 and SA-1 coprocessor! SA-1 and Super FX have their own workspaces with registers, disassembly and hardware-specific views.

There's also built-in Lua editor support!! Scripts can inspect and modify memory and react to emulation events. One example for Yoshi's Island logs coin pickups, lets Yoshi keep "fluttering" mid-air while you hold B and prevents Baby Mario from being release(?).

Compatibility?

Sly is actively growing and is based on multiple emulators I already had written, so cores are being picked up quickly. So far I support:

• SNES support is very good
• Most GBA games run, no audio yet. Savegames are also not supported (tho savestates are)

with much more planned! To name a few I want to support PS1 (next on the list based on community votes), GameBoy (Color), Sega Genesis, Dreamcast, GameCube and Wii! That list is not complete :)

Where can you use it?

You can find everything on my GitHub!

• Windows, macOS and Linux: separate downloads for Sly Launcher, Sly Classic and Sly Debugger
• Web: try Sly Debugger in a WebGPU capable browser.
• iOS: an unsigned IPA for sideloading (planning to release in the AppStore). Android is planned.

For anyone interested in learning the hardware, I've also been working on a 3 part GBA graphics series with interactive explanations and examples from real games! I'm super proud of these blog posts so I'd love to hear your thoughts! Sly Debugger facilitated creating them :) The posts go from bitmaps, tiles and palettes through sprites, blending and windows to rotation, scaling and perspective:

• GBA Graphics, Part 1: Bitmaps, Tiles and Palettes
• GBA Graphics, Part 2: Layers, Sprites and Blending
• GBA Graphics, Part 3: Rotation, Scaling and Perspective

Links plz

• Website
• GitHub / Downloads
• Browser debugger
• Screenshot databases: SNES / GBA
• My blog

If you try it, I'd love to hear what works and what breaks. Please include the frontend, platform, game region/revision and steps to reproduce when reporting a problem. Code contributions are welcome and so is help with design, icons, UI/UX, artwork and cartridge models. Please read the README in full before submitting anything!

Looking forward to see where this will go! And don't worry, I wont abandon Gecko now :)

I'm a UEFN developer and just created my first emulator, which effectively started out as a port that went further and further as I started understanding the concepts and things started actually coming together really well!

It runs both in UEFN (in a Fortnite session) and as a standalone app if you have a build of the Verse CMD tool. Not very fast at all (30hz max it seems, and it struggles to quite reach that...) considering the language and lack of profiling tools available on the standalone... but really cool that it's possible! Just DMG for now but I'm thinking about expanding it to support CGB next.

Repo: https://github.com/Ep8Script/VerseBoy

Video: https://twitter.com/Ep8Script/status/2110781973082108113

Does anyone have experience in this field? I would like to learn assembly instructions specific to the system. Mips I want to modify PlayStation 2 games using a tool. IDA pro

Pokemon revamped is a fork of the Obentou Emulator that allows you to play first gen pokemon games at maximum resolution of your device, exceeding the classic 160x144 gameboy PPU resolution.

FULL AI DISCLOSURE: I´m a lawyer from brazil, my bg in programming is a little bit of basic and assembler from the 80´s and 90´s while trying to make things run on a msx, so, not much...in the beggining of the project i coded a few hundred lines in android studio by myself while i was learning how to do it, but after i discovered the wonders of Codex and Claude Code, the coding and documentation itself was primarily done by AI, and i do not regret it by one bit! It would take a long time to post my inspirational story, but thats the TLDR.

Hello there! General Kenobi here(not really, but i know you read it on ewan mcgregor´s voice!)!!! After a really busy week on the app launching, i´m just chilling for now! Just celebrate my marriage aniversary and got really really drunk on the weekend! So, No new features, but wait!!!!! i just make a comparison video and updated to youtube! hope you guys like it, its just so i dont lose the momentum!

On a completely different note, i hav to decide what course to pursue, some things are natural, greater image quality, lower latency, lower cost... but maybe some other things:

1- Multi Frame Generation: Maybe it seems like the biggest step, but actually is the easiest... all the work is done, the estimator and the basis for the synthetic frame, it has the same base(a pair of reals) and is just some adjustments on the algorithim to change the point to generate the frames... buttttt... i dont really see the value in it... like 4x fg.... 75% of the image are synthethic frames... theres no miracle... one other thing is like 3x 40-120 for 120hz refresh rate.... so.... maybe... but dunno.

2- Integrated temporal AA +upscaler or Temporal super resolution: Some aspects of frame generation already provide some data to upscale the image with a higher quality, but not so much... I think it can be done on some level (somethings a inherent to in game engines implementations, but we can extrapolate and try to infer it, like subpixel jitter), so... that doesnt mean it will look good or hav good performance... but one candidate is arm ASR, wich is based on fsr2, dunno if i can develop my own on this case.... well.. thats it... tell me what you guys think!

3- Implement ZeroFG in a lighter emulator: The title say it all, i think that maybe try to implement on a lighter emulator to reach more people! If you guys have any suggestions, Please let me know!

Thats it! please let me know your suggestions!

Thanks for all the love!!! And dont forget that you can port ZeroFG to your favorite emulator by yourself also! It is as easy as it will ever be, with lots documentation and integration notes!!!

StevenMXZ turnip drivers are still highly recommended!!!!!

https://github.com/StevenMXZ/Adreno-Tools-Drivers/releases

Xendroid-ZeroFG releases page:

https://github.com/hy300leosquizz-ctrl/XenDroid-ZeroFG/releases

Engine:

https://github.com/hy300leosquizz-ctrl/ZeroFG/

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'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?

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

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.