Jump to content
IGNORED

RXB - Rich Extended Basic


Bones-69

Recommended Posts

 

Although I agree with the rest of your post, this statement is not necessarily true. You should always try to understand the reason behind a particular request, it's unlikely that an end-user can come up with the best solution for a given problem, so you understanding the reason behind the feature request could allow you to propose an even better/easier solution.

 

Although all of the above of course assumes that the developer is interested in listening to his/her users to begin with, so the point is probably moot in this discussion.

Thanks. Like I have said if anyone wants to make a version for themselves then go for it as the Source Code and tools are in the package for you to do so.

And like in the Documents I insist you show me what you did and do not distribute a broken copy or RXB as your own.

This seems more then reasonable and does not entail me making 5 versions then attempting to maintain all of them at same time.

Link to comment
Share on other sites

 

XB should also have an option to turn off the auto loader. Or is there a shortcut I'm not aware of?

I do not get why the menu is a issue?

 

The only thing RXB is different is it will not run the Boot or FW broken loaders to XB. It runs everyone else's XB loaders fine. RXB has a smaller and just as fast XB/EA/EA3 loader.

 

And pressing the space bar when the menu is up is not a big deal as you are sitting there already?

 

Why is pressing the spacebar a big deal? (not one single person has answered me on this question for 5 times now)

  • Like 1
Link to comment
Share on other sites

I do not get why the menu is a issue?

 

The only thing RXB is different is it will not run the Boot or FW broken loaders to XB. It runs everyone else's XB loaders fine. RXB has a smaller and just as fast XB/EA/EA3 loader.

 

And pressing the space bar when the menu is up is not a big deal as you are sitting there already?

 

Why is pressing the spacebar a big deal? (not one single person has answered me on this question for 5 times now)

 

Because people want to select XB and see a command prompt without all that rigamarole.

 

Ksarul suggested a wonderful idea with the menu choices, you get the best of both worlds and everyone is happy.

What's wrong with that? Although as TheMole suggested, you're not interested in listening to the users of your software.

If that's the case, just say so. I guess that's what you were doing by thanking him for pointing that out?

No one will ever suggest improvements to RXB again if those are your wishes.

 

But in my opinion it's not right to act that way. :(

Link to comment
Share on other sites

Well the problem is not RXB it is Boot and FW and some of these loaders do not use a standard address to access XB but instead exploit a XB bug that I would have to re install.

 

RXB does include the SOURCE CODE and you can make your own version pretty easy as the ALL THE TOOLS are in the package.

 

I type in programs with a Text Editor in TI Writer (FW) or Classic99 then use my RXB CALL USER to make programs instead. (Faster and I can see the more of the code in 40/80 columns)

 

Rich - I think it is the bug exploit you fixed that is the root of much incompatibility people are seeing. For me, it isn't so much the RXB menu as being able to properly use two of the more useful and widely-used programs - FW and BOOT. To me, this is sort of like our old bug discussion related to CALL INIT, except this change really impacts people's options, where INIT really just made things better.

 

The other challenging change (for me anyway) is FCTN-8 (REDO). All I can tell you now is FCTN-8 is necessary when I am programming and debugging XB, I can't see exiting XB. Maybe arrow keys and such could reduce my dependence on it. I guess there is only one way to know for sure, and that is to use RXB and more of its capabilities.

 

I do want to play with the CALL USER idea to enter a program...

Link to comment
Share on other sites

 

Because people want to select XB and see a command prompt without all that rigamarole.

 

Ksarul suggested a wonderful idea with the menu choices, you get the best of both worlds and everyone is happy.

What's wrong with that? Although as TheMole suggested, you're not interested in listening to the users of your software.

If that's the case, just say so. I guess that's what you were doing by thanking him for pointing that out?

No one will ever suggest improvements to RXB again if those are your wishes.

 

But in my opinion it's not right to act that way. :(

See the problem is the amount of code that would need to be changed to do both would just not fit.

That requests is virtually impossible to do.

There simply not enough room to do both.

RXB already skirts the max GPL space left and would cripple any new concepts or upgrades.

 

I am not being a dick or hard headed it is just not possible to do both in a single version.

 

I am working on a new RXB 2014 that would slightly appease you, but not 100% as I am not going to throw away years of work on a single whim.

Nor am I going to support multiple versions as I do not get paid for this besides who does that?

 

Then again as I have suggested multiple times. RE-WRITE YOUR OWN VERSION AS I PROVIDED ALL THE TOOLS.

  • Like 1
Link to comment
Share on other sites

 

Rich - I think it is the bug exploit you fixed that is the root of much incompatibility people are seeing. For me, it isn't so much the RXB menu as being able to properly use two of the more useful and widely-used programs - FW and BOOT. To me, this is sort of like our old bug discussion related to CALL INIT, except this change really impacts people's options, where INIT really just made things better.

 

The other challenging change (for me anyway) is FCTN-8 (REDO). All I can tell you now is FCTN-8 is necessary when I am programming and debugging XB, I can't see exiting XB. Maybe arrow keys and such could reduce my dependence on it. I guess there is only one way to know for sure, and that is to use RXB and more of its capabilities.

 

I do want to play with the CALL USER idea to enter a program...

If I put REDO back in then all CALL USER batch file processing is gone.

There is no where else to put that feature in XB.

And I dare anyone to come up with a place to put it and not interfere with interrupts or change the locations of XB graphics or features.

(And still be 100% compatible with normal XB)

 

Besides REDO buffer is a smaller buffer then the CRUNCH buffer where the program is stored.

(REDO buffer 152 bytes untokenised, CRUNCH buffer 163 bytes tokenised)

 

As I explain in the RXB Documents this is a major screw up by TI.

Edited by RXB
Link to comment
Share on other sites

I have to say this is frustrating like people telling you to put the dents back in the car!

 

Or I like that the engine smokes and makes so much noise. I like it broken and not right.

 

Then switch carts to normal XB, not like it is that much of a hassle is it?

 

Hell even I do that sometimes if I am running a broken piece of software.

Link to comment
Share on other sites

Hi Rich:

I've been playing a bit with RXB. One thing that I think could be better is to use a different lower case font. If all the characters are moved up one pixel then you can use descenders for y,g,p,q. Of course, a capital letter below a g will touch it, but to me that is preferable to having the lower case letters different heights as they are now. I have character definitions that I can send you if you are interested in trying them out. My other gripe is that I don't like the cursor at all and would like to see just the normal 5x7 block used in BASIC and XB. These changes would be trivial to make, but of course, RXB is your creation and you can do whatever you want with it.

Link to comment
Share on other sites

'Broken' is a subjective term. Perhaps used in a reverse fashion in this discussion.

 

One person in a community decides what's 'broken' for everyone else? Hmm... Food for thought...

 

I'm out, this problem ain't 'gonna get fixed.

 

I tried, guys. Thanks for the support. :)

Link to comment
Share on other sites

Hi Rich:

I've been playing a bit with RXB. One thing that I think could be better is to use a different lower case font. If all the characters are moved up one pixel then you can use descenders for y,g,p,q. Of course, a capital letter below a g will touch it, but to me that is preferable to having the lower case letters different heights as they are now. I have character definitions that I can send you if you are interested in trying them out. My other gripe is that I don't like the cursor at all and would like to see just the normal 5x7 block used in BASIC and XB. These changes would be trivial to make, but of course, RXB is your creation and you can do whatever you want with it.

Thanks any fonts you think would be best?

 

The fonts I use are the GKXB ones used in the original Miller Graphics GK XB.

 

Pretty hard to pick a set of fonts that pleases everyone.

Link to comment
Share on other sites

'Broken' is a subjective term. Perhaps used in a reverse fashion in this discussion.

 

One person in a community decides what's 'broken' for everyone else? Hmm... Food for thought...

 

I'm out, this problem ain't 'gonna get fixed.

 

I tried, guys. Thanks for the support. :)

Fixed is what I did.

Something does not work right you fix it.

I am not one that spits in the back of the TV then kicks it to get it to stop rolling.

Maybe bad habits are hard to break.

Like I said A. Use the tools to make what you want. B. Use something else as I am not forcing you to use RXB am I?

Link to comment
Share on other sites

If I put REDO back in then all CALL USER batch file processing is gone.

There is no where else to put that feature in XB.

And I dare anyone to come up with a place to put it and not interfere with interrupts or change the locations of XB graphics or features.

(And still be 100% compatible with normal XB)

 

Besides REDO buffer is a smaller buffer then the CRUNCH buffer where the program is stored.

(REDO buffer 152 bytes untokenised, CRUNCH buffer 163 bytes tokenised)

 

As I explain in the RXB Documents this is a major screw up by TI.

Understood. Remember REDO is not my primary concern and I am going to look at your suggestions to import using CALL USER.

 

The impasse seems to be the "bug" you fixed was relied upon by some programs. it is just semantics calling it broken, since I could say that TI created it, TI was right, and you should never have changed it. But we all know that approach is just as unreasonable.

 

Overall this is your program and you need to be the one enjoying and programming it. However, if you want more people to use your work, reintroducing a "bug" that was in use long before RXB came out seems to me a good compromise. I don't recall if you said this wasn't possible or if you are just set against it.

Link to comment
Share on other sites

Understood. Remember REDO is not my primary concern and I am going to look at your suggestions to import using CALL USER.

 

The impasse seems to be the "bug" you fixed was relied upon by some programs. it is just semantics calling it broken, since I could say that TI created it, TI was right, and you should never have changed it. But we all know that approach is just as unreasonable.

 

Overall this is your program and you need to be the one enjoying and programming it. However, if you want more people to use your work, reintroducing a "bug" that was in use long before RXB came out seems to me a good compromise. I don't recall if you said this wasn't possible or if you are just set against it.

The bug only is in a couple of badly written loaders. Many other XB loaders do not have this issue.

 

FW and BOOT for example went from a well written XB loader to a badly written one. And when I notified Tony McGovern about this he said "Just use the older version that works."

So why do I need to "FIX RXB" when I did not create the issue or do the wrong thing. Just find the old FW or BOOT loaders from the older version and fix the problem.

 

Why do I have to fix a problem someone else created by doing the wrong thing? It is not my fault they screwed up! They did not debug the Loaders by checking if it was a bugged version.

 

Here is a copy of my DSK1 that runs Funnelweb and works fine in RXB as this is the old loader for FW. Just to prove a point that RXB is not the problem.

DSK1.zip

Edited by RXB
Link to comment
Share on other sites

The bug only is in a couple of badly written loaders. Many other XB loaders do not have this issue.

 

FW and BOOT for example went from a well written XB loader to a badly written one. And when I notified Tony McGovern about this he said "Just use the older version that works."

So why do I need to "FIX RXB" when I did not create the issue or do the wrong thing. Just find the old FW or BOOT loaders from the older version and fix the problem.

 

Why do I have to fix a problem someone else created by doing the wrong thing? It is not my fault they screwed up! They did not debug the Loaders by checking if it was a bugged version.

 

Here is a copy of my DSK1 that runs Funnelweb and works fine in RXB as this is the old loader for FW. Just to prove a point that RXB is not the problem.On

 

Time out.

 

The loaders worked until you made a change in RXB. The loaders work in other XB versions. You state BOOT and FW and others 'screwed up'. Is there another TI release of XB with your 'fix' that we don't know about? Are we barking up a wrong tree?

 

If not, then I say: "you created the problem by changing XB and by your own words, shouldn't you fix a problem that you created, not the other way around?"

 

How about an analogy. If RXB was a gas station, it would be like changing all the pump nozzles to a larger diameter. Then you tell everyone that to fill their car with gasoline, they need to first fill up a portable gas can then load the gas tank from the portable can. Sure, you can still fill the tank and you can still buy gasoline, but not everyone would want to take the extra step, even if some 'fixed' their cars by boring out a larger fill hole. (ok, maybe not a perfect analogy)

 

See how this can go around and around?

 

The point is -you- changed something that broke the programs, not the other way around. There does not appear to be any point in further discussion as there is no compromise solution or you are unwilling to entertain it, based on earlier comments.

 

And no, this doesn't mean I won't play with RXB... it just means when I do want to use it, I'll have to bring my spare gas can.

Link to comment
Share on other sites

 

Time out.

 

The loaders worked until you made a change in RXB. The loaders work in other XB versions. You state BOOT and FW and others 'screwed up'. Is there another TI release of XB with your 'fix' that we don't know about? Are we barking up a wrong tree?

 

If not, then I say: "you created the problem by changing XB and by your own words, shouldn't you fix a problem that you created, not the other way around?"

 

How about an analogy. If RXB was a gas station, it would be like changing all the pump nozzles to a larger diameter. Then you tell everyone that to fill their car with gasoline, they need to first fill up a portable gas can then load the gas tank from the portable can. Sure, you can still fill the tank and you can still buy gasoline, but not everyone would want to take the extra step, even if some 'fixed' their cars by boring out a larger fill hole. (ok, maybe not a perfect analogy)

 

See how this can go around and around?

 

The point is -you- changed something that broke the programs, not the other way around. There does not appear to be any point in further discussion as there is no compromise solution or you are unwilling to entertain it, based on earlier comments.

 

And no, this doesn't mean I won't play with RXB... it just means when I do want to use it, I'll have to bring my spare gas can.

 

RXB had already been out there for a year before with no issues. So FW and BOOT break it and you blame me????????

 

I stated this in the Micropendium feedback. And notified Tony McGovern about it after I got a copy of FW 5.01 and RXB worked fine up until that time.

 

The new loaders broke RXB not the other way around. You got the sequence BACKWARDS. FW 4.40 worked fine with RXB and 5.01 FW XB loader broke it.

 

So it is only 2 freaking bad loaders out of how many? Like 30 non broken ones so do not use bugged broken loaders!

 

Since when has bad software badly written made the standards? Simple fix is do not use bugged badly written XB Loaders.

Edited by RXB
Link to comment
Share on other sites

gallery_34177_1071_24698.gif

The upper font is the standard XB font. The middle font is from RXB. The lower font is from TML. Notice how the lower fonts are much more even in height compared to the RXB font.

Why don't you put it to a vote and see if people have a preference?

Sure I have no issue with that?

Does your lower case over lap onto the UPPER case as many complained about that and I had to change Fonts.

Link to comment
Share on other sites

Yep, the descenders gjpqy will reach down and touch the tops of many of the capital letters. To me that seems less objectionable than a lower case font where the letters are all at different heights. Others may have a different opinion.

Dang well can not have it both ways. Some complained about this but others like you prefer this.

 

Guess a poll is about the only thing I can do huh?

Link to comment
Share on other sites

 

RXB had already been out there for a year before with no issues. So FW and BOOT break it and you blame me????????

 

I stated this in the Micropendium feedback. And notified Tony McGovern about it after I got a copy of FW 5.01 and RXB worked fine up until that time.

 

The new loaders broke RXB not the other way around. You got the sequence BACKWARDS. FW 4.40 worked fine with RXB and 5.01 FW XB loader broke it.

 

So it is only 2 freaking bad loaders out of how many? Like 30 non broken ones so do not use bugged broken loaders!

 

Since when has bad software badly written made the standards? Simple fix is do not use bugged badly written XB Loaders.

 

I see your point. TI's Extended BASIC came first. So if I apply your own argument, there are 10 non-broken Extended BASIC versions that load FW. RXB didn't conform to TI Extended BASIC methods and broke the FW & BOOT loaders. So do not use the broken RXB with FW. Is that what you are trying to say?

Link to comment
Share on other sites

 

I see your point. TI's Extended BASIC came first. So if I apply your own argument, there are 10 non-broken Extended BASIC versions that load FW. RXB didn't conform to TI Extended BASIC methods and broke the FW & BOOT loaders. So do not use the broken RXB with FW. Is that what you are trying to say?

Look RXB worked with FW loaders fine for a year version 4.40 was not broken.

RXB did not break FW, FW broke RXB so version 5.01 broke it.

 

Want it to work then USE the previously unbroken FW loaders. That is EXACTLY WHAT TONY MCGOVERN SAID TO DO!

 

Tony did not tell me to change RXB he said just use the old loader that worked. He knew he broke it but did not plan to fix it.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...