RXB - Rich Extended Basic

[Gazoo]

 

it's your choice, of course, but it won't hurt the code and I would think it would be nice to have a single version of the binary out there?

 

Agreed. I'm not going to manufacture any RXB carts because I don't have to. Anyone can buy the stuff to make their own. The ROM Eprom code has been posted here, and boards with pre-programmed AVR boot code are available. You can load the RXB Grom files with GROMCFG if you want and you've got an RXB cart. It's everyone else that needs a version of RXB that selects Rom bank 1, not me. I'd just hack it for my needs if I wanted to.

 

Gazoo

[RXB]

RXB 2015 UPDATE 1

 

I have added the GPL code at GROM address >6AF4

 

>6AF4 DCLR @>6000

>6AF7 B TOPLEV

 

This allows the Gazoo cartridge to be used without modifications.

RXB2015 UPDATE 1.zip

Edited March 27, 2015 by RXB

[Gazoo]

RXB 2015 UPDATE 1

 

I have added the GPL code at GROM address >6AF4

 

>6AF4 DCLR @>6000

>6AF7 B TOPLEV

 

This allows the Gazoo cartridge to be used without modifications.

 

Stuff gets done when you poke the bear a little.

[+arcadeshopper]

LOL they are both GRAMKRACKER versions and both are the same code except for some slight additional code in RXB 2015,

 

other then that they are IDENTICAL. The ROMs are exactly the same and GROM 4 only had 25 bytes changed.

 

The RXB 2015 files are saved in GRAMKRACKER format. Gazoo may be able to help you if the problem is the HSGPL card.

 

You can also get RXB (any version) from the AtariAge:

 

http://atariage.com/forums/topic/153704-ti-994a-development-resources/

 

So is it normal for it to have a blank black screen when you start XB? Seems like it's prompting me for a disk number or something like the old version, but no screen..

 

Greg

[RXB]

 

So is it normal for it to have a blank black screen when you start XB? Seems like it's prompting me for a disk number or something like the old version, but no screen..

 

Greg

Yes as Gazoo and some others suggested it be more like normal XB is took out the menu screen.

(I kept most of the options but all are hidden now with no menu.)

 

Most of the options remained exactly the same: i.e. Key presses.

 

Any key still will select that drive to DSK#.LOAD so 0 to 9 or A to z run LOAD from that Disk.

COMMA key loads DSK1.BATCH (User DV80 Batch files)

PERIOD key switches to REA Cart

ENTER key switches to REA Cart and runs DSK1.UTIL1

0 (ZERO) key runs WDS1.LOAD

 

And finally SPACE BAR key will bypass the DSK1.LOAD going to Extended Basic Command mode.

[Gazoo]

Yes as Gazoo and some others suggested it be more like normal XB is took out the menu screen.

(I kept most of the options but all are hidden now with no menu.)

 

Most of the options remained exactly the same: i.e. Key presses.

 

Any key still will select that drive to DSK#.LOAD so 0 to 9 or A to z run LOAD from that Disk.

COMMA key loads DSK1.BATCH (User DV80 Batch files)

PERIOD key switches to REA Cart

ENTER key switches to REA Cart and runs DSK1.UTIL1

0 (ZERO) key runs WDS1.LOAD

 

And finally SPACE BAR key will bypass the DSK1.LOAD going to Extended Basic Command mode.

 

That isn't what I suggested. If you look at the modification I did to RXB 2012, you will see exactly what I suggested. On the RXB 2012 cartridge that you have in your possession you have the best of both worlds.

 

 

Pressing 2 from the TI title screen enters RXB exactly like any other Extended Basic, DSK1.LOAD is searched for and if found, it's loaded and run. If it is not found, you are put in command mode. The spacebar option is available to bypass the disk load. AND it makes RXB compatible with the BOOT and MENU programs.

Pressing 3 from the TI title screen enters RXB with the full menu available as you intended.

Pressing 4 from the TI title screen enters REA with the full menu available as you intended.

 

IMHO having the menu in RXB but not displaying it (or maybe it is displayed but foreground and background are both black) is a step backwards, as well as confusing.

 

Gazoo

Edited April 3, 2015 by Gazoo

[+arcadeshopper]

Yes as Gazoo and some others suggested it be more like normal XB is took out the menu screen.

(I kept most of the options but all are hidden now with no menu.)

 

Most of the options remained exactly the same: i.e. Key presses.

 

Any key still will select that drive to DSK#.LOAD so 0 to 9 or A to z run LOAD from that Disk.

COMMA key loads DSK1.BATCH (User DV80 Batch files)

PERIOD key switches to REA Cart

ENTER key switches to REA Cart and runs DSK1.UTIL1

0 (ZERO) key runs WDS1.LOAD

 

And finally SPACE BAR key will bypass the DSK1.LOAD going to Extended Basic Command mode.

 

my 2c. if you are going to give options have the menu.. if someone wants to load xb without the delay for the menu another entry point like the gazoo module is fine, me personally I don't care..but a blank screen made me feel like I did something wrong.

 

Greg

[RXB]

 

my 2c. if you are going to give options have the menu.. if someone wants to load xb without the delay for the menu another entry point like the gazoo module is fine, me personally I don't care..but a blank screen made me feel like I did something wrong.

 

Greg

Ok I can do like Gazoo wants but do you guys know why Boot and Menu refuse to work?

The RXB Menu routines are exactly the same, other then looking for a key press in RXB and which drops out of that loop if no key pressed and does exactly the same thing as normal XB. DSK1.LOAD

 

The problem seems to be Boot and Menu just uses a goofy GPL address to jump into the XB cart and that address does not make a lick of sense. To blame me for this stupidity is silly.

Edited April 3, 2015 by RXB

[+arcadeshopper]

Ok I can do like Gazoo wants but do you guys know why Boot and Menu refuse to work?

The RXB Menu routines are exactly the same, other then looking for a key press in RXB and which drops out of that loop if no key pressed and does exactly the same thing as normal XB. DSK1.LOAD

 

The problem seems to be Boot and Menu just uses a goofy GPL address to jump into the XB cart and that address does not make a lick of sense. To blame me for this stupidity is silly.

 

Nobody's blaming you for Menu Richard.. we are just making suggestions and observations.. I hope that we can burn RXB/REA to many ubergroms and get it out there.. I was just saying it seemed like I broke it when i burned an uber with it and i got a black screen when I knew RXB was waiting for a keystroke or timeout..

 

Greg

[Gazoo]

Ok I can do like Gazoo wants but do you guys know why Boot and Menu refuse to work?

The RXB Menu routines are exactly the same, other then looking for a key press in RXB and which drops out of that loop if no key pressed and does exactly the same thing as normal XB. DSK1.LOAD

 

The problem seems to be Boot and Menu just uses a goofy GPL address to jump into the XB cart and that address does not make a lick of sense. To blame me for this stupidity is silly.

 

Rich,

 

Does it really matter why BOOT and MENU don't play nice with your modified RXB startup routine? The fact is that you changed something in the XB powerup to break some existing software. To blame it on the authors of those pieces of software when they expected certain GPL code to be in a certain place isn't fair, is it?

 

That's why I took great care while designing my Grom0 replacement for the HSGPL card to not change any absolute GPL addresses that I knew other people relied on in their programs. The Grom0 that was shipped with the card did not honor those absolute addresses and did not function correctly with a lot of software. The same concept is true of XB.

 

There was a request from a number of users to have a version of RXB that didn't have the powerup menu, and it wasn't even for the BOOT/MENU reasons, it was for simplicity sake. Some people just don't want to start XB, have a menu show up, and have to make choices. They want it to behave normally, where it just looks for DSK1.LOAD and if it's not there go to the command prompt. The cart that I created and sent to you was to show you that you could satisfy both requirements, having a cart that started up in the normal XB fashion (#2) as well as being able to start with your custom menu (#3). Is there something wrong with that improvement that you are dead set against? As software authors, it should be our responsibility to respond to people's requests to make the software better, and to suit their needs. Your attitude has been 'My way or the highway', and I'm not sure how the new 'invisible menu' is supposed to be an improvement. I jumped in and created the additional 'No Menu' entry in the 2012 cart to try and fill a request to make the cart more user friendly, and there were positive responses to the modification. Hopefully it created a larger user base for the software, as there are some valuable CALLS added in your version of XB.

 

Here's hoping you understand this message, cheers!

 

Gazoo

Edited April 4, 2015 by Gazoo

[RXB]

I understand.

I like anyone that writes software hate the perpetuation of a bug to keep people happy.

 

If feels like a Medical Doctor that must do a Witch Doctor dance shaking a dead chicken over people's head before they can treated with real medicine.

 

I look forward to your new GROM 0. (I made one myself for the TIM Card but never released it as my Hard Drive failed.)

 

But thanks for the advice.

Edited April 4, 2015 by RXB

[+InsaneMultitasker]

Does the latest version of RXB have the FCTN-8 REDO feature?

[RXB]

Does the latest version of RXB have the FCTN-8 REDO feature?

The REDO buffer was used for CALL USER (the batch file process command) in RXB instead. Sorry no is the answer.

 

As explained in the Documentation the REDO Buffer is 157 bytes long UNCOMPRESSED TEXT but when enter is pressed it converts that text into COMPRESSED XB TOKENS and is placed into the Crunch buffer 163 bytes.

 

So TI made a huge mistake making the TEXT buffer (157 bytes) smaller than the TOKEN buffer (163 bytes). A problem made exponentially worse by compression.

This is why when you press REDO you only get part of the line instead of the entire line.

 

In order for the REDO buffer to work properly it would need to be over 968 bytes in size so the XB TOKENS could be converted to text.

Example:

PRINT INT(X) is 12 characters in TEXT BUFFER, but XB TOKENS would be 5 bytes >9C=PRINT and >CF,>B7,>37,>D7,>B6=INT(X) in CRUNCH BUFFER.

 

So the problem is 12 bytes you type in is turned into 5 bytes in the Crunch buffer. But the Crunch buffer is larger??????

Edited April 4, 2015 by RXB

[+InsaneMultitasker]

The REDO buffer was used for CALL USER (the batch file process command) in RXB instead. Sorry no is the answer.

 

As explained in the Documentation the REDO Buffer is 157 bytes long UNCOMPRESSED TEXT but when enter is pressed it converts that text into COMPRESSED XB TOKENS and is placed into the Crunch buffer 163 bytes.

 

So TI made a huge mistake making the TEXT buffer (157 bytes) smaller than the TOKEN buffer (163 bytes). A problem made exponentially worse by compression.

This is why when you press REDO you only get part of the line instead of the entire line.

 

In order for the REDO buffer to work properly it would need to be over 968 bytes in size so the XB TOKENS could be converted to text.

Example:

PRINT INT(X) is 12 characters in TEXT BUFFER, but XB TOKENS would be 5 bytes >9C=PRINT and >CF,>B7,>37,>D7,>B6=INT(X) in CRUNCH BUFFER.

 

So the problem is 12 bytes you type in is turned into 5 bytes in the Crunch buffer. But the Crunch buffer is larger??????

Can this buffer serve both purposes - REDO and batch processing?

 

I agree the limitation is somewhat confounding but for editing and programming in XB, the REDO function is almost a necessity (in my opinion).

[RXB]

Can this buffer serve both purposes - REDO and batch processing?

 

I agree the limitation is somewhat confounding but for editing and programming in XB, the REDO function is almost a necessity (in my opinion).

That is a interesting question, so I think the problem would be checking every single keypress if CALL USER has been engaged as I do have a FLAG set.

 

Will have to look at the code to see if it is possible, or that it might be more complicated than it sounds.

[RXB]

Problems fixed so far:

 

Added Menu and No Menu options.

Added the Gazoo Cart set ROM bank with GPL Command DCLR @>6000 on either menu option.

 

Currently working on:

Add IDE# as a option of RXB for devices.

Fix Sector for Hard Drive access, still does not work correctly.

Add REDO key to work and still have CALL USER batch file processor function. (Still a maybe as this is very very complicated.)

[+Ksarul]

Thanks for plugging away at these things, Rich. RXB is a great TI tool.

[+Schmitzi]

Thanks a lot for the IDE-option :)

[+Ksarul]

Hey Rich, I was reading through the TI Software spec today and saw an interesting note on GROM pages in the cartridge port. "Programs may branch between pages with the CALL subprogram feature described on page H-6 of the GPL Programmer's Guide."

 

Using that feature, you might actually be able to write a 15-GROM cartridge. . .that is all one GPL program. Of course, I may be totally off-base, but it is an interesting note, since it shows that the original console designers actually thought about how they were going to use multiple GROM bases in a cartridge.

[Gazoo]

Hey Rich, I was reading through the TI Software spec today and saw an interesting note on GROM pages in the cartridge port. "Programs may branch between pages with the CALL subprogram feature described on page H-6 of the GPL Programmer's Guide."

 

Using that feature, you might actually be able to write a 15-GROM cartridge. . .that is all one GPL program. Of course, I may be totally off-base, but it is an interesting note, since it shows that the original console designers actually thought about how they were going to use multiple GROM bases in a cartridge.

 

The XB v2.7 Suite cartridge actually does this.

 

Gazoo

[Omega-TI]

 

Using that feature, you might actually be able to write a 15-GROM cartridge. . .t

 

 

The XB v2.7 Suite cartridge actually does this.

 

 

So, a massive GUI OS is possible... TI Windows?

[atrax27407]

And exactgly where could one find the latest update?

[RXB]

And exactgly where could one find the latest update?

Latest update is not done yet. Working on making REDO key and CALL USER work at same time.

 

Much more complicated than I first thought.

 

The XB Software has to figure out if the Edit Buffer is being used for Edit mode or USER mode even though they use the same buffer area.

 

I had to figure out where to put flags that are unchanged by ANY SOFTWARE EVER when switching from Edit REDO key mode or USER Buffer used mode.

 

Also without affecting the PAB for USER that is in the REDO Key Edit Recall Buffer. There is no place else to put all this in XB.

[RXB]

Working on the REDO (RECALL LAST LINE) and retaining CALL USER("DSK#.BATCH") is proving to be a nightmare project.

 

Elimination of the RECALL Buffer was easy but restoring both means placing flags all over the place in GROM and checking to see if USER is running or not.

 

As I also removed EDIT functions to use the RECALL Buffer as having two places where the same line resided seemed obviously redundant.

 

This is why RXB 2015C has not been released yet. (C is the current version of update I am working on.)

Edited May 11, 2015 by RXB

[Opry99er]

Keep us posted, for sure! Id like to have a physical copy of RevC in my cart case.