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

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/

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.

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.