RXB - Rich Extended Basic

[Gazoo]

I'm the Guy that dies in the tube and gets flushed in scene one :-)

 

[+InsaneMultitasker]

 

RXB runs LOAD that is smaller and takes less space and a pathname can be 255 characters long. (and yes I have used BOOT mostly with my Supercart)

 

 

Quick FYI - there is a <device.path.filename> length limitation of 40 (39?) characters imposed by the HFDC DSR. I do not recall for certain whether or not the current SCSI and IDE DSRs adhere to this same length restriction, though practically speaking they should. Knowing Fred, the HDX device probably allows longer pathnames.

[Gary from OPA]

Take off for day or two, and come back to pages of 'drama'.

 

BOOT is outdated and very buggy, I agree with RXB about the XB Loader it is not good.

 

One of reasons I wrote RAMOS long time again to replace BOOT, but its XB Loader still not better, but after seeing this drama, I have some ideas to fix it now.

 

I like the fact RXB is working on replacement for loading, and stuff, can't wait to see final product.

 

The only part I took offense to was GPL programmer statement, I understand and program in GPL also, and did the SOB (ti99 OS) update without breaking anything and improving things.

 

All tho I have coded any GPL in a few years, it still fresh in my mind, and I got GPL programmers guide on my desk next to my PC.

[Gazoo]

Take off for day or two, and come back to pages of 'drama'.

 

BOOT is outdated and very buggy, I agree with RXB about the XB Loader it is not good.

 

One of reasons I wrote RAMOS long time again to replace BOOT, but its XB Loader still not better, but after seeing this drama, I have some ideas to fix it now.

 

I like the fact RXB is working on replacement for loading, and stuff, can't wait to see final product.

 

The only part I took offense to was GPL programmer statement, I understand and program in GPL also, and did the SOB (ti99 OS) update without breaking anything and improving things.

 

All tho I have coded any GPL in a few years, it still fresh in my mind, and I got GPL programmers guide on my desk next to my PC.

 

Any chance of adjusting the SOB code to get it to work with the HSGPL, Gary? Dan Eicher asked me to check this out some years ago, but I couldn't do much as there was no emulator at the time. It locked up the card, and I had to take out one of the flash chips and reprogram it for every change. Understandably it got a little frustrating and I gave up.

 

Gazoo

[RXB]

 

Quick FYI - there is a <device.path.filename> length limitation of 40 (39?) characters imposed by the HFDC DSR. I do not recall for certain whether or not the current SCSI and IDE DSRs adhere to this same length restriction, though practically speaking they should. Knowing Fred, the HDX device probably allows longer pathnames.

Do not know about others but I tested 255 character paths on my SCSI card. By making max 10 character volume names.

 

Yes I know that the HFDC has a 39 Character limit.

Edited July 10, 2014 by RXB

[RXB]

Rich,

Been meaning to ask this for a while and keep forgetting. Did you ever create the latest version of RXB for PC99. If not, any idea what the procedure, if possible, to convert the current files to PC99 .grm files.

The ez way is use the GPL Assembler and GPL*Loader from Ryte Data with my RXB Source code.

The ROMs for RXB are the same ones as GK XB just change

<0518>               * GK XB ROMs are same for RXB
<0519>               * Code for new commands DEL, COPY, and MOVE
<0520>               *
<0521>               * NOTICE !!!!!
<0522>               * RAM BANK 2 CHANGED AS FOLLOWS-----
<0523>               * 7D1B changed from >08 to >0B
<0524>               * 7D35 changed from >08 to >0C
<0525>               *
<0526>               

I even made a video on how to build RXB from scratch.

 

[+hloberg]

The ez way is use the GPL Assembler and GPL*Loader from Ryte Data with my RXB Source code.

The ROMs for RXB are the same ones as GK XB just change

<0518>               * GK XB ROMs are same for RXB
<0519>               * Code for new commands DEL, COPY, and MOVE
<0520>               *
<0521>               * NOTICE !!!!!
<0522>               * RAM BANK 2 CHANGED AS FOLLOWS-----
<0523>               * 7D1B changed from >08 to >0B
<0524>               * 7D35 changed from >08 to >0C
<0525>               *
<0526>               

I even made a video on how to build RXB from scratch.

 

thanks! will get on it.

[Gazoo]

Ksarul had a wonderful idea when he suggested having a menu option to choose RXB with or without a menu.

 

It's not as if there isn't plenty of room to do something like this, and I liked his idea, so I ran with it. Thanks Ksarul!

 

This should keep everyone happy, those that want the menu and those that don't. The best of both worlds!

 

Attached are the files for testing this in Classic99, let me know if there's anything that doesn't work.

This version, in my opinion, is definitely "Cart worthy". Once it's found to work ok, I can easily create the ubergrom cart files for it. Let me know!

 

Gazoo

 

 

 

RXB 2012 Updated.zip

 

[atrax27407]

I have been using the HRD MENU program with RXB and it works fine for loading XB programs.

[+hloberg]

Ksarul had a wonderful idea when he suggested having a menu option to choose RXB with or without a menu.

 

It's not as if there isn't plenty of room to do something like this, and I liked his idea, so I ran with it. Thanks Ksarul!

 

This should keep everyone happy, those that want the menu and those that don't. The best of both worlds!

 

Gazoo

 

 

Dude, a thing of absolute beauty. You just moved RXB from my 2nd favorite XB to #1. Now all I have to do is figure out how to convert it to PC99 via Rich's instructions a few post up.

[RXB]

As I have said many times now I am working on a compromise for the menu in RXB 2014

 

Also will change some things in XB that will make XB a little faster.

The change will be the minimum size for a program vs a Internal Variable 254 file size will change.

In normal XB the file size is determined by available VDP memory to load the entire program say about 12K, but the new limit will be 2K in size.

 

XB programs that run from RAM are faster then programs that run from VDP so this is not hard to figure out why.

People asked me why large XB programs run faster then small XB programs.

 

Internal Variable 254 programs move to upper RAM to run instead of running entirely from VDP.

The VDP is only used for Constant values, Variables (String & Numeric) and File Buffer space.

The Line Number Table and Programs will run from the upper RAM.

 

 

 

98% of XB programs are larger then 2K so this should not be a problem unless you are saving BASIC programs from RXB to be run from BASIC.

Normal XB can not run many BASIC programs but RXB will still be able to run any BASIC program unless it requires EA Support routines.

[Gazoo]

Dude, a thing of absolute beauty. You just moved RXB from my 2nd favorite XB to #1. Now all I have to do is figure out how to convert it to PC99 via Rich's instructions a few post up.

 

Thanks, I sort of like it too. Does PC99 support multiple cartridges loaded at once? I used a trick here to suppress Review Module Library by putting the same Groms on the first two pages and the different Groms on the third page. A real cartridge won't need to do that since the first two pages can be mapped to the same memory area, thereby saving 40k of Grom space. I think all you have to do to make it PC99 format is split up the Grom files into separate Groms and name them properly, easily done with a Hex editor. Do you know the format of the PC99 module files? I haven't used PC99 for about 20 years, so I don't remember offhand.

 

Gazoo

[+Ksarul]

Rich, I do have a question here: what will this change do to the cassette loading routine? There are still folks out there in cassette-only mode, as I have recently run into a few of them. As the BASIC program saced to cassette will LOAD from cassette in Program Image format to VDP, will your new limit cause that functionality to break (assuming the program is small enough to fit into the remaining VDP memory (there are a few cassette programs out there that won't run on a system with a Disk Controller, even with a CALL FILES(1)?

 

Many thanks for the things you do--this was just the first thought that hit my mind when I saw what you were trying to change, so I hope the question is useful.

[+InsaneMultitasker]

As I have said many times now I am working on a compromise for the menu in RXB 2014

 

Also will change some things in XB that will make XB a little faster.

The change will be the minimum size for a program vs a Internal Variable 254 file size will change.

In normal XB the file size is determined by available VDP memory to load the entire program say about 12K, but the new limit will be 2K in size.

 

XB programs that run from RAM are faster then programs that run from VDP so this is not hard to figure out why.

People asked me why large XB programs run faster then small XB programs.

 

Internal Variable 254 programs move to upper RAM to run instead of running entirely from VDP.

The VDP is only used for Constant values, Variables (String & Numeric) and File Buffer space.

The Line Number Table and Programs will run from the upper RAM.

 

 

 

98% of XB programs are larger then 2K so this should not be a problem unless you are saving BASIC programs from RXB to be run from BASIC.

Normal XB can not run many BASIC programs but RXB will still be able to run any BASIC program unless it requires EA Support routines.

Rich,

In your speed test, what happens if you rerun the program via "RUN" instead of re-loading it from disk? It seems to me your timing is measuring both the load time AND the execution time. You need to separate the two for an accurate representation of the execution time

[RXB]

Rich, I do have a question here: what will this change do to the cassette loading routine? There are still folks out there in cassette-only mode, as I have recently run into a few of them. As the BASIC program saced to cassette will LOAD from cassette in Program Image format to VDP, will your new limit cause that functionality to break (assuming the program is small enough to fit into the remaining VDP memory (there are a few cassette programs out there that won't run on a system with a Disk Controller, even with a CALL FILES(1)?

 

Many thanks for the things you do--this was just the first thought that hit my mind when I saw what you were trying to change, so I hope the question is useful.

It most likely would save in IV 254 onto Cassette as XB does not check what kind of device it saves to or loads from, it does not care what type.

 

But as XB or RXB will load IV 254 that should not matter unless you use characters sets 14 and 15 then that would crash normal XB but not RXB.

 

As for this problem with removal of the Disk Controller try this:

Load into RXB 2014 with CALL FILES(1) from Cassette, then save to Cassette and it will save as IV 254 so after that you reconnect you Disk Controller and run these programs from Cassette.

Tadaa you now have Cassette programs that run from RAM instead of VDP only and can be any size you want.

 

This solves two problems for you, using the Disk Controller and now programs can be larger and faster.

[RXB]

Rich,

In your speed test, what happens if you rerun the program via "RUN" instead of re-loading it from disk? It seems to me your timing is measuring both the load time AND the execution time. You need to separate the two for an accurate representation of the execution time

I used a RUN "DSK1.LOAD" as I wanted the timing to be exactly the same for both tests.

 

Using "RUN" instead would beep twice way to fast to count and screw up the timing count.

 

The video only showed 1 minute difference. If you run the test for 10 minutes the difference is much more dramatic as time goes on.

 

I could have used other methods like a variable, but the problem is variables are in VDP so are counter to the test also a VDP screen flash would be counter to the test.

Edited July 11, 2014 by RXB

[+InsaneMultitasker]

I used a RUN "DSK1.LOAD" as I wanted the timing to be exactly the same for both tests.

 

Using "RUN" instead would beep twice way to fast to count and screw up the timing count.

 

The video only showed 1 minute difference. If you run the test for 10 minutes the difference is much more dramatic as time goes on.

 

I could have used other methods like a variable, but the problem is variables are in VDP so are counter to the test also a VDP screen flash would be counter to the test.

Understood.

 

In my BBS program, I use the lowest address in high memory to store variables to pass between programs. I use one of the variables to indicate which file I want to load, which means with 20+ programs I only need to edit one program to change all the RUN pathnames. (I'll probably change this even further to use Jacques run example). Anyway... I think you could count total iterations something like this:

 

Step 1: Clear the counter from the command line. We'll use -24576 (>A000) as our variable:

CALL INIT !needed for XB

CALL LOAD(-24576,0) !set the variable to 0

 

Step 2:

In place of your RUN command, we'll read the variable from memory, add 1, and then store it back into memory.

We'll then test for 20 iterations and make a sound when we reach the limit:

 

100 CALL PEEK(-24576,A)::A=A+1::CALL LOAD(-24576,A)

110 IF A=20 then CALL SOUND(1000,600,0)::END ELSE RUN

 

I think Classic99 has a clock feature which could be incorporated into this somehow, maybe printing the time if A=0 and when A=20.

 

Might save you some steps for this and other timing, especially when the beeps are hard to count.

[+Ksarul]

Actually, I'm looking at this from the standpoint of existing cassettes, Rich. They are already 12K-13K files, saved as PROGRAM format files. What effect will your change have on LOADing these files initially? I pretty much figured that files saved with RXB would not be a problem. I'm looking at the hundreds of programs already on cassette--and whether it breaks compatibility with those existing files, as the PROGRAM files are larger than the PROGRAM buffer you have set up here.

[RXB]

Understood.

 

In my BBS program, I use the lowest address in high memory to store variables to pass between programs. I use one of the variables to indicate which file I want to load, which means with 20+ programs I only need to edit one program to change all the RUN pathnames. (I'll probably change this even further to use Jacques run example). Anyway... I think you could count total iterations something like this:

 

Step 1: Clear the counter from the command line. We'll use -24576 (>A000) as our variable:

CALL INIT !needed for XB

CALL LOAD(-24576,0) !set the variable to 0

 

Step 2:

In place of your RUN command, we'll read the variable from memory, add 1, and then store it back into memory.

We'll then test for 20 iterations and make a sound when we reach the limit:

 

100 CALL PEEK(-24576,A)::A=A+1::CALL LOAD(-24576,A)

110 IF A=20 then CALL SOUND(1000,600,0)::END ELSE RUN

 

I think Classic99 has a clock feature which could be incorporated into this somehow, maybe printing the time if A=0 and when A=20.

 

Might save you some steps for this and other timing, especially when the beeps are hard to count.

Any commands with a Variable like A or Z or whatever uses VDP memory and that was not what I wanted to test.

 

The problem is we need a program large enough to know it is loaded into RAM and not VDP to test.

 

But how we count can not use variables. Why I used a CALL SOUND(10,110,0) as it contains no variables at all and will execute only from RAM in upper 24K.

 

Kind of a unique problem, so I used the RUN "DSK1.LOAD" as a test from XB as this was to prove that RXB or XB are the same mostly.

[RXB]

Actually, I'm looking at this from the standpoint of existing cassettes, Rich. They are already 12K-13K files, saved as PROGRAM format files. What effect will your change have on LOADing these files initially? I pretty much figured that files saved with RXB would not be a problem. I'm looking at the hundreds of programs already on cassette--and whether it breaks compatibility with those existing files, as the PROGRAM files are larger than the PROGRAM buffer you have set up here.

This will not affect any current cassettes you use, unless you save with RXB then if they are larger then 2K they would be Internal Variable 254 instead of Program Image files.

By the way XB or RXB would still load them in either format, just RXB will save them differently then XB. No effect on loading just saving, cool huh?

XB and RXB both look to see if the program size is to large for VDP so switches to IV 254 format.

When XB or RXB opens a file it looks for the type of Program Image or IV 254 and loads the proper one even if it is smaller then normal.

The file type loaded is controlled by the header saved on Disk or Cassette. The Saved version is a default that TI set up to be like BASIC and IV 254 was for XB.

 

The problem is all smaller problems look exactly like BASIC even though they will not run in BASIC as they are XB programs.

This RXB change fixes that confusion that was overlooked by TI and that way unless the program is under 2K it has to be a XB program as it is IV 254 only.

As this fix does not affect XB or RXB or SXB or others in any way for loading it might be possible to make any XB program saved a IV 254, still have to take a closer look.

[+InsaneMultitasker]

Any commands with a Variable like A or Z or whatever uses VDP memory and that was not what I wanted to test.

 

The problem is we need a program large enough to know it is loaded into RAM and not VDP to test.

 

But how we count can not use variables. Why I used a CALL SOUND(10,110,0) as it contains no variables at all and will execute only from RAM in upper 24K.

 

Kind of a unique problem, so I used the RUN "DSK1.LOAD" as a test from XB as this was to prove that RXB or XB are the same mostly.

Yea, I just considered the variable being negligible compared to the overall run time that is being tested.

 

Which reminds me .. so when you load this two different ways, what do the STACK and PROGRAM free counters look like? Are those different too?

[RXB]

Yea, I just considered the variable being negligible compared to the overall run time that is being tested.

 

Which reminds me .. so when you load this two different ways, what do the STACK and PROGRAM free counters look like? Are those different too?

Here is the XB source comments that describe SAVE:

***********************************************************
<0231>               *                    SAVE STATEMENT
<0232>               * SAVE "NAME", MERGE : Save in crunched form in program
<0233>               *  into a file one line at at time with the line number.
<0234>               *  File opened with sequential accessed, variable-length
<0235>               *  records (161 max), display type & output mode, move one
<0236>               *  line number and one in text to the crunch buffer then
<0237>               *  write to the file one line at a time.
<0238>               * A normal SAVE : When ERAM not exist or the size of the
<0239>               *  program and line number table in ERAM can fit in VDP
<0240>               *  (can be moved into VDP from ERAM once), then the save
<0241>               *  statement saves a program image to an external device,
<0242>               *  including all the information the system needs for
<0243>               *  rebuilding the program image on a machine with a
<0244>               *  different memory size, also included is a checksum for
<0245>               *  rudimentary error checking and for PROTECTION VIOLATION
<0246>               * A sequential SAVE : Maximum-length records are performed
<0247>               *  to write the file and each record is copied into the VDP
<0248>               *  from ERAM before it is written.
<0249>               ***********************************************************
<0250> 8DB8 DA,45,80 SAVE   CLOG >80,@FLAG         * PROTECTION VIOLATION

Here is the alternate comments that saves IV 254 named GSAVE:

***********************************************************
<0352>               * Open the sequential file, set the PAB
<0353>               * File type             : sequential file
<0354>               * Mode of operation     : output
<0355>               * Data type             : internal
<0356>               * Record type           : variable length records
<0357>               * Logical record length : 254 maximum
0358> 8EB7 31,00,09 GSAVE  MOVE 9,G@PAB3,V@4(@PABPTR) Build the PAB

Farther down in GSAVE are these XB comments:

<0306>               * Check is there enough memory in VDP to move the program
<0307>               *  text and line number table from ERAM to VDP
<0308> 8E56 0A              GT                  Not enough memory in VDP for sur
<0309> 8E57 4E,B7           BR   GSAVE
<0310> 8E59 BF,10,0A        DST  VRAMVS+64+256,@VAR5 * 64 bytes are for safety b
       8E5C 98
<0311>                
<0312>               * DSR routine give file error when loading a program which
<0313>               *  VDP maximum size and was saved from VDP to be a program
<0314>               *  on disk when ERAM not exist. In order to fix this proble
<0315>               *  restrict the program memory to be 256 bytes less then th

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0040 
FLMGR-359
<0316>               *  real space in VDP when ERAM not exist.
<0317> 8E5D C9,00,10        DCHE @VAR5,@VAR0       Not enough memory in VDP in
<0318>               *                              sequential file save
<0319> 8E60 4E,B7           BR   GSAVE
<0320> 8E62 A7,10,00        DSUB 10,@VAR5        * 10 bytes for control informat
       8E65 0A
<0321> 8E66 06,8F,4A        CALL GVMOV             Enough memory in VDP, move it

VDP Stack stays the same. The PROGRAM POINTERS switch from VDP to ERAM (that is what they call RAM) so Pointers and Line Numbers and the program are in RAM.

 

Can you imagine how fast XB would be if it all ran from RAM instead of Strings and Variables being in VDP?

 

This is why I set up the SAMS in RXB to leave 32K untouched as I was thinking of making a SAMS RXB like this?

[+InsaneMultitasker]

Here is the XB source comments that describe SAVE:

 

VDP Stack stays the same. The PROGRAM POINTERS switch from VDP to ERAM (that is what they call RAM) so Pointers and Line Numbers and the program are in RAM.

 

Can you imagine how fast XB would be if it all ran from RAM instead of Strings and Variables being in VDP?

 

This is why I set up the SAMS in RXB to leave 32K untouched as I was thinking of making a SAMS RXB like this?

 

I am not convinced that a program runs from VDP when 32K is available to XB.

 

The comments in the source code refer to moving the program and line number table into VDP during a save. This happens all at once (if the program is small enough) or on a record-by-record basis using IV254 file type (if the program is larger than a specific size). Either way, the program is being saved through the use of VDP, because the file IO uses buffers and PABs in VDP. These comments are not referring to program execution.

 

The reason I asked about program versus stack space in your example programs was to understand if those values change. When I have written programs in XB, the program FREE size always reflects the 32K RAM space with stack being stored in VDP. Where are you seeing smaller programs executing from VDP?

[RXB]

 

I am not convinced that a program runs from VDP when 32K is available to XB.

 

The comments in the source code refer to moving the program and line number table into VDP during a save. This happens all at once (if the program is small enough) or on a record-by-record basis using IV254 file type (if the program is larger than a specific size). Either way, the program is being saved through the use of VDP, because the file IO uses buffers and PABs in VDP. These comments are not referring to program execution.

 

The reason I asked about program versus stack space in your example programs was to understand if those values change. When I have written programs in XB, the program FREE size always reflects the 32K RAM space with stack being stored in VDP. Where are you seeing smaller programs executing from VDP?

Sorry only posted the SAVE and GSAVE data as I was attempting to cut down the size of that post:

***********************************************************
<0002>               *                     OLD STATEMENT

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0034 
FLMGR-359
<0003>               * A normal load:
<0004>               *   Get a program from an external device to VDP and
<0005>               *   reinitialize the program pointers. Also update the line
<0006>               *   pointer table, since the memory size of the machine on
<0007>               *   which the program was created doesn't have to be the
<0008>               *   same as on the current system!!!! Then check if ERAM
<0009>               *   existed, move it to ERAM if does exist (in relocated
<0010>               *   from)
<0011>               * Load a sequential file:
<0012>               *   When program is bigger than 13.5K and ERAM exists,
<0013>               *   maximum-length record reads are preformed to read the
<0014>               *   file and each record is copied into the ERAM as it is
<0015>               *   read.
<0016>               ***********************************************************

A little ways down in XB source is:

<0162>               * V@OLDTOP : old top of memory, set up above
<0163>               * @STADDR  : base of current program image in ERAM, set abo
<0164> 8D1F 06,8D,36        CALL RELOCA            Relocate the program
<0165> 8D22 4C,5A           BR   OLDZ7             Go to set the RAMFRE and back
<0166>               *                              toplevel

Father down is:

***********************************************************
<0174>               * RELOCATE THE PROGRAM IMAGE ACCORDING TO THE NEW TOP OF
<0175>               * MEMORY:
<0176>               *         STLN         : old STLN
<0177>               *         ENLN         : old ENLN
<0178>               *         V@OLDTOP     : old top of memory
<0179>               *         V@NEWTOP     : new top of memory
<0180>               *         @STADDR      : current base for the old image
<0181>               ***********************************************************
<0182> 8D36 BD,A3,B4 RELOCA DST  @PABPTR,V@SIZCCP  Save in temp.
       8D39 04

So how else would explain what happened with the same program in normal XB but the only change was Program Image vs IV 254?

 

(QUOTE: When program is bigger than 13.5K and ERAM exists, .... ) I think this says it all....

Edited July 12, 2014 by RXB

[+InsaneMultitasker]

So how else would explain what happened with the same program in normal XB but the only change was Program Image vs IV 254?

 

(QUOTE: When program is bigger than 13.5K and ERAM exists, .... ) I think this says it all....

 

My suspicion is that the difference is related to XB moving the program and line table around from VDP to ERAM during the load. The comments infer the program image must be manipulated whereas the IV254 is directly copied into ERAM. I think the following comments support this theory:

 

 

<0003> * A normal load:

<0004> * Get a program from an external device to VDP and

<0005> * reinitialize the program pointers. Also update the line

<0006> * pointer table, since the memory size of the machine on

<0007> * which the program was created doesn't have to be the

<0008> * same as on the current system!!!! Then check if ERAM

<0009> * existed, move it to ERAM if does exist (in relocated

<0010> * from)

 

So I think the loading speed changes because it is quicker without the extra manipulation. But I don't think the program is executing from VDP if 32K is available, the comments seem to support this. You could validate speed by timing program execution; however, if you time execution AND loading, that muddies the waters for the very reasons above.

 

(Also if I understand correctly, the IV254 program load operation requires 32K. So by saving programs smaller than 13K in this format, someone with XB and no 32K will be unable to load the program from standard XB. This is the only compatibility danger I see in saving all XB programs to IV254)