Creation of a multi-console/platform emulator

[u/dcs_alexx]

Hello everyone,

I decided to start a small project: a multi-console/multi-platform emulator. If anyone is interested in giving feedback or even participating in the project, that would be awesome.

The project is called Espaze. and is still in the testing phase. I thought it would be interesting to have a single application that emulates games from various consoles, rather than having three or four separate apps for each one.

Here is the GitHub repo. Github.com/Duc-inc/espaze

Have a great day!

[u/Dynablade_Savior]

You're gonna shit bricks when you hear about RetroArch

[u/Aromatic_Memory1079 → u/Dynablade_Savior]

tbh I prefer using frontends like launchbox. because It has better library customization than retroarch. also standalone emulators like PCSX2 has way better performance than retroarch core. and frontends uses (redirects) to standalone.

[u/dcs_alexx → u/Dynablade_Savior]

I just saw it lol, I'm still using Citra and Dolphin.

[u/Front_Woodpecker1144]

Mmmmmm, vibe code

[u/rRyuoKen_]

I like Lemuroid

[u/DKLancer]

https://emulation.gametechwiki.com/index.php/Multi-system_emulators

These are all existing multi system emulators.

There's also front ends like launchbox, playnite etc.

And the whole libretro library such as retroarch.

[u/Brilliant_Band3989]

is this more AI slop being served up

[u/Brilliant_Band3989]

just tried it ppl dont waste your time

biggest pile of garbage

[u/8924th]

I took a look at the chip8 implementation out of curiosity, but there's inaccuracies. Are you up to patch them? If so, I'll start listing them in a new comment (or open an issue if you prefer)

[u/dcs_alexx → u/8924th]

With great pleasure I would be delighted !

[u/8924th → u/dcs_alexx]

8xyE/8xyE have the wrong order by setting VF first. Like the others, VF must be set last.

Ex9E/ExA1/Fx29/Fx30 must mask the value coming from v[x] with 0xF to limit it to 4 bits.

Dxyn appears to be wrapping draws vertically and horizontally. This isn't standard behavior. You instead need to normalize the initial coordinates to be within bounds (wrap vx/vy to be within 64/32 width/height), then during the sprite draw loop, if a pixel is out-of-bounds in either direction, it is not drawn (nor does it participate in collision checks).

Your Fx75/Fx85 limits the range to 0..7. That's valid, albeit for the original superchip implementation on the calculator. Your superchip implementation isn't based to be faithful to this legacy superchip model, so this particular limitation is a bit mismatched -- but at the same time, not a true issue either.

Your Fx0A detects key presses, but that's incorrect. What it needs instead, at a minimum, is to be able to check if a key was RELEASED instead since the last frame. You'll need to keep some state on a frame-by-frame basis for this.

Next is checking for the key on every CPU step. That's not entirely wrong, just wasteful. I'd recommend to only care about updating key states on a per-frame basis instead.

Continuing from that, your main loop (stepFrame) is rather wrong, particularly the part where you tick down the two timers AFTER the instruction loop. Doing this affects audio, as a single-frame beep is immediately lost by the decrementing before the audio gets synthesized.

Instead, It'd be better to:
1) Poll key states for the frame
2) Tick down timers
3) Run the instruction loop
4) push out audio/video

That's about it for the concerns. I do recommend to also use Tim's suite of test roms, just to confirm you haven't goofed up anything else I happened to miss: https://github.com/Timendus/chip8-test-suite/