Following the still-recent discussion around native code support being removed from the CE, I had some thoughts about how doing so destroys the legacy of existing calculator software and how the (inevitable) availability of hacks to bypass this limitation is not a useful long-term solution. The result of those thoughts and a while spent programming?


(pronounce it like "tile")

I wrote ~7000 words about this on my own web site, so go ahead and read the gory details there. To summarize:

• This is a new emulator meant to avoid using any TI code
  
• It's written in Rust
  
• Right now Phoenix is playable and maybe other things (but I've only tested Phoenix)
  
• You can run it in a web browser (or as a native program)

Here it is running Phoenix, and you can play Phoenix in your browser right now:


The general concept is something of an end-run around the problem that it's feasible to reimplement much of TI-OS, but too much work for anybody to have tried/made much progress on it. It's much easier to implement some things in a Real Programming Language (Rust!) than straight assembly, so that's what I've done.

Source, binaries, etc on GitLab

Discuss, or whatever? Make suggestions, ask questions..

Wow Tari, that is a very interesting and provoking thought regarding ASM.

Also loving the emulator and the title already runs Phoenix! Awesome 😀.

If you are looking at games then I would envisage that there are only a handful of tios routines required to cover a large percentage of existing software.

Do you plan on supporting TI-BASIC programs?

I would like to, but it also requires an interpreter implementation. As alluded to on my web site, it doesn't seem too hard if 100% floating-point compatibility is not required; I imagine naive IEEE decimal64 implementations of most functions would be sufficient and conveniently avoid the implementation cost of more closely emulating TI-float.

Hey, that's pretty cool

That finally solves the problem I had of embedding games on a webpage without requiring the user to provide a ROM. Gonna try it out soon, and if it works I might integrate this on CodeWalrus

Wow! Sort of along the lines of what I was thinking for the TI emulator I want to make for Prizm, so people could play all their favorite games just with the .8xp files on their calc. Glad you beat me to it so I have a great code reference. Keep it up this is so great for the community

This is awesome; you can bet I'll be reading all ~7000 words of that later.

Well done! I read your essay and I found it quite interesting!
There's an issue with your embedded link in the image above, you have

Code:
(There's a [/url] in a place there shouldn't be)

instead of
Code:

Heh, tricky. Fixed.

I've started a program compatibility list on the project wiki, so if you try any programs it would be helpful to record how well (or not) they work.

Just had a thought, will you support greyscale?

Since rst28 (bcall) is trapped, then hypothetically we just implement the bcalls in Rust (?) as need arises?

At one point I had worked on a parser that was supposed to parse BASIC code, but motivation dropped off quickly. Maybe I should work on that again XD

Wow! What a cool project! I loved to take a little break playing phoenix. Will this be available as an app on a desktop computer, or will it just sta as a web application?

As noted near the end of my essay, yes it would be nice to support.

bcalls right now actually do a kind of funny ping-pong where TRAP_BCALL reads from the vector table on page 1B and jumps to the appropriate target, which means bcalls can be implemented as traps in Rust or in straight Z80, whichever is more convenient.

Currently cpHLDE, PutS, VPutS and GetCSC are implemented in Z80, while the other implemented bcalls are done as traps.

As somebody pointed out in SAX too, it already is; see the releases page or you can build it yourself.

You mentioned in your article that you would prefer a more liberal license, but had to go for GPL because of the z80 core. Before you write your own z80 core, I recommend you take a look at zymosis. It's very accurate, very fast, and licensed under WTFPL.

Other than that, congrats for pulling this off. And congrats for making me log into cemetech for the first time in, like, half a decade

Fantastic idea, interesting implementation, and the fact that both Rust-written and Z80-written BCALL implementations are possible makes it even better

Maybe this project will raise the priority of the making of a community OS providing good binary compatibility with TI's OS, similar in spirit to PedroM for the TI-68k series, which contains filesystem, floating-point and link communication implementations, all of which are crucial for emulation compatibility and accuracy.
Of course, PedroM has no TI-68k Basic implementation, since that's way too much work; a compatible, independent TI-Z80 Basic implementation is also probably way too much work, but should definitely be less intractable than a TI-68k Basic reimplementation, since there's no CAS on the TI-Z80 series.

I have a feeling that IEEE decimal64 floats might work for some PoCs, but unless no programs whatsoever depend on the data format and memory layout of TI's float implementation, a proper implementation compatible with TI's code will eventually prove necessary.

I very much appreciate your contribution to the community. It's value should not be understated.

I've been doing some work on providing a nicer UI (especially for touchscreen devices) and debugging support.

Here's a slightly eye-crossing comparison image of a photo of an 83+ with my keyboard overlaid on it:


And the beginnings of a debugger:

I chose to implement debugging with an in-process remote communication stub and nice UIs talking to it from another process, since that allows a pretty debugger to be implemented with any desired tools and avoids the complexity of needing to build a GUI in terms of SDL primitives.

Wow it's looking awesome - I think it's a very good idea to make the UI touch friendly.

Debugger support, nice!

Haven't touched this in a while, but I pulled it out again today and made the skeleton of nicer interactive debugging that I had left it with more useful. Representative mini-session:

Code:

It knows to how evaluate simple expressions, including references to registers. References to memory locations aren't yet implemented but are parseable, though I also need to devise some kind of syntax to indicate whether you want 8 or 16 bits at a given address. Currently all values are 16-bit, and memory references are written with parentheses as they usually are in assembly (so (hl + 3) is the memory with address [value of HL] + 3). Any bright ideas on ways to indicate memory operand size?

This game reminds me of CalcuZap.

CalcuZap was made by the same author as Phoenix, (seems like he liked shoot-em-up games ) as a kind of CE version of it. That could be why it reminds you of CalcuZap.