+Vorticon Posted April 14, 2019 Share Posted April 14, 2019 Hi. When chain-loading XB programs, my usual process has been to save the variables to disk before loading the next program then retrieving them back. I was thinking, since low memory is preserved in XB during that process, why not use CALL LOAD to save the variables to low memory and retrieve them subsequently with a CALL PEEK? This would speed up the process tremendously. Am I missing something here? Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 14, 2019 Share Posted April 14, 2019 Hi. When chain-loading XB programs, my usual process has been to save the variables to disk before loading the next program then retrieving them back. I was thinking, since low memory is preserved in XB during that process, why not use CALL LOAD to save the variables to low memory and retrieve them subsequently with a CALL PEEK? This would speed up the process tremendously. Am I missing something here? From my limited understanding you are on to something. Unless you need a large amount of assembly code to go there, any other use is up to you. You will have to stay away from the resident stuff at the bottom of course. Quote Link to comment Share on other sites More sharing options...
Casey Posted April 14, 2019 Share Posted April 14, 2019 This reminds me of an article in one of COMPUTE!'s TI books about using CALL CHAR and CALL CHARPAT to pass variables and values from one program to the next since the character definitions are not replaced when RUN is used within a program. Probably wouldn't work if you had a lot of values to pass, but for a few values, it would work also for a few variables. 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 14, 2019 Share Posted April 14, 2019 That should work provided they are integers from 0 to 255. If the number is greater than 255 then it would need to be divided into a high and low byte which would take time. And of course, when you read them you would have to read both bytes and reassemble the word. Floating point would not be practical with this method. If your intention is to compile the program, and if you want to put the runtime routines into low memory, then there is a problem. The entire low memory is saved in the first section of code. When it is loaded back to low memory, the entire low memory is loaded which would overwrite the stored values. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 14, 2019 Share Posted April 14, 2019 Based on the expert comments and caveats, perhaps a solution would be to write a "saver" and a "loader" in Assembly Language that puts your data in a free block of VDP RAM. You could use the program load/save functions to "blit" this data to and from file and CPU RAM almost instantly. Lee and I do this for Font saving and restoring in Forth. The challenges of integrating that into the BASIC or compiled BASIC environment are above my pay grade. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 14, 2019 Share Posted April 14, 2019 It looks like you had and "ahah" moment here Vorticon. Is this relevant for your current situation? http://atariage.com/forums/topic/236923-what-is-retained/?p=3213220 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 14, 2019 Share Posted April 14, 2019 If you don't intend to compile the program then XB256 offers a way to chain programs while automatically retaining every numeric and string variable. No need to pass the variables; they are there automatically. I didn't suggest this earlier because I assumed you would be compiling. 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 14, 2019 Author Share Posted April 14, 2019 It looks like you had and "ahah" moment here Vorticon. Is this relevant for your current situation? http://atariage.com/forums/topic/236923-what-is-retained/?p=3213220 Ah! It looks like I have been there before! Funny how senility works... 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 14, 2019 Author Share Posted April 14, 2019 That should work provided they are integers from 0 to 255. If the number is greater than 255 then it would need to be divided into a high and low byte which would take time. And of course, when you read them you would have to read both bytes and reassemble the word. Floating point would not be practical with this method. If your intention is to compile the program, and if you want to put the runtime routines into low memory, then there is a problem. The entire low memory is saved in the first section of code. When it is loaded back to low memory, the entire low memory is loaded which would overwrite the stored values. These are serious limitations. However, they could be overcome with a little assembly support. But then, if I'm going to do that, I might as well use XB256 and not re-invent the wheel 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 14, 2019 Share Posted April 14, 2019 (edited) I don't think it would be too difficult to change the loader a bit so it only saves and loads the runtime routines without overwriting all of low memory. XB256 can chain programs in XB and retain the variables. This is not an option when you chain conpiled versions. For that you would have to save to disk, store in CPU memory, or store in VDP memory. Edited April 14, 2019 by senior_falcon Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 14, 2019 Author Share Posted April 14, 2019 Or SAMS. One question: do the runtime utilities of the XB compiler use all of the low memory or is there room for some user created assembly support routines? Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted April 14, 2019 Share Posted April 14, 2019 This seems to work for whole numbers in the range from 0 to 9999999999. 100 input a 110 b$=str$(a) 120 c$=rpt$("0",16-len(b$))&b$ 130 call char(96,c$) 140 call charpat(96,d$) 150 print val(d$) run 4 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 14, 2019 Author Share Posted April 14, 2019 This seems to work for whole numbers in the range from 0 to 9999999999. 100 input a 110 b$=str$(a) 120 c$=rpt$("0",16-len(b$))&b$ 130 call char(96,c$) 140 call charpat(96,d$) 150 print val(d$) run The think is will it be faster than disk access given all the processing needed for each number? I have a feeling it will be slower. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted April 15, 2019 Share Posted April 15, 2019 I find disk storage works fine, and only really costs a second or two. I've been down this road, and have chosen to use disk. I did this with Werewolves, and I do it with my Beryl Reichardt demo as well. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted April 15, 2019 Share Posted April 15, 2019 (edited) The think is will it be faster than disk access given all the processing needed for each number? I have a feeling it will be slower. Yes, I think it's much faster, but as Owen says, a few seconds more for disk storage may not matter. It was only an alternative to the suggested byte based storage via character patterns. Also I rolled out the code a bit, so it'd be easier to follow. Edited April 15, 2019 by sometimes99er Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 15, 2019 Share Posted April 15, 2019 Hi. When chain-loading XB programs, my usual process has been to save the variables to disk before loading the next program then retrieving them back. I was thinking, since low memory is preserved in XB during that process, why not use CALL LOAD to save the variables to low memory and retrieve them subsequently with a CALL PEEK? This would speed up the process tremendously. Am I missing something here? I do quite a bit of this in Heatwave's programs, both to save simple variables and to leverage a single loader to launch all programs. I use memory starting at >A000 since none of my programs+numerics are exactly 24k For example, I use one loader program that contains all of the "RUN" statements. To chain to another program, I CALL LOAD with the number representing the program I want to load; launch the loader, CALL PEEK the value, and do an ON GOTO to the right RUN statement. Saves me (and others) from modifying paths all over the place in every program. There are also ways to RUN programs via a string or via assembly (thanks SeniorFalcon) which I employ to launch the loader. I save the path into low memory using a STRREF link so that the assembly run routine knows where my loader is located. Stops me from having to edit that one, last path per program I have also used a configuration file and a RUN String routine for some programs but had to be careful due to error trapping and it adds another level. I guess the nice thing is you can be creative in your uses of memory, from the simple to complex. (I just use standard XB cartridge and no compiling) Edit: lol, I saw TheBF's link just now as well. Forgot about that thread myself. 3 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 15, 2019 Author Share Posted April 15, 2019 I do quite a bit of this in Heatwave's programs, both to save simple variables and to leverage a single loader to launch all programs. I use memory starting at >A000 since none of my programs+numerics are exactly 24k For example, I use one loader program that contains all of the "RUN" statements. To chain to another program, I CALL LOAD with the number representing the program I want to load; launch the loader, CALL PEEK the value, and do an ON GOTO to the right RUN statement. Saves me (and others) from modifying paths all over the place in every program. There are also ways to RUN programs via a string or via assembly (thanks SeniorFalcon) which I employ to launch the loader. I save the path into low memory using a STRREF link so that the assembly run routine knows where my loader is located. Stops me from having to edit that one, last path per program I have also used a configuration file and a RUN String routine for some programs but had to be careful due to error trapping and it adds another level. I would love to see a tutorial on this some day. 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.