QuoteThe number at the top of the screen shows how many ticks it took to render the scene (1 tick = 1/350th of a second).

350 Hz sounds like you used AUTO_INT_1 for timing, which is a good idea on HW2+ calculators from 1999 onwards - but in such a case, the rate is 256 Hz
Only HW1 calculators "feature" that inaccurate and varying AUTO_INT_1 rate, usually said to be 350-395 Hz (depending on battery strength, the phase of the moon, etc.).

Quote(which can be run with TIEmu if you don't have a physical calc)

Or https://tiplanet.org/pad_ti68k_emu/v12.html , started by Patrick Davidson and largely improved by myself. It aims at being an install-less, portable, "good enough" emulator. It's unfinished - it lacks a debugger, to begin with - and it was started before Emscripten became a usable option, but it works for most purposes.

QuoteThe TI89 on the other hand has twice as much flash and a 16 MHz CPU (compared to the 12 MHz TI92+) but it only has a 160x100 display. X3D runs on them both though! Actually, it will run faster on the TI89 because of the faster clock speed.

The CPU frequency of the 89 and 92+ is the same, actually.
Now, the frequency of the 89T's CPU was at first thought to be ~16 MHz, but it was a benchmarking issue stemming from comparing an empty 89T to a loaded 89, which had consequences on the memory allocation and VAT subsystems. Pure assembly benchmarks didn't show such a significant speed difference.

From the dependencies on Github:
* you're linking to the obsolete and unmaintained TIGCC, but not to the newer, improved and less buggy GCC4TI - how sad
* copying third-party headers / libraries to the GCC4TI environment can certainly cause issues with some projects and end up referencing files from the environment when one would like to reference other files, so I'm not keen on anyone copying ExtGraph (or any widely used third-party library, again) there.

QuoteBut you'd have to implement all the "interfaces" that the host (SV) expects to find/call, and everything. Good luck with that, it would be a huge amount of reverse-engineering

That said, this reverse-engineering could be quite clean-room, through DTrace-style user-space probes in the JVM, or custom JVM builds.
For understanding some aspects of the communication between the Prime CK and the computer version of the Prime software, I patched Wine on my computer.

AFAICT, TILP works with the 2.24.x runtime at http://garr.dl.sourceforge.net/project/gtk-win/GTK+%20Runtime%20Environment/GTK+%202.24/gtk2-runtime-2.24.8-2011-12-03-ash.exe .

And indeed, the Windows platform's DLL loader's limitations can cause all kinds of wrong behaviour if multiple applications using different versions of the GTK+ runtime (or in fact, anything else) are running concurrently on a given computer.

Indeed, the TI-68k series has always been significantly more powerful than the TI-Z80 series, and the Nspire series significantly more powerful than the TI-68k series
The relative popularity of the TI-Z80 series and TI-68k series is a consequence of standardized testing acceptance at the first order, and price tag at the second order. And as we all know, lower performance does not mean that one can't do great things on a given platform by leveraging all of its power.

The recent TI-eZ80 series is closing the gap, with a 24-bit flat addressing space, 256 KB of RAM and 4 MB of Flash, just like the 89T, and a faster processor. However, the eZ80 remains a 8-bit CPU with few registers, and represents an older generation than the 68000. Both were designed in the 1970s, nearly 40 years ago by now. What's more, TI is shackling the eZ80 with all of those memory access wait states, effectively reducing the processor speed to a quarter or an eighth of the maximum speed - which weakens a lot the eZ80's ability to drive a 320x240 screen at an optimal filling rate.

For select USB transfers, e.g. sending screenshots or FlashApps to the computer, the TI-eZ80 series seems faster than the 89T, which could be explained pretty much only by the usage of a DMA.

Yeah, the huge popularity of the online mViewer GX Creator converter took its toll on the server's responsiveness at times...
Before the 2014-2015 school season, we had identified a variety of improvements and additions. Some of them, e.g. the new ToutMonExam site, were implemented this year by critor and Adriweb. Work started on several others, and yet more items, such as a job queue for mViewer GX Creator, remain to be implemented.

Looks good, as before. Keep going

Some die-hard HP calculator fans are so disappointed with the Prime that they resell theirs at much reduced price tags, sub-$100 price tags are fairly common.

Multiple implementations of high-level languages which execute faster than the TI-Basic have been made on the TI-68k platform, years ago. GFA-Basic (known from another platform), NewProg, etc.

I used to be one of the admins of the TICT/TIGCC board, indeed.
Around 2005, several months after finding out for good about you know who's shenanigans, and understanding how he had betrayed my trust and naiveness, the mood had degraded on the board, as a result of the tougher interaction between him and me now gone public. So I gave moderator privileges to a couple reasonable friends from TI-Gen (they were root staff there and we interacted with them on a daily basis), with a mission of keeping him and me on check, because our behaviour had started turning users off the board. I did so without discussing the matter with the other admins of the TICT/TIGCC board, and I stated the promotion publicly, IIRC in one of the topics where infighting was occurring.

Soon thereafter (an hour or so, IIRC), you know who revoked these moderator privileges, before either of these persons was even able to use them, as well as my own admin privileges.
Of course, that made me angry, but by the next day (I found out about the move shortly before leaving the university, and at the time, I didn't have Internet access at the flat), I decided not to fight against the move. Not fighting soon proved to be one of the best things I ever did for the TI-68k community's sake: you know who had already conspired with Sebastian about forking the TIGCC message board to another place if I asked Thomas Nussbaumer to override his move, and needless to say, publicly make me forever responsible for the change. He stated multiple times that he was very surprised that I didn't fight his action; looks like he thought my behaviour was as predictable as his... but fortunately, it isn't.

QuoteEven Doors CSE 8.2 and PreOS would be possible in HP PPL

Not quite; most of their functionality (hooks, crash protection, general filesystem access, etc.) needs lower-level access

About the TICT/TIGCC message board: I stopped attending my own board after getting doubly censored, by guess whom, for suggesting to a user that he should post on e.g. Omnimaga, which was more active. That was several days after the post had gone unnoticed. In the first round of censorship, only the links were removed; after I put them back with a public complaint, the whole post, including technical content, was erased.
I could have bothered Thomas Nussbaumer immediately so that he spanked the offender appropriately, but I decided to focus on more productive matters instead. I told him a while later, for informational purposes only.

Like the TI community, the HP community contains a number of good programmers and tinkerers. But they seem to stick to the older models, e.g. the 50g, whose potential hasn't been fully tapped.

My version of PatrickD's JS TI-68k emulator, used in the TI-Planet archives, contains many improvements over the original one. It's an unfinished piece of work, though.
If I started such a project from scratch, I'd use a C core, and Emscripten to translate it into JS.

The Prizm is an interesting idea, and unless it's purely for learning purposes, you should leverage MAME or QEMU, though these aren't necessarily the easiest things to make GUI front-ends for.

Though there are better generic compression algorithms, DEFLATE is already much better than RLE compression or Huffman encoding. The vast majority of ZIP files use DEFLATE as well.

Like the Nspire, the Prime is tailored for school and exam testing usage. HP devs will have the duty to close arbitrary native code execution holes in the standard OS, Cyrille de Brébisson was on public record about that. HP will simply not release a native code SDK for the Prime...

However, the Prime remains a far more open calculator than the Nspire is, because as proven by critor and I, we can flash arbitrary OS onto it. So far, I'm the only person who took advantage of that capability, using standard C/C++ tooling targeting the ARM ISA, in a bare-metal, freestanding environment. That's a real shame.
Nobody bested my man-day of work on that PoC (which means both Proof of Concept and Piece of Crap here). I get to criticize my own work as much as I want, and I can safely state that in absolute terms, what I did thoroughly sucks, though in relative terms, it's the only program of its kind on that platform

For over a year and a half, we've all known what needs to be done with leveraging the Prime's power for our own purposes. However, nobody does it, due to lack of time and low user base, which raises lack of interest in the platform.