27 replies to this topic

[CrimsonCasio]

ok guys, 4nic8 no longer has time to program calculators, thus MLCafx is no longer being developed... meanwhile MLC86 is leagues ahead with support for multiple files, compressed files, and other massive improvements over the current version of MLCafx...

basically, what im saying is that we need a new programmer for MLCafx, i need a dedicated person for the job, we need to catch up with MLC86 so that we can play the same games they can and developement on all models can continue (atm many of the testers use the AFX version).

anyway, if your willing to take over the AFX developement please let me know, the whole project is threatened because of this

[Bob Vila]

i will help in whatever way i can, but i'm definatly don't have the coding skillz 4nic had...

[Orwell]

I'm interested, but I think I won't have enough time for this during the next 2 months...

[DJ Omnimaga]

I'm sorry to hear that. At least will he EVER come back once more on the EPS forum to say goodbye to everyone (like everyone does when they leave the TI community)?

Gimpynerd said he would probably make the TI-68k version in TIGCC after finishing the TI-83+ version but he cannot start before june 27th because of his parents (on june 27th he move out of his parent home) so maybe it will be easy then to port the 68k version to AFX

[octobclrnts]

It should be fairly easy to port considering they both know assembly. I will be very interested in the TI-68k version so when that comes you should post (if you find out first).

[huhn_m]

I could help but I don't have the time to code it in ASM.

I'd port it to pascal using Marcos libs. But you have to wait about 4 weeks since:

Tuesday 17th -> German final exam
Wendsday 18th -> English final exam
Monday 23rd -> Maths final exam
3 weeks later -> Final oral exam in History ...

so I'm quite busy till then but afterwards I'm gonna do my "community service" (I called it civil service before but my teacher told me that this was the wrong expression) and have some time then. Maybe I'm also gonna get myself a notebook soon Then I've even more time.

But I need the latest COMPLETE sources to use the same internal bytecode or I'd make my own bytecode format if you don't mind

[DJ Omnimaga]

I think the AFX version is written in C

EDIT: Maybe you should post this on the FCC and the Graph100 forum, even though most people here speak french maybe they could be able to help too

[Orwell]

It should be fairly easy to port considering they both know assembly.

<{POST_SNAPBACK}>

But it's a different processor, thus it's another assembly language... This comparison is a bit odd

But I don't understand why you're speaking about the assembly language for MLCafx: 4nic8 has written the current version in C, the main purpose now is to maintain the code updated and add some new features right? I think it would be a loss of time to rewrite it completely

[DJ Omnimaga]

I agree. Also I guess C on AFX is almost the same than on TIGCC for 68k calcs so it might be easy to port

[CrimsonCasio]

well, actually a few parts of MLC may need to be re-written as they are now totally diffrent in MLC86. but most of it should be valid.

I was hoping you would have time orwell since you already helped nic out so much on what has already been done... but alas... :|

[Orwell]

Also I guess C on AFX is almost the same than on TIGCC for 68k calcs so it might be easy to port

I don't think so... Ti programmers use a a lot of "special features" that we don't have on afx, I'm sure this would'nt be such a simple work

I was hoping you would have time orwell since you already helped nic out so much on what has already been done... but alas... :|

Unfortunately like huhn I have some final exams to pass... And for me it's not 4 tests, but 10

[DJ Omnimaga]

ouch 10 tests? O_O Hopefully people will get some work done during the summer on MLC. I hope to see this come out on my 83+ and also on AFX

[Marco]

Maybe I also could help, but I have no time to do it all alone (I started a project for PC few weeks ago and decided to reduce my AFX coding efforts significant for it (in fact DFA was the last thing I wrote for the calc so far...)).

If there are different moduls of MLCafx (e.g. one for the compiler, one for the bytecode interpreter and one for the environment or something) I could assume one of them, but I definitely wouldn't have time to do them all, and, of course, the moduls should be Pascal then

So if there are any volunteers who wanna (re)write it in Pascal and also don't want to do it alone I could take part (else not). The only thing is that all would need to be done from scratch then again though 4nic did it already, I don't know if this makes much sense...

[huhn_m]

I already stated developing a new "bytecode" for myself.

If I send it to you you can do either the compiler (-> bytecode) or the interpreter, as you wish. Maybe we could work together

But I do still have to improve it since it has some flaws.

[CrimsonCasio]

remember that what ever we do has to be compatiable with MLC86

[huhn_m]

No problem since we won't change the language but only creatre our own bytecode format that is used internally only.

[Orwell]

I don't really see what advantages you would have by changing the bytecodes' format... Perhaps your new format will allow us to use some more complex or specific syntax, but like crimson said we have to stay compatible with the other MLC versions thus...
What did EPS decide about this? I think it's ok for each version to use some specific technics on each model, but we must be sure that if some improvement is made on the common MLC language it will be possible to implement it "easily" on all versions

[huhn_m]

the bytecode is totally irrelevant for the different models.
It is just used to speed up the code. Only the code is given on
and not the bytecode. The code is compiled for every calculator.
This is how I understood it.

So it should be no problem if we use our own bytecode since
nobody except the interpreter programmers ever get to know it.

I also found NO definition for a MLC bytecode so I don't even have a basis to use. Since I'm not willing to find the bytcode out of 4nic8s sources
I thought we could compose our own.

If this is not OK with you then please give me your bytecode specifications
that are defined with MLC

[CrimsonCasio]

there really isnt any, each version internally uses what ever it can to best fit the calculator model it works with, however, any bytecode generated must be storable in a basic file as MLC now supports compressed (bytecode) programs and multiple files (which if not compressed already must be compressed durring run-time).

[Marco]

however, any bytecode generated must be storable in a basic file as MLC now supports compressed (bytecode) programs and multiple files

Should they also be transmittable by FA-123? Then a few codes couldn't be used wich would lead to bigger code files. But I think as the interpreters use different bytecodes anyways this isn't implicitly needed (you have to compile each program at least one time on a calc)

Btw, are there also any docs about the latest MLC specification? (syntax, commands and so on)

[CrimsonCasio]

no need to have the bytecode FA-123 complaint, we plan to make a MLC transfer program eventually to interface with all the calcs using a simple .txt format for holding the programs.

i can get you the docs on MLC, i'll only provide the 86 version since the afx is so out of date. (will post links)

[CrimsonCasio]

this should be pretty much everything you need to know about MLC:

Commands:

DATA - Starts a data section
DEND - Ends a data section
BITM [name] [size] - (used in a data section) Creates a bitmap with a name of [name] and a height and width of [size]
ARRY [array name] [size] - Defines array [array name] with size of [size]
SIZE [varname 1] [int name] - Stores size of array or string [varname1] to [int name]
CLRS - Clears screen buffer
TEXT × [y] [string] [color] - Draws [string] at ×,[y] in [color]
LINE [x1] [y1] x² [y2] [color] - Draws line from [x1],[y1] to x²,[y2] in [color]
PIXL × [y] [color] - Sets pixel at ×,[y] to [color]
PIXT × [y] [int name] - Stores color of pixel at ×,[y] to [int name]
SPRT [sprite name] [bitmap name] - Creates a new sprite [sprite name], with the graphics data contained in [bitmap name] and a position of 0,0
DISP [sprite name] - Draws sprite [sprite name] (if sprite name is replaced with .0, all existing sprites are drawn)
DBMP [bitmap name] × [y] - Draws bitmap [bitmap name] at ×,[y]
CLSN [sprite name 1] [sprite name 2] [int name] - Detects if [sprite name 1] and [sprite name 2] are colliding, sets [int name] to 1 if so, otherwise sets [int name] to 0
CLSN [sprite name] .0 [int name] [pointer name] - Detects if [sprite name] is touching any other existing sprites, if not sets [int name] to 0, otherwise sets [int name] to 1 and returns a pointer to the sprite that it's touching in [pointer name]
RECT [x1] [y1] x² [y2] [color1] [color2] - Draws a box from [x1],[y1] to [x2,y2] with line color of [color1], fill color of [color2]
DRAW - Draws contents of screen buffer to screen (all graphics operations draw to buffer)
STOP - Stores the contents of the screen buffer
RCLP - Recalls the saved screen buffer
SHFT × [y] [mode] - Shifts the screen buffer horizontally by × and vertically by [y], loops if [mode] is -1, otherwise fills the area with color specified by [mode]
GKEY [keycode] [int name] - Sets [int name] to 1 if the key [keycode] is pressed, otherwise sets [int name] to 0
WKEY [int name] - Waits for a key to be pressed, then stores the keycode to [int name]
PAUS - Waits until Enter is pressed
FNCT [name] - Defines a function with a name of [name]
FRUN [name] - Runs the function [name]
FGOB - Jumps to the beginning of the current function
FEND - Returns from the current function, continuing execution after the line where the function was called
IIFF [conditional expression] - If [conditional expression] is true, executes the next line, otherwise skips it
RNDM [lower limit] [upper limit] [int name] - Generates a random number between [lower limit] and [upper limit], inclusive, and stores it to [int name]
HALT - Ends the program
WAIT [delay] - Waits for a time determined by [delay] before continuing
WRTE [position] [varname] - Writes the contents of [varname] to position [position] in the program's data string
READ [position] [varname] - Reads the data from position [position] in the program's data string and stores it in [varname] (must be the same type of var as the stored data!!!)
POLR [length] [angle] [x int name] [y int name] - Converts the polar vector of [length], [angle] to a rectangular vector and stores the x portion in [x int name] and the y portion in [y int name]
SUBS [string] [starting position] [ending position] [string name] - Stores the segment of [string] from [starting position] to [ending position] in [string name]
RSET - Restarts the program (useful for returning to the title menu of a game, etc.)
CINT [string] [int name] - Converts the string [string] to a number and stores it in [int name] (negative numbers allowed)
ABSL [number] [int name] - Finds the absolute value of [number] and stores it in [int name]
INPT × [y] [prompt] [color] [var] - Displays [prompt] in [color] at ×, [y], waits for a number or string (depends on the type of [var]), and stores it to [var]
NMAP [width] [height] [map name] - Creates a tilemap with a name of [map name] and dimensions of [width] and [height]
TILE [map name] [bitmap 1] [bitmap 2]... - Sets the specified bitmaps in [map name] to be "solid"
CMAP [map name] [sprite name] [x array] [y array] - Finds where each corner of [sprite name] is touching [map name] and stores the positions of the map elements in [x array] and [y array] (the position of [map name] is determined from the position it was last drawn with DMAP)
TCHK [map name] [x array] [y array] [int name] - Checks each of the map elements specified by [x array], [y array] in [map name] - if any of them are "solid", [int name] is set to 1, otherwise [int name] is set to 0
DMAP × [y] [map name] - Draws [map name] with the top left corner at ×,[y]


Arguments:

[number]: Any numerical expression, can involve variables, numbers (preceded with a '.'), sprite properties, the 4 basic operators, and the modulus operator ('|')
[int name]: The name of an integer variable, preceded by a % (array elements are also allowed for most commands - for example, "#PIXT .0 .5 @COLOR(%X)"
[string name]: The name of a string variable, preceded by a '$'
[array name]: The name of an array variable, preceded by a '@'
[bitmap name]: The name of a bitmap defined in a data section, preceded with a '['
[sprite name]: The name of a sprite object, preceded with a '^'
[pointer name]: The name of a pointer, preceded with a '*'
[map name]: The name of a tilemap, preceded with a '{'
[color]: The color for a graphics operation: 0 is white, 1 is light gray, 2 is dark gray, 3 is black, 4 is inverted, and 5 is transparent (only allowed in rectangles)
[keycode]: A number representing a key: 10*row+col (on TI calcs, 4th row is skipped)
[conditional expression]: For example: "%A+.2<.73"  Separate expression segments can be separated with '&', and the expression will only be true if each segment is true - for example: "%A<%B&%B<%C&%C<%D"


Valid expressions (examples):

conditional
numerical
  (valid conditional operators are <, >, =, !, and &)
  %POS+.3=%X/.8
  @ARRAY(.8)>.2
  %A=%B&%C=%D
string
  (valid conditional operators are = and !)
  $STR="TI86"
  $STR1!$STR2
bitmap
  (valid conditional operators are = and !)
  ^SPR.BMP=[BMP1
  ^SPR1.BMP!^SPR2.BMP
numerical
  %A=%A+.3-%B/.7
  %NUM=@ARY(%I+.1)-.2
  %INT+ (increments %INT)
  %INT- (decrements %INT)
  %INT+=.2 (same as %INT=%INT+.2)
  %INT-=.2 (same as %INT=%INT-.2)
  %INT/=.4 (same as %INT=%INT/.4)
  %INT*=.4 (same as %INT=%INT*.4)
array / tilemap
full definition
  @ARRAY=.3 .2 .0 .89 %NUM %NUM2+.1
  {MAP=[BMP1 [BMP2 [BMP3 [BMP4
single element
  @ARRAY(.1)=.7
  {MAP(.1 .2)=^SPR.BMP
string
  $STR="A test string"
  $STR=$STR+" "+$INP
  $STR=%INT+.3
  $STR="Score:"+%SCR
sprite properties
  ^SPR1.X=.2
  ^SPR1.Y=^SPR2.X+%VX
  ^SPR.VX=.3
  ^SPR.VY=.0-^SPR.VY
  ^SPR.DX=.50
  ^SPR.DY=^SPR3.X*.10
assigning pointers
  *PTR:%INT
  *PTR:@ARRAY
  *PTR:$STR
  *PTR:^SPR
  *PTR:[BMP
  *PTR:{MAP

[huhn_m]

thank you a lot. This makes our work easier

We already thought about the VM and the bytecode.

So pointers do actually exist (you should update the docs on your site)

Another question:
is it still the case that 5+3*4 = 32
or did you change it. (no recogition of order of operations makes work easier)

Thanks huhn_m

(But you have to wait at least for 2 weeks till work beginns because of
my final exams.)

I'm gonna do the bytecode translator and Marco will do the interpreter part.

[DJ Omnimaga]

you should post updates in the MLCafx section of the EPS forum too

[CrimsonCasio]

yeah, that would be nice.

always remember that the 86 doc's are correct, the afx doc's are correct for the current version of MLCafx.

and of course any comentary you have on are decisions about MLC would be appreciated (perferably on the EPS mlc fourm to keep it all in one place).

thanks for the help guys

[huhn_m]

how can I reach them? I tried your sigs link but it is broken ...

[DJ Omnimaga]

yeah redirction domains sucks, they are always down, try http://dysfunction.e...forge.com/forum

[CrimsonCasio]

actually, thats our fault, dys hasnt updated to .co.nr account to the new server.