A question of ignorance... (XB / EA5)

[Omega-TI]

I've not done a whole lot of programming in the past 23 years and I never learned Assembly Language. Now I would like to do a few things, but I do not want to start from 'square one'. So my question is this...

 

Is there a program out there that will convert an Extended BASIC program into an E/A 5 program?

 

[+Ksarul]

Not without running it through a compiler first--just read the various compiler threads here to see what I mean there. There IS a way to put a TI BASIC program into cartridge space (several very early TI cartridges were built this way), but the method does not extend to Extended BASIC programs.

[Omega-TI]

Not without running it through a compiler first--just read the various compiler threads here to see what I mean there. There IS a way to put a TI BASIC program into cartridge space (several very early TI cartridges were built this way), but the method does not extend to Extended BASIC programs.

 

Bummer.... I was afraid of that. Thanks.

[Willsy]

You could try learning Forth. For things like simple games you could pick up most of what you need to know in an afternoon. It's bonkers simple!

[Omega-TI]

You could try learning Forth. For things like simple games you could pick up most of what you need to know in an afternoon. It's bonkers simple!

 

I probably will in the future as there are things I do want to accomplish. Right now, besides work and other responsibilities, I have two elderly parents (one with Alzheimers) that always seem to know when I have a free moment, so they can call and take it. Anything to do with the TI has to get 'crammed' in the middle, as family is my priority. Hell, I feel happy when I have enough time to add a couple of paragraphs to a new manual.

[senior_falcon]

Is there a program out there that will convert an Extended BASIC program into an E/A 5 program?

If your goal is to convert an XB program into assembly language then the closest you will come is to use the compiler. However, your question brings up the possibility of storing a BASIC or XB program in an EA5 format. Then when you run the EA5 program the BASIC or XB program is loaded and run. It could even be set up so you could choose a point to save the program, say after characters have been defined and the screen displayed. Then, when you run the EA5 program it would start at that point, bypassing those steps.

[RXB]

I've not done a whole lot of programming in the past 23 years and I never learned Assembly Language. Now I would like to do a few things, but I do not want to start from 'square one'. So my question is this...

 

Is there a program out there that will convert an Extended BASIC program into an E/A 5 program?

 

Having spent 2 months working on a Extended Basic to GPL compiler I had to dump the project when the Extended Basic to Assembly programs were introduced.

GPL is much slower then Assembly so made my project almost pointless.

Now it is much more easy to use GPL then Assembly as less space is needed to do the same thing.

But like I said the speed is slower so any advantages are lost due to the increased performance overall by Assembly.

A slight increase in difficulty of 25% is the extra requirement for Assembly vs GPL.

 

Sorry but if the number of people using a new application is less and dwindling then no point putting out that app is there?

[+Ksarul]

Rich--there is an advantage to an Extended BASIC to GPL compiler. It lets you build cartridges that fit into the GPL space of the ÜberGROM. There are lots of folks out there that can write an Extended BASIC program--but this would let them write that program and hoist it into cartridge space easily. That is a major good thing. Please don't give up on it.

[+OLD CS1]

Rich--there is an advantage to an Extended BASIC to GPL compiler. It lets you build cartridges that fit into the GPL space of the ÜberGROM. There are lots of folks out there that can write an Extended BASIC program--but this would let them write that program and hoist it into cartridge space easily. That is a major good thing. Please don't give up on it.

 

Second.

[Willsy]

Third.

[RXB]

Well I can continue that project, presently working on a new GROM 0 and replacement GROM 1 and 2

 

Thanks for the vote to continue.

[RobertLM78]

If your goal is to convert an XB program into assembly language then the closest you will come is to use the compiler....

As one of our resident compiler experts, would it be possible to write a compiler that would be able to do floating point operations?

(It wouldn't hurt my feelings if every line had to be a one statement line .)

[Gazoo]

Well I can continue that project, presently working on a new GROM 0 and replacement GROM 1 and 2

 

Thanks for the vote to continue.

 

Be VERY careful about relocating code in Grom0. The slightest change could break a lot of programs. Prime example is the Winkler Grom0, lots of programs that expect things to be at absolute addresses just won't run with it.

 

Gazoo

[senior_falcon]

As one of our resident compiler experts, would it be possible to write a compiler that would be able to do floating point operations?

(It wouldn't hurt my feelings if every line had to be a one statement line .)

The code produced by the compiler would support floating point operations with just a few minor tweaks. Basically, 8 bytes have to be reserved for numbers instead of the two bytes currently reserved. Also, certain constants such as pi would need to be in floating point format. That's the easy part. The hard part is that someone would have to rewrite all the runtime routines to support floating point operations. That someone is not going to be me. I will make the offer again, that If anyone else is interested in rewriting the runtime routines to support floating point math, then I could make the necessary changes to the compiler to support the new routines. In my tests 20 years ago some simple programs that used floating point ran around 3x faster when compiled, compared to around 20x using integer math. One thing to keep in mind is that the runtime routines would need to be larger if floating point is used, plus the program itself would get larger because of the 8 bytes vs. 2 byte space needed for numbers.

[Gazoo]

The code produced by the compiler would support floating point operations with just a few minor tweaks. Basically, 8 bytes have to be reserved for numbers instead of the two bytes currently reserved. Also, certain constants such as pi would need to be in floating point format. That's the easy part. The hard part is that someone would have to rewrite all the runtime routines to support floating point operations. That someone is not going to be me. I will make the offer again, that If anyone else is interested in rewriting the runtime routines to support floating point math, then I could make the necessary changes to the compiler to support the new routines. In my tests 20 years ago some simple programs that used floating point ran around 3x faster when compiled, compared to around 20x using integer math. One thing to keep in mind is that the runtime routines would need to be larger if floating point is used, plus the program itself would get larger because of the 8 bytes vs. 2 byte space needed for numbers.

 

I'm not making an offer to do the rewrite, as I've got other things going. But I think that the speed issue (3x vs 20x) is irrelevant to the people wanting the decimal math compatibility. For myself, I'd be happy if a compiled XB Program ran at the same speed as the original, the important part is having it in EA5 format and it accepting decimal points. Case in point would be the many music programs written for the TI and the excellent 'Decimal to Hex to Binary' converter program written in XB.

 

Gazoo

[+InsaneMultitasker]

 

Be VERY careful about relocating code in Grom0. The slightest change could break a lot of programs. Prime example is the Winkler Grom0, lots of programs that expect things to be at absolute addresses just won't run with it.

 

Gazoo

You mean like programs that save a few bytes by referencing values in ROM for data and comparisons? I never liked that practice and long ago ended up "fixing" some of those programming conveniences.

[Gazoo]

You mean like programs that save a few bytes by referencing values in ROM for data and comparisons? I never liked that practice and long ago ended up "fixing" some of those programming conveniences.

 

No, more like programs that use GPL routines that aren't where they're supposed to be.

 

Gazoo

[RobertLM78]

I would offer myself, however I have a lot more assembly to learn. One day perhaps .

[RXB]

 

Be VERY careful about relocating code in Grom0. The slightest change could break a lot of programs. Prime example is the Winkler Grom0, lots of programs that expect things to be at absolute addresses just won't run with it.

 

Gazoo

I know this very well as a GPL programmer. The only things broken are crazy things like Bruce Harrison did in some of his programs.

 

Direct access that only works of one version of GROM 0 is always going to be a problem. But then when you ignore TI standards that is always the result.

[RXB]

The code produced by the compiler would support floating point operations with just a few minor tweaks. Basically, 8 bytes have to be reserved for numbers instead of the two bytes currently reserved. Also, certain constants such as pi would need to be in floating point format. That's the easy part. The hard part is that someone would have to rewrite all the runtime routines to support floating point operations. That someone is not going to be me. I will make the offer again, that If anyone else is interested in rewriting the runtime routines to support floating point math, then I could make the necessary changes to the compiler to support the new routines. In my tests 20 years ago some simple programs that used floating point ran around 3x faster when compiled, compared to around 20x using integer math. One thing to keep in mind is that the runtime routines would need to be larger if floating point is used, plus the program itself would get larger because of the 8 bytes vs. 2 byte space needed for numbers.

Very true. The problems is most of the XB programs written are using Floating Point.

When working on a XB to GPL compiler I figured that once the code was turned into GPL.

A second Compiler run would look for where Floating Point could be turned to integer math.

As long as the decimal is not more than 2 places this would work most of the time. (I could be wrong)

[senior_falcon]

 

For myself, I'd be happy if a compiled XB Program ran at the same speed as the original, the important part is having it in EA5 format and it accepting decimal points.

 

Do you want to run XB programs without the XB cartridge, or is the EA5 format important to you for some reason - perhaps some sort of menu loader?

[Gazoo]

 

For myself, I'd be happy if a compiled XB Program ran at the same speed as the original, the important part is having it in EA5 format and it accepting decimal points.

 

Do you want to run XB programs without the XB cartridge, or is the EA5 format important to you for some reason - perhaps some sort of menu loader?

 

 

Yes and Yes.

 

Gazoo

[Gazoo]

I know this very well as a GPL programmer. The only things broken are crazy things like Bruce Harrison did in some of his programs.

 

Direct access that only works of one version of GROM 0 is always going to be a problem. But then when you ignore TI standards that is always the result.

 

"The only things broken are crazy things like Bruce Harrison did in some of his programs."

 

Not true, about 50% of all the software I owned didn't work after I got my HSGPL card with the non-standard Grom0 pre-loaded in it.

 

"Direct access that only works of one version of GROM 0 is always going to be a problem."

 

Not true, a healthy respect for pre-existing standards allows one to create a Grom0 that works in all cases. Case in point - 'TKGROM0'.

 

'But then when you ignore TI standards that is always the result.'

 

That was the point of my original post about relocating unrelocatable code.

 

Gazoo

[RXB]

 

"The only things broken are crazy things like Bruce Harrison did in some of his programs."

 

Not true, about 50% of all the software I owned didn't work after I got my HSGPL card with the non-standard Grom0 pre-loaded in it.

 

"Direct access that only works of one version of GROM 0 is always going to be a problem."

 

Not true, a healthy respect for pre-existing standards allows one to create a Grom0 that works in all cases. Case in point - 'TKGROM0'.

 

'But then when you ignore TI standards that is always the result.'

 

That was the point of my original post about relocating unrelocatable code.

 

Gazoo

Yes, I never have moved any code that is non relocatable.

After all RXB is very compatible with all other problems except for the Funnel Web loader but that does not work with any XB that uses the GK XB mods.

 

I informed Tony about this problem but it never got fixed as far as I know. FunnelWeb used >6372 as a hard coded address instead of getting the header address from XB.

Then running that address from the header, that would be compatible with any XB as the header always points to the correct address to start the module.

But you could patch FunnelWeb disk to fix this issue.

[Gazoo]

Yes, I never have moved any code that is non relocatable.

After all RXB is very compatible with all other problems except for the Funnel Web loader but that does not work with any XB that uses the GK XB mods.

 

I informed Tony about this problem but it never got fixed as far as I know. FunnelWeb used >6372 as a hard coded address instead of getting the header address from XB.

Then running that address from the header, that would be compatible with any XB as the header always points to the correct address to start the module.

But you could patch FunnelWeb disk to fix this issue.

 

RXB is also not compatible with BOOT, and any other interrupt driven XB program loader that replaces 'DSK1.LOAD' when starting XB. That's why the startup code in XB v2.7 is untouched, to remain compatible with TI XB.

 

Gazoo