XB Compiler v2.1

[Bones-69]

After many hours I *think* I have found where the compiled error is coming from. I felt the nature of this one was a little odd because under normal XB everything worked as expected, but when compiled things went wrong. Anyway, I am putting it out there for contemplation.

 

Old version;

340 IF YI=0 THEN 370
350 IF YI<0 THEN GOSUB 440 :: GOTO 370
360 IF YI>0 THEN GOSUB 450
370 IF XI=0 THEN 400
380 IF XI<0 THEN GOSUB 470 :: GOTO 400
390 IF XI>0 THEN GOSUB 480

Re-written which when compiled now runs. I think the drama was due to the GOTO commands in lines 350 and 380 which appear after an IF/THEN/GOSUB command.

340 IF YI=0 THEN 390
350 IF YI<0 THEN 360 :: GOTO 370
360 GOSUB 500 :: GOTO 390
370 IF YI>0 THEN 380 :: GOTO 390
380 GOSUB 510
390 IF XI=0 THEN 440
400 IF XI<0 THEN 410 :: GOTO 420
410 GOSUB 530 :: GOTO 440
420 IF XI>0 THEN 430 :: GOTO 440
430 GOSUB 540

[senior_falcon]

Bones, you are on the right track here. You had forgotten that IF, THEN, ELSE can only work with line numbers, so for example:

350 IF YI<0 THEN GOSUB 440::GOTO 370 will not work. But you can invert the logic here:

350 IF 0>Y1 THEN 360::GOSUB 440::GOTO 370 and this should work fine in the compiled code.

 

Don't be afraid to look at the source code created by the compiler:

L340 In XB: 340 IF YI=0 THEN 370
DATA CEQ,NV4,NC4,NT1
DATA IF,NT1,L370
L350 In XB: 350 IF YI<0 THEN GOSUB 440::GOTO 370
DATA CLT,NV4,NC4,NT1
DATA IF,NT1,L440
DATA GOTO,L370

You can see in the code above that line 350 will simply GOTO line 440 and not GOSUB 440

[senior_falcon]

Robert L encountered an interesting problem with the compiler. He was trying to compile his decimal to hex and bin converter. It was getting hung up at the input line. The offending line of code was this:

440 IF X<0 OR X>65535 THEN 400 i.e. check that the number is within limits. But the integer arithmetic used sees that line as:

440 IF X<0 OR X>-1 THEN 400 meaning the program will always be sent back to 400

There are a lot of subtleties in using the compiler......

[1980gamer]

"There are a lot of subtleties in using the compiler......"

 

Yes, But I LOVE IT!

 

It has got me back to tinkering with the TI. I haven't used the TI this much since I was 12.

 

Just for some info... What would be the max value? 32767?

[RobertLM78]

Robert L encountered an interesting problem with the compiler. He was trying to compile his decimal to hex and bin converter. It was getting hung up at the input line. The offending line of code was this:

440 IF X<0 OR X>65535 THEN 400 i.e. check that the number is within limits. But the integer arithmetic used sees that line as:

440 IF X<0 OR X>-1 THEN 400 meaning the program will always be sent back to 400

There are a lot of subtleties in using the compiler......

So is there a way to work around this? I've been trying to get my head around two's compliment and how that works - it seems like an understanding of that will be helpful. Indeed, getting my head around how the computer handles negative numbers will probably help, too.

 

Just for some info... What would be the max value? 32767?

I believe so... but I wouldn't take my word for it

[senior_falcon]

Integers are from -32768 to + 32767. Page 5 of the manual is "Differences from Extended BASIC" and this information is on that page. C'mon now, the manual is only 13 pages long so it isn't a tome like "War and Peace". Believe it or not there is useful information in there! (I'm one to talk, I still haven't watched Tursi's video on using Classic99)

[RobertLM78]

C'mon now, the manual is only 13 pages long so it isn't a tome like "War and Peace". Believe it or not there is useful information in there! (I'm one to talk, I still haven't watched Tursi's video on using Classic99)

LOL - yeah, at least myself, I like to "jump right in" on things - even though doing so can come bite you in the ass. I will read it from "cover to cover" now .

[senior_falcon]

So is there a way to work around this? I've been trying to get my head around two's compliment and how that works - it seems like an understanding of that will be helpful. Indeed, getting my head around how the computer handles negative numbers will probably help, too.

 

I believe so... but I wouldn't take my word for it

Here's a program to consider:

100 FOR I=1 TO 9 :: READ N :: PRINT N :: NEXT I

1000 DATA -100000,-75000,-50000,-25000,0,25000,50000,75000,100000

In XB it runs just like you'd expect. Compiled, it prints these numbers: 31072,-9464,15536,-25000,0,25000,-15536,9464,-31072

One way to think about it is that the compiler adds or subtracts 65536 until the number ends up between -32768 and 32767.

As far as a work around goes, I would be tempted to ignore it. Or you could print the decimal number next to the one that was entered, which might be handy. For example, knowing that -31804 = >83C4 is useful info - at least to some of us.

Edited January 2, 2014 by senior_falcon

[RobertLM78]

Here's a program to consider:

100 FOR I=1 TO 9 :: READ N :: PRINT N :: NEXT I

1000 DATA -100000,-75000,-50000,-25000,0,25000,50000,75000,100000

In XB it runs just like you'd expect. Compiled, it prints these numbers: 31072,-9464,15536,-25000,0,25000,-15536,9464,-31072

One way to think about it is that the compiler adds or subtracts 65536 until the number ends up between -32768 and 32767.

As far as a work around goes, I would be tempted to ignore it. Or you could print the decimal number next to the one that was entered, which might be handy. For example, knowing that -31804 = >83C4 is useful info - at least to some of us.

I'll have to play around with this once I'm done going over the manual.

 

As for a work around - perhaps I'll start by just dropping the test altogether - it shouldn't be too serious if the number falls out of range - just give a null result I would think. I suppose there will still be the issue of any number being entered in that is greater-than +32767 though...

[Bones-69]

Bones, you are on the right track here. You had forgotten that IF, THEN, ELSE can only work with line numbers,

The crazy thing was - I hadn't forgotten this at all. You know - because a GOSUB command has a line number, it just never occurred to me that I was breaking the rules.

 

By the way Senior, thanks again for your work. I am having an amazing amount of fun with this compiler!

[JamesD]

Bones, you are on the right track here. You had forgotten that IF, THEN, ELSE can only work with line numbers, so for example:

350 IF YI<0 THEN GOSUB 440::GOTO 370 will not work. But you can invert the logic here:

350 IF 0>Y1 THEN 360::GOSUB 440::GOTO 370 and this should work fine in the compiled code.

...

That functions very different under Microsoft BASIC. I can see where there would be confusion.

 

[1980gamer]

Hi Harry,

I have had off and on success with INPUT commands in the compiler.

In XB this works fine, It is "hidden" code for debugging. So, if you download my latest mirror maze version, if you press a key at run... you should be prompted.

It works in XB....

 

60 FOR KK=1 TO 50
70 CALL KEY(1,K,S):: IF S<>0 THEN 100
80 NEXT KK
90 GOTO 200
100 PRINT "DEBUG 1=Y 2=N";
110 INPUT HDG
120 PRINT "GHOST ATTRACT DFLT=2 -15 TO 15";
130 INPUT HD
140 PRINT "SCREEN (1-3)";
150 INPUT MZ
160 IF MZ<3 THEN 180
170 MZ=1 :: RD=1
180 PRINT "# GHOSTS";
190 INPUT NG
200 CALL CLEAR

 

I have a few other examples that fail. Some even CRASH the system.

Page 7 of the manual does not have an example, but AGAIN, I have also been successful in using similar code?

 

At a loss?????

 

Thanks,

Gene

[parsec]

Hi Harry,

 

First a huge thank you for your compiler, it's a great tool and I really appreciate your work!

 

I recently went back to working on a silly game that I started back in 2011. At the time it compiled succesfully under the older XB compiler version. I decided to update my stuff and downloaded the latest XBC V2.1 but it appears the line number bug that was discussed in another thread, or something related, is still present.

 

During assembly I get 'UNDEFINED SYMBOL - 0182'. Looking in the assembler code, line 182 is 'DATA IF,NT1,L643' but L643 is not defined anywhere.

 

I tried the old compiler version and there were no issues. My code is well over 200 lines so resequencing does not work. If you need more info or anything let me know.

[senior_falcon]

Hi Harry,

I have had off and on success with INPUT commands in the compiler.

In XB this works fine, It is "hidden" code for debugging. So, if you download my latest mirror maze version, if you press a key at run... you should be prompted.

It works in XB....

 

60 FOR KK=1 TO 50

70 CALL KEY(1,K,S):: IF S<>0 THEN 100

80 NEXT KK

90 GOTO 200

100 PRINT "DEBUG 1=Y 2=N";

110 INPUT HDG

.........(deleted some lines here)

180 PRINT "# GHOSTS";

190 INPUT NG

200 CALL CLEAR

 

I have a few other examples that fail. Some even CRASH the system.

Page 7 of the manual does not have an example, but AGAIN, I have also been successful in using similar code?

 

At a loss?????

 

Thanks,

Gene

I don't see anything in your code that the compiler won't support. The problem might be that 50 loops doesn't give you enough time to get on a key. One thing to try when you RUN is to keep holding the ENTER key down until your menu appears. Another possibility might be to start the game with a loop until no key is pressed, then follow that with another loop to scan the keyboard until a key is pressed. If the key is <Fctn 9> go to your menu, otherwise continue with the game. Report back on how that works out, and then we'll go from there. Also, could you post an example that crashes the system? Thanks!

[senior_falcon]

Hi Harry,

 

First a huge thank you for your compiler, it's a great tool and I really appreciate your work!

 

I recently went back to working on a silly game that I started back in 2011. At the time it compiled succesfully under the older XB compiler version. I decided to update my stuff and downloaded the latest XBC V2.1 but it appears the line number bug that was discussed in another thread, or something related, is still present.

 

During assembly I get 'UNDEFINED SYMBOL - 0182'. Looking in the assembler code, line 182 is 'DATA IF,NT1,L643' but L643 is not defined anywhere.

 

I tried the old compiler version and there were no issues. My code is well over 200 lines so resequencing does not work. If you need more info or anything let me know.

Sounds like the line number bug, but that should be fixed. Can you post the line of XB code, then the assembly source code version of that line.

[parsec]

Sounds like the line number bug, but that should be fixed. Can you post the line of XB code, then the assembly source code version of that line.

 

Assembly (last line is 180 182) :

L410
       DATA KEY,NC7,NV30,NV31
       DATA CEQ,NV31,NC1,NT1
       DATA IF,NT1,L643

For XB, there is no line 643, closest surrounding lines are 600 and 645. Line 410:

410 CALL KEY(1,K,S):: IF S=0 THEN 645

Edited March 4, 2014 by parsec

[1980gamer]

Hi Harry,

The 20 lines of code I put in the example are the first 20 lines of Mirror Maze. Current version.

Yes, you have to be quick to press a key... I hold a key on the left side of the keyboard after hitting enter on the RUN command.

 

This will give the input prompt, it just will not let me enter any data.

Also, you cannot break the execution. Only a reset will free this! Well, in emulation anyway. Win99 and Classic99

 

I was thinking I am killing the input buffer? But I have been lucky enough to get the input prompt with 1 quick key hit.

So I am not certain about anything!

 

I'll but up another demo I made that has the same problem. But it will have to be tonight when I get home.

 

Thanks for your help. And on the screen blanking... I'll try the load command too.

 

Gene

[1980gamer]

Hi Harry,

I posted everything about Mirror Maze/pacman in the other thread.

Here is an other example: the input works at the beginning but the accept at does not after the game over. ( works in XB )

 

No response for me, I have to reset.

Gene

 

SNAKE.zip

[senior_falcon]

 

 

Assembly (last line is 180 182) :

L410
       DATA KEY,NC7,NV30,NV31
       DATA CEQ,NV31,NC1,NT1
       DATA IF,NT1,L643

For XB, there is no line 643, closest surrounding lines are 600 and 645. Line 410:

410 CALL KEY(1,K,S):: IF S=0 THEN 645

It looks like this is a variation of the line number bug. Some of the extras added to the XB version of the compiler led to problems, and it looks like one was missed. I will make a comprehensive check of how all the line numbers compile and see if anything else is lurking there. Fix to come soon.

[senior_falcon]

Parsec, there are definitely a couple of bugs involving the line number bug. It looks like you can avoid this doing a resequence so you wind up with only even numbers. A simple RES would do this as that uses an increment of ten. Or else RES 100,2 or something like that.

[parsec]

Parsec, there are definitely a couple of bugs involving the line number bug. It looks like you can avoid this doing a resequence so you wind up with only even numbers. A simple RES would do this as that uses an increment of ten. Or else RES 100,2 or something like that.

 

Yes sir, that worked like a charm! Thanks for your help.

[senior_falcon]

Hi Harry,

I posted everything about Mirror Maze/pacman in the other thread.

Here is an other example: the input works at the beginning but the accept at does not after the game over. ( works in XB )

 

No response for me, I have to reset.

Gene

 

Hi Gene: SNAKE is an excellent test to show what is happening. I now know what is going on and how to fix it for you. When a program scans the keyboard, the key unit (0 to 5) is placed in >8374 and the key value is returned in >8375. It looks like XB does the keyscan, then sets >8374 back to 0. The compiler doesn't do that. Your line 170 CALL KEY(1,K,S) sets >8374 to 1 and scans the keyboard. XB resets it to 0 but the compiler leaves it at 1. The fix is simple: just before the input add CALL LOAD(-31884,0) or CALL KEY(0,K,S) and the input should then work normally for you.

[1980gamer]

Thank You!

This has been a head scratch-er for me. I cannot believe I didn't notice KEY 0 works and KEY 1 didn't.

I just seemed random to me.

 

How about the accept at? I can press the V key and it exits. But I am looking for Y or N.

 

Thanks for checking this out for me!

Gene

[senior_falcon]

Gene, have you tried re-compiling it? I haven't tested it, but it should work with the changes mentioned above.

[1980gamer]

Gene, have you tried re-compiling it? I haven't tested it, but it should work with the changes mentioned above.

Yes, I changed the call key to key(0,k,s) and that worked.

 

I also changed mirror maze to not take away the power pellets on the back side of the maze, so you will not loose power pellets.

Just thought of something... You can now eat the power pellet location twice, so I have to change the dot count for screen completion.

Darn! It's easy, but I'll have to recompile and test all levels again.

 

Thanks for the help and suggestions!

Gene