G2 Emulator

[muteki]

(09-16-2022 07:13 PM)Jean-Baptiste Boric Wrote:  

(09-15-2022 06:12 PM)muteki Wrote:  I'd suggest to base the effort on Unicorn. It tries to provide a stable "scripting" API for QEMU which could slow down code rot especially after the project went into maintenance mode, and it also has bindings for other easier-to-develop-for languages (namely rust in this case).

That depends on what the end goal is. If I were to eventually upstream the machine emulator code to QEMU then there aren't a lot of options but to work within QEMU's codebase.

I've never worked with Unicorn, but I do understand the appeal given QEMU's... smelly innards. I've managed to figure out enough of it on my own to hack together machine emulators and peripherals without making a mess in the process, but that was not for the faint of heart. That being said, QEMU does offer a fully-featured machine emulation framework, whereas Unicorn does not. I'd expect Unicorn to be much easier to start with, but to also require a lot more work to get a fully-featured emulator out of it.

Yes, Unicorn is more bare compare to qemu(-system) because it's a CPU and not a platform emulator by design, but a lot of the "extra works" associated should be one time. Also these "extra works" might simplify the development in the later stage when deeper customization is needed (especially when you consider the possibility of mainlining the work).

Want 2 screens instead of one? Add another rendering surface on the GUI. Want an on-screen keyboard? Just add it, even make it skinnable by target. Want to have FTDI integration so you can talk to real devices (for easier reverse engineering, etc.)? Include libftdi and write some glue logic. However if you have any of these in QEMU it would be a huge s***storm to get it mainlined because "does not meet standard" and stuff.