Jump to content
IGNORED

Chain loading XB programs


Vorticon

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

  • Like 1
Link to comment
Share on other sites

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 by senior_falcon
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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 by sometimes99er
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...