Introducing Structured Extended BASIC and TiCodEd

[+Vorticon]

One little detail: when editing an SXB text and you click beyond the end of a program line or an empty line, the cursor does snap to the last character on the line or the beginning of an empty line but rather stays where the mouse click occurred. This is a little annoying as you have to make sure you position the mouse cursor exactly after the last character if you want to make additions or deletions to the end of that line, a frequent occurrence.

 

One more thing: if a label has an underscore in it, it does not get translated to a line number. For example, scroll_right does not work, but scrollright does. Not a big deal but it may affect readability for long label names.

Edited July 15, 2021 by Vorticon

[SteveB]

Hi everyone,

 

@grammostola and I today compiled TiCodEd for Mac OSX (Big Sur, Intel) and it works quite good. The Char Tab Preview doesn't work yet and there is actually no emulator with FIAD Support for the Mac. You may use Ralph's xdm99 to put the files into a disk-image using the "Post Processing" command on the Project Tab. You can find the Mac OSX Beta V 1.20 on http://lizardware.de/

 

Any Mac Users out there?

 

Steve and Grammostola

[+dhe]

I've been doing some coding the TiCodEd.

 

I think there is an area that can be improved.

 

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      one(x,y)=z
  next y
next x  


// define a zero
data 0,0,0,0,0,0
data 0,0,1,1,0,0
data 0,1,0,0,1,0
data 1,0,0,0,0,1
data 1,0,1,1,0,1
data 1,0,0,0,0,1
data 0,1,0,0,1,0
data 0,0,1,1,0,0

xb output
430 data 0,0,0,0,0,0
440 data 0,0,1,1,0,0
450 data 0,1,0,0,1,0
460 data 1,0,0,0,0,1
470 data 1,0,1,1,0,1
480 data 1,0,0,0,0,1

 

1) TiCodEd seems to violate it's own rules, the docs, say to put data statements in to the 20000 line numbers.

2) restore works with line numbers, the code above breaks down in to a new line for each line, which is logical, but I think it would be better to have a databegin and dataend statement so each blob of data went in to a single line to work more hand in hand with the restore statement, a simple warning could be issued the your data blob broke the length of a single line.

 

  My code above reads in a char def for 0, I have a 8 digits left. Anyone know of a good way to load arrays one, two, etc, with out resorting to 8 more double for loops?

 

 

 

[+dhe]

I finished a toy project in TICodEd. It's **AMAZING** the difference it makes in coding. Sooo Much Easier.

A big thanks to Steve for TICodEd and his help with questions I had along the way.

 

 

 

// comment 07-25-2021
call clear
call screen(9)
call color(5,2,9)

call char(65,"0000000000000000")
call char(66,"FFFFFFFFFFFFFFFF")


// data setup
dim zero(8,6)
dim one(8,6)
dim two(8,6)
dim three(8,6)
dim four(8,6)
dim five(8,6)
dim six(8,6)
dim seven(8,6)
dim eight(8,6)
dim nine(8,6)

// open clock
OPEN #1:"CLOCK"

// read clock
INPUT #1:A$,B$,C$


print "Loading arrays " ; c$
// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      zero(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      one(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      two(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      three(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      four(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      five(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      six(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      seven(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      eight(x,y)=z
  next y
next x

// load array for digit display
for x=0 to 7
  for y=0 to 5
      read z
      nine(x,y)=z
  next y
next x
INPUT #1:A$,B$,C$
print "Finished array " ; c$ ;

begin:
INPUT #1:A$,B$,C$

// make numbers of time
// on gosub doesn't work with zero, have to fake it
t1=asc(seg$(c$,1,1))
t1=t1-47
t2=asc(seg$(c$,2,1))
t2=t2-47
t3=asc(seg$(c$,4,1))
t3=t3-47
t4=asc(seg$(c$,5,1))
t4=t4-47
// print t1;t2;t3;t4

// get numbers in date
d1=asc(seg$(b$,1,1))
d1=d1-47
d2=asc(seg$(b$,2,1))
d2=d2-47
d3=asc(seg$(b$,4,1))
d3=d3-47
d4=asc(seg$(b$,5,1))
d4=d4-47

// print first digit - time
srow = 2
scol = 1
on t1 gosub pzero, pone, ptwo, pthree, pfour, pfive, psix, pseven, peight, pnine

// print second digit
srow = 2
scol = 09
on t2 gosub pzero, pone, ptwo, pthree, pfour, pfive, psix, pseven, peight, pnine

// print third digit
srow = 2
scol = 19
on t3 gosub pzero, pone, ptwo, pthree, pfour, pfive, psix, pseven, peight, pnine

// print fourth digit
srow = 2
scol = 27
on t4 gosub pzero, pone, ptwo, pthree, pfour, pfive, psix, pseven, peight, pnine


// print first digit - date
srow = 12
scol = 1
on d1 gosub pzero, pone, ptwo, pthree, pfour, pfive, psix, pseven, peight, pnine

// print second digit
srow = 12
scol = 09
on d2 gosub pzero, pone, ptwo, pthree, pfour, pfive, psix, pseven, peight, pnine

// print third digit
srow = 12
scol = 19
on d3 gosub pzero, pone, ptwo, pthree, pfour, pfive, psix, pseven, peight, pnine

// print fourth digit
srow = 12
scol = 27
on d4 gosub pzero, pone, ptwo, pthree, pfour, pfive, psix, pseven, peight, pnine


while s=0
  call key(0,k,s)

  // read clock
  INPUT #1:d$,e$,f$

  // tt = time test
  tt=asc(seg$(f$,5,1))
  tt=tt-47

  if t4 <> tt then goto begin

endwhile
end
// end of main program



// subroutines begin here

pzero:
for x=0 to 7
  for y=0 to 5
      If zero(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

pone:
for x=0 to 7
  for y=0 to 5
      If one(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

ptwo:
for x=0 to 7
  for y=0 to 5
      If two(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

pthree:
for x=0 to 7
  for y=0 to 5
      If three(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

pfour:
for x=0 to 7
  for y=0 to 5
      If four(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

pfive:
for x=0 to 7
  for y=0 to 5
      If five(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

psix:
for x=0 to 7
  for y=0 to 5
      If six(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

pseven:
for x=0 to 7
  for y=0 to 5
      If seven(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

peight:
for x=0 to 7
  for y=0 to 5
      If eight(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return

pnine:
for x=0 to 7
  for y=0 to 5
      If nine(x,y)=0 then call hchar(srow+x,scol+y,65,1) else call hchar(srow+x,scol+y,66,1)
  next y
next x
return


// data statements

// define a zero
data 0,0,0,0,0,0
data 0,0,1,1,0,0
data 0,1,0,0,1,0
data 1,0,0,0,0,1
data 1,0,1,1,0,1
data 1,0,0,0,0,1
data 0,1,0,0,1,0
data 0,0,1,1,0,0

// define a one
data 0,1,1,1,0,0
data 1,1,1,1,0,0
data 1,0,1,1,0,0
data 0,0,1,1,0,0
data 0,0,1,1,0,0
data 0,0,1,1,0,0
data 0,0,1,1,0,0
data 1,1,1,1,1,1

// define a two
data 0,1,1,1,0,0
data 1,0,0,0,1,0
data 0,0,0,0,0,1
data 0,0,0,0,1,0
data 0,0,0,1,0,0
data 0,0,1,0,0,0
data 0,1,0,0,0,0
data 1,1,1,1,1,1

// define a three
data 0,0,1,1,0,0
data 0,1,0,0,1,0
data 1,0,0,0,0,1
data 0,0,1,1,1,0
data 0,0,1,1,1,0
data 1,0,0,0,0,1
data 0,1,0,0,1,0
data 0,0,1,1,0,0

// define a four
data 0,0,0,1,1,0
data 0,0,1,0,1,0
data 0,1,0,0,1,0
data 1,1,1,1,1,0
data 0,0,0,0,1,0
data 0,0,0,0,1,0
data 0,0,0,0,1,0
data 0,0,0,0,1,0

// define a five
data 1,1,1,1,1,1
data 1,0,0,0,0,0
data 1,0,0,0,0,0
data 0,1,1,1,0,0
data 0,0,0,0,1,0
data 0,0,0,0,0,1
data 0,0,0,0,0,1
data 1,1,1,1,1,0

// define a six
data 0,0,0,1,1,0
data 0,0,1,0,0,0
data 0,1,0,0,0,0
data 1,0,1,1,0,0
data 1,0,0,0,1,0
data 1,0,0,0,0,1
data 0,1,0,0,1,0
data 0,0,1,1,0,0

// define a seven
data 1,1,1,1,1,1
data 0,0,0,0,1,0
data 0,0,0,0,1,0
data 0,0,0,1,0,0
data 0,0,0,1,0,0
data 0,0,1,0,0,0
data 0,0,1,0,0,0
data 0,1,0,0,0,0

// define a eight
data 0,0,1,1,0,0
data 0,1,0,0,1,0
data 1,0,0,0,0,1
data 0,1,0,0,1,0
data 0,0,1,1,0,0
data 0,1,0,0,1,0
data 0,1,0,0,1,0
data 0,0,1,1,0,0

// define a nine
data 0,0,1,1,0,0
data 0,1,0,0,1,0
data 1,0,0,0,0,1
data 0,1,0,0,1,0
data 0,0,1,1,0,1
data 0,0,0,0,0,1
data 0,0,0,0,1,0
data 0,0,1,1,0,0

// define a example
data 0,0,0,0,0,0
data 0,0,0,0,0,0
data 0,0,0,0,0,0
data 0,0,0,0,0,0
data 0,0,0,0,0,0
data 0,0,0,0,0,0
data 0,0,0,0,0,0
data 0,0,0,0,0,0

end

// ; - adjacent, , - next 14 char field, : - next line.
// todo - add analog digital clock roll over effect       

 

 

 

 

[SteveB]

On 7/21/2021 at 11:55 PM, dhe said:

1) TiCodEd seems to violate it's own rules, the docs, say to put data statements in to the 20000 line numbers.

2) restore works with line numbers, the code above breaks down in to a new line for each line, which is logical, but I think it would be better to have a databegin and dataend statement so each blob of data went in to a single line to work more hand in hand with the restore statement, a simple warning could be issued the your data blob broke the length of a single line.

ad 1.) you missed an "i.e." in the manual, this is just a suggestion to include some few line numbers in your code to build these blocks. Except for SUB commands, which have to be last in the program, DATA and GOSUB-Routines may be in any order in your program, so automatic assignments would be difficult. You could include a "20000" in front of the first DATA statement to increase the line-number counter to this value.

ad 2.) This would mean that I keep track of all RESTORE commands, because I have to make sure that this line is adressable. Quite easy for labels, as I could combine any DATA statements without a label, but as you may also continue to use line-numbers, this would not work. To be safe, I could combine DATA statements without labels and without line-numbers, right. But for what benefit? It would save some bytes, but would sacrifice my goal to create good maintainable XB code. I would rather leave this to the programmer to decide.

 

Your program is a really nice example. You should insert another "INPUT #1:A$,B$,C$" before the "print "Finished Array " ; c$ ;", otherwise you will always output the same time twice.

 

[+dhe]

>Your program is a really nice example. You should insert another "INPUT #1:A$,B$,C$" before the "print "Finished Array " ; c$ ;", otherwise you will always output >the same time twice.

 

Thanks, I think that must have gotten deleted in an edit, the purpose was to show the usefulness of having a clock available to time subroutines and so that you can optimize for speed.

[+Vorticon]

I noticed that if a label does not exist or is misspelled when referenced, TICODED does not throw an error but happily just includes the name of the label in the code. Interestingly, XB does not throw an error either when it encounters that label and so that creates unexpected program flows when running the program.

[SteveB]

6 hours ago, Vorticon said:

I noticed that if a label does not exist or is misspelled when referenced, TICODED does not throw an error but happily just includes the name of the label in the code. Interestingly, XB does not throw an error either when it encounters that label and so that creates unexpected program flows when running the program.

Yes, there is no check like in SUB/CALL. I will check if I can add some checking, but this is more complicated as you see at first glance. You may check if there is a non-number following GOTO or RESTORE. ON GOTO gets more tricky. Okay, let's check for numbers and comma. But how about IF THEN ELSE? There might be a number or a valid statement. How to distinguish this easily ...?  I will see if I have a clever idea, I don't want the program to become unmaintainable. Perhaps I can check in the tokenizer that there must not be an unquoted string after certain token.

 

XB should give an syntax error. What kind of unexpected program flow did you get?

 

I will also check if the underscore-label is possible or list it under "limitations" in the docs.

 

[+Vorticon]

4 hours ago, SteveB said:

Yes, there is no check like in SUB/CALL. I will check if I can add some checking, but this is more complicated as you see at first glance. You may check if there is a non-number following GOTO or RESTORE. ON GOTO gets more tricky. Okay, let's check for numbers and comma. But how about IF THEN ELSE? There might be a number or a valid statement. How to distinguish this easily ...?  I will see if I have a clever idea, I don't want the program to become unmaintainable. Perhaps I can check in the tokenizer that there must not be an unquoted string after certain token.

 

XB should give an syntax error. What kind of unexpected program flow did you get?

 

I will also check if the underscore-label is possible or list it under "limitations" in the docs.

 

In the case of the program I am working on, the program simply ignores the label and keeps going, eventually running into a subroutine and then I get an error when RETURN is encountered without a proper GOSUB.

On further thought, I do have an ON ERROR statement early on, so it might be ignoring the erroneous label upon first encounter, and then reverting to normal behavior afterwards which is STOP on any subsequent error.

Edited August 4, 2021 by Vorticon

[+dhe]

I was just reading the section on "ON ERROR" today.... Sounds like something I would need to write some experiential programs to understand..

 

Note: A transfer of control following the execution of an ON ERROR statement acts like the execution of a GOSUB statement. As with GOTO and GOSUB, you must avoid transfers to and from subprograms. The most common result of an illegal transfer into a subprogram is a syntax error on a statement that appears to be correct.
[See \articles\raguse\xbmisc\xbmisc.pdf, XB Miscellany #3, for more information on the above paragraph.— Cyc Ed.]

 

 

[+TheBF]

IMHO this is one of the cool features of XB. It let's you handle errors the way we see it done in more modern languages. 

It's great to be able to trap things like a bad file name typed into the system by a user for example.

It does add a layer of responsibility to the programmer but it makes your programs more polished rather than bouncing out to the BASIC interpreter.

 

1 hour ago, dhe said:

I was just reading the section on "ON ERROR" today.... Sounds like something I would need to write some experiential programs to understand..

 

Note: A transfer of control following the execution of an ON ERROR statement acts like the execution of a GOSUB statement. As with GOTO and GOSUB, you must avoid transfers to and from subprograms. The most common result of an illegal transfer into a subprogram is a syntax error on a statement that appears to be correct.
[See \articles\raguse\xbmisc\xbmisc.pdf, XB Miscellany #3, for more information on the above paragraph.— Cyc Ed.]

 

 

 

[+Vorticon]

In TidBit, one can place a .. at the end of a line to indicate that it continues on the next line. This is extremely helpful in creating a more structured look when using long IF statements. For example:

IF MOUSE=1 THEN MOUSE=0::MFLAG=1::CALL LINK("MCLR")::CALL DELSPRITE(#1)::GOSUB cursor ELSE mouseon

With TidBit, this can be broken into the following:

IF MOUSE=1 THEN ..
   MOUSE=0::
   MFLAG=1::
   CALL LINK("MCLR")::
   CALL DELSPRITE(#1)::
   GOSUB cursor ..
ELSE mouseon

which is far more readable. Can this be implemented in TICoded by any chance?

 

 

[RXB]

2 hours ago, Vorticon said:

In TidBit, one can place a .. at the end of a line to indicate that it continues on the next line. This is extremely helpful in creating a more structured look when using long IF statements. For example:

IF MOUSE=1 THEN MOUSE=0::MFLAG=1::CALL LINK("MCLR")::CALL DELSPRITE(#1)::GOSUB cursor ELSE mouseon

With TidBit, this can be broken into the following:

IF MOUSE=1 THEN ..
   MOUSE=0::
   MFLAG=1::
   CALL LINK("MCLR")::
   CALL DELSPRITE(#1)::
   GOSUB cursor ..
ELSE mouseon

which is far more readable. Can this be implemented in TICoded by any chance?

 

Hmm you can write this like that in RXB using my DV80 converter  called CALL USER("DSK#.BATCHFILE")

But what are these .. as that would crash XB?

There is nothing in symbol table like .. that exists, must be in TidBit only?

 

[SteveB]

3 hours ago, Vorticon said:

In TidBit, one can place a .. at the end of a line to indicate that it continues on the next line. This is extremely helpful in creating a more structured look when using long IF statements.

Yeah, that should be possible. I have noted it on the Version 1.3 wishlist.

 

Funny, I didn't remembered this one, even I was porting TidBit first when I started TiCodEd. And it works only partially in my port.

 

For long IF-THEN-ELSE the new version will feature a BEGIN-END, which comes at the cost of a GOSUB-RETURN in XB. It generates a subroutine, but saves you from the line-length limit. And will be nestable. 

[SteveB]

17 minutes ago, RXB said:

Hmm you can write this like that in RXB using my DV80 converter  called CALL USER("DSK#.BATCHFILE")

But what are these .. as that would crash XB?

There is nothing in symbol table like .. that exists, must be in TidBit only?

Yes, this is really just a feature of the pre-processor, not visible in the resulting XB code anymore.

[RXB]

3 hours ago, SteveB said:

Yeah, that should be possible. I have noted it on the Version 1.3 wishlist.

 

Funny, I didn't remembered this one, even I was porting TidBit first when I started TiCodEd. And it works only partially in my port.

 

For long IF-THEN-ELSE the new version will feature a BEGIN-END, which comes at the cost of a GOSUB-RETURN in XB. It generates a subroutine, but saves you from the line-length limit. And will be nestable. 

RXB just ignores spaces so you do not need oddball things at end of lines like ..

Again the only line limit is in the CRUNCHED code there is no limit on number of lines or line text in DV80.

Example:

If MOUSE=1 THEN

    MOUSE=0 ::

       MFLAG-1 ::

         CALL LINK("MCLR") ::

           CALL DELSPRITE(#1) ::

ELSE

  MOUSEON 

carriage return character 13

 

A CHARACTER 13 (ENTER KEY) or Carriage Return marks the end of lines. TI writer type files or FW can do this.

See no need for goofy .. to denote that the line continues, just ignore spaces. (Well unless in QUOTE MARKS)

[+dhe]

I've always wanted to see if I could improve on TI Base (the star trek like game clone TI put out as demo).

What would be the best path to convert an existing XB (I think it's XB) game to TICodEd?

[+OLD CS1]

FWIW, the ".." is not necessary in TIdBiT for line continuations in IF-THEN-ELSE statements.

[+Vorticon]

Rich, your DV80 conversion program requires line numbers to be included in the text and cannot use symbolic labels for jumps etc... While a huge step up from using the XB editor directly, it only makes sense for development on real hardware. It is also slow in the conversion process, so for long programs this could get painful.

For an emulated environment, TICoded provides a cleaner path with no line numbers, symbolic labels and advanced loops while providing nearly instantaneous conversion and direct writing to a FIAD disk.

Each has its uses depending on the environment used.

[+Vorticon]

23 minutes ago, OLD CS1 said:

FWIW, the ".." is not necessary in TIdBiT for line continuations in IF-THEN-ELSE statements.

That is actually true! I had forgotten that...

[RXB]

1 hour ago, Vorticon said:

Rich, your DV80 conversion program requires line numbers to be included in the text and cannot use symbolic labels for jumps etc... While a huge step up from using the XB editor directly, it only makes sense for development on real hardware. It is also slow in the conversion process, so for long programs this could get painful.

For an emulated environment, TICoded provides a cleaner path with no line numbers, symbolic labels and advanced loops while providing nearly instantaneous conversion and direct writing to a FIAD disk.

Each has its uses depending on the environment used.

Yes it is EXTENDED BASIC and is backwards compatible with TI BASIC.

And can be instantly changed and checked in less time then Compilers as there are no steps to put in a line and test it.

There are several steps to do the same thing with a Compiler. Yes last result is faster but writing with a compiler is slower.

I should know I have been doing this with GPL and Assembly for over 30 years now.

It may take longer to run that program at start but typing in a line then typing run beats the hell out of a compiler.

[SteveB]

10 hours ago, Vorticon said:

11 hours ago, OLD CS1 said:

FWIW, the ".." is not necessary in TIdBiT for line continuations in IF-THEN-ELSE statements.

That is actually true! I had forgotten that...

I was just ready implementing it ... 

 

Okay, now when the line ends with THEN or ELSE the next line is joined as well.

 

[+Vorticon]

1 hour ago, SteveB said:

I was just ready implementing it ... 

 

Okay, now when the line ends with THEN or ELSE the next line is joined as well.

 

Is this change in version 1.2? 

 

IF MOUSE=1 THEN
   MOUSE=0::MFLAG=1::
   CALL LINK("MCLR")::
   CALL DELSPRITE(#1)::
   GOSUB cursor
ELSE
    mouseon 

gets translated to this

 

1080 IF MOUSE=1 THEN
1090 MOUSE=0::MFLAG=1::
1100 CALL LINK("MCLR")::
1110 CALL DELSPRITE(#1)::
1120 GOSUB 3620
1130 ELSE
1140 mouseon

which is obviously all wrong...

And some kind of line continuation symbol like .. is still needed to join the end of the THEN block with the ELSE block.

Edited August 7, 2021 by Vorticon

[RXB]

45 minutes ago, Vorticon said:

Is this change in version 1.2? 

 

IF MOUSE=1 THEN
   MOUSE=0::MFLAG=1::
   CALL LINK("MCLR")::
   CALL DELSPRITE(#1)::
   GOSUB cursor
ELSE
    mouseon 

gets translated to this

 

1080 IF MOUSE=1 THEN
1090 MOUSE=0::MFLAG=1::
1100 CALL LINK("MCLR")::
1110 CALL DELSPRITE(#1)::
1120 GOSUB 3620
1130 ELSE
1140 mouseon

which is obviously all wrong...

And some kind of line continuation symbol like .. is still needed to join the end of the THEN block with the ELSE block.

This is why my approach is much more simple here. i.e. just ignore spaces until you get a Carriage Return as that would be end of line.

Or error out if line is to long as above. (But the above example would not crash RXB)

Bonus is you can arrange the text anyway you want.

[SteveB]

43 minutes ago, Vorticon said:

Is this change in version 1.2? 

No, this is in the upcomming version 1.3 I am currently working on. I will join the source-next line when

• the last command is a THEN
• the last command is a ELSE
• the last command is a ::
• the last command is a .. and remove the .. inbetween

is this the desired behaviour?

 

In my development-version 1.3 alpha it gets translated to:

100 IF MOUSE=1 THEN MOUSE=0::MFLAG=1:: CALL LINK("MCLR"):: CALL DELSPRITE(#1):: GOSUB cursor
110 ELSE mouseon

As I do a sequential read and do not know the next line the .. after the GOSUB is needed, then it works like

100 IF MOUSE=1 THEN MOUSE=0::MFLAG=1:: CALL LINK("MCLR"):: CALL DELSPRITE(#1):: GOSUB cursor  ELSE mouseon

I will send you a private message when I am in a beta-state with 1.3, also to test the CASE and BEGIN-END feature, if you like.

 

Steve