Assembly on the 99/4A

[RXB]

5 hours ago, Asmusr said:

Which ones are those?

Let's see RXB, SXB and XB 2.8 are backwards compatible, except RXB is only one that can run TI Basic programs without modifications.

 

Abasic, Power Basic, and Kull XB 2 can not run XB programs without major modifications to XB programs, thus NOT BACKWARDS COMPATIBLE.

[Asmusr]

19 minutes ago, RXB said:

Abasic, Power Basic, and Kull XB 2 can not run XB programs without major modifications to XB programs, thus NOT BACKWARDS COMPATIBLE.

Thanks. So those BASICs are based on a compiling of the XB GPL into machine code?

Edited May 23, 2021 by Asmusr

[RXB]

Just now, Asmusr said:

Thanks. So those BASICs are based on compiling the XB GPL into machine code?

Yep that is exactly what you find!

It is very very hard to convert GPL to Assembly and make it work without using the built in GPL.

There are things Assembly can do that are very fast but you give up many features of GPL in return.

 

Tursi had the best solution is to get rid of GROM delays as that would make GPL the same speed as Forth.

[+InsaneMultitasker]

21 minutes ago, RXB said:

Let's see RXB, SXB and XB 2.8 are backwards compatible, except RXB is only one that can run TI Basic programs without modifications.

Abasic, Power Basic, and Kull XB 2 can not run XB programs without major modifications to XB programs, thus NOT BACKWARDS COMPATIBLE

If abasic refers to the Geneve basic, it is very compatible with standard XB, barring programs that went outside the XB playground.  Although like RXB and other enhanced BASICs, the Geneve Basic adds features and CALLS that can render a program unusable with standard XB.  I do not know if Geneve basic can run TI Basic programs without modifications, though from what I've read it is likely since it doesn't use VDP for processing, garbage collection, or program space.

 

Geneve Basic is written in assembly (no GPL) and the source is available.  Since Myarc worked with TI, I wouldn't be surprised if the XB ROM assembly code portion had been consumed into the project and then updated for the new environment.  Maybe there are some hints and tricks that could be applied on the TI side as well, should such a programming effort move forward.

[senior_falcon]

50 minutes ago, RXB said:

Let's see RXB, SXB and XB 2.8 are backwards compatible, except RXB is only one that can run TI Basic programs without modifications.

 

Abasic, Power Basic, and Kull XB 2 can not run XB programs without major modifications to XB programs, thus NOT BACKWARDS COMPATIBLE.

Incorrect. XB 2.8 G.E.M. can also run TI BASIC programs without modifications.

[Asmusr]

1 hour ago, InsaneMultitasker said:

Geneve Basic is written in assembly (no GPL) and the source is available.  Since Myarc worked with TI, I wouldn't be surprised if the XB ROM assembly code portion had been consumed into the project and then updated for the new environment.  Maybe there are some hints and tricks that could be applied on the TI side as well, should such a programming effort move forward.

So I assume you don't think the assembly code was generated by compiling the XB GPL into assembly. That leaves only Power Basic and Kull XB 2 as candidates for doing what I suggested. 

[+InsaneMultitasker]

2 minutes ago, Asmusr said:

So I assume you don't think the assembly code was generated by compiling the XB GPL into assembly. That leaves only Power Basic and Kull XB 2 as candidates for doing what I suggested. 

I did not make that clear in my post but yes, that is a correct assumption based on my knowledge of the code.

[RXB]

2 hours ago, senior_falcon said:

Incorrect. XB 2.8 G.E.M. can also run TI BASIC programs without modifications.

Hmmm is just loaded XB 2.7 on Classic99 and typed:

CALL CHAR(158,"FF")

ERROR BAD VALUE

But you can do this in RXB no problem, so it sounds like you have to prepare XB 2.7 to pull this off.

 

Or can you do this in XB 2.8 without doing anything but just type it in or run it without a CALL to make it work?

[senior_falcon]

"Or can you do this in XB 2.8 without doing anything but just type it in or run it without a CALL to make it work?"

 

Of course it can be done. XB 2.7 is not the same as XB 2.8 G.E.M.!!!!!

Edited May 23, 2021 by senior_falcon

[RXB]

19 minutes ago, senior_falcon said:

"Or can you do this in XB 2.8 without doing anything but just type it in or run it without a CALL to make it work?"

Of course it can be done. XB 2.7 is not the same as XB 2.8 G.E.M.!!!!!

Any news on when XB 2.8 will be in Classic99 so I can test it?

[senior_falcon]

You can download it right now and run it as a user cartridge.

 

(sorry about the big blue heart-dunno where that came from!)

Edited May 23, 2021 by senior_falcon

[Airshack]

22 hours ago, senior_falcon said:

 

(sorry about the big blue heart-dunno where that came from!)

From deep down perhaps?

[Tursi]

On 5/23/2021 at 3:35 PM, RXB said:

Any news on when XB 2.8 will be in Classic99 so I can test it?

Not /every/ new product lands in Classic99.

 

We need that TI-based app store...

 

 

[+TheBF]

A question that I know has been answered before but I cannot find the right search words.

 

I see that starting an program file with E/A 5  will look for a file if even if you type nothing at the command line and just hit ENTER.

 

What file is it searching for?

[+FarmerPotato]

16 minutes ago, TheBF said:

A question that I know has been answered before but I cannot find the right search words.

 

I see that starting an program file with E/A 5  will look for a file if even if you type nothing at the command line and just hit ENTER.

 

What file is it searching for?

I seem to recall it searches for DSK1.UTIL1

 

If not E/A, then TI-Writer does that?

 

[+mizapf]

Yes, Editor/Assembler loads DSK1.UTIL1 when an empty path is entered in option 5.

[+TheBF]

Thanks guys.

 

I am getting tired of typing DSK1.CAMTTY67  everytime I need to restart my system.

 

 

[+Vorticon]

I am mulling over the feasibility of a new project in XB with assembly language support and I have a question: does chaining XB programs corrupt the lower 8K of the expansion RAM assuming the programs are kept under 24K to fit in upper memory? This is important information since assembly language programs usually reside in the lower 8K with XB.

[RXB]

10 hours ago, Vorticon said:

I am mulling over the feasibility of a new project in XB with assembly language support and I have a question: does chaining XB programs corrupt the lower 8K of the expansion RAM assuming the programs are kept under 24K to fit in upper memory? This is important information since assembly language programs usually reside in the lower 8K with XB.

No it does not.

 

[senior_falcon]

11 hours ago, Vorticon said:

I am mulling over the feasibility of a new project in XB with assembly language support and I have a question: does chaining XB programs corrupt the lower 8K of the expansion RAM assuming the programs are kept under 24K to fit in upper memory? This is important information since assembly language programs usually reside in the lower 8K with XB.

The 8K lower memory is not altered as long as you do not perform CALL INIT. Typically utilities such as The Missing Link are loaded with a loader program and once in place you can load XB programs as desired without having to reload the utility.

 

Here is something may whet your appetite. With the "Juwel" package, compiled XB programs can use assembly support in low memory. The order of operations is just like in XB. Load the assembly support, then load and run the compiled XB program. The compiled XB program can chain to another compiled XB program just like in normal XB without having to reload the assembly portion. As usual, you can save in EA5 format but then you lose the ability to chain programs.

Edited June 28, 2021 by senior_falcon

[+Vorticon]

Thanks for the info!

[+Vorticon]

55 minutes ago, senior_falcon said:

The 8K lower memory is not altered as long as you do not perform CALL INIT. Typically utilities such as The Missing Link are loaded with a loader program and once in place you can load XB programs as desired without having to reload the utility.

 

Here is something may whet your appetite. With the "Juwel" package, compiled XB programs can use assembly support in low memory. The order of operations is just like in XB. Load the assembly support, then load and run the compiled XB program. The compiled XB program can chain to another compiled XB program just like in normal XB without having to reload the assembly portion. As usual, you can save in EA5 format but then you lose the ability to chain programs.

One question: Does Juwel load any assembly utilities into the lower 8K? And if it does, how much space is left over for custom ALC support programs?

[senior_falcon]

41 minutes ago, Vorticon said:

One question: Does Juwel load any assembly utilities into the lower 8K? And if it does, how much space is left over for custom ALC support programs?

Good question! Normally when you use assembly subs with XB, CALL LOAD will put them into memory from >24F4 to >4000. Like XB, Juwel uses the memory from >2000 to >24F4 for support routines, workspaces, etc. It has its own custom STREF, STRASG, NUMREF, NUMASG, etc. routines but everything is below >24F4. If you don't do any trickery with AORG's to areas below >24F4 you should be fine.

[+Vorticon]

9 hours ago, senior_falcon said:

Good question! Normally when you use assembly subs with XB, CALL LOAD will put them into memory from >24F4 to >4000. Like XB, Juwel uses the memory from >2000 to >24F4 for support routines, workspaces, etc. It has its own custom STREF, STRASG, NUMREF, NUMASG, etc. routines but everything is below >24F4. If you don't do any trickery with AORG's to areas below >24F4 you should be fine.

So the First Free Address pointer should then be automatically updated and allow for relocatable code just as usual. I did not know your compiler replaced the standard XB utility routines. If I may ask, why did you replace them?

[senior_falcon]

7 hours ago, Vorticon said:

So the First Free Address pointer should then be automatically updated and allow for relocatable code just as usual. I did not know your compiler replaced the standard XB utility routines. If I may ask, why did you replace them?

VSBW, VSBR, VMBW, VMBR, VWTR are all there and can be used as usual. As written,NUMASG, NUMREF, STRASG, STREF cannot work. They were written to pass values to and from an XB program. They would have no idea where the strings and numbers are kept in a compiled program. These are replaced with routines that actually do work. Since everything is integer, CFI and CIF have no purpose and are simply bypassed.

 

Edited June 28, 2021 by senior_falcon