XB Compiler v2.1

[Willsy]

Release of the XB enhancements will be in a couple of weeks. Then to merge this with the compiler and fix a few more bugs (Joe Morris is merciless in finding them!) and release that soon after.

 

Excellent job! Looking forward to playing with it!

 

Has anyone here checked out The Missing Link? Another excellent program by "the falcon". I remember seeing a demo of it in the UK and was just totally blown away. Seriously awesome!

[Tursi]

The Missing Link was amazing, I bought it back when it first came out.

[kl99]

How are you testing your compiler?

Are the Extended Basic instructions tested individually by a human comparing the results on screen or have you achieved to create some kind of automated tests?

Maybe we as the community can help you here in order you can concentrate on coding.

 

I will have a talk with the tester in our team in my company. He creates Gherkins, Automated Tests, Manual Tests on a daily basis.

 

Of course to create some kind of test framework for this compiler there is the need to know a lot about the compiler.

 

Ideally we would write something like:

I take instruction CALL CLEAR for a first example. After execution I expect the VDP memory from 0000-02FF to be filled with Char 30. The rest of the memory should be basically untouched and ideally be checked as well. Maybe an emulator is good for such a test framework, since it can save/compare all the memory from outside world easily?

Another test example would be. I execute CALL SCREEN(17). I expect an error message with a specific exception - value out of range or something. And ideally simply ignore this Extended Basic Instruction.

When I execute all the tests: the framework should give me information like

TESTING CALL CLEAR: OK

TESTING CALL SCREEN: OK

...

 

Maybe it's overkill but this way we could be sure that such a compiler handles each instruction correct and does proper error handling. If someone finds one of the many hints in ti books or magazines where XB actually behaves strange or a bugs occur, we could easily add a test for this and see if the compiler recreates this "wrong" behavior.

[senior_falcon]

I do all the testing. For the most part that is not too difficult. Most of the XB instructions and subprograms are pretty simple and the programmer has a good idea where they might fail. For instance, CALL HCHAR not difficult to debug. Be sure the character appears where it is supposed to and is the right one. Make sure it repeats the specified number of times. Make sure it wraps around if it should get to the lower right corner of the screen. The ones that are so difficult are PRINT/DISPLAY and INPUT/ACCEPT and that's because there are so many different things that can be done with them - is it a string or a number, is AT or SIZE used, are comma, semi or colon used and so on. Fixing any one of these can break it elsewhere. (and has!) Then will the fix break something else? Things are pretty much ironed out but I'm sure there are some bugs left. When found they will be fixed - I don't have any desire to seek them out.

 

As far as error messages go, the compiler doesn't give any. Do your checking for errors in XB and don't try to debug XB errors in the compiled code - that way lies madness.

[kl99]

Hi!

 

It's only partly related to the XB Compiler but with the Assembler Function VREAD I can read from VRAM a number of bytes. Since XB stores your string variables in VRAM as well, I wonder if it is a waste of memory if I store all my strings as a string variable.

I can store/read a string into/from VRAM anyway. Or is it a performance question - is it faster to have dedicated string variables in the XB program already. I mostly need them in loops, so only one string at a time.

 

I ask because I want to do some string functions on the dr. mario 16x8 game screen: check for 4 chars of the same type in a row, check for 4 chars of the same type in a column. It's like a full line in Tetris which gets erased and the rest of the chars "fall down" accordingly.

 

If you don't know Dr. Mario, check out:

 

Klaus

[sometimes99er]

I ask because I want to do some string functions on the dr. mario 16x8 game screen: check for 4 chars of the same type in a row, check for 4 chars of the same type in a column.

 

Not really an answer to your question, other than a tip or an observation regarding Dr. Mario. When a capsule “lands”, you have have to check in both directions around the landing capsule. That’s always 2 rows and 1 column or 1 row and 2 columns to check. It might be easier to simply check all of the board.

 

I've checked with the Game Boy version, and with one capsule you can clear as many as 15 viruses/capsule elements beside the falling capsule itself. What I’m saying is, you have to check for more than 4 chars - one direction can clear 7 chars. Consider this situation ...

 

 

Edited February 6, 2013 by sometimes99er

[kl99]

Thanks sometimes. It seems you took some deep thoughts into it and I appreciate it. I had my TI Basic version once as far as all the 4+ capsule check and erasing worked. The reshaping of remaining half-capsule was fine too. But when that part is finished all capsules should "fall down" whenever there is a hole below them. Under certain circumstances there can be a lot of pills to handle (and when those landed check again for 4+). I didn't get the falling algorithm to work, more precisely I didn't find an algorithm for that.

 

Now with attempt #2 on programming this I know at least that I better check the whole screen for 4+ times of each pill color. My current proposal for this is using string function POS.

[sometimes99er]

Maybe things would be easier with the complete 16x8 in an array, like DIM GAME(15,7). No funny string manipulations. Have the relevant character codes directly there in the array. Easy loops through rows and columns. Count, and if same element found 4 or more times, then mark them up for later removal. One element can be candidate in both a row and a column. Maybe use yet another array, say DIM MARK(15,7). Clear them in GAME and clear MARK, then display GAME (using a loop with HCHAR). Check for “fall down”. Only have go through columns one at a time. Go from bottom and up. If you find an empty space, take all above and move one down. Continue loops. Display.

 

The pro here is simple array access, and I think it will be easier to get the logic right, not being confused by long string statements with POS and much more. The con is an array to display (loop of 128) instead of, what I think you were aiming at, some strings (loop of 16).

 

Sorry for the mess, just off my head.

 

Edited February 6, 2013 by sometimes99er

[RXB]

Just a thought here, what about binary?

 

I mean looking at the board you have:

 

White----- Black----- Plaid------

00000000 00000000 00000000

00000000 00000000 00000000

00000000 00000000 00000000

00000000 00000000 00000000

00010000 00000000 00000000

00010000 00000000 00000000

00000000 00000000 00000001

00000000 00000000 10000000

00000000 00000000 00000000

00000000 01000000 01010001

11101110 01001100 01110001

11101110 00000000 00000000

01000010 00000001 00000000

00010100 00001001 10001011

10010000 00000001 10010011

 

I mean it is 8 bits for each line and in binary horizontally and 16 bits vertically.

I was thinking how to save memory and time in comparisons to look for hits or miss.

Like I said just a thought.

 

Rich

Edited February 6, 2013 by RXB

[+Vorticon]

Hi!

 

It's only partly related to the XB Compiler but with the Assembler Function VREAD I can read from VRAM a number of bytes. Since XB stores your string variables in VRAM as well, I wonder if it is a waste of memory if I store all my strings as a string variable.

I can store/read a string into/from VRAM anyway. Or is it a performance question - is it faster to have dedicated string variables in the XB program already. I mostly need them in loops, so only one string at a time.

 

I ask because I want to do some string functions on the dr. mario 16x8 game screen: check for 4 chars of the same type in a row, check for 4 chars of the same type in a column. It's like a full line in Tetris which gets erased and the rest of the chars "fall down" accordingly.

 

If you don't know Dr. Mario, check out:

http://www.youtube.com/watch?v=xT4ksAgQouc

 

Klaus

There is a game called Virus Attack by Vern Jensen that is a clone of Dr. Mario. You can find it here on the tigameshelf.net site: http://tigameshelf.net/asm.htm

[Willsy]

I think you could look at stacks and recursion.

 

Check the whole board, from top left to bottom right.

 

If a cell is determined to be removed he marks himself for later removal, then he will then check his neighbours by calling the same checking routine, passing in his row & column. This continues in a recursive fashion.

 

Eventually all positions are checked, the recursion un-winds and the playfield can be redrawn.

[kl99]

Thanks to sometimes99er, RXB, Vorticon and Willsy for the tips on this complicated topic. I will answer to these in a dedicated game thread.

 

@senior_falcon:

I found two XB Compiler issues:

 

1. Extended Basic supports variable assignment like:

100 A,B=5
110 PRINT A;B

The compiler keeps hanging on a line number that contains such a multiple variable assigment. I suggest either add this to the documentation or try to add multiple variable assignment.

 

2. DISPLAY AT - SIZE Parameter is not interpreted:

Example:

100 CALL HCHAR(1,1,64,768)
110 DISPLAY AT(21,1)SIZE(:"12345678"
120 GOTO 120

In Extended Basic this program results in a screen filled with 760 "@" characters and 8 digits in row 21 from column 3 to 10.

This program compiles fine in XB Compiler 2.1 but the result looks like if you have not set the SIZE parameter.

So at least in this example the SIZE parameter is not interpreted and the whole row gets erased.

 

This should not be taken as a critic but the possibility to further enhance the undoubtable usefulness of your Compiler.

BTW: I will demonstrate the XB Compiler on the upcoming TI99 February Meeting in Vienna.

[senior_falcon]

Thank you for the feedback on the compiler. I will look into implementing your example 1 above. I will change the docs if it cannot be implemented. Example two is a bug that Joe Morris found. This crept in sometime when adding the comma, colon, and semicolon to DISPLAY AT. It worked fine earlier. Acually, it partially works - if you make the SIZE(5) then 12345 will be displayed, but then the rest of the line is blanked as you observed. I will fix this bug when I get a chance. Meanwhile a work around would be to use the DISPLY subroutine contained in CXTRAS. When done printing a string to the screen DISPLY does not blank the rest of the line. You might need to use SEG$ to make the string the right length. Thanks for demonstrating the compiler in Vienna!

[1980gamer]

Hi Harry,

I am trying to fix my game scoring.... here are 3 methods:

 

This one compiles but the # show on the screen and the score wraps.

3810 DISPLAY AT(15,22)USING "#######":SCR :: DISPLAY AT(14,23):"PLAYER"

3820 DISPLAY AT(10,22)USING "#######":HSC :: DISPLAY AT(9,24):"HIGH"

 

This one gives me...DSR ERROR:0082

3810 DISPLAY AT(15,22)SIZE(7):RPT$("0",7-LEN(STR$(SCR)))&STR$(SCR) :: DISPLAY AT(14,23):"PLAYER"

3820 DISPLAY AT(10,22)SIZE(7):RPT$("0",7-LEN(STR$(HSC)))&STR$(HSC) :: DISPLAY AT(9,24):"HIGH"

 

This works, but it only allows a score of 32K.

3810 DISPLAY AT(15,22):SCR :: DISPLAY AT(14,23):"PLAYER"

3820 DISPLAY AT(10,22):HSC :: DISPLAY AT(9,24):"HIGH"

 

Do you know of a work around?

 

Thank You,

Gene

[senior_falcon]

Hi Gene:

 

DISPLAY USING is not supported.

I don't know what is happening in the second example that gives the DSR error. I copied your code and added a few lines and it all compiled and ran properly:

5 CALL CLEAR

10 SCR=1234 :: HSC=5678

3810 DISPLAY AT(15,22)SIZE(7):RPT$("0",7-LEN(STR$(SCR)))&STR$(SCR):: DISPLAY AT(14,23):"PLAYER"

3820 DISPLAY AT(10,22)SIZE(7):RPT$("0",7-LEN(STR$(HSC)))&STR$(HSC):: DISPLAY AT(9,24):"HIGH"

3830 GOTO 3830

Maybe you are running out of memory - I'm not sure what will happen when you go over.

 

Integer arithmetic limits you to -32768 to 32767. If you divide everything by ten you'd be adding one for each dot eaten, 20 for the first ghost, etc. Then add a trailing zero when you print the score. This would get you up to 327670. If you want to get up into the millions you need two values for score - call them SCR and HSCR. Start out with both equal to zero. Add numbers to SCR the way you have been. If SCR is greater than 9999 then subtract 10000 from SCR and add one to HSCR. When you display the score, display 4 digits of HSCR (with leading zeros as necessary), then 4 digits of SCR (again with leading zeros where needed) That would get you up to 99,999,990 before rolling over. You only need to print HSCR when it changes, not every time you print the score.

Edited March 23, 2013 by senior_falcon

[1980gamer]

It seems the DSR error was do to disk space.

 

I have solved the scoring problem, but now I am out of space, I get memory full when I run!

 

Strange, I have 2600 Byte free before running and 2000-ish after running.

I have shrunk some variables and reused some as well! This doesn't give me room before running, but it does after running.

 

I am hoping for the best on this current build.

 

Thanks for the help,

Gene

[1980gamer]

Hi Harry,

I am at a loss. I have taken your scoring idea above, but I cannot get it to work.

Well, in XB it works fine, but when compiled, it doesn't keep the formatting.

I have attached lines cut from pacman and but into a scoring loop.

If you run both versions, you will see the problem. SC=Score It is +100 instead of 10 just to speed up testing.

 

Thanks,

Gene

 

PS I have tightend up pacman, it now has 2,325 bytes free after running and 2,989 before running.

But I have just enough room to create the loader, but I get memory full when running the -c version.

 

I don't think I have any variables I can re-use, I removed a few, these seem to help, where freeing bytes, does not.

I am so close, I'd hate to have to remove a maze t this point!

DSK2.zip

[senior_falcon]

Hi Gene:

Once again, you have found a creative way to use XB! I never thought RPT$ with a value of zero would be useful and so RPT$ in the compiler doesn't handle that situation properly - it treats RPT$(A$,0) the same as RPT$(A$,1). You can modify the file RUNTIME2 to fix this. Find RPTS near the end of the file. The third line is MOV *R5,R9. After this line add JEQ RPTS5 After this change your sample program works. SIZE seems to need a little work yet. I will see what I can do with that.

 

I don't know what else you can do to get a little extra memory. About all I can suggest is to go through the code with a fine toothed comb to see if there is anything else that can be tightened up.

[senior_falcon]

There is more than one way to divest a feline of it's fur... Instead of using RPT$ you can use SEG$ as follows:

20 DISPLAY AT(15,22):SEG$("00",1,3-LEN(STR$(HSR)))&STR$(HSR)&SEG$("000",1,4-LEN(STR$(SC)))&STR$(SC)

30 DISPLAY AT(10,22):SEG$("00",1,3-LEN(STR$(HHS)))&STR$(HHS)&SEG$("000",1,4-LEN(STR$(HSC)))&STR$(HSC)

Then you don't have to change RUNTIME. This runs fine in XB and compiled, plus is a little more compact than your code.

[1980gamer]

Thanks Harry,

The funny part, I was just messing with SEG$... I was way more convoluted in my methods... The cat would have used all 9 lives with my way of doing it! LOL

 

I am over 3000 bytes and I can compile and run without memory full. But I have not tested enough to know that will not happen.

I had been getting the memory full message during game play prior. Hoping that is behind me now!

I should have a final release tonight... What do I work on next?????

 

I have always liked space games, but the 4-5 sprites on a row issue has always bugged me!

With the ne smooth scroll, I will have to play with that new functionality.

Gene

[1980gamer]

Hi Harry,

I was wondering if you could take a look at this little program.

When I go to the RADAR screen it is nothing like I wrote it.

 

In XB it works fine, but compiled it is a mess. If I can get passed this screen, the battle screen is fine.

 

I will re-reference the XB Compiler manual, but the only thing I can think is call magnify(2)

But, I didn't think this could be it...

 

Thanks for taking a look.

Gene

DSK2.zip

Edited April 15, 2013 by 1980gamer

[senior_falcon]

Gene, you are using nested arrays which will crash the compiler. In lines 660 to 700 you have this type of line: 660 CALL CHAR(108,A$(FGS(1)).

 

FGS(1) returns a number which you are plugging into the string array A$(n). The fix is to change the line like this:

660 T=FGS(1)::CALL CHAR(108,A$(T)

 

This is not obvious looking at the XB code, but if you look at the source code you will see:

L660

DATA CHAR,NC36,SA1,NA5,NC9 etc.

The SA1 followed by NA5 is the tipoff. (SA1 means String Array 1 and NA5 means Numeric Array 5)

 

N.B. I stopped looking when I found the nested arrays mentioned above - there may be others in there.

[1980gamer]

Ah, Yes, nested arrays! I had this in my brain, we talked about arrays a few weeks ago, I guess I need to defrag and re-index my memory.

Thank you!

 

I will make the changes and see how it goes. Hopefully, I don't have anything else goofed up.

Gene

[Opry99er]

I know that Owen had a library for XB for background music, but it was different than just playing notes, IIRC. Not sure if that'd work with the compiler.

 

Just wait 'til you see what Harry's got cooking NOW, Howie... =) Oooooooh, you're gonna see some wicked stuff in the next week or two. =)

[RobertLM78]

I did a sum of the files on the TIDISK image, it looks like 365 sectors... what are the minimum files needed for the compiler to fit on a 90k disk?