+jedimatt42 Posted June 30, 2021 Author Share Posted June 30, 2021 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. 4 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 30, 2021 Share Posted June 30, 2021 (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 June 30, 2021 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 30, 2021 Share Posted June 30, 2021 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. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted June 30, 2021 Share Posted June 30, 2021 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 30, 2021 Share Posted June 30, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted June 30, 2021 Share Posted June 30, 2021 1 hour ago, senior_falcon said: takes 84 seconds Good God! Is the loader written in BASIC?? 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted June 30, 2021 Share Posted June 30, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 30, 2021 Author Share Posted June 30, 2021 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. 4 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 30, 2021 Share Posted June 30, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 30, 2021 Share Posted June 30, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 30, 2021 Share Posted June 30, 2021 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 30, 2021 Share Posted June 30, 2021 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!) 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 30, 2021 Share Posted June 30, 2021 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! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 30, 2021 Share Posted June 30, 2021 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 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 30, 2021 Share Posted June 30, 2021 I see we're back off the rails again. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 30, 2021 Share Posted June 30, 2021 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? Quote Link to comment Share on other sites More sharing options...
RXB Posted June 30, 2021 Share Posted June 30, 2021 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 30, 2021 Share Posted June 30, 2021 1 hour ago, senior_falcon said: I see we're back off the rails again. Sorry about that. ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 30, 2021 Share Posted June 30, 2021 Just now, Lee Stewart said: Sorry about that. ...lee You're not the engineer... 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted July 1, 2021 Author Share Posted July 1, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.