Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - lunixbochs

Pages: [1]
1
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 24, 2011, 04:04:00 pm »
Will there be Axe support?
I'm planning to work on Axe support in pitybas, so he'll be able to execute it if he wants

2
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 22, 2011, 02:01:01 pm »
Request: Full math support. I know it's kind of obvious, but sometimes it annoys me to waste time writing simple functions (that take a long time to execute on-calc) in PC math languages that could be done very quickly in TI-BASIC.
like this?
(watch in 480p for best effect)

Pretty much.
it's in a working state right now, if you wanted to try it out :) it'll just need some math tokens/functions implemented depending on what you're doing. if you run into a token I haven't implemented yet, it's pretty easy for me to do so

https://github.com/lunixbochs/pitybas

3
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 22, 2011, 10:20:25 am »
I'm looking into compiling to byte-code because I'm sure that'd be alot easier for both of us
not easier. if you have untokenized text, I can execute that directly :P

the only thing we need in C# is the actual IDE, the detokenizer (though I'll probably implement one soon), and the graphical interface emulating the calculator screen. that would be easier for both of us, because my part can already take plain text source and execute it perfectly.

4
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 21, 2011, 08:10:46 pm »
dopewars running on pitybas

I only replaced the Output()s with my own display function (I don't emulate the homescreen for Output() to work yet), otherwise it's verbatim the detokenized 8xp I downloaded from a random site

5
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 19, 2011, 10:04:08 pm »
Request: Full math support. I know it's kind of obvious, but sometimes it annoys me to waste time writing simple functions (that take a long time to execute on-calc) in PC math languages that could be done very quickly in TI-BASIC.
like this?
(watch in 480p for best effect)

6
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 19, 2011, 09:55:31 pm »
Besides, with lunixbochs's Python interpreter (we might have to port it to C#) there really won't be a need for an emulator.
No need for a C# port, we can integrate Python code cleanly with C# via IronPython: http://ironpython.net/

7
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 19, 2011, 01:17:08 am »
That is where my .exe "engine" and my misc. come in to play.
my entire project right now is simulating the basic interpreter, which sounds like what you'd be doing in your EXE engine. You could embed Python at this point instead of writing your own VM.

I just got functions working. The next step is a Block stack, then skip/goto ability and I'll have most of the interpreter done, sans the actual token behaviors (which are all separate and self-contained)

8
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 19, 2011, 12:50:13 am »
Perhaps for comma based Disp's you could just write a new line?

I don't know Python, but in C# you could interpret
Code: [Select]
Disp "Hello","World"
as
Code: [Select]
Disp "Hello" + "\n" + "World"

right, but what happens when I do this? :)
Code: [Select]
Disp "Hello", 1I got it anywho, the test passes now.

you understand it'll be very hard to implement some of the quirks of TI-BASIC without an interpreter or specialized virtual machine, right?

my goal:
given an existing TI-BASIC program that runs on a calculator, execute it as identically as possible except for speed.
with this, I should be able to take any program from ticalc.org and run it verbatim

it sounds close enough to what you're doing, I still think we could work together (unless you have some really good ideas for translating BASIC's quirks to CLR)

9
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 19, 2011, 12:29:24 am »
I don't need to detokenize, because I'm only interested in running the code - not displaying it :)
I define tokens as classes in python, with methods like get(), set(), run()

tokens have an "order of operations" property, which allows me to push the proper token types into expressions, and evaluate expressions in the right order

right now, the following test cases work:

Code: [Select]
Disp "string constant:"
Disp "spam"

Disp "string concatenation:"
Disp "eggs" + " foo"

Disp "expression with parens"
Disp ((1 + 2) + 3) * 4

Disp "unterminated brackets"
Disp ((1 + 2

Disp "logic operators"
Disp 1 < 3 and 4 > 3

Disp "variable set, implied multiplication"
2->A
1->B
Disp AB

Disp "-> should close all brackets (this should Disp 6)"
3+(1+2->C
Disp C

Disp "->D->E"
1->D->E
Disp D + E

the only code constructs I can't handle yet, are If/Then/Else/End, While, Repeat statements (blocks), which actually just need an interpreter method to skip around (when I hit an "If" token, it'll evaluate the expression i.e. "If 1" will check to see if 1 is true, then either continue execution or jump to the next (Else or End))

when I hit an End during normal execution, it'll look at the stack of blocks I'm in and ask the last block on the stack whether to repeat the block or not. this even allows me to simulate the "If 1 End" feature to skip back to the last While loop

for Goto, I just need to be able to say "Skip to the next Label token with the label x"

the interpreter can already handle all of this except the skipping around part :)


for comma-separated values, that's function arguments and Disp as per this test case:
Code: [Select]
Disp 1, 2, 3
Output(1, 2, 3)

once I get these working, I just need to implement the behavior of a lot of tokens/functions - but the way it's designed, that's completely separate from the VM.
I just define a class with a run() function, and its behavior is completely isolated there

for the pure-python version, I'm thinking I'll just implement something along the lines of really limited homescreen emulation for now, and aim for being able to at least run menu-based games like drugwars :) I might implement vt100 control codes for better homescreen emulation so we can play mofrog and such

for the javascript version, I was planning to do full homescreen and graph screen emulation, including the fonts used. that's a bit down the road.


I'm pretty happy with my progress so far, and excited to have a turing-complete language pretty soon.

in the next few days, I'm hoping to be able to run most BASIC programs driven by menus and text input, which don't rely on the graph screen or homescreen positioning from Output()


I think he's trying to build an interpreter that will actually run a TI-Basic program from the computer.
it can already run simple programs

10
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 19, 2011, 12:03:24 am »
well, once I get the interpreter fleshed out a bit more (it still needs a finished implementation of comma-separated values like used in Disp+functions, and working jump/skip for blocks (If, While, Repeat) + Goto/LBL), my next goal is a Javascript port w/ html canvas for display

afaik you can invoke both python and javascript from C#/CLR, maybe you could save a lot of work that way :) my token handling is extremely flexible, and I could easily delegate parts or all of it to C#

11
TI Z80 / Re: TIConvert
« on: July 18, 2011, 11:56:46 pm »
my tokenizer method should be pretty easy to implement in most languages

12
TI Z80 / Re: TBEXE - Pre-alpha feature requests
« on: July 18, 2011, 10:29:26 pm »
How mature is the project so far? What sort of details can you provide (implementation language, general design)?

This project is relevant to my interests... if you like Python at all, I'm in the middle of writing a very flexible TI-BASIC interpreter (it's almost to the point of running normal programs, can parse and execute simple ones already)

13
TI Z80 / Re: TIConvert
« on: July 18, 2011, 10:24:11 pm »
I just started a Python TI-BASIC implementation a few weeks back. It's actually doing pretty well.

My parser/tokenizer implementation is here
I'm using a list of tokens and simply comparing each token (sorted from longest to shortest) against my position in the text until I find a match, then incrementing my position by the length of the match. It's worked perfectly so far with many tests, and it's extremely fast (5000 lines / 70k characters took <1s to tokenize). If you take away the cruft for expressions and bracket parsing, it might be useful for your purposes :)

This commit has the raw token lists, the current version is all dynamic. The full parser from that commit might actually be useful, as it's the raw version with just string output.

Pages: [1]