Omnimaga

Calculator Community => TI Calculators => TI-BASIC => Topic started by: program4 on July 28, 2010, 09:41:21 am

Title: Basic to ASM?
Post by: program4 on July 28, 2010, 09:41:21 am
I downloaded a random BASIC program on ticalc.org, and ran it through the ASM File Unsquisher (http://asmtools.omnimaga.org/asmunsquisher/), and there was a long list of hex codes. If you typed it in your calculator, would the program actually be in ASM?
Title: Re: Basic to ASM?
Post by: Deep Toaster on July 28, 2010, 09:45:21 am
No, BASIC is totally different from ASM. The File Unsquisher basically takes the hex data of a program and displays it; so if you did that with a BASIC program, all it would do is display the hex codes of the tokens (commands, etc.) in the BASIC program. It would not be ASM, since the commands themselves aren't translated.

And it wouldn't run on a calculator, even if you compile it (using the AsmComp( command), because you're making the calculator think it's ASM, even though it's not.

EDIT: Oh yeah, and if you run it with Asm(, like an ordinary assembly program, chances are your calculator will crash :D
Title: Re: Basic to ASM?
Post by: mapar007 on July 28, 2010, 10:13:36 am
Your calculator would have a 99.999999% of crashing if you actually tried to run it.
Title: Re: Basic to ASM?
Post by: Hot_Dog on July 28, 2010, 10:19:27 am
I downloaded a random BASIC program on ticalc.org, and ran it through the ASM File Unsquisher (http://asmtools.omnimaga.org/asmunsquisher/), and there was a long list of hex codes. If you typed it in your calculator, would the program actually be in ASM?

The calculator would be running a bunch of "data" instead of actual commands.  Like everyone else said, it will most likely crash the calculator.
Title: Re: Basic to ASM?
Post by: calcdude84se on July 28, 2010, 07:53:13 pm
First person to make a program that runs in ASM and BASIC without crashing the calculator or erring (for the ASM program you can ignore the mandatory BB6D at the beginning) wins something. (Non-trivial solutions only)
It'd be interesting to see if such a program could exist ;D
Title: Re: Basic to ASM?
Post by: Deep Toaster on July 29, 2010, 12:53:23 am
:D We should have a contest for that someday: a game that runs both in BASIC and ASM. That would be absolutely amazing.

What about a BASIC>ASM converter? I think there's one on ticalc.org, but I don't think it works.
Title: Re: Basic to ASM?
Post by: thepenguin77 on July 29, 2010, 01:01:51 am
Well... I did it. The program does the same thing in both languages. It was a fun challenge, but it was also really hard. The main problem is that bcall is represented by $EF, and it has no token counterpart. So the next logical thing is to skip that step and straight call $0028. But guess what, no $00 either.

Here is the code in both languages.

Basic:
Code: [Select]
:
:
:Disp "(0.0)_Hel
lo!!!!"
:Return
:_sin-1(fMax(0fMa
x(0CubicReg 0_ra
ndM(HDegree>>(not equals)me
an(mean(mean(mea
n(00000000mean(a
bs(Vertical ?2in
t(Vertical 210^(V
ertical tanh-1(?V
ertical rEtanh-1(
?Vertical CubicR
eg Ey

And assembly:
Code: [Select]
.db $BB, $6D
sbc a, $2A
djnz $9DC9
ld a, ($1130)
add hl, hl
ld c, b
cp e
or h
cp e
cp h
cp e
cp h
cp e
cp a
dec l
dec l
dec l
dec l
ld hl, ($D53F)
ccf
add hl, hl
_9DAF:
jp $3028
_9DB2:
.db "(0.0) Hello!!!!"
_9DC1:
.db $30, $30
jr nc, $9DF5
jr nc, $9DF7
jr nc, $9DF9
_9DC9:
ld hl, $9DB2
xor a
ld ($9DB1), a
ld ($9DC1), a
call $9DAF
.dw _putS
call $9DAF
.dw _newLine
cp e
ret

BB 6D shows up as a ? on the calc as you can see from the screen shot. But that is the only token that I had to use calcsys to get. The rest of the program was typed in by hand. For converting back and forth, you change those first two returns to BB 6D.
Title: Re: Basic to ASM?
Post by: Deep Toaster on July 29, 2010, 03:07:03 am
I tried...

Code: ("TI-BASIC") [Select]
:::Asm(prgmA)
:Return
:?2[size=8]E[/si
ze]Pt-On(28Pt-On
(tanh(^-1)(9Pt-O
n(XEmean(iPart(V
ertical tanh(^-1
)(9Pt-On(^r^E:Pa
ramtanh(^-1)(9Pt
-On(►DMSEsinh(^-
1)(randM(randM(r
andM(randM(randM
(randM(randM(ran
dM(TEngDegreeran
dM(randM(randM(ra
ndM(randM(randM(
randM(randM(rand
M(randM(randM(ra
ndM(randM(randM(
randM(randM(rand
M(randM(randM(ra
ndM(randM(randM(
randM(randM(rand
M(randM(randM(ra
ndM(randM(RFloat
randM(randM(rand
M(randM(randM(ra
ndM(randM(randM(
randM(randM(rand
M(randM(R≠>>Degr
eeAnsfMin(Fix r
andM(randM(randM
(randM(randM(ran
dM(randM(randM(r
andM(randM(randM
(randM(randM(ran
dM(randM(randM(r
andM(randM(randM
(randM(randM(ran
dM(randM(randM(≠
NormalrandM(rand
M(randM(randM(ran
dM(randM(randM(r
andM(randM(randM
(randM(randM(ran
dM(randM(randM(r
andM(randM(randM
(randM(randM(ran
dM(randM(randM(r
andM(randM(randM
(randM(randM(ran
dM(randM(T≠≤≠Ans
Ans≠0sin(^-1)fMa
x(0
Generated by [url=http://sc.cemetech.net]SourceCoder[/url], © 2005-2010 [url=http://www.cemetech.net]Cemetech[/url]

Code: (TI-ASM) [Select]
#include ti83plus.inc
.org $9D93
.db $BB,$6D
cp E ;$9D95
ld L,D ;$9D96
ld E,A ;$9D97
ld B,C ;$9D98
ld DE,$D53F ;$9D99
ccf ;$9D9C
xor A ;$9D9D
ld (BCALLER+2),A ;$9D9E
ld (TEXTEND),A ;$9DA1
call BCALLER ;$9DA4
.dw _HomeUp ;$9DA7
ld HL,TEXT ;$9DA9
call BCALLER ;$9DAC
.dw _PutS ;$9DAF
ld A,$77 ;$9DB1
call BCALLER ;$9DB3
.dw _PutMap ;$9DB6
ret ;$9DB8
TEXT:
.db "        The     " ;$9DB9
.db "                " ;$9DC9
.db "        Rick    " ;$9DD9
.db "        Roller",$27,"s" ;$9DE9
.db "                " ;$9DF9
.db "        of      " ;$9E09
.db "                " ;$9E19
.db "        Tomorro" ;$9E29
TEXTEND:
.db $30 ;$9E38
BCALLER:
jp $3028 ;$9E39

Basically, I was trying to cheat by making a program that would run itself as assembly if you ran it in BASIC. And then I realized that for it to work in BASIC, it has to start with the two colons, while for it to work in ASM, it has to start with $6DBB. And so I failed.

(Don't even try. The screenshot uses two separate programs to show what I tried to make. As you can see, I was trying to build my own version of the rickrolling program.)

EDIT: A pity it didn't work. If it worked, all you'd have to do is add that extra header, and any ASM program would run from the homescreen without Asm(.

EDIT2: Wait, since the plain TI-83 doesn't have a compiled ASM token, couldn't we make something like this (with a slightly different header) for it? It'd be more convenient than calling from an extra BASIC program.

EDIT3: Of course, somebody probably already thought of that :P
Title: Re: Basic to ASM?
Post by: thepenguin77 on July 29, 2010, 10:17:32 am
Wow, ours look really similar. But last night when I went to bed, I was wondering the same thing, if a basic program could Asm( itself. But I just found out it's not. I used a parser hook to trace through the execution of a program and the OS checks for either, BB 6D or BB 6C. BB 6C as you probably guessed is AsmPrgm.

I guess the only thing would be self modifying basic code.
Title: Re: Basic to ASM?
Post by: Deep Toaster on July 29, 2010, 10:58:24 am
Wow, ours look really similar.

Oh yeah, I took the idea to modify the jump from your example. I was going to give you credit for that in my post, but I totally forgot x.x Really sorry about that.

Do you think it would work on a plain 83?
Title: Re: Basic to ASM?
Post by: thepenguin77 on July 29, 2010, 11:06:25 am
I don't care if people copy me.  :)  But the 83 idea should work. I don't see why it wouldn't. Too bad I have never seen an 83 in my life.

It would totally be possible to make a game that runs in asm and basic though. You could use a djnz like I did because that is just a (. Then "if 0:" off a section where it jumps to say $9A00. That way you could make a basic game before the assembly game. At that point, I wouldn't even care if I used illegal characters in the assembly part.
Title: Re: Basic to ASM?
Post by: Deep Toaster on July 29, 2010, 11:09:29 am
It would totally be possible to make a game that runs in asm and basic though. You could use a djnz like I did because that is just a (. Then "if 0:" off a section where it jumps to say $9A00. That way you could make a basic game before the assembly game. At that point, I wouldn't even care if I used illegal characters in the assembly part.

But then you couldn't code it using the BASIC editor...

EDIT: Wow, just thought of an way this could be useful: Forget about having it run as a BASIC program. If we managed to make games completely compatible with the BASIC editor, calc users without link cables could just code the program directly, without bothering to use hex,

EDIT2: Oh, wait, $6DBB :P
Title: Re: Basic to ASM?
Post by: DJ Omnimaga on July 29, 2010, 08:56:23 pm
The code above isn't TI-BASIC, though, right? I wonder if someone could manage to make a BASIC program wrote with legit BASIC syntax do the exact same thing as its ASM unsquished counterpart :P
Title: Re: Basic to ASM?
Post by: thepenguin77 on July 30, 2010, 12:57:32 am
DJ, you are saying have the assembly program run the exact same code that the basic one does and come up with the same result?

It might be remotely possible, but it would take a ridiculous amount of time. Plus the assembly is usually longer. Mine is really two separate programs in one. Only the first 4 bytes are used by both.
Title: Re: Basic to ASM?
Post by: DJ Omnimaga on July 30, 2010, 03:13:28 am
Yeah that's what I meant. At first that thread had my hopes up lol :P

Still nice to see the above, though. Also I agree finding a combination of BASIC commands that does exactly what its Galandros unsquisher-generated counterpart does (after ASM compiling) would be insanely hard o.o
Title: Re: Basic to ASM?
Post by: Deep Toaster on July 30, 2010, 03:37:56 am
I don't care if people copy me.  :)  But the 83 idea should work. I don't see why it wouldn't. Too bad I have never seen an 83 in my life.

So apparently, if a TI-83 assembly program starts with
Code: (TI-83 ASM) [Select]
rst 20h
add HL,SP
ld E,A
.db [program name]
ld DE,$D53F
ccf
it should run from the normal BASIC menu, no weird Send(9prgm or anything. This could be useful. Too bad there aren't that many plain TI-83 users out there anymore :(

I don't know much assembly at all, so here's my n00b question: Could this potentially crash the calculator? Like if we do a rst 20h without knowing what HL is, could that be unstable?
Title: Re: Basic to ASM?
Post by: thepenguin77 on July 30, 2010, 11:14:37 am
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.
Title: Re: Basic to ASM?
Post by: Deep Toaster on July 30, 2010, 11:58:06 pm
Oh yeah, numbers...

I wonder if it's possible for an assembly program to call itself as BASIC. Probably harder, though (with syntax errors x.x).

EDIT: Anyone want to try? I give up :)
Title: Re: Basic to ASM?
Post by: Deep Toaster on November 03, 2010, 07:44:40 pm
*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? ???) :P So there's no way to run it as BASIC.
Title: Re: Basic to ASM?
Post by: guy6020665 on November 03, 2010, 09:21:51 pm
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)
Title: Re: Basic to ASM?
Post by: AngelFish on November 03, 2010, 10:23:30 pm
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.
Title: Re: Basic to ASM?
Post by: meishe91 on November 04, 2010, 12:05:36 am
I believe I asked the same question a while ago. Whether it's possible to pre-parse a TI-BASIC program to have it run faster? If I remember correctly I think someone said it would actually be the exact same speed if you did manage to pre-parse it correctly, which in itself is extremely hard if not impossible.
Title: Re: Basic to ASM?
Post by: 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. O.O
Title: Re: Basic to ASM?
Post by: meishe91 on November 04, 2010, 01:05:54 am
Ya, I don't know.

One thing that could technically work, in theory, is if someone did something like Axe Parser. Go through each command and write a Assembly routine that does the exact same thing, just faster. Then just run the TI-BASIC program through this new parser and bang, a TI-BASIC program with much faster speed. That parser would be a nightmare to code though.
Title: Re: Basic to ASM?
Post by: AngelFish on November 04, 2010, 01:16:05 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. O.O

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.
Title: Re: Basic to ASM?
Post by: meishe91 on November 04, 2010, 01:22:58 am
The thing though is that it's not those easy, simple commands that are the issue. It's things like seq( and such. Pause, Horizontal, Vertical, and like commands are relatively ok in TI-BASIC so I wouldn't see much of a point for Assembly routines for things like those.
Title: Re: Basic to ASM?
Post by: DrDnar on November 04, 2010, 01:24:01 am
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.
Title: Re: Basic to ASM?
Post by: AngelFish on November 04, 2010, 01:42:25 am
@Meishe91

You're right. The commands that are easily hard coded are the ones that are the slowest. That's probably because they're the ones that have the smallest routines. I'm sure that that things like Rand could be done in Assembly with the proper alterations. Axe executes that command very quickly. Also, TI probably made B_calls out of the majority of them, seeing as how lazy some of the other B_calls are written. For example, B_call (5089) is literally five lines of Assembly.
Title: Re: Basic to ASM?
Post by: DJ Omnimaga on November 04, 2010, 04:27:46 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. O.O

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. :P
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.
Title: Re: Basic to ASM?
Post by: Deep Toaster on November 04, 2010, 11:45:00 am
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.

And in some cases loops that look fixed-point have decimals added somewhere in the loop, which causes a bigger problem. So any program that compiles BASIC to ASM would definitely need to be on a comp, since it would take so much mem (not to mention time) to make such a complicated compiler.