Finished XB Compiler

[senior_falcon]

The XB Compiler is finished (for now) and a zipped folder is attached to this post. There are 3 files. The docs are in a PDF file. The compiler is in an archived file COMPILER@ and the same files are also contained in a disk image for Win994a called "Extended BASIC Compiler".

 

I'm hoping to see some good programs created with this!

 

Dec. 29, 2012 - Be sure to load the updated version which you can find at XB Compiler v2.1 on this forum

Extended BASIC Compiler.zip

Edited December 30, 2012 by senior_falcon

[sometimes99er]

Excellent. Thanks.

[+Gemintronic]

I've seen ZX BASIC ported to other machines (there's even a Sega Master System port).

 

Is this project too tied to the TI hardware to even consider other platforms?

 

EDITED: For clarity.

[senior_falcon]

Since I have no idea what is meant by compartmentalized, I guess the answer must be no.

[+Gemintronic]

Since I have no idea what is meant by compartmentalized, I guess the answer must be no.

 

Sorry, not trying to sound smart - just a poor choice of words. I was wondering if the TI specific code was could be replaced with code for other platforms.

 

Again, I appologise if I sounded patronizing. I really no nothing of low level coding. Heck, I no nothing of sane high level language coding!

 

On that note, could you explain what "threaded" means in the context of your runtime engine? I assume that doesn't mean "multi-threaded" but something else?

[senior_falcon]

I think this compiler is too coupled to the TI to be used with other platforms. I could be wrong, but one thing I can say for sure is that it won't be done by me!

 

As far as threaded code is concerned - the first time I read the term was when Willsy stated that the compiler was a "direct threaded interpreter." Look at page two of "Extended Basic Compiler", about 60% of the way down for a listing of how an XB program is compiled. Then read the Wikipedia article on "Threaded code" and you'll know as much about it as I do.

[Willsy]

Threaded code is normally a list of addresses. But basically, you could say a 'thread' in this context is a list of things. An interpreter 'walks' this thread, reading each item in the thread sequentially and using some algorithm, it determines what exectable code to execute.

 

In the XB compiler the thread is a list addresses - executable code is found at those addresses. So the interpreter is very simple. In TI BASIC and XB the thread is a thread of "tokens" (token threaded code) where more work is required in order to find the actual code to execute to represent that token - perhaps a table look-up or a search of a table, for example.

 

HTH

 

Mark

[senior_falcon]

Thanks Mark! Boy, computerese is almost as bad as legalese for the uninitiated. But with a good explanation it makes sense.

 

BTW, to "the loon", you didn't sound "smart". It's just that I'm a little too dumb to understand what you were asking. After some thought, I think that it might be possible to write runtime routines in some more universal language than 9900 assembly code. But I sure wouldn't have a clue how to do it.

 

Harry

[RXB]

The term you might be looking for Harry is Cross Compiler.

Takes Assembly from one processor and turns it into Assembly for another processor.

 

I am very surprised that no one has done this for the TI 9900 given that this would be absolute fastest method to speed programs up from TI99/4A to PC.

 

You would pop in a TI program of Assembly and out pops a PC version that you can tweak.

Edited December 20, 2012 by RXB

[slinkeey]

Wouldn't that kill off your hobby faster?

[TheMole]

The term you might be looking for Harry is Cross Compiler.

Takes Assembly from one processor and turns it into Assembly for another processor.

 

That's not correct. A cross compiler is a compiler that runs on a different host platform from the target architecture. GCC for the TI is a cross-compiler that runs on Linux/x86 and targets the TMS9900, for instance.What you are talking about is a binary translator (http://en.wikipedia....ary_translation). And (un)fortunately (depending on who you ask), the current implementations are not nearly good enough to use in the "other" direction (fast PC to slow TI, for instance), so I don't think it's going to kill our hobby in the near future

[Bones-69]

I did the download and had a play with this today. Only being an XB programmer I can really see a lot of potential from this compiler and I was fascinated by the results. In short this is awesome!

[RXB]

I am running a BASIC program and keeps getting a Assembler error on 0141 but have no clue where that is as I get no Listing file to check?

How do you figure out what is wrong?

Edited December 24, 2012 by RXB

[senior_falcon]

Rich, can you post the basic listing here or else upload the program you are trying to compile?

[senior_falcon]

Rich, your description is a bit cryptic to diagnose. It's a bit like going to the doctor and saying "I have this pain in my side - what's wrong with me?"

 

I'll outline a couple of steps that you can do to help sort things out when there is a problem with the compiler.

 

1 - Sometimes the compiler does not like one or more of the statements in the XB program. Normally it will say "compiling Line 10" (or whatever the first line number is). If successful in compiling that line it will then say "compiling Line 20" and so on until it is done. If it gets stuck on a line number then there is something in that line that it doesn't like. Check the XB program and try to see which statement is unsupported. If you want to see this in action (actually in inaction) try to compile this program: 10 OPEN #1:"DSK3.TEST" and you will see it get stuck on line 10

 

2 - if the compiler was happy with your XB program you will get this option at the bottom of the screen:

Press:

1 - Compiler

2 - Assembler

3 - Loader

4 - End

Try assembling the program. If the assembler issues an error message then you should look in the source code file that the compiler created to see if there is anything that doesn't look right. You can use a text editor, the editor for the E/A cart, or TI99dir which lets you view a file. Except for the B @RUNEA5 there should be nothing but DATA statements, something like this:

 

DEF RUN,CON

RUNEA B @RUNEA5

FRSTLN

L100

FOR1

DATA FOR,NV1,NC1,NC2,ONE,0,0

DATA COLOR,NV1,NC3,NC4

DATA NEXT,FOR1+2

L110

DATA DISPLY,NC1,NC5,SC1,NC6,NC7

L120

FOR2

DATA FOR,NV2,NC3,NC8,ONE,0,0

DATA HCHAR,NV2,NC1,NC6,NC3

DATA NEXT,FOR2+2

L130

DATA AT,NC8,NC9

DATA SIZE,NC3

DATA ACCEPT,SV1

L140

DATA VREAD,NC10,NC3,SV2,NC11,NC3,SV3,NC12,NC3,SV4

DATA NC13,NC3,SV5

L150

DATA VWRITE,NC14,SV2,NC10,SV3,NC11,SV4,NC12,SV5

L160

DATA GOTO,L130

LASTLN DATA STOP

OPTBAS DATA 0

NC0

ZERO DATA 0

ONE DATA 1

PI DATA 3

(etc.)

The code the compiler creates should be understandable when compared to the original XB program. Look for a missing DATA statement or something that doesn't look right. If the assembler gives a line number you should be able to find it easily. If the assembler is giving an error message it should be in the source code file the compiler just made and not in the runtime routines. I like TI99dir to view files, but when you look at a file there are no line numbers and you have to count the lines by hand.

 

The third way the compiler can fail is if there is a bug in the runtime routines that makes the compiled program crash or behave differently than it does in XB. Doesn't sound like you got that far, though.

 

Post your results here so we can all learn.

[RXB]

The compiler works great it is the Assembler in EA or FW that crashes with the strange error in line 0141 but there is no listing so no way to figure out the problem.

Anyway here is the original.

 

100 CALL CLEAR
110 PRINT TAB(6);"**************"
120 PRINT TAB(6);"* SUPERCHASE *"
130 PRINT TAB(6);"**************"
140 CALL CHAR(96,"00183C7E7E3C18")
150 CALL COLOR(9,14,12)
160 PRINT: : : :"USE THE ARROW KEYS TO MOVE."
170 PRINT: :"TRY TO GATHER AS MANY"
180 PRINT:"TREASURES (`) IN THE MAZE"
190 PRINT:"AS POSSIBLE BEFORE THE"
200 PRINT:"ENEMY CATHES YOU!"
210 CALL COLOR(10,5,5)
220 CALL COLOR(11,12,12)
230 CALL CHAR(120,"383810FE10387CFE")
240 CALL COLOR(12,7,12)
250 CALL CHAR(128,"383810FE10387CFE")
260 CALL COLOR(13,16,12)
270 PRINT: : :"PRESS ANY KEY TO BEGIN.";
280 CALL KEY(0,K,S)
290 IF S<1 THEN 280
300 SC=0
310 LV=1
320 CALL CLEAR
330 CALL SCREEN(4)
340 FOR X=3 TO 21
350 CALL HCHAR(X,3,104,27)
360 NEXT X
370 RANDOMIZE
380 FOR I=1 TO 65
390 X=2*(INT(9*RND))+4
400 Y=2*(INT(11*RND))+4
410 CALL HCHAR(X,Y,112,5)
420 NEXT I
430 FOR I=1 TO 60
440 X=2*(INT(7*RND))+4
450 Y=2*(INT(13*RND))+4
460 CALL VCHAR(X,Y,112,5)
470 NEXT I
480 CALL HCHAR(4,4,112,5)
490 CALL VCHAR(4,4,112,5)
500 FOR I=1 TO 80
510 X=2*(INT(9*RND))+4
520 Y=2*(INT(13*RND))+4
521 CALL GCHAR(X-1,Y,PU)
522 CALL GCHAR(X+1,Y,PD)
523 CALL GCHAR(X,Y-1,PL)
524 CALL GCHAR(X,Y+1,PR)
528 IF PU=112 OR PD=112 OR PL=112 OR PR=112 THEN 530
529 GOTO 510
530 CALL HCHAR(X,Y,96)
540 NEXT I
550 ! SCORE
560 DISPLAY AT(23,3):"COLLECTED:"
580 CALL SOUND(100,1497,2)
590 T=0
600 IF LV<8 THEN 620
610 LV=7
620 A=4
630 B=4
640 C=4
650 D=4
660 PG=112
670 CALL HCHAR(A,B,120)
680 IF T<8-LV THEN 1410
690 IF FL=0 THEN 740
700 IF FL/2=INT(FL/2)THEN 1140
710 CCX=CX
720 CCY=CY
730 FL=0
740 CALL GCHAR(C+1,D,GC)
750 IF GC=120 THEN 1760
760 IF GC=104 THEN 810
770 IF GC<>128 THEN 810
780 CX=1
790 CY=0
800 GOTO 1340
810 CALL GCHAR(C,D+1,GC)
820 IF GC=120 THEN 1760
830 IF GC=104 THEN 880
840 IF GC<>128 THEN 880
850 CX=0
860 CY=1
870 GOTO 1340
880 CALL GCHAR(C-1,D,GC)
890 IF GC=120 THEN 1760
900 IF GC=104 THEN 950
910 IF GC<>128 THEN 950
920 CX=-1
930 CY=0
940 GOTO 1340
950 CALL GCHAR(C,D-1,GC)
960 IF GC=120 THEN 1760
970 IF GC=128 THEN 1320
980 IF GC=112 THEN 1320
990 FL=FL+1
1000 IF FL/2=INT(FL/2)THEN 1040
1010 CX=CCX
1020 CY=CCY
1030 GOTO 1160
1040 CX=SGN(A-C)
1050 CY=0
1060 IF CX<>0 THEN 1080
1070 CY=SGN(D-B)
1080 CALL GCHAR(C+CX,D+CY,GC)
1090 IF GC=104 THEN 1110
1100 IF(GC=96)+(GC=112)THEN 1340
1110 CX=-1
1120 CY=0
1130 GOTO 1160
1140 FL=FL+1
1150 IF FL>1 THEN 1300
1160 CALL GCHAR(C+CX,D+CY,GC)
1170 IF(GC=112)+(GC=96)+(GC=128)THEN 1340
1180 CX=1
1190 CY=0
1200 CALL GCHAR(C+CX,D,GC)
1210 IF(GC=112)+(GC=96)+(GC=128)THEN 1340
1220 CX=-1
1230 CALL GCHAR(C+CX,D,GC)
1240 IF(GC=112)+(GC=96)+(GC=128)THEN 1340
1250 CX=0
1260 CY=-1
1270 CALL GCHAR(C,D+CY,GC)
1280 IF(GC=112)+(GC=96)+(GC=128)THEN 1340
1290 CY=1
1300 CALL GCHAR(C+CX,D+CY,GC)
1310 IF GC=104 THEN 1390 ELSE 1340
1320 CX=0
1330 CY=-1
1340 IF PG=96 THEN 1360
1350 PG=112+FL
1360 CALL HCHAR(C,D,PG)
1370 C=C+CX
1380 D=D+CY
1390 CALL HCHAR(C,D,42)
1400 PG=GC
1410 CALL KEY(0,K1,S)
1415 IF INT(RND*9000)=0 THEN 670
1420 IF K1<8 OR K1>11 THEN 1410
1430 CALL HCHAR(A,B,128)
1440 ON K1-7 GOTO 1590,1640,1540,1690
1450 IF G<>96 THEN 670
1460 CALL SOUND(100,-1,4)
1470 SC=SC+1
1475 IF SC=28 THEN 300
1480 CALL HCHAR(24,2+SC,96)
1520 T=T+1
1530 IF T<45 THEN 670 ELSE 320
1540 CALL GCHAR(A+1,B,G)
1550 IF G=104 THEN 1740
1560 IF G=42 THEN 1760
1570 A=A+1
1580 GOTO 1450
1590 CALL GCHAR(A,B-1,G)
1600 IF G=104 THEN 1740
1610 IF G=42 THEN 1760
1620 B=B-1
1630 GOTO 1450
1640 CALL GCHAR(A,B+1,G)
1650 IF G=104 THEN 1740
1660 IF G=42 THEN 1760
1670 B=B+1
1680 GOTO 1450
1690 CALL GCHAR(A-1,B,G)
1700 IF G=104 THEN 1740
1710 IF G=42 THEN 1760
1720 A=A-1
1730 GOTO 1450
1740 CALL SOUND(-100,-5,4)
1750 GOTO 670
1760 CALL SOUND(200,-6,4)
1770 FOR I=1 TO 3
1780 CALL SCREEN(16)
1790 CALL SCREEN(9)
1800 CALL SCREEN(
1810 NEXT I
1820 PRINT "GOT CAUGHT!!!"
1830 PRINT "TRY AGAIN? (Y/N)";
1840 CALL KEY(0,K,S)
1850 IF K=89 THEN 300
1860 IF K<>78 THEN 1840
1870 CALL CLEAR
1880 END

 

I never understood why Assemblers do not still put out a LIST file and end at the point where it could not continue?

Edited December 24, 2012 by RXB

[senior_falcon]

OK, I've found out what is causing the problem, though I don't know why just yet. I copied and pasted the program listing into Classic 99. It seems to run just fine in XB, so I saved it in merge format and compiled it. No problems so far. When I assemble the source code file I get an error message "undefined symbol 0141" What this means is that line 141 of the source code file refers to a symbol that does not exist. I used TI99Dir to view the source code and didn't see anything that was obviously wrong. I copied the text from TI99Dir and pasted it in Notepad++ so I could see the line numbers. Aha!

Here are lines 139-141:

L529

DATA VALID

DATA GOTO,L256

It turns out there is no line 256

 

Here is the XB code:

524 CALL GCHAR(X,Y+1,PR)

528 IF PU=112 OR PD=112 OR PL=112 OR PR=112 THEN 530

529 GOTO 510

530 CALL HCHAR(X,Y,96)

 

I also checked that line 529 was GOTO 510 in the MERGE format file. It was.

So the compiler is causing the problem. I don't yet know why the line number is wrong and where the VALID came from - it may have something to do with line 528, though that looks right in the compiled code. I have to run some tests to see just what is going on. Unfortunately this is happening in the compiler and not the runtime routines. The compiler is 1/3 black magic, 1/3 smoke and mirrors, and 1/3 9900 assembly code.

 

Meanwhile, while that is being addressed, you need to make a few changes to the program. Lines 700 and 1000 need to be modified:

700 IF FL/2=INT(FL/2)THEN 1140

1000 IF FL/2=INT(FL/2)THEN 1040

FL/2 always equals the INT of FL/2 due to the integer arithmetic.

It looks like these lines are checking whether FL is even or odd. You could make the line:

700 IF (FL AND 1)=0 then 1140 and it should work the same way.

Another way would be:

700 IF FL=2*INT(FL/2) THEN 1140

 

Your problem led to discovery of another bug:

PRINT : : : compiles right but does not scroll the screen. That should be fairly easy to fix. This all worked in the BASIC compiler, but changes to make it compatible with XB seem to have broken it.

[RXB]

So I guess I was not doing anything wrong. Strange on my very first program I tried it crashed.

Wow what are the odds?

Thanks for the help.

Edited December 25, 2012 by RXB

[senior_falcon]

I've figured out where the error is in the compiler. It will be a few days before a fix can be implemented, but I can suggest a temporary fix. XB line numbers that end in >EB,>EF,>FE,>F0 and >EE do not compile correctly. This is a glitch that entered when I added some of the XB extras. In decimal the line numbers 235,238,239,240,254 are effected plus numbers made by adding 256, 512,768 etc to these. If you avoid 235 to 255, 490 to 510, etc. you will be safe.

One easy way to do this, at least for Riches program is to RES 1,1. The highest line number is under 200.

 

The scroll can be fixed with PRINT " ":" ": which should make it scroll twice.

[RXB]

Thank no rush enjoy the holidays.

[senior_falcon]

I took the "Superchase" program that Rich was trying to compile, changed lines 700 and 1000 to deal with the integer arithmetic: 700 IF FL=2*INT(FL/2) THEN 1140 and RESequenced 1,1. It now compiles and loads fine, though the scroll bug keeps the title screen from being quite right. (I had decided to shrink the bulky but super fast scroll routine. I started writing it and then realized that I'd have to give the new routine a thorough test. So I restored the original scroll routine, but evidently not entirely!)

 

I've attached a zip folder. In it are SCHASE, the original BASIC program and SCHASE-C, the compiled version. Both load and run as XB programs. Try SCHASE first, then SCHASE-C. You will see that the compiled version is lightning fast - and unplayable! There need to be delay loops to slow things down. This shows one of the problems with any compiler - even if it is 100% compatible, it may still need changes to work right.

 

The line number bug is fixed - all my test programs were too short to find it. The scroll bug will be fixed soon and I will repost the compiler.

Super Chase.zip

[Kurt_Woloch]

I tried out the compiler too. I tried to created a compilable version of my "SSGC Racer" program which I created back in 2010 for the Short & Sweet game contest. According to the manual, there weren't too many changes required. The compiler didn't give any error, however the assembler complained about several undefined symbols. The corresponding commands are seemingly compiled into a corresponding assembler subroutine, but that subroutine doesn't seem to be implemented. Those commands, functions and subprograms are neither listed as "supported" nor as "unsupported", and they seem to be supported by the compiler, but unsupported by the runtime libraries.

 

Those commands are:

RPTS (Function RPT$)

SAY (CALL SAY)

MAX (Function MAX)

MIN (Function MIN)

 

Are these commands supposed to get supported, or do they remain unsupported?

[senior_falcon]

Boy, you folks are sure making me work on my week off! I will implement RPT$, MAX and MIN along with the bug fixes. In all probability speech will not be implemented in the compiler.

[marc.hull]

Boy, you folks are sure making me work on my week off! I will implement RPT$, MAX and MIN along with the bug fixes. In all probability speech will not be implemented in the compiler.

 

How about disk files ? does it have that ability ?

[senior_falcon]

Nope - no disk access.

 

From the manual:

 

IF-THEN-ELSE will only work with line numbers. See the discussion below for ways to partially work around this limitation.

Nested arrays cannot be used. See discussion below.

User defined subprograms are not supported.

Assembly language subroutines cannot be used except for the four included with the compiler.

Disk and other peripheral access is nor supported.

Trig functions, LOG and DEF not supported.