Extended BASIC G.E.M.

[RXB]

13 hours ago, senior_falcon said:

I am finally in the home stretch on the XB Game Developer's Package.

One of the side effects that happened when the more complicated XB style IF/THEN/ELSE statements was that a trailing comment in the line would sometimes cause an error in the compiled code.

Interestingly enough, these two lines fail in different ways:

10 IF X=3 THEN Y=7 ! comment

10 IF X=3 THEN Y=7 REM comment

I have no idea why this happens or why they are different, but I put yet another band-aid on the code and it now works properly. Even better, I see no way this will lead to unexpected trouble in the future.

When the interpreter finds ! (explanation point) it has code in the XB ROMs to ignore this token after a program line 

When the interpreter finds REM (REMARK) it is not the same code but branches to part of that code 

This is why you get different results. 

If you put a :: between end of the line and the Y=7 in both lines you will get no errors.

 

10 IF X=3 THEN Y=7 ::  ! comment

10 IF X=3 THEN Y=7 :: REM comment

 

I bet if you test this it never gives different results in your compiler.
If you want I can show you the XB ROM code that is causing the problems.

 

[senior_falcon]

I have made a few updates to XB 2.9 G.E.M.

I have added the latest version of SteveB's Multi Color utilities, version 1.1

In another thread there was some discussion about the slowness of CALL CHAR. I was not aware of how slow it was, but once I knew about that, it was a straightforward job to replace some GPL code with assembly to speed things up a bit

CALL GCHAR can now read from more than one screen position with CALL GCHAR(ROW1,COL1,CHAR1,ROW2,COL2,CHAR2,ROW3,COL3,CHAR3,etc.)

In the near future, I will add this new material to the XB Game Developer's Package

Enjoy!

 

XB29GEM231229.zip

 

Here is an example of the speed difference between the old and new CALL CHARs, defining the characters starting at A with a 255 byte long string, first all F's, then all 0's. Only RXB and XB 2.9 G.E.M. can use a string of 255 bytes. (EDIT - it looks like RXB can only use 240 bytes of the string)  I used RXB for this example, but the previous XB 2.9 would have been just as slow. I understand that RXB 2024 will have a similarly modified CALL CHAR.

Once again, this is yet another good example of the difference between GPL and assembly.

 

 

 

 

Edited December 28, 2023 by senior_falcon

[SteveB]

A message from the future ...? Even in Europe it is still the 28th of December 🙂

 

Will these changes also be included in the compiler ? GCHAR is of interest to me, while I use VWRITE instead of CHAR for repeated re-definitions of characters where time is critical.

 

 

[senior_falcon]

2 hours ago, SteveB said:

A message from the future ...? Even in Europe it is still the 28th of December 🙂

Will these changes also be included in the compiler ? GCHAR is of interest to me, while I use VWRITE instead of CHAR for repeated re-definitions of characters where time is critical.

I have been accused of living in the past, but never in the future! Actually, I just put that date in thinking it would probably be done after that, then, but it turns out the work went a little faster than expected.

 

It is easy to modify GCHAR to read multiple screen locations. I will do that right now so I don't forget.

(edit - all done, testing now just tested and it works fine)

 

I adapted the assembly code for CHAR from the compiler, so there is nothing to add there.

I have to modify multicolor to be compatible with the compiler.

Edited December 29, 2023 by senior_falcon

[+OLD CS1]

8 hours ago, senior_falcon said:

Here is an example of the speed difference between the old and new CALL CHARs

Even in the presence of VDP bulk writes, this could be used for CALL CHAR-based animations.  Very cool.

[Retrospect]

CAPER < program file 

 

I've had a little tinker around with XB2.9.  Notice in my video the speed of the screen building up the graphics.  This is not compiled, it's straight XB2.9.  I've used CALL SCREENOF and built the entire screen using CALL HCHAR and VCHAR and then CALL SCREENON.  Also used is CALL CHIME, CALL CRASH and CALL NYANYA , and the nice font was present in the list of fonts installed in 2.9, I used CALL FONT(19)    

The game itself isn't much of a "game" at all it's just to demonstrate the speed increases in HCHAR.  It uses Joystick for left and right, Fire button jumps but you can only jump if not moving and only jumps to the right.  I won't bog this thread up with my stuff, this is merely so people can see the improvements  .  
 

 

 

[RXB]

Wonder how it would look in RXB 2023 as CALL HCHAR and CALL VCHAR are in Assembly not GPL.

Also you can combine many into one line like

10 CALL HCHAR(row,column,character-code,repetition,row,column,character-code,repetition,row,column,character-code)

See no having to call each HCHAR and use :: between them like normal XB

 

Than there is CALL ONKEY(string-variable,key-unit,key,status) GOTO line number list

that way instead of IF key=something it is done in the routine by looking at list in string variable

Example:

100 CALL ONKEY("123456789",KEY,STATUS) GOTO 510,520,530,540,550,560,570,580,590 :: GOTO 100

 

Or CALL JOYLOCATE(key-unit,x-return,y-return,row-index,column-index,#sprite,dot-row,dot-column) GOTO line number

the dot-row and dot-column are put into those variables as you move the joystick and move the sprite too

also the Joystick Fire button is detected and only if then the GOTO is used if pressed

(there is also CALL JOYMOTION)

 

These are all routines so programming is more easy and less program lines needed to be read into interpreter

Just wondering if the program speed would be better.

[senior_falcon]

To address a request for features, I took a few minutes to modify HCHAR and VCHAR so they can now perform multiple HCHARs or VCHARs in a single line.

If you choose to use this, the length is only optional for the last one. i.e.

CALL HCHAR(R1,C1,CH1,RPT1,R2,C2,CH2,RPT2,R3,C3,CH3)

The compiler has been modified so it will accept this format.

The other good news is that I am no longer unstuck in time!

XB29GEM231231.zip

Edited January 1 by senior_falcon

[fabrice montupet]

Very interesting new feature, thank you!

Do you have planned to propose a new disk based version of XB256/Compiler in next days?

[RXB]

On 12/28/2023 at 1:15 PM, senior_falcon said:

I have made a few updates to XB 2.9 G.E.M.

I have added the latest version of SteveB's Multi Color utilities, version 1.1

In another thread there was some discussion about the slowness of CALL CHAR. I was not aware of how slow it was, but once I knew about that, it was a straightforward job to replace some GPL code with assembly to speed things up a bit

CALL GCHAR can now read from more than one screen position with CALL GCHAR(ROW1,COL1,CHAR1,ROW2,COL2,CHAR2,ROW3,COL3,CHAR3,etc.)

In the near future, I will add this new material to the XB Game Developer's Package

Enjoy!

 

XB29GEM231229.zip 2.24 MB · 14 downloads

 

Here is an example of the speed difference between the old and new CALL CHARs, defining the characters starting at A with a 255 byte long string, first all F's, then all 0's. Only RXB and XB 2.9 G.E.M. can use a string of 255 bytes. (EDIT - it looks like RXB can only use 240 bytes of the string)  I used RXB for this example, but the previous XB 2.9 would have been just as slow. I understand that RXB 2024 will have a similarly modified CALL CHAR.

Once again, this is yet another good example of the difference between GPL and assembly.

 

 

 

 

That is RXB 2023 and does not have the 2024 Assembly routines after RXB 2024 has not been released yet. 

Also like XB 2.9 GEM up to 255 characters in a string so RXB 240 character string was just a thought at the time.

 

Lastly RXB 2024 can do this from Console only with no 32K to get that speed increase.

And it will be the same speed with or without 32K installed as this all runs from FAST SCRATCH PAD RAM.

 

(Nice to have a competitor as since RXB 2000 I did not have many competitors at all doing updates.)

[RXB]

1 hour ago, fabrice montupet said:

Very interesting new feature, thank you!

Do you have planned to propose a new disk based version of XB256/Compiler in next days?

Thanks I had that FEATURE in RXB 2000 and that was some time ago, as RXB was the first one to do it.

 

So I agree it is a great feature to be included into XB 2.9 GEM

[senior_falcon]

19 hours ago, fabrice montupet said:

Very interesting new feature, thank you!

Do you have planned to propose a new disk based version of XB256/Compiler in next days?

Yes, I will release that soon.

[fabrice montupet]

21 hours ago, RXB said:

Thanks I had that FEATURE in RXB 2000 and that was some time ago, as RXB was the first one to do it.

 

So I agree it is a great feature to be included into XB 2.9 GEM

 

Yes, your RXB had this feature since a very long time, its pretty nice. But Harry's one is  just a little enhancement of a masterpiece tool: XB256/Compiler whose the powerful meets (even outperforms) the expectations of any Extended Basic programmer. 

The French philosopher and author Albert Camus said "Most important is not to be the first but to be the best".

[RXB]

1 hour ago, fabrice montupet said:

 

Yes, your RXB had this feature since a very long time, its pretty nice. But Harry's one is  just a little enhancement of a masterpiece tool: XB256/Compiler whose the powerful meets (even outperforms) the expectations of any Extended Basic programmer. 

The French philosopher and author Albert Camus said "Most important is not to be the first but to be the best".

I give credit where credit is due. Thus when I get help or an idea I credit where I got it.

Lee Stewart for his work on ROM 3 of RXB. Miller Graphics for GK XB included in RXB.

Honesty is more important then pride.

[fabrice montupet]

Please don't exaggerate, adding parameters for multiple CALL HCHAR in one CALL is very nice  but just a common improvement, it is not new and not anyway a "RXB" innovation.  TI developers used this feature in the original BASIC far before RXB existed. And I didn't read you in your manual thanking (crediting) them for that.

[Retrospect]

call say("uhoh")

[RXB]

1 hour ago, fabrice montupet said:

Please don't exaggerate, adding parameters for multiple CALL HCHAR in one CALL is very nice  but just a common improvement, it is not new and not anyway a "RXB" innovation.  TI developers used this feature in the original BASIC far before RXB existed. And I didn't read you in your manual thanking (crediting) them for that.

Hmmm what have you ever done? 

I do not see your name pop up on anything? (And you are going to disrespect me?)

[+OLD CS1]

Guys, take it elsewhere.

[Retrospect]

On 1/2/2024 at 11:37 PM, fabrice montupet said:

TI developers used this feature in the original BASIC

If this is from back in time, say the late 1970's, or early 1980's , which Basic used it?  Was it something they had on the 990?  This is actually interesting.  For me, anyhow.

[fabrice montupet]

I'm sorry, a word is missing in my sentence, I wanted to write "Extended Basic" not only "Basic".

[RXB]

21 hours ago, Retrospect said:

If this is from back in time, say the late 1970's, or early 1980's , which Basic used it?  Was it something they had on the 990?  This is actually interesting.  For me, anyhow.

Well it was not in XB3 as I just checked.

i.e. CALL HCHAR(row,column,character-code,repetition,row,column,character-code,repetition,row,column,character-code,...)

Not part of Mechatronics Extended Basic 2+

Advanced Basic (ABASIC) is same as BASIC format

990 BASIC is almost exactly the same as TI99/4 Basic or TI99/4A Basic with some added memory feature not found in a TI99/4A

 

CALL HCHAR is pretty unique to the TI world and other Basic in other computers were quite different with similar features.

All in all the first one with repeated use in a single command was RXB way back in 1997/1998/2000 and each version later...

I was also curious about this so I did some research to find out going through all the manuals in all these XB versions.

 

 

[fabrice montupet]

I didn't specifically talk about CALL HCHAR but the fact to add the way to pass multiple statements in a single CALL.  
I just said that this kind of optimization was not new, CALL COLOR, SPRITE, CHAR, CHARPAT and some others permit that since the original TI Extended Basic. I also said that adding this to CALL HCHAR on RXB was nice and it was a good news to see it in XB256 was nice too. I said nothing else, no disrespect.

[senior_falcon]

This is a little embarrassing, but here is yet another revision of XB 2.9 G.E.M., version 2.920240104

Retrospect found a bug in my fast HCHAR and VCHAR routines, which only happened very occasionally. Somehow the interrupt routine and the VCHAR and HCHAR routines were occasionally colliding. After a good look at the code, I realized there was a simpler way that had the advantage of being a wee bit faster. That is fixed now.

This is a perfect example of the old saying, "The sooner you start to code, the longer the job will take."

 

While testing his program, I found another bug that I am afraid will have to remain. When using XB256, there are 2 screens, Screen1 and Screen2. Both use the same VDP area for the actual screen, but they have separate character patterns, colors, etc. When you are in Screen2 and break the program with <Fctn 4>, screen2 must be swapped out for screen1. To do this, the interrupt routine looks for a character code of 2 in >8375. When it sees this, it knows that a break is happening and to swap the screens. This works fine, except when you are using a key unit of 1. In that case, if you press "S", the character code is 2 and the screens are swapped, but the program does not break. In this case, you can press <Fctn 4> to break the program, then start it up again.

I have looked at several methods to deal with this, but so far have had no success. I have a few more ideas, but am not very optimistic. This will not affect compiled programs.

 

There was yet another "bug" that caused Classic99 to report an illegal opcode. This was in XB256 in the routines that do the Star Wars text crawl. In a subroutine, I did an INC R11 instead of INCT R11, leaving the program counter set to an odd address on return. This caused no problems, but it should not be that way and it is all fixed now.

 

XB29GEM240104.zip

[1980gamer]

@senior_falcon Will you be adding the same update to GCHAR?

I think most of us use 4 or even 8 call GCHAR commands at a time.

 

I want to look ahead North, South, East and West, maybe even NE, NW, SE, SW 

 

I know many methods can be used to avoid GCHAR.  I just love GCHAR because I can build any random maze or screen etc. and always know I can hit a wall etc.

Or looking for an OBJECT on the screen, I don't need to keep track of object locations. 

 

Thank you for continuing to improve G.E.M. 

[senior_falcon]

24 minutes ago, 1980gamer said:

@senior_falcon Will you be adding the same update to GCHAR?

I think most of us use 4 or even 8 call GCHAR commands at a time.

 

I want to look ahead North, South, East and West, maybe even NE, NW, SE, SW 

 

I know many methods can be used to avoid GCHAR.  I just love GCHAR because I can build any random maze or screen etc. and always know I can hit a wall etc.

Or looking for an OBJECT on the screen, I don't need to keep track of object locations. 

 

Thank you for continuing to improve G.E.M. 

Yes, GCHAR can do that. But only in XB 2.9 G.E.M.

It will be compatible with the compiler, but wait for the new version for that.