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 Friday at 12:32 PM by senior_falcon