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 Smile

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 Smile
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 Very Happy
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:
[center][url=https://gitlab.com/taricorp/tihle[/url][img]https://i.imgur.com/Dh8934E.png[/img][/url]
(pronounce it like "tile")[/center]
(There's a [/url] in a place there shouldn't be)

instead of

Code:
[center][url=https://gitlab.com/taricorp/tihle][img]https://i.imgur.com/Dh8934E.png[/img][/url]
(pronounce it like "tile")[/center]
TheLastMillennial wrote:
There's an issue with your embedded link in the image above, you have
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?
tr1p1ea wrote:
Just had a thought, will you support greyscale?
As noted near the end of my essay, yes it would be nice to support.

Xeda112358 wrote:
Since rst28 (bcall) is trapped, then hypothetically we just implement the bcalls in Rust (?) as need arises?
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.

TIny_Hacker wrote:
Will this be available as an app on a desktop computer, or will it just sta as a web application?
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 Surprised
Fantastic idea, interesting implementation, and the fact that both Rust-written and Z80-written BCALL implementations are possible makes it even better Smile

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:
tihle> help
tihle debugger CLI

USAGE:
    Type commands, send them to the emulator

SUBCOMMANDS:
    addbreakpoint    Add a breakpoint
    continue         Resume execution
    exit             Exit the debugger
    getregs          Get the values of all registers
    help             Prints this message or the help of the given subcommand(s)
    print            Display the value of an expression
tihle> addbreakpoint 0x9d95
Ok
tihle> print pc, a, hl, de, ix + 3
pc => 41604
a => 2
hl => 34922
de => 65268
ix+3 => 41092
tihle> print asdf

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 Razz ) as a kind of CE version of it. That could be why it reminds you of CalcuZap.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement