XB Game Developers Package

[senior_falcon]

Yes, you are right on both counts.

The statement separator :: will not compile properly if it is at the end of a line, whether it is followed by a comment or not.

REM can be used in XB following the statement separator, but that will not compile, so it has to be like your

10 A=B+C ! summation of variables

or my

1170 IF YEL+BLU+RED=0 THEN 690 ! CLEARED

[SteveB]

This had me wasting half an evening some months ago ... I cut&paste XB code and left a :: :: standing ... bad idea. 

 

TiCodEd now looks for it and issues a warning ... I might include ":: REM" as well.

[jschultzpedersen]

Hi

 

Just in case someone runs into this problem... If you have Norton installed on a Windows machine, and you download TiCodEd 251, you may experience that Norton wants to kill off the folder LibXBKTN and the TiCodEd.exe file. The files are put in quarantine and disappears from the downloaded and unpacked installation. This happens because Norton decides that the files are so rare and thus not verified by enough users, and that makes them suspicious even if a manual scanning finds no problems. One easy solution is to remove them from quarantine manually in Norton. This, of course, assumes that you trust the source of the files, and in this case, I do. This can happen whenever there is an update.

[senior_falcon]

On 3/2/2024 at 8:06 AM, SteveB said:

This had me wasting half an evening some months ago ... I cut&paste XB code and left a :: :: standing ... bad idea. 

 

TiCodEd now looks for it and issues a warning ... I might include ":: REM" as well.

Thank you! That should help the unwary avoid this in the future.

[Cheung]

On 3/2/2024 at 3:03 PM, jschultzpedersen said:

Hi

 

Just in case someone runs into this problem... If you have Norton installed on a Windows machine, and you download TiCodEd 251, you may experience that Norton wants to kill off the folder LibXBKTN and the TiCodEd.exe file. The files are put in quarantine and disappears from the downloaded and unpacked installation. This happens because Norton decides that the files are so rare and thus not verified by enough users, and that makes them suspicious even if a manual scanning finds no problems. One easy solution is to remove them from quarantine manually in Norton. This, of course, assumes that you trust the source of the files, and in this case, I do. This can happen whenever there is an update.

might be a good idea to add this to any release notes or readme for the next release.

[SteveB]

Ooops ... we did it! We reached the maximum symbols and got an "Symbol table overflow" in our latest project.

 

As many symbols where line-number labels, we managed to reduce the number of lines by packing multiple statements in one line using the :: . 

 

Right now we have 1994 labels in our assembly listing. We haven't found the limit in the E/A Manual, but have an idea what the maximum might be ... 

 

So keep this limit in mind when coding compiled XB.

 

Steve and Grammostola 

 

PS: Something great is comming up ...

 

Edited September 3 by SteveB
typo

[senior_falcon]

16 hours ago, SteveB said:

Ooops ... we did it! We reached the maximum symbols and got an "Symbol table overflow" in our latest project.

 

"Symbol table overflow"

I wrote a 2122 line XB program like this: 1 X=3   2 X=3   ....    2122 X=3.

When assembling with the TI assembler included with the XBGDP, I get the "symbol table overflow" error message.

But Asm994a which is also part of the XBGDP will assemble this without error. (Plus it is much faster.)  I would think that any assembler that run on windows would work.

Edited September 3 by senior_falcon

[+OLD CS1]

1 hour ago, senior_falcon said:

I wrote a 2122 line XB program like this: 1 X=3   2 X=3   ....    2122 X=3.

OMG the pain and the agony of time:

 

NUM 1,1
1 X=3
2 X=3
3 X=3
4 X=3
5 X=3
6 X=3
7 X=3
...

[senior_falcon]

I used a text editor to copy X=3 a bunch of times.

Then Num 1,1 and Paste XB

The first 100 go fast, but by the time you get to 2000 it is pretty slow.

[SteveB]

6 hours ago, senior_falcon said:

But Asm994a which is also part of the XBGDP will assemble this without error. (Plus it is much faster.) 

That was my first thought ... Asm994 assembled without error, but the loader was not able to load the created file, it crashed the TI. 

 

I used @F.G. Kaal Xa99 from within TiCodEd when I got "Error 4 - Symbol Table Overflow" and was surprised that it was that compatible to the original E/A, which I also tried.

 

 

 

[senior_falcon]

Interesting. I will take a look to see if there is a solution.

[+Lee Stewart]

On 9/2/2024 at 3:58 PM, SteveB said:

Ooops ... we did it! We reached the maximum symbols and got an "Symbol table overflow" in our latest project.

 

As many symbols where line-number labels, we managed to reduce the number of lines by packing multiple statements in one line uing the :: . 

 

Right now we have 1994 labels in our assembly listing. We haven't found the limit in the E/A Manual, but have an idea what the maximum might be ... 

 

So keep this limit in mind when coding compiled XB.

 

Steve and Grammostola 

 

PS: Something great is comming up ...

 

1 hour ago, SteveB said:

That was my first thought ... Asm994 assembled without error, but the loader was not able to load the created file, it crashed the TI. 

 

I used @F.G. Kaal Xa99 from within TiCodEd when I got "Error 4 - Symbol Table Overflow" and was surprised that it was that compatible to the original E/A, which I also tried.

 

I ran into a symbol table overflow with Cory Burr’s Asm994a on fbForth 2.0 at somewhere around 2800 symbols, as I recall. At some point, I figured out how to reduce the number of labels I was using by 500 – 1000. At the moment, fbForth 3.0 is at 2487 symbols and I am using @ralphb’s very nice xas99.

 

...lee

[senior_falcon]

6 hours ago, SteveB said:

That was my first thought ... Asm994 assembled without error, but the loader was not able to load the created file, it crashed the TI.

I added one line to my program with the X=3 statements: 10000 PRINT "MADE IT THROUGH"

This assembles without error using Asm994a.

The loader was able to load the program properly, and I could save in EA5 and XB format. And the program runs properly by printing MADE IT THROUGH and then stopping.

I understand there are some errors in Asm994a, but have not seen any that caused problems when assembling compiled code.

So....I don't know why your program would have assembled without error but then crashed in the loading process.

 

 

 

[jschultzpedersen]

In case someone is interested... Instead of COPY/PASTE exercises you can create a small EXTENDED BASIC program to generate the test material. The program below will generate a thousand lines numbered 1-1000, each with the content 'A=3'. It takes a few minutes at normal TI99 speed and generates a file in MERGE format. The bad news is, that merging a thousand lines into a program with the MERGE command takes a very long time - perhaps half an hour in fact. So it is highly recommended to use the 'CPU overdrive' option in Classic99. Even then it takes about 3.5 minutes on my PC. But hey... The computer is doing all the work, so who cares. Once the 1000 line program is created from the MERGE operation, you can save it as a normal program and load at normal speed.

 

PS. Be careful not to miss any ';' characters.

 

100 OPEN #1:"DSK3.TSTPGM",VARIABLE 163,DISPLAY ,OUTPUT
105 FOR N=1 TO 1000
106 A=INT(N/256):: B=N-A*256       * Calc 2-byte line no.
110 PRINT #1:CHR$(A)&CHR$(B);     * Insert line no in program line.
120 PRINT #1:CHR$(65)&CHR$(190)&CHR$(200)&CHR$(1)&CHR$(51);     * insert variable name 'A' (chr$(65)); insert token (190) for '='; insert token for undelimited text of length 1 (200,1); Insert value as string. We use '3' (chr$(51)). 

130 PRINT #1:CHR$(0)      * insert end of program line code.
135 NEXT N
140 PRINT #1:CHR$(255)&CHR$(255)    * insert end of file marker.
150 CLOSE #1
 

[SteveB]

... or create a text-file using Libre Office, Excel or Google Sheets for the line numbers and use Ti99Dir to convert the text file it to a tokenized TIFILES program (for those who think TiCodEd is lava .... 😉 as it saves in merge- and regular tokenized format to a FIAD directory)

[F.G. Kaal]

22 hours ago, SteveB said:

I used @F.G. Kaal Xa99 from within TiCodEd when I got "Error 4 - Symbol Table Overflow"

Do you need more symbol space? It is just a number in XA99!

 

#define MAX_SYMBOLS 2000    // Maximum number of symbols
 

[SteveB]

1 hour ago, F.G. Kaal said:

Do you need more symbol space? It is just a number in XA99!

 

#define MAX_SYMBOLS 2000    // Maximum number of symbols
 

The Asm994 generated object code didn't work, but it might have been another reason.

 

Could you send me a version with an increased constand, 2500 or 3000 ?

 

I will revert my changes and try if this works... the tests of @senior_falcon sound encouraging ...

 

[SteveB]

And another question for @senior_falcon : We are always fighting memory limitations on the TI. SIZE show me some 11kB of Stack Size. 

 

Do you have any hint of making more use of it for compiled XB? Strings are stored in CPU RAM. Video RAM is slower ... but how can I use it?

 

Thank you

Steve

 

 

[+Lee Stewart]

1 hour ago, SteveB said:

The Asm994 generated object code didn't work, but it might have been another reason.

 

Years ago, I ran into trouble with Asm994a when some of my symbols stepped on undocumented Asm994a conditionals for conditional assembly. Use of labels like “IF”, “ELSE”, “ENDIF”, logical/Boolean operators (I think), etc., resulted in mysterious, i.e., very unhelpful, error messages or none at all.  When I got no error messages, but the code wouldn’t work, I had to do some pretty painful debugging until I eventually realized I needed to avoid the above sorts of labels. I used such labels because the original TI Forth used them for the assembly code field addresses of Forth words with the same names—it was convenient, after all. Prepending ‘_’ to all of those labels finally produced working code.

 

...lee

[senior_falcon]

7 hours ago, SteveB said:

And another question for @senior_falcon : We are always fighting memory limitations on the TI. SIZE show me some 11kB of Stack Size. 

 

Do you have any hint of making more use of it for compiled XB? Strings are stored in CPU RAM. Video RAM is slower ... but how can I use it?

 

Thank you

Steve

 

 

String constants have to be somewhere in the program, which resides in CPU ram. You could copy them into VDP ram, but they would still be in CPU ram, so there is nothing to be gained by moving them.

In theory, string variables and arrays could be put into the VDP ram. I have no interest in changing the code. The slightest change in the compiler can lead to unexpected problems elsewhere, and that would be a major change.

String handling is in the runtime routines, probably RUNTIME1. You are welcome to try to make this change.

[RXB]

1 hour ago, senior_falcon said:

String constants have to be somewhere in the program, which resides in CPU ram. You could copy them into VDP ram, but they would still be in CPU ram, so there is nothing to be gained by moving them.

In theory, string variables and arrays could be put into the VDP ram. I have no interest in changing the code. The slightest change in the compiler can lead to unexpected problems elsewhere, and that would be a major change.

String handling is in the runtime routines, probably RUNTIME1. You are welcome to try to make this change.

Did you start releasing all the source code in XB 2.6 GEM for others to use or modify?

Edited September 5 by RXB
missing text

[SteveB]

8 hours ago, senior_falcon said:

String constants have to be somewhere in the program, which resides in CPU ram. You could copy them into VDP ram, but they would still be in CPU ram, so there is nothing to be gained by moving them.

In theory, string variables and arrays could be put into the VDP ram. I have no interest in changing the code. The slightest change in the compiler can lead to unexpected problems elsewhere, and that would be a major change.

String handling is in the runtime routines, probably RUNTIME1. You are welcome to try to make this change.

Yes, the current string-handling is very efficient, this was not my request. I frequently use strings as "array of bytes" to store runtime data. I could store this data in the stack area with VPOKE/VPEEK or MOVE, if I knew how to reserve space or which memory areas are safe to use, saving string CPU RAM. In XB256 I can reserve additional VRAM with CALL LINK("XB256”[,n bytes VDP memory to reserve]), but I don't know how to do this for a compiled program. 

 

[senior_falcon]

47 minutes ago, SteveB said:

Yes, the current string-handling is very efficient, this was not my request. I frequently use strings as "array of bytes" to store runtime data. I could store this data in the stack area with VPOKE/VPEEK or MOVE, if I knew how to reserve space or which memory areas are safe to use, saving string CPU RAM. In XB256 I can reserve additional VRAM with CALL LINK("XB256”[,n bytes VDP memory to reserve]), but I don't know how to do this for a compiled program.

My bad - I misunderstood the request. Assuming the default space for 3 disk files is used, I think the addresses below should be safe if running from EA5 or a cart. If you are using an XB loader and want to return to XB, there would be somewhat less room at each end.

For:

XB         >0958 - >37D7

XB256   >1820 - >37D7

T40XB   >13C0 - >37D7

T80XB   >1780 - >37D7

[+Lee Stewart]

2 hours ago, senior_falcon said:

My bad - I misunderstood the request. Assuming the default space for 3 disk files is used, I think the addresses below should be safe if running from EA5 or a cart. If you are using an XB loader and want to return to XB, there would be somewhat less room at each end.

For:

XB         >0958 - >37D7

XB256   >1820 - >37D7

T40XB   >13C0 - >37D7

T80XB   >1780 - >37D7

 

The VRAM upper limit (>37D7 here) is available at >8370, is it not?

 

...lee

[senior_falcon]

1 hour ago, Lee Stewart said:

 

The VRAM upper limit (>37D7 here) is available at >8370, is it not?

 

...lee

Yep, so that would be different if you did CALL FILES(1).