G2 Emulator

[devin122]

For the past couple weeks I've been working on emulating the g2 hardware, and I've finally made it to the point where I am making visible progress (although still plenty of things are still unimplemented and/or buggy). If there is any interest from the community I can work to make the code a bit more presentable and make it available.

[toml_12953]

(09-15-2022 05:21 AM)devin122 Wrote:  For the past couple weeks I've been working on emulating the g2 hardware, and I've finally made it to the point where I am making visible progress (although still plenty of things are still unimplemented and/or buggy). If there is any interest from the community I can work to make the code a bit more presentable and make it available.

What will this do that the HP Prime Virtual Calculator doesn't already do? Is it really an advantage for Prime users to emulate the hardware? I'm not trying to be facetious or knock all your hard work. I'd really like to know.

[Jean-Baptiste Boric]

(09-15-2022 09:19 AM)toml_12953 Wrote:  What will this do that the HP Prime Virtual Calculator doesn't already do? Is it really an advantage for Prime users to emulate the hardware? I'm not trying to be facetious or knock all your hard work. I'd really like to know.

There are several practical reasons besides plain ol' fun. That being said, given the availability of the HP Prime Virtual Calculator and the lack of native third-party applications support, this is not something that most casual users will care about, unlike a TI-83 Premium CE emulator for example. As-is, I expect that this will be useful mostly for people that either port third-party operating systems to the HP Prime G2, develop firmware for it (whether official or third-party) or want to reverse-engineer the calculator.

Maybe if you want to develop HP PPL or Python programs on a computer, but with an accurate simulation of the physical calculator's memory, storage and speed constraints (if the emulator is accurate enough) would a "vanilla" user want to use this, but that's stretching it a bit.

This reminds me of the QEMU-based HP Prime G1 I used to co-develop (https://github.com/opcod3/qemuPrime). IIRC it could run the official firmware, but the biggest issue was the undocumented, proprietary touch chip. Kinda hard to pass the unlock widget on first boot without that, although very early alpha releases lacked it.

[devin122]

(09-15-2022 09:19 AM)toml_12953 Wrote:  What will this do that the HP Prime Virtual Calculator doesn't already do? Is it really an advantage for Prime users to emulate the hardware? I'm not trying to be facetious or knock all your hard work. I'd really like to know.

For regular users, it really doesn't have much if any use. I'm developing it to assist with native development and reverse engineering firmware.

(09-15-2022 10:35 AM)Jean-Baptiste Boric Wrote:  This reminds me of the QEMU-based HP Prime G1 I used to co-develop (https://github.com/opcod3/qemuPrime). IIRC it could run the official firmware, but the biggest issue was the undocumented, proprietary touch chip. Kinda hard to pass the unlock widget on first boot without that, although very early alpha releases lacked it.

Indeed I did use qemuPrime as a reference for the keyboard driver. As for the touchscreen controller, fortunately the one on the G2 is documented, so that makes things significantly easier

[muteki]

(09-15-2022 10:35 AM)Jean-Baptiste Boric Wrote:  This reminds me of the QEMU-based HP Prime G1 I used to co-develop (https://github.com/opcod3/qemuPrime). IIRC it could run the official firmware, but the biggest issue was the undocumented, proprietary touch chip. Kinda hard to pass the unlock widget on first boot without that, although very early alpha releases lacked it.

I'd assume that they would reuse the same digitizer as G1 in G2? Quick and dirty Google search suggests that G2 uses a Goodix GT5688 which is pretty well documented and has Linux driver support.

[Jean-Baptiste Boric]

(09-15-2022 02:32 PM)devin122 Wrote:  Indeed I did use qemuPrime as a reference for the keyboard driver. As for the touchscreen controller, fortunately the one on the G2 is documented, so that makes things significantly easier

Hmm... I've also bootstrapped a QEMU-based emulator for the NumWorks series of calculators (https://github.com/RedGl0w/numworks-qemu) and I'm aware of one fork based on that one for emulating the Zero series of calculators.

Maybe there's room for some cooperation amongst all of this parallel work. The home communities of these efforts are respectively the Discord channels of Omega (fork of Numworks' epsilon firmware) and TI-Planet, if you're interested.

[muteki]

(09-15-2022 05:03 PM)Jean-Baptiste Boric Wrote:  

(09-15-2022 02:32 PM)devin122 Wrote:  Indeed I did use qemuPrime as a reference for the keyboard driver. As for the touchscreen controller, fortunately the one on the G2 is documented, so that makes things significantly easier

Hmm... I've also bootstrapped a QEMU-based emulator for the NumWorks series of calculators (https://github.com/RedGl0w/numworks-qemu) and I'm aware of one fork based on that one for emulating the Zero series of calculators.

Maybe there's room for some cooperation amongst all of this parallel work. The home communities of these efforts are respectively the Discord channels of Omega (fork of Numworks' epsilon firmware) and TI-Planet, if you're interested.

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).

[Liamtoh Resu]

It would be nice to have a G2 emulator for wintel Linux distributed as a debian and rpm packages.

Updates for the current windows emulator have involved unilaterally upgrading Window$ from
windows 7 to 10. Some of us use offline versions of win7 boxes. Additionally I had to
change one of the security settings of windows in order for the emulator to work.
See references to "could not initiate application" in previous forum entries.

here's a link:

"https://www.hpmuseum.org/forum/post-111574.html"

[Jean-Baptiste Boric]

(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.

[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.

[devin122]

(09-16-2022 07:13 PM)Jean-Baptiste Boric Wrote:  I've never worked with Unicorn, but I do understand the appeal given QEMU's... smelly innards.

Honestly I dont find the qemu code base that bad, or at least not really much worse than any other C codebase of similar age + size. What I find worst about it is really the lack of documentation on the various subsystems. Once you kinda figure them out its not so bad.

(09-18-2022 02:58 PM)muteki Wrote:  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).

I feel like once you have implemented a device emulation framework, you have basically just re-invented qemu. Also that's quite alot of stuff to implement, that I'm not particularly interested in. At the moment I don't really have any code that couldn't be unstreamed into qemu, however the general plan is to keep it in a form that's reasonably maintainable as a patch on qemu

(09-15-2022 05:03 PM)Jean-Baptiste Boric Wrote:  Maybe there's room for some cooperation amongst all of this parallel work.

I'm definitely open to cooperation, but I'm not sure how much overlap there really is among the various projects. Although having a shared frontend to qemu more tailored to calculators would be useful.

[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.

Speaking of code rot: The G1 emulator on GitHub is already not buildable and nothing is upstreamed. That's exactly why I would stay away from downstreaming a huge project like QEMU or GCC unless I'm sure that I will constantly working on it. Once the plug is pulled it's dead after a few years or even months.