Harry Wilhelm's XB 2.0 Compiler, Newb Help Request

[Airshack]

So I've successfully compiled and run a simple XB2.7 program using Harry's amazing compiler. My second attempt on a more complex program is yielding the following message:

 

ASSEMBLER EXECUTING (and after a minute or so)

SYNTAX ERROR - 0089

0001 ERRORS

Press <ENTER> to continue

 

Any ideas about where I go next? Is 0089 a line number or an error code? HELP!

 

 

[senior_falcon]

The compiler takes a merge format (DV163) XB program and converts it to assembly language source code. When you run the assembler, it takes this A/L source code and converts it into A/L object code which then is loaded as an XB program in the final step. There are a number of features that are legal in XB that cannot be used in the compiler. Your error message means there is something about your XB program that is not supported by the compiler. Fortunately there is only one error, so it should be easy to track down. Syntax error - 0089 is saying that there is a problem in line 89 of the A/L source code created by the compiler. You need to look at the file created by the compiler to see what is going on. This should be a display/variable 80 file that you called something like DSK1.PROGRAM-S if you are using a real TI99 or else a .txt file if you are using Classic99 (which I highly recommend.) It should be pretty easy to figure out where line 89 is in the XB program - the XB line numbers start with an L so that L100 would be the start of line 100. Then look at the XB program and the manual to find the mistake. If you cannot find it post the XB program and the A/L source code and someone here will sort it out for you.

[Airshack]

The compiler takes a merge format (DV163) XB program and converts it to assembly language source code. When you run the assembler, it takes this A/L source code and converts it into A/L object code which then is loaded as an XB program in the final step. There are a number of features that are legal in XB that cannot be used in the compiler. Your error message means there is something about your XB program that is not supported by the compiler. Fortunately there is only one error, so it should be easy to track down. Syntax error - 0089 is saying that there is a problem in line 89 of the A/L source code created by the compiler. You need to look at the file created by the compiler to see what is going on. This should be a display/variable 80 file that you called something like DSK1.PROGRAM-S if you are using a real TI99 or else a .txt file if you are using Classic99 (which I highly recommend.) It should be pretty easy to figure out where line 89 is in the XB program - the XB line numbers start with an L so that L100 would be the start of line 100. Then look at the XB program and the manual to find the mistake. If you cannot find it post the XB program and the A/L source code and someone here will sort it out for yo

 

Thank you! I figured as much yet couldn't find the line numbers in the source code? I'll give it another look. Any way to toggle line numbers on in the editor?

 

I'll begin by loading the dsk1.program-s file into the editor via calssic99's editor/assembler cart. There I'll give it another look.

 

I know... this is my first exposure to the TI editor/assembler so I'm using a little braille to find my way around.

 

All assistance is greatly appreciated.

[Airshack]

Yes, I'm doing all of the development on Classic99 due to TI's crap keyboard. I tried to do it on real iron and found the process too painful. More importantly, classic99 gives me portability, and I'm constantly on the road.

Edited August 31, 2016 by Airshack

[Airshack]

Harry Wilhelm is a genius! The source code generated by the compiler will expedite the assembler learning process! So throughly impressed by this community.

[Airshack]

Turns out my problem was with XB advanced style IF-THEN-ELSE statements. Fixed...holy crap this runs faster! Oh joy!

[senior_falcon]

Turns out my problem was with XB advanced style IF-THEN-ELSE statements. Fixed...holy crap this runs faster! Oh joy!

Think TI BASIC when you use IF-THEN-ELSE and you'll stay out of trouble. You can use multiple statement lines which does help. So you could have something like this:

10 IF X=3 THEN 30::Y=7::Z=29::GOTO 40 ! if x<>3 then y=7 and z=29

30 Y=4::Z=21 ! because x=3 then y=4 and z=21

40 program continues...

 

By the way, the term "genius" is used a lot. Sadly, I don't qualify as one. However, I will confess to being very clever!

[Opry99er]

^^Clever indeed.

 

 

I need to compile the Jedi Gauntlet Demo one of these days... Just to see the difference.

[senior_falcon]

Something to consider when developing XB programs is how much you intend to use the compiler. If the answer is "not much" then by all means use all the advanced features of Extended BASIC. I love subprograms; the XB style IF-THEN-ELSE can really simplify your programs, etc. But if you intend to use the compiler, then you are probably better off not getting into the habit of using program statements that it does not support, especially the more advanced IF-THEN-ELSE which have caused me no end of trouble with debugging. These days I only use IF-THEN as follows:

20 IF X=7 THEN 30::Y=23::Z=4::GOTO 40 ! equivalent to if x=7 then 30 else y=23::z=4::goto 40

30 Y=17::Z=9

40 program continues...

I think that something like

20 IF A=3 OR X=7 THEN 30::Y=23::Z=4::GOTO 40

should work fine when compiled.

[Airshack]

Thanks for the tips as they've helped me move along. I'm practicing with XB256 and the compiler together.

 

Two questions:

 

1. Can music files from the Music Maker Cart's saved format be imported by the sound list compiler?

 

2. My XB256 code has an instance where a subroutine, in some cases, never gets RETURN'd. In other words, under some conditions the code redirects via a GOTO instead of progressing to the end and returning. This causes no issues to XB256 yet seems to crash in the compiled version. Why would that be?

[senior_falcon]

Thanks for the tips as they've helped me move along. I'm practicing with XB256 and the compiler together.

 

Two questions:

 

1. Can music files from the Music Maker Cart's saved format be imported by the sound list compiler?

 

2. My XB256 code has an instance where a subroutine, in some cases, never gets RETURN'd. In other words, under some conditions the code redirects via a GOTO instead of progressing to the end and returning. This causes no issues to XB256 yet seems to crash in the compiled version. Why would that be?

1 - Don't know about the music files - I have no experience with Music Maker.

2 - Examples please!

[senior_falcon]

There is a minor bug in XB256. Assembly subroutines in XB use a lookup table to find the address of the subroutine. Somehow DELAY was removed from that table. All the code is there, and I checked that it is also in the compiler. The fix is pretty simple:
Type OLD DSK1.XB256 which will load XB256.
The loader consists of 2 lines. Edit these to be:

5 ! XB256 by Harry Wilhelm December 23, 2014 Copyright 2013,2014 Free distribution only
9 CALL INIT :: CALL LOAD(8192,255,154)
10 CALL LINK("X"):: CALL LOAD(8197,224,"",16096,68,69,76,65,89,32,50,90):: CALL LINK("XB256")!:: RUN "DSKn.PROGNAME"

Type SAVE DSK1.XB256 to save the modified program.

This modification adds DELAY to the table, and now it should work as described. Be sure the loader says December 23, 2014 in line 5.

[senior_falcon]

James' problem was simple, and simple to solve. IF THEN ELSE must be done as in TI BASIC. THEN and ELSE must be followed by line numbers. XB gives you a lot more flexibility, but the compiler is very unhappy with anything that differs from the TI BASIC standard and will crash.

 

Here are two examples from James' code where THEN is not followed by a line number:

360 IF C<>24 THEN GOSUB 440

370 IF C<>24 THEN GOTO 210

Here's how to fix it:

360 IF C=24 THEN 370::GOSUB 440 (Notice how the logic is inverted here)

370 IF C<>24 THEN 210 (Can't have GOTO after THEN)

 

To reiterate and sorry for the caps:

USE ONLY LINE NUMBERS IN AN IF/THEN/ELSE STATEMENT. If you have doubts you can search for THEN and ELSE with a text editor. Any place where they are not followed by a line number must be changed.

[Airshack]

There is a minor bug in XB256. Assembly subroutines in XB use a lookup table to find the address of the subroutine. Somehow DELAY was removed from that table. All the code is there, and I checked that it is also in the compiler. The fix is pretty simple:

Type OLD DSK1.XB256 which will load XB256.

The loader consists of 2 lines. Edit these to be:

 

5 ! XB256 by Harry Wilhelm December 23, 2014 Copyright 2013,2014 Free distribution only

9 CALL INIT :: CALL LOAD(8192,255,154)

10 CALL LINK("X"):: CALL LOAD(8197,224,"",16096,68,69,76,65,89,32,50,90):: CALL LINK("XB256")!:: RUN "DSKn.PROGNAME"

 

Type SAVE DSK1.XB256 to save the modified program.

 

This modification adds DELAY to the table, and now it should work as described. Be sure the loader says December 23, 2014 in line 5.

 

Done! Thank you! A real pleasure to get this feedback from the author/creator btw.

[Airshack]

Wrote a simple program to test the DELAY:

 

10 Print "TEST"::CALL LINK("DELAY",3000)::Print "END TEST"

 

Of course it worked like a charm. I'll be using it in my project tomorrow. Thanks again Harry!