Omnimaga
Calculator Community => HP Calculators => Topic started by: gigi1237 on May 08, 2017, 11:48:04 am
-
Hey guys, I'm new here. I've been working on an emulator for the HP Prime as to better understand how it's OS works and possibly develop something like ndless for the Prime. Right now the emulator it's in it's super early stages, no input, display or anything at all for that matter. Just some of the Prime's armfir.elf (the main OS file) code running and not yet doing aything useful.
I've approached the emulator from a relativley high level perspective. I'm not trying to emulate it at a hardware level and instead I'm emulating the systemcalls that the Prime makes. Right now I'm targeting the earliest public Prime OS available (20130808) as it contains the most debug info. All the code is hosted on Github https://github.com/Gigi1237/PrimeU . Check it out and hit me up if any of you would be interested in contributing. ;)
-
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 (https://www.winehq.org/about)). 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 (https://www.cemetech.net) 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 (https://github.com/Eeems) and I'll give it a once over the best I can.
-
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.
-
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 (https://www.winehq.org/about)). 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 (https://www.cemetech.net) 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 (https://github.com/Eeems) 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... :banghead:
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 haven't tried to create a hardware emulator yet, mostly because I'm thoroughly overworked with an internship, sysadmin freelance work and a GSoC student to mentor. I don't expect a saner workload until September. Also, my C++ is rusty and my knowledge of Qt is nil, even though Qt Creator looks slick as heck.
I did not attempt to use JTAG. I did all my debugging with the UART. I wrote a GDB stub to poke stuff around, but without interrupts it is rather limited.
About exam mode: unlike TI hardware, there is no root of trust inside the HP Prime hardware. You can always program whatever you want into the first 8 KiB of Flash and the S3C2416 will happily run it. While HP could introduce crypto checks and obfuscate things in an update, it's nothing some reverse-engineering and a soldering iron can't reverse. Fixing that hole for real would require at the very least a new hardware revision.
-
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.
-
I don't have access to my HP Prime right now, but I posted an UART dump here a long time ago : https://www.omnimaga.org/introduce-yourself!/hello-everybody-22224/msg403203/#msg403203. It was with an early version of my own firmware.
From memory, the HP Prime booting process has three stages :
- BXCBOOT0.BIN (the first 256 KiB of the NAND) : the first 8 KiB initializes the hardware and chainloads the rest of the stage, it also contains the recovery and the first splashscreen ;
- PRIME_OS.ROM (the next 1 MiB) : this is what Rip'Em replaces ;
- Either armfir.elf for the normal firmware, or the diagnostics utility.
An incomplete, reverse-engineered disassembly of the first 8 KiB of BXCBOOT0.BIN is available at https://tiplanet.org/hpwiki/index.php?title=BXCBOOT0.BIN_reverse_engineering, if that can be of help.
I can take a look at your sources if you want. I promise I won't judge :)
-
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 (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 (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.
-
I am glad to see Prime dev going on! I have just ordered a prime, and have the tools for jtagging. Once I get the prime, I'll have a look at stuff, and can maybe help get more things done.
-
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 (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 soonTM.
-
Here's the PRIME_OS.ROM of Rip'Em and the ELF programs, for testing on your side.
-
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. ;D ;D ;D
(http://i.imgur.com/CsxWqsG.png)
Edit (Eeems): Merged double post
-
So I took a quick look at your branch and I've already submitted a pull request (mostly just cleanups to make it work on my Linux box).
Soon I'll finally be able to work on Rip'Em without losing my sanity in the process. Yay! :w00t:
-
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. :banghead:
-
Rip'Em is a really, really simple piece of code, so it's fairly easy to make it run. It doesn't even uses interrupts or timers, it has effectively the equivalent complexity of a "Hello World!"-class program.
The official firmware is infinitely more sophisticated than that. There's much, much more going on inside a HP Prime than just a ARM9 core and a bunch of RAM.
-
Yep I'm perfectly aware of that. I initially thought it was because the interrupt controller was not working properly but that can't be the case because the boot process breaks before unmasking any interrupts. I for the life of me can't figure what unimplemented system is causing the failure to boot.
Debugging with gdb does not provide anything too useful as the fault occurs far from where the code hangs.
-
You can't emulate this at the system level without the various system call API.....where are you going to get that? I doubt if HP is just going to give it to you....
just curious...
Thx
-
We're emulating at a level much lower than the syscall level, we're emulating the hardware the syscalls run on.
-
You can't emulate this at the system level without the various system call API.....where are you going to get that? I doubt if HP is just going to give it to you....
just curious...
Thx
My original project was doing exactly this. The way I obtained the SysAPIs was by reverse engineering the calc's firmware. So no need for HP to hand them over.
The new project is a hardware level emulator.
-
Ah, OK, because in an earlier post, it was stated that it wasn't going to be a hardware emulator, but a syscall level emulator. That makes more sense. Emulating the hardware allows the system rom file to be used.....makes much more sense...
Thks
-D
-
I've been bashing my head on the emulator. I've narrowed down the biggest issue at the moment being memory allocation being incorrect. Does anyone know exacly how the RAM/SRAM is mapped on the Prime? Because if I allocate 32mb at 0x30000000 the prime tries reading and writing above that too, even though it correctly detects the amount on memory in the UART output logs.
-
It's been way too long (NumWorks is kinda distracting me these days), but there should be 32 MiB at 0x30000000 and 64 KiB at 0x0. The DRAM controller can map up to 128 MiB of memory.
Not sure why the official firmware would want to poke beyond 0x32000000. It could be memory prodding/detection (unlikely), GPIO/hardware registers not having the right values or plain old sloppiness. I can poke memory around with the Rip'Em GDB stub over serial if you need.
-
My best best is something being wonky in the DRAM configuration registers. Right now I'm initializing the values to the defaults found in the s3c2416 manual, these might be incorrect for the prime or even plain wrong in general (its happened already).
If you could poke around and dump the values of the registers relating to memory you'd do me a huge favor. At the moment I've got no way to use the GDB stub on my Prime. :-\
-
I checked and I have everything at hand in my flat. I'll perform the hex dumps tomorrow.
-
Took a bit longer to set up everything once again than expected, but here it goes :
# DRAM Controller
(gdb) x/8xw 0x48000000
0x48000000: 0x0004890d 0x44000050 0x0099003f 0x80000033
0x48000010: 0x00000405 0x00000000 0x00000000 0x00000000
0x48000020: 0x00000000 0x00000000 0x00000000 0x00000000
0x48000030: 0x00000000 0x00000000 0x00000000 0x00000000
# Matrix & EBI
(gdb) x/16xw 0x4E800000
0x4e800000: 0x00000004 0x00000004 0x00000004 0x00000000
0x4e800010: 0x00000004 0x00000004 0x00000004 0x00000000
0x4e800020: 0x00000004 0x00000004 0x00000004 0x00000000
0x4e800030: 0x00000004 0x00000004 0x00000004 0x00000000
# Memory Controllers ( SSMC )
(gdb) x/64xw 0x4F000000
0x4f000000: 0x0000000f 0x0000001f 0x0000001f 0x00000002
0x4f000010: 0x00000002 0x00303000 0x00000000 0x0000001f
0x4f000020: 0x0000000f 0x0000001f 0x0000001f 0x00000002
0x4f000030: 0x00000002 0x00303000 0x00000000 0x0000001f
(gdb) x/8xw 0x4F000100
0x4f000100: 0x00000000 0x0000001f 0x0000001f 0x0000001f
0x4f000110: 0x0000001f 0x0000001f 0x0000001f 0x0000001f
(gdb) x/8xw 0x4F000200
0x4f000200: 0x00000000 0x00000003 0x00000000 0x0000000a
0x4f000210: 0x00000000 0x00000000 0x00000000 0x00000000
# Interrupt controller
(gdb) x/16xw 0x4A000000
0x4a000000: 0x00004004 0x00000000 0xffffffff 0x00000000
0x4a000010: 0x00000000 0x00000000 0x00010003 0x1fffffff
0x4a000020: 0x00000000 0x00000000 0x00000000 0x00000000
0x4a000030: 0x00000000 0x0000007f 0xdeadcafe 0xdeadcafe
# System controller
(gdb) x/16xw 0x4C000000
0x4c000000: 0x0000ffff 0x0000ffff 0x00008000 0xdeaddead
0x4c000010: 0x80640061 0xdeaddead 0x01200102 0x00000000
0x4c000020: 0x00000118 0x0000022d 0x00000000 0x00000000
0x4c000030: 0xffffffff 0xffffffbf 0xffff9fff 0xdeaddead
# I/O ports
(gdb) x/72xw 0x56000000
0x56000000: 0x005e0000 0x00007000 0x00000000 0x00000000
0x56000010: 0x00141016 0x000003ea 0x00000950 0x00000000
0x56000020: 0xaaaa56aa 0x000000b0 0x00000000 0x00000000
0x56000030: 0xaaaa5555 0x00000080 0x00000000 0x00000000
0x56000040: 0xa0000000 0x0000c000 0x05555555 0x00000000
0x56000050: 0x000061a1 0x0000007d 0x00000404 0x00000000
0x56000060: 0x00000000 0x0000ff00 0x00005555 0x00000000
0x56000070: 0x1400150a 0x00000062 0x01554050 0x00000000
0x56000080: 0xd0000020 0x00000000 0x00000000 0x00000000
0x56000090: 0x00000000 0x00000000 0x00000000 0x00000000
0x560000a0: 0x00000000 0x00fffff0 0x00000040 0x0000000f
0x560000b0: 0x32450003 0x00000000 0x00000000 0x00000000
0x560000c0: 0x2aaaaaaa 0x0aaaaaaa 0x0aa8aaaa 0x00000000
0x560000d0: 0x00000000 0x00000000 0x55555555 0x00000000
0x560000e0: 0xaaaaaaaa 0x00000000 0x55555555 0x00000000
0x560000f0: 0x04050055 0x00007cf0 0x00050055 0x00000000
0x56000100: 0x00000008 0x00000003 0x00000000 0x00000000
0x56000110: 0x000002aa 0x00411540 0x05451500 0x00ff0000
-
Hey guys, just a quick update. I recently tinkered with the emulator a bit more and finally got the original prime OS to boot :w00t: :w00t:
(https://i.imgur.com/S6E6Qot.png)
I'm using a flash dump done through jtag to boot from posted on one of the formus, don't remeber which. I tried to manually make flash images from the update files but none of them seem to work so far. Still this is good progress. Although everything is just mostly a massive hack at this point. The next challenge will be getting the touch input working. This won't be easy at all since the nt11002 touch controller chip appears to be undocumented except for a few source files for linux drivers. :mad: :banghead:
-
Impressive!
I think really old firmwares don't have the slide-to-unlock at first boot. Might be worth trying one out, I vaguely recall the flash having the following layout: BXCBOOT0.BIN (256KiB) | PRIME_OS.ROM (1MiB) | PRIME_MASTER.DAT (4MiB) | PRIME_APP.DAT (32MiB) | data (remainder). Perhaps you can double-check with your existing image if this matches?
Does the diagnostics tool (C-F-O) work? It's likely to be useful for troubleshooting/reverse-engineering, there's test modes for the touch screen.
I'm not tooled for bus sniffing unfortunately, but maybe I can jury-rig something with a Raspberry Pi. Not going to happen right now though, I'm on vacation and I left my equipment behind...
-
So I managed to get ahold of the NT11002 datasheet. Sadly it contains nothing particularly useful. Most of the functionality is determined by the firmware as it's basically a 8051-compatible processor. So I guess we should try to get a dump of the firmware on the prime. There might be something in the update images, if the driver is anything like the linux one, which basically tries to perform a firmware update everytime it intializes the NT11002.
For the images I tried to build them by appending the files in the order you mentioned, one after the other and then using truncate to get the image to 256Megs. Which matches the image I have. But the image refused to boot. So either I appended in the wrong order, different versions don't work or there is other data beyond that supplied in the firmware updates.
I was also unable to get into the diagnostic tool. SInce it requires the reset button to be pressed and the emulator does not implement that yet. This, along with implementing touch and getting video to be more stable should be the two main priorities for the emulator right now.
Edit:
I managed to dump the Touch controller's firmware from the diagnostic utility executable. The challenge will be analyzing it now. If anyone is interested PM me and ill send you a copy.
-
I'm not sure doing a low-level emulation of the NT 11002 is the way to go. I believe a high-level emulation of the I2C protocol and not worry about reverse-engineering+emulating a whole MCU would be simpler.
I got a bunch of old firmware update files from educalc.net and I managed to launch them, only to quickly get stuck on a HP logo inside what appears to be PRIME_OS.ROM. Firmwares 20130808 and 20130813 have egregious amounts of logging on the UART which could prove useful (after cleaning up garbage):
Run>
Init 320x240
Init 320x240 rVIDCON0=0x5270
320x240 rVIDTCON0=0x110300 rVIDTCON1=0x401100 rVIDTCON2=0x7793f rVIDCON1=0x80
ARMCLK:400000000
HCLK : 133333333
PCLK : 66666666
nandid: ec da 10 95 44
InitBfsHeader...
nandid: ec da 10 95 44
block size:0x20000 page size :0x800 Attr:1c03110b NandSize:256(MB)
read header...ok
has BFS header
[00][01]
BFS End.
1ram size :32MB
rBANKCFG:4890d
CodeEntry:0x30000020
CodeLoadeAddress:0x30000000
CodeLoadSize:0x100000
CodeEntry:0x30000020
CodeLoadeAddress:0x30000000
CodeLoadSize:0x100000
MPLL : 800000000
CLK : 400000000 (400 MHz)
HCLK : 133333333
PCLK : 66666666
ARMCLKDIV : 1
HCLKDIV : 1
PCLKDIV : 1
Nand0ID = EC DA 10 95 44
Nand0Attr = 51c110b
Nand0Sz = 256 (MB)
[BFS][0] table items = 2048
[BFS][SetupCorrectTable] wTableItemSum = 2048
Nand1ID =
Nand1 not exist!
CODE INFORMATION 1
ARCH: V5J, CPU: 2416
CMV: 0
CURRENT RUNNING CODE
ARCH: V5J, CPU: 2416
CMV: 0
Data0: 00000000 01000000 / 00000000 00400000
nDataInNand0Size=00000000 00500000
finding appsdisk(00000000 00500000)...
Data1: 00000000 02000000 / 00000000 02000000
NandChipNum =1
CodeSz =00100000
Data0Sz =00000000 00400000
ApDskSz =00000000 02000000
ApDskInNand0 =00000000 02000000
TotalSz =00000000 02500000
Unlcok area: 4a00 ~ 20000
SetVRAMAddress=31e80000
UsbVBusInit
[INFO] makedata version=20090828
[INFO] makedata version=20090828
This system don't support hardware 2D accelerate!!!
kv= 0
[ARCH] id=32450003
[ARCH] name=S3C2450
[ARCH] interface=000000F5
UsbHostVbusInit DEV_CONNECTkv= 0
startblock: 139
endblock: 7c7
startblock: 139
endblock: 7c7
[NAND Scan]Block size:0x 0 20000
[NAND Scan]Page size:0x 0 800
[NAND Scan]OOB size:0x 40
[NAND Scan]Scan start addr:0x 0 2720000
[NAND Scan]Scan end addr:0x 0 f8e0000
NAND Scan Start!
Firmwares 20130813 onwards show a subliminal message ("Firmware verification in progress. HP Prime will automatically continue when the operation is completed. This may take up to 1 minute").
I used the following to get these images: cat BXCBOOT0.BIN BESTAARM.ROM MASTER.DAT APPSDISK.DAT > dat.raw && dd if=/dev/zero of=dat.raw count=1 bs=1 seek=$((256*1024*1024-1))
-
Apologies, I forgot to commit the last changes to github so you were still running and old version of qemu. Nonetheless, I tried making images that way and I get the same result as yours. I think the problem is that they are missing something that is not included in the update files. The dumped image I have confirms it. Try to boot with it: http://bit.ly/1z6jv9B (http://bit.ly/1z6jv9B), you should get to where I got in the screenshot.
I also was not planning of low level emulating the nt11002, but I think the firmware could provide us with good information about the i2c protocol it uses.
Do you happen to know on what pin is the reset switch on the prime?
-
By combining the data part of your image with the firmware bits of an old update file I got something that booted to this:
(https://i.imgur.com/wuPdq6u.png)
$ dd if=flash_dump of=dat.raw bs=1024 skip=$((256+1024+4096+32768)) seek=$((256+1024+4096+32768))
It's not responding to the keyboard and the clock on the upper right is hung. The firmware doesn't seem to be hung after a quick look with GDB, but obviously something prevents it from fully ticking. The UART has a whole bunch of yaffs logs, I assume the firmware got stuck because homemade images don't have a yaffs filesystem. I do wonder if the "Format Disk C" option in the diagnostic tools would've fixed that.
Do you happen to know on what pin is the reset switch on the prime?
I assume nRESET. I remember being able to boot the calculator straight into recovery mode by holding the SYMB button down and hooking an USB cable without the battery, so I would expect to be able to drop into the diagnostic tools by holding down C-F-O the same way.
With the emulator, I seem to be able to drop into the recovery (which just hangs with a black screen), but not into the diagnostics program. Odd...
-
Tried pressing C-F-O on my calc while powering up from usb, no dice. Needs to press the reset button. Would you be able to implement it in qemu? So we can then get into the diag utility.
The recovery doesn't work because it sets up the graphics buffer in a different way, one that isn't really supported by the datasheet. I'll try to implement that mode too soon.
-
I tried prodding the obvious (GPIO data registers, RSTSTAT) with no results. I'll need to take a closer look at the reset circuit on the hardware and see if I can spot something of interest (once I'm back from vacation 'cause I left the calculator back in my flat). Depending on how HP implemented the C-F-O thing, this may end up being a royal pain to figure out.
-
(https://i.imgur.com/ImFgZvS.png)
Turns out there's an easy way to trigger the diagnostics tool: replace the FirstRunApp key value inside FIRSTRUN.INI with \\.\DIAGNOSE.ROM. This file is located inside the PRIME_APP.DAT's FAT32 partition, offset 8192 bytes.
Still no response to keyboard input. The firmware doesn't seem to scan the keypad matrix once booted.
-
Sweet, great solution! I theorize lack of input is probably due to a missing external interrupt triggered by keypresses.
-
I checked and input is definitley not interrupt based. Looking at the BESTAARM code it appears that it runs in a separate thread. I think this is the problem, thread scheduling is likley based on on of the internal timers (likley timer2 as it is the only unmasked one), the RTC tick timer does not appear to be relevant to this. The thing is that the current exynos implementation is broken and the timers are not firing. I tried to fix it but it appears they're still not working. I'll commit it to github in a few hours, could you take a look at it boricj?
Edit: I'm a dumbass I never actually tired to fix the timers, just the RTC tick. So yeah... Ignore that
-
Well I was a bit bored for the past week so I took another stab at the emulator and finally got it mostly working(tm) :w00t::w00t:
(https://i.imgur.com/aolOlSy.png)
And by mostly working I mean it can run the official firmware (version 20130808) relatively well, you can interact with is and most functionality is working, although there is no touch support
whatsoever yet. There is also no GUI keyboard so we have to use the keyboard's physical keys to control it and the key bindings are quite weird. RTC is also not fully working either.
There are also some small screen refresh issues but nothing too serious. Here's a little demo video https://gfycat.com/LikelyDecisiveKite (https://gfycat.com/LikelyDecisiveKite).
-
Oh, nice work! I wish I knew the HP Prime better so that I could offer some real input :P
-
Any news with this project?