Jump to content

Photo

Chain loading XB programs

XB Extended Basic Chain programs

16 replies to this topic

#1 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 4:57 AM

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?



#2 TheBF ONLINE  

TheBF

    Dragonstomper

  • 987 posts
  • Location:The Great White North

Posted Sun Apr 14, 2019 6:33 AM

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.



#3 Casey OFFLINE  

Casey

    Moonsweeper

  • 340 posts

Posted Sun Apr 14, 2019 6:47 AM

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.



#4 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,487 posts
  • Location:Lansing, NY, USA

Posted Sun Apr 14, 2019 6:52 AM

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.


  • RXB likes this

#5 TheBF ONLINE  

TheBF

    Dragonstomper

  • 987 posts
  • Location:The Great White North

Posted Sun Apr 14, 2019 7:11 AM

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.



#6 TheBF ONLINE  

TheBF

    Dragonstomper

  • 987 posts
  • Location:The Great White North

Posted Sun Apr 14, 2019 7:18 AM

It looks like you had and "ahah" moment here Vorticon.  Is this relevant for your current situation?

 

http://atariage.com/...ined/?p=3213220



#7 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,487 posts
  • Location:Lansing, NY, USA

Posted Sun Apr 14, 2019 7:24 AM

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.



#8 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 7:35 AM

It looks like you had and "ahah" moment here Vorticon.  Is this relevant for your current situation?

 

http://atariage.com/...ined/?p=3213220

 

Ah! It looks like I have been there before! Funny how senility works...  :P



#9 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 7:38 AM

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



#10 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,487 posts
  • Location:Lansing, NY, USA

Posted Sun Apr 14, 2019 11:47 AM

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, Sun Apr 14, 2019 11:51 AM.


#11 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 12:17 PM

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?



#12 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,225 posts
  • Location:Denmark

Posted Sun Apr 14, 2019 1:47 PM

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
 


#13 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Sun Apr 14, 2019 3:56 PM

 

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.



#14 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 10,733 posts
  • Location:Hustisford, WI

Posted Sun Apr 14, 2019 7:04 PM

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.

#15 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,225 posts
  • Location:Denmark

Posted Sun Apr 14, 2019 10:34 PM

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, Sun Apr 14, 2019 10:36 PM.


#16 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,427 posts

Posted Mon Apr 15, 2019 12:18 AM

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.



#17 Vorticon OFFLINE  

Vorticon

    River Patroller

  • Topic Starter
  • 3,726 posts
  • Location:Eagan, MN, USA

Posted Mon Apr 15, 2019 9:10 AM

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.







Also tagged with one or more of these keywords: XB, Extended Basic, Chain programs

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users