Forum TI-Planet.org

Dans un article précédent, nous vous présentions en vidéo le firmware tiers de Jean-Baptiste Boric pour calculatrice HP-Prime.

Ce firmware ne faisait pas grand chose et n'allumait même pas l'écran, mais il n'empêche qu'il démontrait quand même un contrôle total sur le matériel en étant capable d'allumer les diodes examen, composants censés être les plus critiques de la machine et donc les plus sécurisés !

Mais depuis il a évolué, est capable d'afficher sur l'écran et commence même à gérer les touches clavier !

Pour le plaisir, voici donc l'installation et le lancement en vidéo de la toute dernière version de ce firmware :


A bientôt !


Source + téléchargement : https://github.com/boricj/ripem

Great,
What is the next progress of project?

compsystems wrote:Great,
What is the next progress of project?

I haven't worked on it since I'm too busy at school at the moment, but here's the overly optimistic roadmap.

Short-term goals include :

• figuring out the rest of the hardware,
• porting a proper GDB stub,
• carrying more than one payload and having a menu to select which one to launch.

Long-term goals (a.k.a pipe dreams) include :

• launching payloads from NAND,
• launching payloads from USB Mass Storage,
• GDB stub over USB.

Long-term goals will probably require porting a real time operating system (RTOS) beforehand.

Ridiculously long-term goals include :

• porting NetBSD.

However, since I'm the only guy working on this, even clearing the short-term goals would probably take an infinite amount of time (procrastinating is one of my many weaknesses). As native development on the HP Prime requires ripping open said calculator and soldering a few wires to access the UART (hence the code name Rip'em), I expect to remain the only guy working on this for a very, very long time...

wish a C compiler and python interpreter or at least one QBASIC interpreter

> .. As native development on the HP Prime requires ripping open said calculator and soldering a few wires to access the UART
>> please can include images of pin RS232 connection

Thanks

- C compiler: same issue as on the Nspire: you'd need to port a compiler to this device/ARM, and the RAM is low...
- Python interpreter: once some console I/O lib has been done, probably MicroPython can be ported as it was done on the Nspire
- QBasic : don't know about this one, but probably the same sentence as the python interpreter applies

compsystems wrote:> .. As native development on the HP Prime requires ripping open said calculator and soldering a few wires to access the UART
>> please can include images of pin RS232 connection

Thanks

The pads (UART_RX, UART_TX) are labeled on the motherboard, BAT- can be used for ground. On the revision A hardware they are located to the right of the SoC chip, on the revision C hardware they are located above the NAND chip.

Unfortunately I kinda sprayed hot glue all over the place to prevent the wires from ripping out the pads, so aside from a big patch of glue you wouldn't see much. If you have trouble finding the pads, let me know which revision hardware you have. If it's revision A I can highlight the pads on a picture from the web ; if it's revision C I'll need you to post a picture of your motherboard since I can't find one on the web.

Also, please take note that this is not RS232, it's 3.3v TTL. You'll fry the UART and possibly more if you directly hook up a PC serial port to the HP Prime.

Adriweb wrote:- C compiler: same issue as on the Nspire: you'd need to port a compiler to this device/ARM, and the RAM is low...
- Python interpreter: once some console I/O lib has been done, probably MicroPython can be ported as it was done on the Nspire
- QBasic : don't know about this one, but probably the same sentence as the python interpreter applies

Any of which would at least require porting a real-time operating system and figuring out the hardware. I wouldn't hold my breath waiting for a homebrew port of Lua on the HP Prime.

Though I guess TCC or PCC could fit in 32 MiB of RAM.

jean-baptiste boric wrote:

compsystems wrote:if it's revision C I'll need you to post a picture of your motherboard since I can't find one on the web.

Here are some HW-C pictures :

Here are the locations of the UART pads.

HW-A :



HW-C :

A GDBstub over USB would make it easier for developers to start fiddling, and seems therefore higher priority to me than a menu for choosing the payload... but as you wrote, achieving the aim of a GDBstub over USB is easier with a RTOS...

I had gathered several links about emulation at https://tiplanet.org/hpwiki/index.php?t ... /Emulation .