Jump to content
Sign in to follow this  
jedimatt42

fully relocatable assembly linking with XB

Recommended Posts

I recommend developers learn to have a cup of tea, and savor the time they are spending while their classic software is loaded on their classic computer.  If I wanted fast, I'd use... literally any other computer.

 

 

As the vendor of the driver, I'm not interested in producing a different file and instructions for TI XB, RXB or XB256. I am guilty here of producing for the lowest common denominator: TI XB. 

 

I provide the assembly source on github, so anyone can incorporate it in optimal fashion for their specific environment.  If you want to use a specific loading technique, I recommend just embedding it with your other deliverables.

 

These load times are a bother for people while developing, but completely inconsequential to the end user unless the final product isn't entertaining or useful enough to consume 15x the loading time per session.

  • Like 4

Share this post


Link to post
Share on other sites
Posted (edited)
25 minutes ago, jedimatt42 said:

As the vendor of the driver, I'm not interested in producing a different file and instructions for TI XB, RXB or XB256. I am guilty here of producing for the lowest common denominator: TI XB. Writing for the lowest common denominator is a good thing and until I created G.E.M. has always been my philosophy. Hence, The Missing Link, XB256, T40XB and T80XB all started as disk based extensions for plain vanilla XB using nothing more than 32K and a disk drive, and they are still available in disk format.

 

These load times are a bother for people while developing, but completely inconsequential to the end user unless the final product isn't entertaining or useful enough to consume 15x the loading time per session. Using XB 2.8 G.E.M. for development work has the advantage of loading object code much faster, yet the end result is 100% compatible with TI XB. Naturally, that doesn't preclude having a nice leisurely cup of Earl Grey if desired. In fact, I am going to do that right now! (Edit) Turns out I decided on green tea instead.

 

Edited by senior_falcon
  • Haha 2

Share this post


Link to post
Share on other sites
4 hours ago, jedimatt42 said:

I recommend developers learn to have a cup of tea, and savor the time they are spending while their classic software is loaded on their classic computer.  If I wanted fast, I'd use... literally any other computer.

 

 

As the vendor of the driver, I'm not interested in producing a different file and instructions for TI XB, RXB or XB256. I am guilty here of producing for the lowest common denominator: TI XB. 

 

I provide the assembly source on github, so anyone can incorporate it in optimal fashion for their specific environment.  If you want to use a specific loading technique, I recommend just embedding it with your other deliverables.

 

These load times are a bother for people while developing, but completely inconsequential to the end user unless the final product isn't entertaining or useful enough to consume 15x the loading time per session.

The only delay in load times with RXB 2020 is the first time you load it with CALL LOAD("DSK#.FILENAME")

After you save it with CALL PSAVE it is in program image format so much quicker to load.

Two step process to convert:  Step one LOAD OBJECT with XB CALL LOAD and step two use CALL PSAVE .... DONE

 

The real bonus is it will load any location of 32K quickly.

Share this post


Link to post
Share on other sites
5 hours ago, RXB said:

The only delay in load times with RXB 2020 is the first time you load it with CALL LOAD("DSK#.FILENAME")

After you save it with CALL PSAVE it is in program image format so much quicker to load.

Two step process to convert:  Step one LOAD OBJECT with XB CALL LOAD and step two use CALL PSAVE .... DONE

 

The real bonus is it will load any location of 32K quickly.

While fast loading times for CALL LOAD, be it with RXB or XB GEM, are nice, to be honest the difference is likely just a few seconds as compared to plain XB and likely of little import to the user because it's a one time thing usually at the start of a program. Now if someone told me they had managed to speed up CALL LINK substantially, that would definitely grab my attention because it is usually called much more frequently during the course of program execution.

Share this post


Link to post
Share on other sites
5 minutes ago, Vorticon said:

While fast loading times for CALL LOAD, be it with RXB or XB GEM, are nice, to be honest the difference is likely just a few seconds as compared to plain XB and likely of little import to the user because it's a one time thing usually at the start of a program. Now if someone told me they had managed to speed up CALL LINK substantially, that would definitely grab my attention because it is usually called much more frequently during the course of program execution.

Actually, the difference is somewhat larger than just a few seconds. To load XB256.OBJ,  XB 2.8 G.E.M. takes 4 seconds. To do the same thing in any other flavor of XB (including RXB) it takes 84 seconds. Let's say you are developing a large program such as XB256. Now the slow loading time becomes much more irritating because you have to do it many times in a programming session. You are currently developing a hybrid XB/assembly program. If the assembly routines get very large you will find this to be a major irritation. Once you "dare to compare", you'll never go back.

Why do you single out CALL LINK as something that could benefit from speeding up. The same thing can be said about any other CALL in XB.

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, senior_falcon said:

takes 84 seconds

Good God!  Is the loader written in BASIC??

  • Haha 2

Share this post


Link to post
Share on other sites
1 hour ago, senior_falcon said:

Actually, the difference is somewhat larger than just a few seconds. To load XB256.OBJ,  XB 2.8 G.E.M. takes 4 seconds. To do the same thing in any other flavor of XB (including RXB) it takes 84 seconds. Let's say you are developing a large program such as XB256. Now the slow loading time becomes much more irritating because you have to do it many times in a programming session. You are currently developing a hybrid XB/assembly program. If the assembly routines get very large you will find this to be a major irritation. Once you "dare to compare", you'll never go back.

Why do you single out CALL LINK as something that could benefit from speeding up. The same thing can be said about any other CALL in XB.

84 seconds??? Damn... Ok I take it back 😳. I can totally see how such delays could get frustrating very quickly during development. As for CALL LINK, I'm just keeping it within the context of user loaded assembly support programs. 

  • Like 2

Share this post


Link to post
Share on other sites
46 minutes ago, OLD CS1 said:

Good God!  Is the loader written in BASIC??

Uncompressed traditional XB object format, the format is a mini language, expressed in hex. 

 

Compressed object code is still that language, but already in direct byte values.

 

Program images are just a memcpy (or two). 

 

XB256.obj is big. TMOUSE/O is small. Size matters. It amplifies the time penalty. For just the mouse driver, flexibility matters most.

 

In context, this thread was about developing relocatable code. Program images aren't relocatable. Sure, developers can use memory snapshotting to speed up restoring the dev environment. And they can use it to speed up end-user loading. The value depends on if the object code is stable and you are just playing around in xb. If you are evolving the object code, the program images doesn't help, as each time you change/fix it you still have to use the object loader. 

 

Sorry to butt in.

  • Like 4

Share this post


Link to post
Share on other sites
1 hour ago, OLD CS1 said:

Good God!  Is the loader written in BASIC??

The loader is written in GPL. One advantage is that it can be used to load code anywhere in low or high memory, except for the first few bytes at >2000, which are checked to see whether CALL INIT has happened. Also, being in GPL frees up the ram that would otherwise be used for the loader. Those are about the only good things about this loader.

  • Like 1

Share this post


Link to post
Share on other sites
14 minutes ago, jedimatt42 said:

XB256.obj is big. TMOUSE/O is small. Size matters. It amplifies the time penalty. For just the mouse driver, flexibility matters most.

 

In context, this thread was about developing relocatable code. Program images aren't relocatable. Sure, developers can use memory snapshotting to speed up restoring the dev environment. And they can use it to speed up end-user loading. The value depends on if the object code is stable and you are just playing around in xb. If you are evolving the object code, the program images doesn't help, as each time you change/fix it you still have to use the object loader. 

 

Sorry to butt in.

Amen. The thread diverged a great deal from the original subject. Thank you for putting this runaway train back on the right track.

  • Like 2

Share this post


Link to post
Share on other sites
6 hours ago, senior_falcon said:

Actually, the difference is somewhat larger than just a few seconds. To load XB256.OBJ,  XB 2.8 G.E.M. takes 4 seconds. To do the same thing in any other flavor of XB (including RXB) it takes 84 seconds. Let's say you are developing a large program such as XB256. Now the slow loading time becomes much more irritating because you have to do it many times in a programming session. You are currently developing a hybrid XB/assembly program. If the assembly routines get very large you will find this to be a major irritation. Once you "dare to compare", you'll never go back.

Why do you single out CALL LINK as something that could benefit from speeding up. The same thing can be said about any other CALL in XB.

Hmm since 2001 RXB has had CALL BLOAD and now it is CALL PLOAD and I am loading 540K of SAMS using it and my game IN THE DARK

Does not exactly look slow as shown by this demo:   INTHEDARK - YouTube

What slows it down the most is I show what was loaded onto screen, if just loading into RAM it would be way faster as it is Program Image files.

 

And relocatable data code works great for CALL BLOAD as it can be moved to any place in 32K you want now.

Now the assembly of course has to be re assembled for that location, but again it is Program Image not Object Code with TAGS!

Tags slow down loading for a reason.

 

 

  

Share this post


Link to post
Share on other sites
3 hours ago, senior_falcon said:

Amen. The thread diverged a great deal from the original subject. Thank you for putting this runaway train back on the right track.

Hmm nice thing about what I am doing here is you can USE YOUR RELOCABLE CODE like you want, I just save it as PROGRAM IMAGE FOR YOU 

using CALL PSAVE(memory address boundary, "DSK#.FILENAME)

memory address boundary for example is >2000,>3000,>A000,>B000,>C000,>D000,>E000 and >F000

These are shorted for ease of use as 2,3,A,B,C,D,E and F

 

The crazy bonus is this works hand in hand with SAMS memory. (I AM ALWAYS THINKING AHEAD OF CURVE!)

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, senior_falcon said:

The loader is written in GPL. One advantage is that it can be used to load code anywhere in low or high memory, except for the first few bytes at >2000, which are checked to see whether CALL INIT has happened. Also, being in GPL frees up the ram that would otherwise be used for the loader. Those are about the only good things about this loader.

Hmmm RXB does not have this what I call a outright BUG. Why would you need a CALL INIT for a CALL LOAD in console RAM?

This would make it impossible to do a CALL LOAD to Scratch Pad in XB. But not a issue in EA cart? (SEE THIS IS A STUPID BUG!)

 

Also this is same for Mini Memory you do not need a CALL INIT to do a CALL LOAD, again what a stupid bug in XB!

Share this post


Link to post
Share on other sites
51 minutes ago, RXB said:

Hmmm RXB does not have this what I call a outright BUG. Why would you need a CALL INIT for a CALL LOAD in console RAM?

This would make it impossible to do a CALL LOAD to Scratch Pad in XB. But not a issue in EA cart? (SEE THIS IS A STUPID BUG!)

 

Also this is same for Mini Memory you do not need a CALL INIT to do a CALL LOAD, again what a stupid bug in XB!

 

This is clearly NOT a bug. Both E/A’s and MiniMemory’s reason for existence is to do ALC things, so the first thing they do when powered up is to load linkable utility routines. That is NOT XB’s raison d’être! XB does not need to load such utilities unless and until the user needs to load an ALC routine that needs them. That is the designed, programmed, and proper use for CALL INIT.

 

...lee

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, Lee Stewart said:

 

This is clearly NOT a bug. Both E/A’s and MiniMemory’s reason for existence is to do ALC things, so the first thing they do when powered up is to load linkable utility routines. That is NOT XB’s raison d’être! XB does not need to load such utilities unless and until the user needs to load an ALC routine that needs them. That is the designed, programmed, and proper use for CALL INIT.

 

...lee

So your belief is that XB should not be allowed to do a CALL LOAD ever unless you have a 32K?

Yet Mini Memory and EA cart do not need 32K to do a CALL LOAD?

This sounds as valid as the Basic Support Module was just a silly for making the same insane mistake.

 

And no that sound insanely stupid at best. 

In other post links on Atari Age I fully explained and debunked  this and do I have to show you the code to prove just how stupid this is?

It came down to 3 stupid mistakes in a row done by TI that resulted in this lack of being able to do something that clearly created more problems.

Bug found in Extended BASIC - TI-99/4A Development - AtariAge Forums

 

Lee think about other Basics that do this? Can you name one?

Share this post


Link to post
Share on other sites
56 minutes ago, senior_falcon said:

I see we're back off the rails again.

Sorry people think they know things when they actually make no sense and argue for something that is worse on purpose.

Like making something less useful is some kind of advantage.

Share this post


Link to post
Share on other sites
1 hour ago, senior_falcon said:

I see we're back off the rails again.

 

Sorry about that. |:)

 

...lee

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites

Sorry, when I talk about relocatable code, I meant code before it is linked. Once it is linked it often stops being relocatable. 

 

The reader might have thought I was talking about code skillfully crafted to never refer to its own address range. 

  • Like 2

Share this post


Link to post
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.

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...