RXB - Rich Extended Basic

[+TheBF]

I am curious why the extra field is needed Rich.

Could it not be just three arguments repeated ?

 

CALL PEEK(8192,A,B,8198,C,D)

 

Maybe it would take more tokens to determine if there is more than one address than just adding a symbol to tell the interpreter there is a 2nd one.

 

[+Lee Stewart]

40 minutes ago, TheBF said:

I am curious why the extra field is needed Rich.

Could it not be just three arguments repeated ?

CALL PEEK(8192,A,B,8198,C,D)

Maybe it would take more tokens to determine if there is more than one address than just adding a symbol to tell the interpreter there is a 2nd one.

 

The problem is that the address can be a variable, in which case it would be impossible for the interpreter to decide whether it was a new address or one of the string of variables to receive data bytes.

 

...lee

[+InsaneMultitasker]

3 hours ago, RXB said:

So RXB 2023A has 

CALL PEEK(8192,A,B,&,8198,C,D)

One less token used and when reading it makes a little more logical sense to read.

How does this affect backward compatibility?   I was wondering if it is an option to check for two successive commas to create the same effect without causing 'trouble'.

[+OLD CS1]

28 minutes ago, InsaneMultitasker said:

How does this affect backward compatibility?   I was wondering if it is an option to check for two successive commas to create the same effect without causing 'trouble'.

Neither MM nor E/A like that syntax.  I figure if @RXB wants to be backward compatible with TI BASIC programs which use the MM or E/A syntax of CALL PEEK, the double-quote is the best, even if wasteful, way to go.

[RXB]

15 hours ago, InsaneMultitasker said:

How does this affect backward compatibility?   I was wondering if it is an option to check for two successive commas to create the same effect without causing 'trouble'.

Well try using "" in XB 110 and you will see it does not work.

So using & in 110 will not work either.

Using comma comma is viable way to go and would be even better.

I guess I could do that instead of the & instead.

 

Thanks that is a great idea and I should implement it instead as it is even faster and better.

[RXB]

15 hours ago, OLD CS1 said:

Neither MM nor E/A like that syntax.  I figure if @RXB wants to be backward compatible with TI BASIC programs which use the MM or E/A syntax of CALL PEEK, the double-quote is the best, even if wasteful, way to go.

Well EA and MM are not compatible with XB as many of the Equates are not the same and routine address are not the same or work the same.

So there never was any backward compatibility as can you find a EA or MM program using CALL PEEK that works the same?

But I could provide the option.

Anyway, I think InsaneMultitasker suggestion of comma comma is the very best idea to go with and I will include both "" and ,,

[+OLD CS1]

2 hours ago, RXB said:

So there never was any backward compatibility as can you find a EA or MM program using CALL PEEK that works the same?

NOTTOMH.  My only thought was your work to maintain backward compatibility with both TI BASIC and TI Extended BASIC.  The option is awesome: it gives the compatibility to MM and E/A programs in TI BASIC (excluding the LOADing of assembler programs due to the EQU differences,) and at the same time a new flavor which will be uniquely RXB.

[RXB]

On 5/26/2023 at 12:43 PM, OLD CS1 said:

NOTTOMH.  My only thought was your work to maintain backward compatibility with both TI BASIC and TI Extended BASIC.  The option is awesome: it gives the compatibility to MM and E/A programs in TI BASIC (excluding the LOADing of assembler programs due to the EQU differences,) and at the same time a new flavor which will be uniquely RXB.

Yea just finished RXB 2023A and now you can use CALL PEEK(8192,A,B,"",8198,C,D) just like MM or EA

But I added the InsaneMulititasker suggestion of CALL PEEK(8192,A,B,,8198,C,D) also to RXB.

 

Now RXB has CALL POKE but it does not work like XB CALL LOAD as the number section does not work same as CALL LOAD does.

I will take another look at it to see if it is feasible.

[+InsaneMultitasker]

4 hours ago, RXB said:

But I added the InsaneMulititasker suggestion of CALL PEEK(8192,A,B,,8198,C,D) also to RXB.

If this works as an alternative to "", I would be interested in knowing where you made the change(s) to see if they could also be applied to Advanced BASIC. If for no other reason than to see if it can be done though how soon I would try to implement it is another story altogether!  

 

[RXB]

I just added a small section of GPL code to check for "" or , and skip using XML PGMCHR in ROM to skip the "" or extra , and restart the call peek as normal.

 

[+InsaneMultitasker]

On 5/31/2023 at 12:30 AM, RXB said:

I just added a small section of GPL code to check for "" or , and skip using XML PGMCHR in ROM to skip the "" or extra , and restart the call peek as normal.

 

Nice. Thanks.  Advanced BASIC is all assembly so it is a little different parsing routine.  I found the code and what it does is it checks each entry.  If it finds a string, the length is tested.  If the string length is zero, the string is considered a separator and the next item is parsed. (It seems that a string variable might work as a separator here).  The routine for load/peek/poke has step to convert strings to integers, which suggests that CALL LOAD(8192,"A") would be valid for a single byte value.   I've never tried this.

[RXB]

3 hours ago, InsaneMultitasker said:

Nice. Thanks.  Advanced BASIC is all assembly so it is a little different parsing routine.  I found the code and what it does is it checks each entry.  If it finds a string, the length is tested.  If the string length is zero, the string is considered a separator and the next item is parsed. (It seems that a string variable might work as a separator here).  The routine for load/peek/poke has step to convert strings to integers, which suggests that CALL LOAD(8192,"A") would be valid for a single byte value.   I've never tried this.

I opted for CALL HEX that converts HEX strings to integers or Integers to HEX strings.

CALL HEX(8192,A$) ! A$="2000"

CALL HEX("2000",A) ! A=8192

But you can do a full list of them too: CALL HEX(8192,A$,8198,B$,A$,A,B$,B) thus A$ is also converted to A=8192 and B=8198

 

Looking for HEX or Decimal in all commands was to slow to implement.

[RXB]

Update to what I have been doing lately.

I have been disassembling into source code XB3 as it has a ton of faster math routines then XB normally has so this will be added to RXB.

XB3 by Winfred Winkler was sold by Asgard and in many ways was faster than normal XB due to more Assembly routines replaced GPL routines.

I do not plan on a copy but using some of the routines into RXB as XB3 had some issues with backwards compatibility.

Plans are to include Faster Math routines for things like SQR, ATN, EXP, INT, TAN, SIN, COS, LOG and others.

The method used for adding commands and tokens to the list of commands into XB that are faster using Assembly instead of GPL.

Lastly even more VDP routines will be written in Assembly instead of GPL.

Some commands in RXB are all are faster than any previous XB.

Like CALL HCHAR, VCHAR, CLEAR, HPUT, VPUT, HGET, VGET, HEX, RND are all written in Assembly not GPL.

 

Anyway here is the Source of XB3 I have so far and I need to comment out and do more but this is a great start.

XB3ROMs&GROMs.zip

[+InsaneMultitasker]

@RXB have you considered using the Geneve basic math routines for your endeavor? They are all written in assembly and fairly well commented. I believe that @Lee Stewart reviewed some of the math code a few years ago.  Using commented source might be easier than trying to disassemble XB3's math routines. 

[RXB]

2 hours ago, InsaneMultitasker said:

@RXB have you considered using the Geneve basic math routines for your endeavor? They are all written in assembly and fairly well commented. I believe that @Lee Stewart reviewed some of the math code a few years ago.  Using commented source might be easier than trying to disassemble XB3's math routines. 

Yea Lee and I talked about it, but XB3 routines are faster and more accurate as he debugged many of the TI ways of doing Math.

I have mostly disassembled the XB3 cart now.

[+Lee Stewart]

23 hours ago, InsaneMultitasker said:

@RXB have you considered using the Geneve basic math routines for your endeavor? They are all written in assembly and fairly well commented. I believe that @Lee Stewart reviewed some of the math code a few years ago.  Using commented source might be easier than trying to disassemble XB3's math routines. 

 

Yeah—I ported the complete MDOS L10 FP (Floating Point) Math Library to TurboForth and fbForth. It, pretty much, duplicates the console ROM and GROM routines into all ALC (Assembly Language Code). The basic (not Basic language!) routines are slower because they are on the 8-bit bus, but the transcendental functions (trig, log, etc.) are faster because they are now all ALC with no GPL. In the near(?) future, I plan to modify my fbForth library to use the console ROM FP routines, which should make all FP words faster...but, I digress.

 

...lee

[RXB]

RXB 2023 UPDATE

New feature of CATALOG LOADER built into the title screen of RXB 2023

 

 

[MikeV]

21 hours ago, RXB said:

RXB 2023 UPDATE

New feature of CATALOG LOADER built into the title screen of RXB 2023

 

That will be quite useful!

[JasonACT]

This is a bit of an anomaly I've noticed in RXB...  I'm developing my own Pi Pico Peripheral Expansion Box in the format of a speech synthesizer board, and have just about finished the disk DSR ROM.  Now, since I don't use VDP memory, except where needed (user's PAB/buffers) I don't bother to run CALL FILES(3) (or 1, or whatever) in the reset vector.  I do make the basic and assembler versions available in the DSR, but only to avoid any incompatibility.

 

In TI Basic, TI Extended Basic and RXB, I can run "OLD DSK.CATALOG" (DSK is the special root access point on my FAT32 SD card, it can look up whole disks by name via the directories on the SD card).  When I run my catalog program however, RXB (but not the other 2) gives me an out of memory error on the DSK directory open.  If I CALL FILES(1) and reload it and try it again, it works.

 

Why is RXB doing something different to TI's Basics?

[+jedimatt42]

@JasonACT, we are dealing with really old software that never thought new hardware would ever come into existence. Rich Extended Basic won't be alone. We know that The Missing Link / TML, will also choke if the 'floppy disk controller' hasn't performed the equivalent of CALL FILES(3) during the powerup entry in the DSR ROM.

 

After much discussion previously, and then again when I came around with TIPI, the consensus was, even though your storage device doesn't need sector buffers in VDP, it is wise to let the default state reserve those buffers.

 

Here is the part in my TIPI powerup routine that handles this: https://github.com/jedimatt42/tipi/blob/51855d04633b834f278da938a0ec9a8da753a813/hardware/dsr/powerup.a99#L27  - you'll notice, I only do this if running at crubase 1100, as I'm responsible for being the floppy controller. This code isn't ideal either, as I don't read the current value, and then subtract what I want, instead I just slam 5 bytes int there. I no longer remember why... 

 

Why? : 

- If we don't do this, people may unwittingly produce disk software in XB using your device that is too large to load into someone's XB using a real Floppy Controller, unknowingly... 

- Old software made assumptions, and users will pester you about it if it doesn't work. 

- The BASICs have additional work area associated to each sector buffer, handled by the CALL FILES... 

 

But, 1st and foremost, it is your hobby time... There is always going to be something that isn't compatible, 'cause old assumptive software is out there. 

 

Note, this is just a suggestion that would likely work around the problem and others. Since RXB is actively developed, another solution might be for Rich to update RXB to initialize the VDP stack in a compatible way by default... 

[RXB]

On 6/30/2023 at 7:44 PM, JasonACT said:

This is a bit of an anomaly I've noticed in RXB...  I'm developing my own Pi Pico Peripheral Expansion Box in the format of a speech synthesizer board, and have just about finished the disk DSR ROM.  Now, since I don't use VDP memory, except where needed (user's PAB/buffers) I don't bother to run CALL FILES(3) (or 1, or whatever) in the reset vector.  I do make the basic and assembler versions available in the DSR, but only to avoid any incompatibility.

 

In TI Basic, TI Extended Basic and RXB, I can run "OLD DSK.CATALOG" (DSK is the special root access point on my FAT32 SD card, it can look up whole disks by name via the directories on the SD card).  When I run my catalog program however, RXB (but not the other 2) gives me an out of memory error on the DSK directory open.  If I CALL FILES(1) and reload it and try it again, it works.

 

Why is RXB doing something different to TI's Basics?

Why are you using a old TI Basic program when RXB has a built in catalog routine and you can do this:

 

CALL CAT("DSK.DISKNAME.") ! this will catalog a disk named "DISKNAME" and you pause the catalog with space bar

CALL CAT("DSK4.") ! this will catalog disk 4 and you pause the catalog with space bar

CALL CAT(4) ! this will catalog disk 4 and you pause the catalog with space bar

CALL CAT("DSK4.","DSK3.") ! this will catalog disk 4 then disk 3 (In RXB you could catalog over 20 disks using CALL CAT and commas.)

CALL CAT(4,3) ! this will catalog disk 4 then disk 3 (In RXB you could catalog over 20 disks using CALL CAT and commas.)

CALL CAT("DSKA.") ! this will catalog a RAMDISK A just like if it was any other disk drive

CALL CAT(A) ! this will catalog a RAMDISK A same as above 

 

The CALL CAT works in Edit mode or Program mode EXAMPLE:

10 D$="DSK.DISKNAME."

20 CALL CAT(D$) ! this will catalog disk named DISKNAME

or

10 D=3

20 CALL CAT(D) ! this will catalog disk 3 same as if you typed "DSK3."

 

RXB has a almost AI version of a Cataloger.

[JasonACT]

32 minutes ago, RXB said:

Why are you using a old TI Basic program

Because it's old, like the computer I'm running it on, and me.

[RXB]

8 hours ago, JasonACT said:

Because it's old, like the computer I'm running it on, and me.

Well I am 69 myself so being old is not my reason for making a great Catalog routine on an old computer.

My father had a old John Deere Tractor that had a hand cranked engine that after started had a control arm that started the Tractor main engine.

That kind of thinking thankfully died out on how to do things.

Just because it is old does not mean we have to never change it.

 

Anyway take advantage of my CALL CAT as it figures out what you want to do.

D$="DSK1." :: D=1 :: CALL CAT(D$,D,49) ! Yea it knows 49 is the charcter number for drive 1 so all these ways catalog drive 1

[RXB]

New RXB routine to show you the address of any variable:

 

CALL FINDADDRESS(string-variable,return-variable-address)

or

CALL FINDADDRESS(variable,return-variable-address)

 

Both put the addres in the return-vaiable-address EXAMPLE:

CALL FINDADDRESS(X$,Y) ! will put the actual string address into Y

CALL FINDADDRESS(X,Y) ! will put the numeric variable address into Y

 

Using RXB CALL MOVES with FINDADDRESS for a string address would allow you to make strings of any length.

 

 

[RXB]

Question for Assembly this is the code in XB ROM:

1657 6AC2 0203  LTST90 LI   R3,FAC            Store result in FAC   
       6AC4 834A  
  1658 6AC6 CCC4         MOV  R4,*R3+           Exp & 1st byte of manitissa   
  1659 6AC8 04F3         CLR  *R3+              ZERO the remaining digits  
  1660 6ACA 04F3         CLR  *R3+              ZERO the remaining digits   
  1661 6ACC 04F3         CLR  *R3+              ZERO the remaining digits   
  1662 6ACE 1039         JMP  LEDEND            Jump to end of LED routine  

What do you think of  this change:

3

1657 6AC2 0203  LTST90 LI   R3,FAC            Store result in FAC   
       6AC4 834A  
  1658 6AC6 CCC4         MOV  R4,*R3+           Exp & 1st byte of manitissa   
  1659 6AC8 04F3         CLR  *R3               ZERO the remaining digits  (Would be >0000 at *R3)
  1660 6ACA              MPY  *R3,*R3+          (Would muliply the value >0000 by >0000 in next 4 bytes
  2661 6ACC 04F3         CLR  *R3+              ZERO the remaining digits
  1662 6ACE 1039         JMP  LEDEND            Jump to end of LED routine  
 
* Would save 2 bytes as every byte saved is usefull.

Sorry can not edit the stupid inserted code anymore for some goofy reason on AtariAge.

Line 2661 should not be there at all and line 1662 should be 1661 and that would save 2 bytes.