IGNORED

# XB Compiler v2.1

## Recommended Posts

I think Retrospect's fix will work. There are a couple of more direct methods. The lines in question are:

30 FOR X=0 TO A STEP S :: CALL SOUND(-200,B,X,C,E,D,E) :: E=E+1 :: IF E>30 THEN E=30

31 NEXT X :: RETURN

You can invert the logic this way:

30 FOR X=0 TO A STEP S :: CALL SOUND(-200,B,X,C,E,D,E) :: E=E+1 :: IF E<=30 THEN 31:: E=30

31 NEXT X :: RETURN

Or: E=E-(E<30)

If (E<30) is true then it gives a value of -1. If false then the value returned is 0.

BTW,I don't think line 30 will throw an error. You have to be extra vigilant to find stuff like this.

Also you have a problem in lines 33,139, and 141 where you use a step value of .5 which rounds down to 0 in integer arithmetic. So you would never be able to exit the loop. Use a value of 1 and you should be OK. That's probably the source of the errors.

There are a lot of GOSUBs in your program - it should give the compiler a real workout! Try out those changes and let us know if they work.

spain.txt

First of all, I must note that this program runs correctly in Extended Basic, it has for 20 years or so. Apparently the issue is that the compiler doesn't like decimal points of any kind.

With that being said, I'm still attempting to make the program work with the compiler.

The change suggested in line 30 seems to have resolved that issue.

All decimal points have been removed for the 'STEP .5', it's not as simple as just making it 'STEP 1', though. This is a duration of a note as well as change in volume. So the change suggested would make both happen twice as quickly, which is unacceptable. The only way to use step 1 is to have 2 CALL SOUND statements instead of 1 before the 'NEXT'. I've made that change where needed.

All decimal points have been removed from the 3rd sound generator, which produces the bass notes in sound generator 4. This makes the bass notes slightly out of tune, but the untrained ear is likely not to notice.

The one sticking point is this line:

1310 FOR A=659 TO 587 STEP-14 :: CALL SOUND(-99,A,3,A*.3748,5) :: NEXT A

The compiler doesn't like the A*.3748, I suppose I could just type all the CALL SOUNDs out with the non-decimal values in order, but that eliminates the value of being able to use the STEP modifier for FOR-NEXTs.

This seems like a lot to go through to make a program acceptable for the compiler. Would it be possible to fix the compiler to accept decimal points?

Gazoo

##### Share on other sites

spain.txt

Ok, I've done all the modifications I can. The resulting text file is attached.

It runs ok in Extended Basic.

It compiles ok with the compiler.

It assembles ok with the assembler.

I give up.

Gazoo

##### Share on other sites

I don't know if this helps at all, probably * not * ... but ive just tried pasting this into Java V9T9 ti emulator and it's beeping because lines are too long in places.

because of that i can't test it myself as classic99 wont paste/copy in Wine linux.

Anyone else help ? This is strange.

##### Share on other sites

I don't know if this helps at all, probably * not * ... but ive just tried pasting this into Java V9T9 ti emulator and it's beeping because lines are too long in places.

because of that i can't test it myself as classic99 wont paste/copy in Wine linux.

Anyone else help ? This is strange.

90k.txt

Would a dsk image help? Change the txt extension to dsk.

Gazoo

##### Share on other sites

The one sticking point is this line:

1310 FOR A=659 TO 587 STEP-14 :: CALL SOUND(-99,A,3,A*.3748,5) :: NEXT A

The compiler doesn't like the A*.3748, I suppose I could just type all the CALL SOUNDs out with the non-decimal values in order, but that eliminates the value of being able to use the STEP modifier for FOR-NEXTs.

This seems like a lot to go through to make a program acceptable for the compiler. Would it be possible to fix the compiler to accept decimal points?

Gazoo

Hi Gazoo:

The reason integer arithmetic is used is simply that it gives a huge increase in speed compared to using floating point arithmetic . When I was developing the compiler, tests showed a speed increase of 3x when using floating point arithmetic and a speed increase of 20-30x when using integer math. The compiler is designed in such a way that you could use floating point arithmetic, but that would require a complete rewrite of the runtime routines to make that possible. I would have no interest in this, but if someone is sufficiently motivated to volunteer to donate many months of evenings rewriting the runtime routines, then I could make necessary changes in the compiler to use the new floating point routines.

As to the error message "unrecognized character in 181", this can be cured by resequencing so there are no odd number lines. This is a left over from the "line number bug" first found by Rich Gilbertson. I thought this was corrected, but there is a little more yet to be done. RES will do the trick until those changes are made.

As you are finding out, it can be challenging to adapt existing XB programs. Starting anew will often give better luck, as you will be more likely to take into account the limitations of the compiler. (Even that is not foolproof - there have been many times that I was puzzled until realizing that I was trying to do something that is not supported.) For that matter, not every program benefits greatly from compilation. Your program basically just plays music, which you wouldn't want to speed up, so the main benefit would be that it starts up faster.

When you started with the TI statements such as HCHAR or GCHAR seemed mysterious to you until you used them enough so they became second nature. The same is true of the compiler - it is maddening at first, but once you figure out how to make it work, you will be delighted with the speed increase made possible. The games "Shooting Stars", "Bouncing Babies", much of Joe Morris's prolific output and others (sorry to those I've forgotten) will attest to that.

Edited by senior_falcon
##### Share on other sites

Bug fix is in the works - hopefully within the week.

##### Share on other sites

• 2 weeks later...

Here's a long overdue bug fix for the XB compiler. All the known bugs have been corrected.

There is one caveat though - A little more than a year ago I stupidly erased the only source code for the compiler. I downloaded the compiler from this site and disassembled the compiler. Starting with the original BASIC compiler I added the XB features and kept at it until the newly restored code assembled identically to the original. (Sadly, all the comments were lost.) It seems to work properly, but something might have fallen through the cracks. I'm sure if that's the case that you guys will find it!!

(Edit: Well, you guys found it, so the newly debugged program can be found in post #1 or post #140)

Edited by senior_falcon
##### Share on other sites

Thank you.

I have a question about timing things in compiled XB. I have a game I wrote in BASIC a while back that performs actions every second while waiting for the user. (A timer that ticks away points every second during play.) It turns out that checking for keyboard and joystick input, and responding to the same, takes almost exactly one second in BASIC. In Extended BASIC it goes a little more quickly. When I compiled the program it ran too quickly to play at all.

Is there an established way to manage time while executing statements whether compiled or not?

##### Share on other sites

Well I've started slowing it down by using SOUND statements with the volume turned right down to 30 .... that to me is a sure way of knowing how long the delays are going to be. Call Sound (1000,110,30) the sound runs the same amount of time whether compiled or not .

EDIT

Actually I'm not entirely right there .... in combination with the sound i do use little delays like FOR A=1 to 500 .... bare in mind 500 is barely noticable when compiled.

Edited by Retrospect
##### Share on other sites

Good news...

I just compiled mirror maze with 2.11 and played for about 25-30 minutes.

4-5 levels in. No problems found!

Thank you for continuing the advancement of the compiler!

##### Share on other sites

Thank you.

I have a question about timing things in compiled XB. I have a game I wrote in BASIC a while back that performs actions every second while waiting for the user. (A timer that ticks away points every second during play.) It turns out that checking for keyboard and joystick input, and responding to the same, takes almost exactly one second in BASIC. In Extended BASIC it goes a little more quickly. When I compiled the program it ran too quickly to play at all.

Is there an established way to manage time while executing statements whether compiled or not?

There is a counter at -31879 (>8379) that is controlled the the interrupt routine. This increments every 60th of a second. So one possibility would be to CALL LOAD(-31879,0) then have your code CALL PEEK(-31879,X) and check whether X is greater than 60. If so then X=X-60 :: CALL LOAD(-31879,X) and then do your housekeeping chores. This should work if you are using CALL KEY, however it is used to keep track of the cursor flash rate and might be problematic if you are using INPUT or ACCEPT AT.

##### Share on other sites

There is a counter at -31879 (>8379) that is controlled the the interrupt routine. This increments every 60th of a second. So one possibility would be to CALL LOAD(-31879,0) then have your code CALL PEEK(-31879,X) and check whether X is greater than 60. If so then X=X-60 :: CALL LOAD(-31879,X) and then do your housekeeping chores. This should work if you are using CALL KEY, however it is used to keep track of the cursor flash rate and might be problematic if you are using INPUT or ACCEPT AT.

Thank you. That sounds like it will be my solution since I am not using INPUT or ACCEPT AT. They would be impractical, anyway, as they are "blocking" statements (hang the program until input is received.) Should be easy enough, and the speed of the compiler will allow much better responsiveness to input. With a little debugging work I can figure out how quickly one loop executes and thus how many times in a second it will iterate. I will most likely need some kind of throttling mechanism in place to prevent a single key press from moving the user pointer across the screen. Oh -- unless I make it mouse-like! ::strokes chin::

It may be interesting to note that >8379 behaves differently in RUN than in IMMEDIATE mode. It only increments up to >FF in RUN mode, whereas in IMMEDIATE it seems to rarely increment past >0F.

##### Share on other sites

Yep, in immediate mode you are using the line editor, same as if you were using ACCEPT AT or INPUT, so that's a counter for the cursor flash speed.

##### Share on other sites

Yep, in immediate mode you are using the line editor, same as if you were using ACCEPT AT or INPUT, so that's a counter for the cursor flash speed.

Got it. You know, that is interesting. When not accepting input it acts as a jiffy-clock, otherwise its a cursor counter. Considering nothing uses the jiffy-clock functionality you would think that would be unnecessary work for the interrupt routine.

##### Share on other sites

• 3 weeks later...

Well,one bug fix seems to lead to another. It seems that one of the fixes in v2.11 made DISPLAY AT not work properly when printing numbers (although it worked fine when printing a string). That was tracked down and fixed. Also, the compiler was modified to give you the option of whether to load the C-EXTRAS. If you are not using them then press N and some memory (and time) will be saved.

CMPLR212.zip

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.