The Editor/Assembler

[RobertLM78]

Under Retrocloud's advice, I'm starting a new thread for this question of mine. Perhaps it can become a thread for issues and questions related to the Editor/Assembler as well.

 

Anyway, what is the max file size that can be created/loaded in the Editor? I know the Editor itself has to be using some memory, so it's got to be less than 32k. Thanks for reading .

[Opry99er]

Have you read any of Thierry Nouspikels TI data pages? His work is about as comprehensive as it gets in terms of machine capabilities. As an aside, 32k is a MASSIVE amount of space when you're talking machine code for the TI.

[senior_falcon]

As I recall the Editor can hold a source code file that is around 24K, which makes me think it uses all the high memory (24K) for the source code.

 

In my "for what it's worth" department TI BASIC generally fares poorly when compared to Extended BASIC. BUT... When you compare loading times for A/L subroutines there is no comparison. A recent test took 49 seconds to load a lengthy A/L sub into XB. With the E/A module it was under 3 seconds! Plus, I believe E/A BASIC can load compressed object code, so the files are considerably smaller on the disk (and probably load faster still). So if you wanted to create a program that loads a bunch of different assembly modules but still wanted to keep the main part of the program in the BASIC/XB language then E/A BASIC might be a good solution for you.

[+InsaneMultitasker]

As I recall the Editor can hold a source code file that is around 24K, which makes me think it uses all the high memory (24K) for the source code.

 

In my "for what it's worth" department TI BASIC generally fares poorly when compared to Extended BASIC. BUT... When you compare loading times for A/L subroutines there is no comparison. A recent test took 49 seconds to load a lengthy A/L sub into XB. With the E/A module it was under 3 seconds! Plus, I believe E/A BASIC can load compressed object code, so the files are considerably smaller on the disk (and probably load faster still). So if you wanted to create a program that loads a bunch of different assembly modules but still wanted to keep the main part of the program in the BASIC/XB language then E/A BASIC might be a good solution for you.

 

For Extended BASIC assembly routines, SYSTEX is your friend for the finished product. It will save the loaded routines into a runnable program, eliminating the long, boring wait.

[RobertLM78]

Have you read any of Thierry Nouspikels TI data pages? His work is about as comprehensive as it gets in terms of machine capabilities. As an aside, 32k is a MASSIVE amount of space when you're talking machine code for the TI.

Wow - I have been to that site before, but I hadn't realized just how comprehensive it is .

 

As I recall the Editor can hold a source code file that is around 24K, which makes me think it uses all the high memory (24K) for the source code.

My cursory look at Thierry's page didn't reveal anything on this specific (at least directly), but I bet you're right about 24k being the max - just like a Extended Basic program.

 

Thanks for the input fellas - it sure is fun having the old beast out again .

[Willsy]

it sure is fun having the old beast out again .

 

I say, sir!! Oooh Matron! Steady on old fellow, this is a family friendly forum!!

 

 

Oh, wait.. You're talking about your TI!

 

Ahhhh....

[RobertLM78]

I say, sir!! Oooh Matron! Steady on old fellow, this is a family friendly forum!!

 

Oh, wait.. You're talking about your TI!

- indeed! 'Twas great to be cracked up when reading the first post this morning. (Great picture of Mr. Williams, by the way). It looks like I've found the right place for fellow TI nuts .

[RXB]

For Extended BASIC assembly routines, SYSTEX is your friend for the finished product. It will save the loaded routines into a runnable program, eliminating the long, boring wait.

 

Ok RXB has something much faster then both and I have a demo to load 160K into the SAMS lower 8K much faster then anyone else so far.

CALL BSAVE("DSK#.NAME") ! Saves the lower 8K into a Program Image file.

CALL BLOAD("DSK#.NAME") ! Loads a program image file into the lower 8K.

 

 

To bad fracking Youtube cuts off most of the demo as the new time limit is now 15 minutes on my 30 minute demos.

Do we have somewhere we can upload demos?

[marc.hull]

Ok RXB has something much faster then both and I have a demo to load 160K into the SAMS lower 8K much faster then anyone else so far.

 

There is no CALL anything with SYSTEX Rich. Loads with the program so are you sure it's faster ?

[RXB]

There is no CALL anything with SYSTEX Rich. Loads with the program so are you sure it's faster ?

 

Yep pretty sure.

Using a PGRAM and SYSTEX I did a demo of RXB 2001 at the Chicago Fair and loaded the same Program with RXB using both.

Using XB to load SYSTEX and RXB took the same amount of time.

But when I used CALL BLOAD I could load almost 4 times as much in the same time as Systex.

I also demoed a 40K load of the SAMS faster then SYSTEX could load 32K into Lower 8K and Upper 24K.

 

The reason why is pretty simple. RXB does 8K chunks and Systex uses some other method to load.

Can not test it today but back then it uses the same code as today.

 

Rich

[+InsaneMultitasker]

Yep pretty sure.

Using a PGRAM and SYSTEX I did a demo of RXB 2001 at the Chicago Fair and loaded the same Program with RXB using both.

Using XB to load SYSTEX and RXB took the same amount of time.

But when I used CALL BLOAD I could load almost 4 times as much in the same time as Systex.

I also demoed a 40K load of the SAMS faster then SYSTEX could load 32K into Lower 8K and Upper 24K.

 

The reason why is pretty simple. RXB does 8K chunks and Systex uses some other method to load.

Can not test it today but back then it uses the same code as today.

 

Rich

SYSTEX copies the user-loaded routines from the lower 8K, saves them "between" the extended basic code, and creates a program you can save to disk. Upon loading and running that saved program, SYSTEX dumps the routines back into the 8K space. I would have to review its code again; however, from what I recall it is a simple memory move to lower 8k. Systex is quite a simple-to-use yet ingenious program. Which is why nearly 30 years later it is still so useful.

[Willsy]

- indeed! 'Twas great to be cracked up when reading the first post this morning. (Great picture of Mr. Williams, by the way). It looks like I've found the right place for fellow TI nuts .

 

Yep, we're completely bonkers here, especially the Brits!!

 

Owen is bonkers too - he'd fit right in over here

[marc.hull]

Yep pretty sure.

Using a PGRAM and SYSTEX I did a demo of RXB 2001 at the Chicago Fair and loaded the same Program with RXB using both.

Using XB to load SYSTEX and RXB took the same amount of time.

But when I used CALL BLOAD I could load almost 4 times as much in the same time as Systex.

I also demoed a 40K load of the SAMS faster then SYSTEX could load 32K into Lower 8K and Upper 24K.

 

The reason why is pretty simple. RXB does 8K chunks and Systex uses some other method to load.

Can not test it today but back then it uses the same code as today.

 

Rich

 

Perhaps your thinking of YLOAD and not SYSTEX ?

[RXB]

No I had Systex and a SAMS and it quickly hit me that Systex was useless with the SAMS for loading anything larger then a single Page of 8K in the lower 8K.

That is why I looked at Systex and Yload and thought they have huge issues with the SAMS or 9938 or 9958 as they could not load anymore then a set amount, not flexible to use.

 

Do not get me wrong if you have basically a 32K and a stock TI then Systex and Yload are great, but suck for future devices like the SAMS that is cheap and easy to use.

Also they suck if you want to swap out the lower 8K but keep the XB program running it.

My demo loaded and ran from a single XB program 160K or SAMS in the Lower 8K.

 

By the way RXB (Rich Extended Basic) has been around since version 5.50 and in Micropendium in 1989 so that is over 30 YEARS OLD ALSO!

Edited May 14, 2013 by RXB

[Gazoo]

By the way RXB (Rich Extended Basic) has been around since version 5.50 and in Micropendium in 1989 so that is over 30 YEARS OLD ALSO!

 

2013 - 1989 = 24

[senior_falcon]

Also they suck if you want to swap out the lower 8K but keep the XB program running it.

This is one of the things that is appealing about using TI BASIC with the E/A or MiniMemory cartridge. You could have a small BASIC program sitting in VDP ram calling the shots and load 32K (36K with MiniMemory and 40K with supercart) of A/L modules into the memory expansion. Of course it would not be as fast as loading data with Rich's method or SYSTEX but it just might be fast enough to be useful.

[Opry99er]

Interesting thought.

 

Still, QUICKLOAD (which you shared with me recently) is pretty freaking amazing when paired with COMPRESS. Im still in awe.......

[RXB]

2013 - 1989 = 24

 

So Systex was introduced the same year as the TI99/4A in 1982?

2012 - 1982=30

 

Well RXB wins the up to date race (2012) and will load more then any other method. SAMS, GRAM, VDP, RAM and CRU.

 

Have you even tried RXB CALL BSAVE and CALL BLOAD with the SAMS or just Assembly?

RXB also has CALL EXECUTE(cpu-address) that is 2 times faster then CALL LINK

This is from the RXB manual:

 

RXB TO ASSEMBLY DIRECT ACCESS BY ADDRESS:

----------------------------------------------------------------

EXECUTE is much faster than the traditional LINK routine built

into XB. The main problem with LINK is it checks everything and

pushes everything onto the VDP stack. After getting to Assembly

it pops everything off the stack for use or pushes what is to

be passed to XB onto the stack. EXECUTE on the other hand just

passes a address to a 12 byte Assembly program in Fast RAM and

RTWP ends the users program. A LINK will use up 6 bytes for the

name, 2 bytes for the address and wastes time checking things.

The advantage to EXECUTE is you use LOAD or MOVE or MOVES to

place the values needed directly into the registers then do it.

EXECUTE uses less space, is faster, and is easy to debug.

Edited May 16, 2013 by RXB