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.

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.

I thought I had written another reply before but I'm either crazy or it somehow got deleted.

Anyway I've attempted to hack up something with qemu. Figured out how it works, kind of and got to the point of having most of the first stage bootloader run, reading the rest from NAND and finally starting the os I assume (don't remember the exact address it hands off execution to). It's also throwing the usual uart startup output at me. But it's crashing somewhere after that and I haven't been able to figure out why yet.

Do you happen to have a UART dump from the prime? The output it gives at startup, as I have no ability to grab it for myself right now. So I can compare it to the output I'm getting.

Also I haven't posted the source yet because it's so bad I'm embarrassed about it  If you're interested I can do it anyway though. 

Thanks for giving the link to the UART log, it was helpful. The output qemu is giving me is slightly different: https://gist.github.com/Gigi1237/0a5c3bd41f53bea14434c6673e6f0cbf#file-gistfile1-txt. Mainly becaus it spams me with "B"s right after printing start. I haven't figured out why yet though. Probably some mistake in the UART implementation.

I also uploaded my qemu branch to github: https://github.com/Gigi1237/qemu I'd be very glad if you could check it out. Mainly the s3c2416.c file, as i generated the rest automatically from the datasheet (except s3c2416_lcd.c). I'd be very happy to have some feedback especially if you spot any mistakes. Keep in mind the code is literally hacked together at the moment. I've done many things I shouldn't have as I was just basically playing around to see if I could get anything working. Most things are not even close to functional and I wasn't even following any coding convention although I should have been. If you feel like it, you could contribute and send a pull request, but I know you're busy.

Right now I'm a bit stuck with it, don't really know what exactly to do next to get it working. I'm especially in a hard spot because I don't have acess to my IDA Pro databases of both the OS and the bootloader which would help a ton with debugging at this stage.

Thanks for giving the link to the UART log, it was helpful. The output qemu is giving me is slightly different: https://gist.github.com/Gigi1237/0a5c3bd41f53bea14434c6673e6f0cbf#file-gistfile1-txt. Mainly becaus it spams me with "B"s right after printing start. I haven't figured out why yet though. Probably some mistake in the UART implementation.

Wow, you've reached PRIME_OS.ROM, that's impressive! That means the first stage of the bootloader actually worked.

Right now I'm a bit stuck with it, don't really know what exactly to do next to get it working. I'm especially in a hard spot because I don't have acess to my IDA Pro databases of both the OS and the bootloader which would help a ton with debugging at this stage.

I would try to make Rip'Em work. Since it's vastly simpler and the source code is available (unlike the official firmware), figuring out why stuff is not working should be much easier. Next goal would be the diagnostics utility.

Today is the last day of my internship, so I'll be able to take a closer look at your QEMU tree real soon^TM.

Thank you very much. I'll try to get it running in qemu now

---

Just a little update. Got ripem to run! No functionality yet as GPIO is not implemented yet but it's giving me correct graphical ouput. 



_{Edit (Eeems): Merged double post}

Great changes, nice idea of using the exynos uart. It appears to be similar (identical?).

But I'm still stuck as to why the original prime_rom won't boot. I'm really at a loss.