Extended BASIC G.E.M.

[senior_falcon]

While testing XB 2.9 G.E.M., I found a strange error in "Who's Behind the Mexican UFOs"

It runs fine under normal XB 110.  Using the newest (unreleased) version of XB 2.9, after you run "TITLE", the program tries to run "START", but reports an error  and stops. This took a while to sort out. The newest version of XB 2.9 handles the stack pointers in a different manner, and so I immediately felt that change was at fault. Fortunately, with Classic99 you can run the two side by side to see what is different. And also, the debugger is most helpful to see what is happening when loading a file. To make a long story short, START is 15 sectors long which is almost 4K, and most importantly, it is in program format, not IV254. It is a mystery to me why this should work at all under normal XB. When using TML in the 16 color mode, it should not be possible to load a program file of this size. The new version correctly catches the error and issues an error. This of course, made me suspect the new version was to blame, but it turns out the problem was in the original version.

The solution is simple:

OLD DSK1.START

CALL SAVEIV("DSK1.START")

and after saving in IV254 format, it works as expected.

[+OLD CS1]

On 5/21/2023 at 8:15 AM, mizapf said:

Easy to clarify: The PEEK subprogram from Editor/Assembler supports it, the one from Extended Basic does not.

Huh.  Interesting.  I remembered the same syntax @fabrice montupet was expecting.  However, I never had XB but I had the MiniMemory, so I looked and lo!  (From the MiniMemory manual.)

[senior_falcon]

On 5/20/2023 at 5:02 PM, fabrice montupet said:

I have found a problem in my XB256 compiled program, it concerns CALL PEEK.

If I write: CALL PEEK(W,P) :: CALL PEEK (W+64, Q) , when compiled the program gives the good values to P and Q.

But if I write: CALL PEEK(W,P,"",W+64, Q) , the compiled program gives good values to P but not to Q, so I wonder if the empty string "" between two variables and permitting to read values starting at more than one address works with the compiler.

Here is a modification you can make so it will work the way you want. But you must remember that you cannot test this in XB. it will only work in a compiled program.

In the file RUNTIME3.TXT you will find these lines of code:

PEEK     BL @GET1
            MOV *R6,R1
PEEK1    C *R13,R15   See if next word is a number or an instruction
             JGT MAX3           (was JH) jumps  to B @RTN
             BL @GET1

            BL @ASTRNG       add these two lines

            JEQ PEEK
             MOVB *R1+,R2
             SRL R2,8
             MOV R2,*R6
             JMP PEEK1

[+mizapf]

On 5/21/2023 at 3:29 PM, fabrice montupet said:

Thank you Michael. So the problem is EXB.  I should have verify in EXB.  In fact, I never use it anymore since I  discovered the excellent XB256 .
I wonder what things had in EXB TI developers minds... May be some missing memory space in EXB ROM to do the same as in E/A. In any case, making the same subprogram with different function/behavior is really frustrating.   But i will find another way to speed up my program 🙂 

 

I'm not sure which one was first, Extended Basic (100) or Editor/Assembler. The version 100 already lacks the feature to specify an address after "".

 

Maybe there were different developers involved. Mind that the loader (subprogram LOAD) of Extended Basic does not support the binary encoding of the object code (aka "compressed format") either, while the E/A version does. I'm not sure whether this is really a matter of cartridge space, or whether the E/A version is just enhanced.

[+RXB]

33 minutes ago, mizapf said:

 

I'm not sure which one was first, Extended Basic (100) or Editor/Assembler. The version 100 already lacks the feature to specify an address after "".

 

Maybe there were different developers involved. Mind that the loader (subprogram LOAD) of Extended Basic does not support the binary encoding of the object code (aka "compressed format") either, while the E/A version does. I'm not sure whether this is really a matter of cartridge space, or whether the E/A version is just enhanced.

I think it is due to the EQUats that are not compatible with Editor Assembler in Extended Basic 100 or 110.

I have in RXB the original EA and XB GPL source code for both object code loaders and the uncompressed loader in XB is quite large,

so I think they lacked space for a compressed loader in XB.

I may be able to add a compressed object code loader as more commands are being moved to Assembly from GPL space in RXB.

[fabrice montupet]

7 hours ago, senior_falcon said:

Here is a modification you can make so it will work the way you want. But you must remember that you cannot test this in XB. it will only work in a compiled program.

Thank you very much Harry.

That it only works in a compiled program is not a problem as my program uses memory in a way that it already can't be executed under XB, to play with it I  systematically have to compile it 🙂

 

[+RXB]

I made a note to add a Compressed Object Code Loader to RXB in future.

[senior_falcon]

6 hours ago, fabrice montupet said:

Thank you very much Harry.

That it only works in a compiled program is not a problem as my program uses memory in a way that it already can't be executed under XB, to play with it I  systematically have to compile it 🙂

 

For what it's worth, consider the following program:

10 CALL PEEK(A,B,C,"",D,E,F)
20 CALL PEEK(A,B,C):: CALL PEEK(D,E,F)

In Extended BASIC, line 10 is more compact than line 20, and should execute faster. (this assumes that XB could actually run it)

But when compiled, line 10 uses the same number of bytes as line 20.

I also believe that when compiled, because of the 2 extra instructions needed in the loop, line 10 would actually be a bit slower than line 20.

 

[+RXB]

13 hours ago, senior_falcon said:

For what it's worth, consider the following program:

10 CALL PEEK(A,B,C,"",D,E,F)
20 CALL PEEK(A,B,C):: CALL PEEK(D,E,F)

In Extended BASIC, line 10 is more compact than line 20, and should execute faster. (this assumes that XB could actually run it)

But when compiled, line 10 uses the same number of bytes as line 20.

I also believe that when compiled, because of the 2 extra instructions needed in the loop, line 10 would actually be a bit slower than line 20.

 

Just looking at the problem the "" is 2 tokens not 1 token.

The first " is a token and second " is the other token so you have a comma  than 2 quote tokens and the next comma.

Thus a :: is actually a single token in as parsed by the ROM interpreter, CALL Is a single token too.

Instead of a "" I would have used the & or # single token to save space and be faster.

10 CALL PEEK(A,B,C,"",D,E,F)

or 

10 CALL PEEK(A,B,C,&,D,E,F)

or 

10 CALL PEEK(A,B,C,#,D,E,F)

Would be faster and smaller by saving a token use. (Personally I prefer the & as it make more sense to read.)

[fabrice montupet]

On 5/24/2023 at 4:30 AM, senior_falcon said:

For what it's worth, consider the following program:

10 CALL PEEK(A,B,C,"",D,E,F)
20 CALL PEEK(A,B,C):: CALL PEEK(D,E,F)

In Extended BASIC, line 10 is more compact than line 20, and should execute faster. (this assumes that XB could actually run it)

But when compiled, line 10 uses the same number of bytes as line 20.

I also believe that when compiled, because of the 2 extra instructions needed in the loop, line 10 would actually be a bit slower than line 20.

 

Thank you Harry for this information. I keep it preciously in mind if one day I have to optimize the speed of a future program at its maximum.
For my game project in development, I tried the two options and the XB256 compilation feature is so incredible by its performances that I haven't seen any difference in speed. It's so quick!
Never mind if one Token more is used  when using the null string "". As the CALL PEEK routine is used one time in a subprogram, the one Token more consumed is insignificant.

[senior_falcon]

In a different thread, there was some speculation about the capabilities of CALL DV2XB in XB 2.9 G.E.M. vs. CALL USER in RXB. I think the following short videos should help clarify matters.

 

I made a short batch file that does CALL INIT, then loads SteveB's multicolor routines, then runs his BISBEE demo program

   CALL INIT
   CALL LOAD("DSK3.MCOLOR.OBJ")
   RUN "DSK3.BISBEE"

This was saved in two formats. MCBATCH.TXT is the file saved in windows format. MCBATCHDV is the file saved in DV80 format.

 

This video compares the results loading MCBATCHDV, the DV80 format file. Both work as advertised. You can see that I take my time starting it in XB 2.9, but because of GEM's fast assembly loader, it starts much faster.

 

The next video shows the results loading MCBATCH.TXT, the windows format file. You can see that RXB does not process the windows format batch file properly.

 

To me, the real utility of these subprograms is the ability to save portions of an XB program, then merge it into another program. This is more versatile than saving in merge format because you can select which lines to save.

 

The videos below show how this can be done. In these videos, I load an XB program, then save lines 215 to 225 in DV80 format using LIST. I then NEW, and use DV2XB or USER to enter those lines into XB.

You will see that XB 2.9 G.E.M. is the only one that can handle this.

You can force a save in windows format this way:

LIST "DSKn.?W.FILE.TXT”

The results are the same, so I will not post them.

 

I think you can see that XB 2.9 G.E.M. has some powerful capabilities when it comes to batch processing. Perhaps the misunderstanding happened because I did not specifically mention batch processing in the manual. That omission has been corrected.

 

When used in a batch file, NUM led to some erratic behavior. This, too, has been corrected in the newest version.

Also, using LIST in a batch file will crash the computer. I am not certain why this is so, but can see no reason to spend time fixing something that has no practical use.

 

The most recent version includes SteveB's multicolor routines and should be ready for release soon.

 

(Edit) As far as I can see, RXB cannot use LIST to produce a file that is compatible with CALL USER. But files created with XB 2.9 G.E.M. are compatible. In the video below, I have loaded an XB program, then saved it to disk using LIST. I then use CALL USER and CALL DV2XB to load that program into XB. Both load the program properly, but there is a noticeable difference in performance.

 

 

 

 

 

 

Edited June 2 by senior_falcon

[senior_falcon]

Here is XB 2.9 G.E.M. version 2.9230611

The biggest change is that SteveB's multicolor routines have been added.

I have added STCR and LDCR so you can play with cru access from Extended BASIC.

There are some changes that hopefully will make the graphics programs more compatible with cpu overdrive in Classic99.

XXB and DM1000 have been removed from the main menu and the multicolor routines have been added.

You can still access XXB and DM1000 with CALL XXB and CALL DM1000

 

XB29GEM230611.zip

 

 

Edited June 17 by senior_falcon

[fabrice montupet]

Thank you, that's great.

Is there a new disk based version of XB256/Compiler?

[senior_falcon]

3 hours ago, fabrice montupet said:

Thank you, that's great.

Is there a new disk based version of XB256/Compiler?

Yes. I was going to post that yesterday, but in doing some final testing found a problem with the cartridge maker. This was simple to fix. You need to do CALL FILES(1) before loading and running MAKECART8. The annoying thing is that I already knew that, but didn't take notes and so forgot to put it in the docs.

On vacation for a week. When I'm back, I will do the final testing and will upload it, assuming all works as expected.

[+RXB]

On 6/1/2023 at 7:39 PM, senior_falcon said:

In a different thread, there was some speculation about the capabilities of CALL DV2XB in XB 2.9 G.E.M. vs. CALL USER in RXB. I think the following short videos should help clarify matters.

 

I made a short batch file that does CALL INIT, then loads SteveB's multicolor routines, then runs his BISBEE demo program

   CALL INIT
   CALL LOAD("DSK3.MCOLOR.OBJ")
   RUN "DSK3.BISBEE"

This was saved in two formats. MCBATCH.TXT is the file saved in windows format. MCBATCHDV is the file saved in DV80 format.

 

This video compares the results loading MCBATCHDV, the DV80 format file. Both work as advertised. You can see that I take my time starting it in XB 2.9, but because of GEM's fast assembly loader, it starts much faster.

 

The next video shows the results loading MCBATCH.TXT, the windows format file. You can see that RXB does not process the windows format batch file properly.

 

To me, the real utility of these subprograms is the ability to save portions of an XB program, then merge it into another program. This is more versatile than saving in merge format because you can select which lines to save.

 

The videos below show how this can be done. In these videos, I load an XB program, then save lines 215 to 225 in DV80 format using LIST. I then NEW, and use DV2XB or USER to enter those lines into XB.

You will see that XB 2.9 G.E.M. is the only one that can handle this.

You can force a save in windows format this way:

LIST "DSKn.?W.FILE.TXT”

The results are the same, so I will not post them.

 

I think you can see that XB 2.9 G.E.M. has some powerful capabilities when it comes to batch processing. Perhaps the misunderstanding happened because I did not specifically mention batch processing in the manual. That omission has been corrected.

 

When used in a batch file, NUM led to some erratic behavior. This, too, has been corrected in the newest version.

Also, using LIST in a batch file will crash the computer. I am not certain why this is so, but can see no reason to spend time fixing something that has no practical use.

 

The most recent version includes SteveB's multicolor routines and should be ready for release soon.

 

(Edit) As far as I can see, RXB cannot use LIST to produce a file that is compatible with CALL USER. But files created with XB 2.9 G.E.M. are compatible. In the video below, I have loaded an XB program, then saved it to disk using LIST. I then use CALL USER and CALL DV2XB to load that program into XB. Both load the program properly, but there is a noticeable difference in performance.

 

 

 

 

 

 

Loading a program is not the reason for CALL USER, that is just a secondary use. 

The main use is to load and run programs from a single file and do things like Renumber or Edit files and save them then run them from CALL USER.

Or add lined to programs and save them in merge format or program format.

Sorry but you are comparing only one thing and ignore the hundreds of other uses CALL USER can do.

Can your version run multiple version of Assembly programs all from a single DV80 Text file?

 

This is a video of CALL USER and there are 12 videos made from this single CALL USER file demo.

 

[senior_falcon]

In my testing I found a minor problem that occurs only when using The Missiing Link.

If you use CALL HELP or CALL EDIT40 or CALL EDIT80, then a Missing Link program will crash. I now understand what causes this problem. CALL HELP is fixed and I am about halfway in correcting the other two.

I found this out the hard way. I was working on a short Missing Link program and used CALL HELP to check a color code. Adios program! And of course I had not saved a backup.

[senior_falcon]

Here is XB2.9 G.E.M. version 20230707

The problems mentioned in my previous post have been corrected. Now the 40 or 80 column editor, CALL HELP and CALL SAVEIV work properly when using The Missing Link.

XB29GEM230707.zip

 

(Edit - the README! file has been updated to give the correct information about how to add this to Classic99)

 

 

There has been further speculation regarding supposed shortcomings in XB2.9 G.E.M.'s batch file capabilities. This despite the video I posted showing it processing a short batch file in both .TXT and DV80 format. In that demo, the file only contained 3 lines, but it takes little imagination to see that a much longer batch file should be possible.

I believe the number of people who actually use this capability can be counted on the fingers of one fist. However, if you try this out and find that it comes up short, please post an example showing the problem. (Remember that you cannot LIST in a batch file, but there is no reason to do that.)

Edited July 9 by senior_falcon

[+RXB]

5 hours ago, senior_falcon said:

Here is XB2.9 G.E.M. version 20230707

The problems mentioned in my previous post have been corrected. Now the 40 or 80 column editor, CALL HELP and CALL SAVEIV work properly when using The Missing Link.

 

XB29GEM230707.zip 2.21 MB · 6 downloads

 

There has been further speculation regarding supposed shortcomings in XB2.9 G.E.M.'s batch file capabilities. This despite the video I posted showing it processing a short batch file in both .TXT and DV80 format. In that demo, the file only contained 3 lines, but it takes little imagination to see that a much longer batch file should be possible.

I believe the number of people who actually use this capability can be counted on the fingers of one fist. However, if you try this out and find that it comes up short, please post an example showing the problem. (Remember that you cannot LIST in a batch file, but there is no reason to do that.)

Hmmm RXB can use CALL USER to load and list files even multiple times to multiple drives or hard drives.

I even showed this in the previous Youtube demo.

[SteveB]

16 hours ago, senior_falcon said:

Here is XB2.9 G.E.M. version 20230707

The problems mentioned in my previous post have been corrected. Now the 40 or 80 column editor, CALL HELP and CALL SAVEIV work properly when using The Missing Link.

 

XB29GEM230707.zip 2.21 MB · 9 downloads

 

There has been further speculation regarding supposed shortcomings in XB2.9 G.E.M.'s batch file capabilities. This despite the video I posted showing it processing a short batch file in both .TXT and DV80 format. In that demo, the file only contained 3 lines, but it takes little imagination to see that a much longer batch file should be possible.

I believe the number of people who actually use this capability can be counted on the fingers of one fist. However, if you try this out and find that it comes up short, please post an example showing the problem. (Remember that you cannot LIST in a batch file, but there is no reason to do that.)

I had problems with the memory-settings when updating my Classic99-config, but this works now:

 

[usercart0] 
name=XB 2.9 G.E.M latest
rom0=G|6000|A000|Contributors\Harry_Wilhelm\XB29GEM230707\XB29GEM_G.BIN
rom1=8|0000|80000|Contributors\Harry_Wilhelm\XB29GEM230707\XB29GEM_8.BIN

 

I read the value from the log after drag&drop was working (and I was too lazy to update the config and did not use option 4 or up for a while)

[fabrice montupet]

Thank you Harry,

Could you distribute the disk based version of XB256/Compiler?

[senior_falcon]

3 hours ago, fabrice montupet said:

Thank you Harry,

Could you distribute the disk based version of XB256/Compiler?

This will be ready soon I was working on it when this problem arose.

 

5 hours ago, SteveB said:

I had problems with the memory-settings when updating my Classic99-config, but this works now:I read the value from the log after drag&drop was working (and I was too lazy to update the config and did not use option 4 or up for a while)

Steve is right. I forgot to update the !README file so you can include the extra bank of memory used by the multicolor routines. I will repost XB 2.9 G.E.M. with the updated !README file.

Here is how it should be set up:

[usercart1]
name=XB 2.9 G.E.M
rom0=G|6000|A000|CARTS\XB29GEM_G.BIN
rom1=8|0000|26000|CARTS\XB29GEM_8.BIN       (the readme file shows that as 24000)

[senior_falcon]

Still polishing up the game developer's package.

I have been putting together a short tutorial showing how to make a combination cartridge. In the process I found a problem with the compiler, maybe caused by using an older version.

Anyway, here is the cartridge that the tutorial will create.

It is called COLIBRI for no good reason other than the title screen shows a hummingbird. That is the first bit mapped picture I could find.

You can use the space bar to go through the options, then press enter to select.

COLIBRI-8.BIN

[senior_falcon]

The tutorial for combining cartridges is coming along nicely. There is a short GIF below showing an alternate menu using polyspirals to create some visual interest. You probably wouldn't want to use this same method for making a menu, but the point is that the menu program is a PROGRAM, not just a static list of options. And so you can make it as elaborate as you desire, using sprites, graphics, sound and anything else that you would use in a program.

Edited July 18 by senior_falcon

[+OLD CS1]

1 hour ago, senior_falcon said:

You probably wouldn't want to use this same method for making a menu

Actually, that is a really cool intro menu.  Puts an interesting and cool active spin on the standard loader menu.

[senior_falcon]

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.