hey kinda forgot about this post and the forum. Anyways i've been busy so I had not time to work on aything HP prime related.

If you aren't actually emulating the hardware but just the system calls I'd describe your projects more as a compatibility layer (like Wine). If I had time I'd be interested in helping even though I don't have an HP Prime.

You may also want to cross-post this on Cemetech as they have more c++ developers over there.

That said if you need help with higher level planning or want someone to go over your designs and give feedback feel free to post about it here, or to tag me in the github issue/pr and I'll give it a once over the best I can.

You're absoloutley right it's absoloutley a compatibility layer. I just decided to call it emulator because there is actual CPU instructuor emulation going on, unlike wine which does not allow cross arch executables. I opted to go for a compatbility layer as I was interested in the inner workings of armfir.elf and wanted some way to debug it without using jtag. Considering the limited (~300) number of syscalls armfir makes this sounded like a much better idea compared to a full blown hardware emulator.

I hadn't though of Cemetech though iirc I did cross-post to another forum, now if I only remembered which... 

Thanks for the offer, some feedback could definetley come in useful as I'm quite new at this.

I'm the author of Rip'em, one (the only?) third-party firmware for the HP Prime. My efforts stalled when flashing the calculator under Windows over and over got really old, so I am interested in a HP Prime hardware emulator. It's been a while, but I'm still probably the guy most familiar with the HP Prime hardware outside of HP.

I did not attempt to write an emulator earlier because I'm not motivated enough to make one from scratch and QEMU's source code gives me headaches. However, I've discovered the Unicorn CPU emulator by browsing your source code. That might be enough to get me started.

While I'm here: as soon as someone circumvents the exam mode, you can bet HP will lock down the bootloader in the next firmware version to put a stop to that. Please don't nuke exam mode, whether directly or indirectly.

I tested out your firmware and found it quite interesting, albeit it was not what I was interested in. But nonetheless a hardware emulator would benefit me as much, if not more than what I was currently creating. One question, were you ever able to debug the code running on the calc itself? Whether JTAG or something similar.

You're right about qemu being a massive headache, I to build on that initially but just found the source too incomprehensible and time consuming to edit. Even if theoretically it would be perfect for a hardware emulator.  Did you end up starting with a Unicorn-engine based emulator? If you have I'd be more than glad to take a look and possibly contribute.

Also you're absoloutley right about exam mode. I was intending to stay as far away from that as possible to not have any issues. But nonetheless from my understaing of the Prime's firmware it feels like it would be extremley hard to lock it down anywhere as tighlty as the nspire, it has no built in encryption capability and all it's memory can be written to so even if HP would decide to lock it down (hopefully thid does not happen ever) it'd be quite easy to circumvent, even if just by overwriting the key they'd use to sign their firmware. Am I completley wrong here? All my knowledge of embeded devices and calculators come from reverse engeneering and a minimal amount of google.