C compiler

[webmasterpdx]

I just managed to get a version of MINGW gcc tools working for the ARM926EJ-S chip working. This is the CPU in the Prime.
I was wondering, does anyone have a memory map for the PRIME and the OS? If so, I can try to get a useful C compiler working for it.
It'll be a while yet as I've only just managed to get Hello World to compile and generate assembler and .o files.
It's not going to be useful unless we have a memory map.
If I can get that, then I can work on it when I get a chance....will probably take me a few months to get working properly.
Note that it'll both support C and C++.

Once that is done, it might be possible to support the other gnu compiler tools too (I'm thinking mostly java, and Objective C...for apple users). Note that our CPU supports Jazelle (runs java bytecodes in hardware).

Thanks

[debrouxl]

Quote:I was wondering, does anyone have a memory map for the PRIME and the OS?

Not a full memory map, but most of it is in the S3C2416 datasheet anyway.
Gathering full memory map information may work from inside a full-custom third-party firmware, and getting it out of the calculator is best done through either the RS232 TTL port or one's own character drawing routines.
Custom third-party firmware in armfir.elf does not run entirely bare metal, as evidenced by the fact there's still some base code running at a deeper layer, which enables one to turn the calculator off and on (but lose display contents).

Quote:Note that our CPU supports Jazelle (runs java bytecodes in hardware).

AFAICT, Jazelle is largely undocumented, and therefore unused on most ARM926EJ-S platforms in the real world. On the TI-Nspire, which also uses an ARM926EJ-S, Jazelle support was never used beyond a test program which confirms that the CPU actually supports Jazelle, as indicated by the CPU flags.

[webmasterpdx]

I'm thinking more the OS memory map....not the hardware memory map. The hardware memory map can be obtained from the Core spec sure, but the OS memory map is HP's....like how are matrices stored or how to get at a spreadsheet cell from C.
I'm not thinking of producing custom OS (though you could run linux on it).
If I wanted linux, I could buy a C.H.I.P. board for $9 with wifi, bluetooth, running at 1GHz and it already has linux running on it.
I want a super math machine. I've done programming on TI calculators in the past and ran into problems with them not running fast enough. I was able to speed them up by using vector operations by adding lists of numbers, etc, etc.. but to get true speedups I needed to use C or assembler.
The latter is what I want to achieve....being able to write C code callable from a standard program that implements an algorithm, taking input from PRIME structures (number, matrix, list, spreadsheet, etc.) and outputting the results to PRIME structures. Now it might be doable by allocating a matrix and moving data from the other structures into the matrix, sending the matrix into the C program, getting the results in another matrix, and moving data from the matrix to the other prime structures.
We'd need a way to get the C program into the prime. We'd need a way to access the prime's malloc function to load it into RAM

Note that the flash is NAND which is not execute in place, so all programs run in RAM.

I'm thinking aloud here as I'm typing and am thinking that we could compile the code and convert the machine binaries to a matrix format....maybe as a program with an initialized matrix (in text) which is loaded in as a program, and finding a way to run code at the address of the matrix... You know, with this paradigm, all I need is the screen buffer memory addresses (which we have or can get fairly easily). The rest can be passed in as a matrix with the transfer being done in HP PPL. So all we gotta figure out is how to execute from the address of an array of bytes. I could write a utility a part of the build tools to convert the binary to the array, and I'd have to handle local stack variables...just create a dummy stack as part of the array/matrix. It'd be slower to start up, but this programming is for stuff that spends a long time in the algorithm or is trying to get access to some hardware feature (like the 2D graphics engine, which is currently not being used). Could also be used to communicate through wifi.

BTW, I was looking at the formats of the files in the binary distribution from HP. There is one (the app.dat one) that I was able to mount as a fat16 format, and it contained winCE dlls!!! What are these used for? Do these go into the prime? Then the master.dat file isn't any known disk format.... hard to figure out much from that.

Also, you mentioned that your example used the Linux tools. I got them running under cygwin on windows. They might also run under DOS. There are eclipse versions out there too that could be made to work, but I'm a VIM person (don't like eclipse).

On the subject of Jazelle, this core was the first to implement this so it actually got support. There is a JVM that supports jazelle for this core supplied for free by Sun/Oracle....called Phoneme. Google phoneme JVM. It's mostly for phones running J2ME. Personally, it really doesn't offer any advantages over the PRIME programming language other than running or easily converting existing apps on android or blackberry.

Thanks for the feedback. Anyone interested should speak now or forever hold your peace :-)

Fun stuff :-)

[debrouxl]

Quote:I've done programming on TI calculators in the past and ran into problems with them not running fast enough. I was able to speed them up by using vector operations by adding lists of numbers, etc, etc.. but to get true speedups I needed to use C or assembler.

Yeah, replacing an O(n^2) BASIC implementation of Aitken's delta^2 algorithm by a O(n) implementation in C provided a nice speed boost for me, on the only real math program I did for the TI-68k/AMS platform. The BASIC implementation could probably have been written differently to use a slightly lower complexity, though.

Getting native code running from within the Prime's standard OS might not even be that hard: crashes and various semi-reproducible occurrences of incorrect behaviour which tends to go away, or change after a reboot (often a sign of memory corruption) galore in the OS, though less so nowadays than a couple years ago. But arbitrary native code execution from within the Prime's standard OS is considered a strong no-no here

Quote:BTW, I was looking at the formats of the files in the binary distribution from HP. There is one (the app.dat one) that I was able to mount as a fat16 format, and it contained winCE dlls!!! What are these used for? Do these go into the prime? Then the master.dat file isn't any known disk format.... hard to figure out much from that.

You're rediscovering some information available from https://tiplanet.org/hpwiki/index.php?title=HP_Prime for over a year

[webmasterpdx]

I think we need to be able to execute from a structure that stores data contiguously in memory. We also need to return from the assembler program.
So, we need to be able to get the address of a matrix and to call an assembler subroutine at a given address and pass in another address as an input argument and yet another as an output argument. Simple as that.
2 things we need from HP:

1. Get memory address of a matrix.
2. execute: Call address_name(address_arg, address_return)

That's it!

Anyone at HP listening? Pretty please? :-)

[Tim Wessman]

They aren't wince dlls, nor anything to do with wince. It is fairly common however for asian manufacturers to copy names and organization to aid with familiarity of developers internally. A lot of the OS calls are named fairly similar to windows type calls even when they have slight differences or even outright missing behavior. It can honestly get a little annoying.


Nobody at HP can help in any way with breaking open the system. We have not done anything to prevent it and hope that if/when someone does - PLEASE STAY AWAY FROM ANYTHING THAT MESSES WITH THE EXAM MODE (lights, memory, etc). If people start being able to break the exam mode things then we'll have to start screwing with stuff frequently to try and lock things down. Nobody wants that.

[webmasterpdx]

(09-12-2015 07:19 PM)Tim Wessman Wrote:  They aren't wince dlls, nor anything to do with wince. It is fairly common however for asian manufacturers to copy names and organization to aid with familiarity of developers internally. A lot of the OS calls are named fairly similar to windows type calls even when they have slight differences or even outright missing behavior. It can honestly get a little annoying.


Nobody at HP can help in any way with breaking open the system. We have not done anything to prevent it and hope that if/when someone does - PLEASE STAY AWAY FROM ANYTHING THAT MESSES WITH THE EXAM MODE (lights, memory, etc). If people start being able to break the exam mode things then we'll have to start screwing with stuff frequently to try and lock things down. Nobody wants that.

On wince....gotcha!

I'm not trying to break open the system. I'm trying to run C code that runs totally indepndently. The only thing the code will do is access the screen for graphics and access a preassigned matrix for input data and another for output results. HP PPL code will then transfer the results to the internal structures using existing interfaces.

I just need to know how to run C code from PPL and pass in a pointer to the input and output matrix. I've suggested that I can pass in the machine code in a third initialized matrix. Then if HP can provide a way whereby I can then run code stored in this matrix?

You provide this, you'll simply have the best math engine out there.

Exam mode would never be touched.

You do know that most customers for this product are NOT kids doing school exams....right? For that TI calculators are more accepted. This is for people that actually use math in their day to day jobs (e.g. I'm an engineer).
I wish calculator manufacturers would stop thinking that exams are the only use for calculators....

Until I get the C code capability, my preferred calculator will be Mathstudio running on android. I'd like to change that to HP Prime....but y'all won't help in that endevour...

Think about it.

[Adriweb]

(09-13-2015 02:06 AM)webmasterpdx Wrote:  You do know that most customers for this product are NOT kids doing school exams....right?

Hmm, HP is precisely trying to get as many school students to use the Prime. Looks to me like it's a whole new goal from other previous calcs (at least from a marketing PoV; we see that quite clearly on TI-Planet for example: there has never been as many members with HP calcs (the Prime, in this case) as there are now)
Also, for instance in France, an exam mode will be required starting 2018, so HP doesn't want to have to deal with native programs messing with it. It could potentially have bad consequences for them, like the government deciding the HP Prime can't be trusted thus can't be accepted in an exam (even if it does have the exam LED and test mode).
That's also valid for Casio or TI, even though those two are far more dominant in the market than HP is AFAIK, so a lot more people wouldn't like having TI ousted (and well, politics, lobbies, etc....)

[webmasterpdx]

BUt the TI's, etc, all an run native programs, plus what I'm suggesting doesn't interfere with the OS at all....exam mode isn't affected.

[webmasterpdx]

If we hack it and figure out how to execute assembler, there will be no protection. However, if HP were to provide this ability, they could allow it to run only in an area protected and isolated by the MMU......
....just an FYI.

[AHelper]

(09-13-2015 04:43 AM)webmasterpdx Wrote:  BUt the TI's, etc, all an run native programs, plus what I'm suggesting doesn't interfere with the OS at all....exam mode isn't affected.

Its not just your intentions, opening up native code execution can lead to uncontrolled modifications to the operation of the OS which could potentially include interfering with exam mode features. TI's that allow native code execution are able to have exam modes modified. Look at what TI has to do with the nspire line with the introduction of native code execution, blocking exploit after exploit. And further, newer TI's aimed at being used with exams that need strict exam modes have removed native code execution altogether (TI-82 Advanced).

Getting native code sandboxed in a way that securely prevents interference with the OS but hooks into Giac and other OS-specific libraries in a controlled way is not a small and simple task, probably outside the scope of the design requirements.

This discussion has mainly revolved around the existing HP-made OS, however this hasn't touched on 3rd-party firmware that provides no interaction with the original OS and has no exam mode. I don't know if not having any PTT would be safe regarding "PLEASE STAY AWAY FROM ANYTHING THAT MESSES WITH THE EXAM MODE" if PTT isn't a feature, as-in I don't know if PTT requirement is tied to the OS or the device itself.

[debrouxl]

Tampering with the exam mode is far more likely to occur on a closed platform like the Nspire than on an open platform like the Prime, though. As a matter of fact, the first attempts to tamper with the Nspire's extremely weak exam mode occurred in retaliation to TI announcing that the hole in OS 3.1.0.392 would be closed by OS 3.2...
Before that, I had spent a day of my free time writing text to try and educate the TI top management, and I predicted that things they don't like would happen if they did the wrong thing, like the PS3 and other platforms whose users were mistreated by the manufacturer. No rocket science, just looking back at the history of computing. Their loss, after all...

[webmasterpdx]

Precisely! I don't know if they understand what I'm saying. If they allowed us to be able to run machine language they could use the MMU to block our code from altering any areas they want. This way, any program run in that mode would not be able to adjust exam mode or anything else they wanted. It would only be able to access the input and results area along with the screen and local variables....that's it! So they could control what we could alter....thus protecting their code. However, if we have to hack our way to doing this, there would be no protection.
Thus open system would have superior isolation and protection.

That being said, I predict they are not going to respond favorably, so we need to figure out a way to hack running from a location. We basically need a goto instruction or gosub/call to be more precise. Keep your eyes peeled for such a mechanism.

[webmasterpdx]

here are some links that have useful internal info...such as the format of a user defined program...
https://tiplanet.org/hpwiki/HP_Prime/Fil...C_programs
https://www.omnimaga.org/hp-prime/the-hpprgm-format/
https://github.com/eried/PrimeComm/blob/...UsbFile.cs
https://github.com/eried/PrimeComm

Enjoy.

[cyrille de brébisson]

Hello,

> If they allowed native programming, they could use the MMU to block our code from altering any areas they want.

This is assuming that the OS does support/use the MMU, or can be modified to do so.

Cyrille

[webmasterpdx]

They own the OS, so of course the can program the MMU to do whatever they want.

There are so many things we could do if we had native support.
I was just looking at the hardware breakdown and they have a buzz100 connection. If that is connected to the proper audio outputs, it might do a lot more than a simple buzzer.... The CPU has ac97 and other sound capability....even if it's connected to 2 random output pins, we could hook up a cap and resistor and get PWM sound output.
However, need native programming for this.

[webmasterpdx]

I'm going to start another thread on getting I/O capability, so maybe, instead of internal native code, we can transmit data to an external chip, do the calculations there and get results back. Maybe even have a tiny external board on USB, or use WIFI to do it....this external board could have a tiny speaker for sound and a few other capabilities. Maybe have a 1GHz CHIP board ($9) connected via wifi... wifi has the advantage that you just have to put the external box down on the desk, next to the calculator....Using USB instead of wifi means that we'd have to make the board small enough to not be inconvenient (like the wifi dongle is).
I'll call it: External I/O (Smartstream, etc.).

[Tim Wessman]

(09-14-2015 05:58 AM)webmasterpdx Wrote:  They own the OS, so of course the can program the MMU to do whatever they want.

Actually, we don't own the OS. That's been part of the problem in handling some things that we'd like to do. :-)

[webmasterpdx]

Who owns the code then if not hp?

[xset]

(09-12-2015 07:19 PM)Tim Wessman Wrote:  PLEASE STAY AWAY FROM ANYTHING THAT MESSES WITH THE EXAM MODE

HP did not make adequate 50g replacement. As for me I don't care about exams. I need modern programmable device. NSpire at least has Ndless (though against TI will), but u can easily reset it rebooting device. And no global disaster happened with TI and their exam mode !

At least give us features which would compensate restrictions. I need walk on expressions (x*2+5 => {+ {* X 2} 5}), i need to draw expressions on GROB in textbook format. I need efficiently read and write files on disk: AFiles OK, but it would be too inefficient to read(write) whole list in one shot, also it would be cool to position cursor inside file. I also like to have access to programs, write program writing programs, etc. Where is programmable alert, and customizable START program ?

I am not student, its not my fault. I am working professional, why do u punish me ?

Best regards
XSet