When I say "viable alternative" I mean to address the fact that TI-BASIC is still the best language for math. As well, it provides a useful range of variable types.

EDIT: Also, I just added in better (but not perfect) rounding.

Well, yeah, but that's not what you asked. Literally, here are the differences:
-There is more Flash
-The LCD is changed
-The OS code was changed accordingly

Nothing else has changed. In fact, the LCD uses the same two ports as before. The processor didn't change, and the memory map didn't change, so you can definitely put any monochrome OS on the color calc. It would still read keys, work with flash, the USB and I/O port would work (you could still send stuff to it or get stuff off of it with TI-Connect or TILP). You could even send an assembly program that does work properly with the LCD.

But otherwise, yes, it would be impossible to use an unmodified monochrome OS and fully support monochrome programs or apps. They have to be manually ported.

I started posting about LangZ80 in the FileSyst thread. Although I don't consider it a project-- it is more of a "proof of concept" program-- I have been having updates and instead of derailing the FileSyst thread, I brought it here.

Basically, I want to get FileSyst to a point where it can use variables and functions and basically work as a higher-level programming language and not just an exposed filesystem. I decided to experiment by creating a parser (yet again).

It is really broken and in a messy state, especially with the variable storage. There are lots of bugs there, as well as a few other bugs (integer that are multiples of 256 don't work properly, and I believe I left a few bugs in the float multiply routine). However, when I am not introducing bugs and things are working as they should, here is what it has:

• Commands are typed out, like "UPDATELCD()"
• Integers are arbitrary precision, from 0 to 2040 bits, in multiples of 8. These are unsigned.
• Strings are supported. Start them with either " or ' and end them with the same token. This allows the use of quotes in strings.
• Floats are supported. They default to at least 128 bits of precision (38 decimal digits) and at least 32-bits of precision after the decimal point. Floats can be arbitrary sizes, though, also up to a total of 2040 bits.
• I have wrote the float_times_float and int_times_int routines, but not int_times_float and others.
• It has an XORSPRITE() routine that was just for testing. It totally fakes the sprite rendering by not actually reading a sprite var and just assuming 8x8 sprites. Later this will change.
• It has an UPDATELCD() command
• It has a WAIT() command to wait for a key press
• It has a few stacks to hold intermediate data. This part of the app is complete, to my knowledge. It pushes, pops, converts, updates pointers, all that good stuff.
• When exiting, it returns "Ans" in the OS ans variable as a string (or it returns one of the various errors)
• As such, it has an int?str routine, str?str, and most recently about an hour ago, a float?str routine.
• It parses from prgmTEST
• Storing and reading variables is almost supported. It is still broken and causes crashes, though.

It is really kind of garbage at the moment, but feel free to download it to test out in WabbitEmu. It is not stable and it will likely end up crashing a few times.

If at any point it seems like the program has frozen, it might instead be in the WAIT() loop or in another loop I made. To get out, try the following first:

• Press any key that isn't [ON]
• Press [ON]

If you have to press [ON] to exit, it was in a loop where I haven't added in the needed code yet, so I used that loop as a filler.


(also, it's 3344 bytes of code out of 16384)

Yes, you can. However, the LCD driver is completely different so you would only see garbage.

I don't think I will ever finish writing an OS, but I am trying to get a lot of the key components done. Of the related things I have done that I would like to bring all together:
-EnG which was never finished, but provided a very simple file system spanning the extra RAM pages (detecting whether there were 1 or more RAM pages).
-Grammer as a simple interpreted language.
-FileSyst which exposes a file system and related housekeeping commands.

I haven't merged this with FileSyst yet, but I am making some more progress. Last night I finally added the Str->Float routine, so now floats can be used. The way I am handling floats is by satisfying the following two conditions by default:
-There must be at least 32 bits of precision for the fractional part of the number.
-There must be at least a total of 128 bits of precision.

So for example, if you have a number whose integer part is already 112 bits before the decimal point is encountered, it will allocate 32 bits more for the decimal part making 144 bits.

For math, I only have multiplication. I have int_times_int and float_times_float, but I still need int_times_string and int_times_float and once I add in arrays and lists, I will need to accommodate for those. The way I handle precision with multiplication is by using the size of the highest precision input. So if one float was 128 bits and the other was 144, it would output a 144-bit number. I plan to make a command to modify the accuracy and size of floats.

I actually still need to complete one other part of the floating point code, and that is to handle negative exponents. I am sure I will get to it some time. Aside from floats, I have some variable support. You can make a var from scratch, but I didn't add in the code for updating a var with new data. That should be done easily enough.

I have a few commands that I added for testing purposes. Those are XORSPRITE(), UPDATELCD() and WAIT(). They work The way I have coded this interpreter should make it easy to incorporate a file system. I was already rewriting FileSyst to incorporate features I am using here (like an indexed binary search for files and folders) so I will probably merge the two.

In assembly, sprite rendering would be faster for most size, but only if you have a handful of sprites. Basically, you save time by being able to draw directly to the LCD at pixel coordinates without an LCD delay.

Also, dreamdragon, it is preferred that you use the "Quick Modify" or "Modify" buttons to edit your post instead of posting close together (also known as a "double post" which is referred to in the rules).