If rst 20h is move9ToOp1, then there's not problem there, it's just copying memory.

I'm more worried about executing the name. Just because you write .db data, doesn't mean that the calculator knows that it's data. Most of the letter ($40) commands are safe, just ld a, b type stuff. But the numbers would be dangerous. 0 ($30) and 8 ($38) are jr's, 1 and 3 modify sp, 2 i modify's a random byte, and 4, 5, and 6 modify (hl).

But as long as there are no numbers in the name, that will work perfectly.

*bump*

Sorry for the late post, but just found out it's impossible. The TI-83 can only run unsquished code (written in ASCII hex), but not normal ASM programs (why, TI? ) So there's no way to run it as BASIC.

I've been wondering, when you run a BASIC program the calculator parses as it goes right?

If so wouldn't it be theoretically possible to just have another program parse a BASIC program and output it as an ASM program using the same method? (Kind of like Axe only just faster BASIC)

In theory, yes. But it'd be really difficult because  don't think what the OS interpreter does is perfectly repetitive. I'm fairly sure it does some code swapping too, which would be difficult to parse without an on-calc compiler. Having it on-calc presents it's own problems though.

One thing: I can't imagine how large a BASIC program would become if it was translated to a compiled-style program but with the slowness of BASIC.

One thing: I can't imagine how large a BASIC program would become if it was translated to a compiled-style program but with the slowness of BASIC.

If you compile BASIC, you're removing the overhead of the Interpreter which probably has to look through a database of all of the commands and execute the right one. Doing that ahead of time with a compiler would blow up your file size like Axe does, except that the compiled language would be even larger than an equivalent Axe program because of the floating point calculations.

Some parts of the parser wouldn't be too difficult, such as the Pause command or the Vertical/Horizontal commands, because those are simply B_calls that you feed the arguments into through the registers.

Thinking about it, one could potentially write a reasonably sized compiler/interpreter that would take some of those easy commands and turn them into Assembly library type commands.

The floating point math is definitely a weak point. Using floating point math for For( loops and in other places wastes a lot of CPU power. You'd need a way to inform your compiler that certain variables in certain places can be handled with 8- or 16-bit integer arithmetic.

Quote from: DJ Omnimaga on November 04, 2010, 12:46:22 am

One thing: I can't imagine how large a BASIC program would become if it was translated to a compiled-style program but with the slowness of BASIC.

If you compile BASIC, you're removing the overhead of the Interpreter which probably has to look through a database of all of the commands and execute the right one. Doing that ahead of time with a compiler would blow up your file size like Axe does, except that the compiled language would be even larger than an equivalent Axe program because of the floating point calculations.

Some parts of the parser wouldn't be too difficult, such as the Pause command or the Vertical/Horizontal commands, because those are simply B_calls that you feed the arguments into through the registers.

Thinking about it, one could potentially write a reasonably sized compiler/interpreter that would take some of those easy commands and turn them into Assembly library type commands.

Oh I meant about literally including the needed TI-BASIC interpreter code (from the TI-OS) in the BASIC program that is compiled into assembly. Now that would be huge I am sure.

The floating point math is definitely a weak point. Using floating point math for For( loops and in other places wastes a lot of CPU power. You'd need a way to inform your compiler that certain variables in certain places can be handled with 8- or 16-bit integer arithmetic.

True, I remember a discussion on MaxCoderz a while ago with Kozak, who was working on an RPG, and he said he noticed a considerable speed difference when he tried using them instead of integers for certain things.

Another thing that makes BASIC slow is how the LCD is updated every Line/Pixel command. I am sure it would still be slow if it wasn't, but I am sure it would be much faster. In Axe, a program that fills the screen pixel by pixel almost runs as slow as TI-BASIC when you update the screen every frame. If you only update the screen at the very end, it almost takes an instant.