Jump to content
CamTheBridge

Linking Data Between Programs

Recommended Posts

Hey all,

 

I'm trying to make a really long program, so instead of actually wasting all my space with one program I have several programs daisy chained together in extended basic. So far I've had no problems, but things would be a lot less tricky if I was able to send variables between the programs.

 

From what I understand, whenever you start a new program, the variables are all wiped to zero, but you can save values in specific locations on the expanded memory (like 8199 or something like that). I also believe that you are supposed to use (in some combination) init, load, link and/or peek in order to do so, but I cannot figure out how.

 

Anyone know how to do this?

 

Thanks!

  • Like 1

Share this post


Link to post
Share on other sites

So the easiest way is to have a small data file.

 

-At the end of program 1, OPEN the data file and save your variables., then CLOSE your data file.

 

-Then daisy chain into program 2. At the start of program 2, OPEN the data file and input the data from the data file, then CLOSE your data file.

 

-Then at the end of program 2, OPEN the data file and save your variables, the CLOSE your data file.

 

 

 

Rinse and repeat.

  • Like 2

Share this post


Link to post
Share on other sites

As an example:

 

Program #1:

 

.

.

.

1040 OPEN #1:DSK1.VARS

1050 PRINT #1:A,B,C,A$,B$,C$

1060 CLOSE #1

1070 RUN DSK1.PROGRAM2

 

 

Program #2:

 

100 OPEN #1DSK1.VARS

110 INPUT #1:A,B,C,A$,B$,C$

120 CLOSE #1

.

.

.

Share this post


Link to post
Share on other sites

You can also use XB subprograms saved with the MERGE option on disk to be MERGEd at different times with the main program in an overlay structure. This MERGE process will not clear variable values from the main program. This process is explained fairly well in the XB Manual.

 

...lee

Share this post


Link to post
Share on other sites

You can also use XB subprograms saved with the MERGE option on disk to be MERGEd at different times with the main program in an overlay structure. This MERGE process will not clear variable values from the main program. This process is explained fairly well in the XB Manual.

 

...lee

Merge is a command that can be used from the immediate (command line) mode, but if I understand the manual correctly cannot be used as a statement in a running program.

A couple of months ago I was experimenting with assembly subroutines that let a running program load additional programs and keep running without effecting any of the variables; they just get passed along without any change. The other thing I was going to work on was a way to let XB have a single program of around 30K long. When my updated compiler is released in the next couple of days I will have time to go back and look at this.

 

edit-see post 22 of "Extra large programs spanning multiple files" in TI99/4A development.

Edited by senior_falcon
  • Like 4

Share this post


Link to post
Share on other sites

Wow, thank you all so much! I love how fast getting a response on this forum can be. I wasn't expecting anything until at LEAST later tonight when it would be later on the West Coast. I'll try these methods out and figure out what works best.

Share this post


Link to post
Share on other sites

I think youll find the cleanest method to be the data file. It is hyper fast when using a disk system, and you can use TI99Dir to inspect your data files so you can physically see how the computer saves your data.

 

Using DISPLAY with the OPEN statement will save your numeric variable data in plain numberseasy to see and understand.

 

If you use INTERNAL, it will code your data in a way that is not easy to understand at first glance. This is good for game distribution.

Share this post


Link to post
Share on other sites

you can take a look at my code here (see last post about a bug) - I haven't uploaded the latest version yet but the concept is there and working fairly well when not using dropbox.

OK, confused?Dropbox? Heh, I use multiple shared data files to store given variables that two different classic99 sessions share to play a number guessing game head to head two player.

http://atariage.com/forums/topic/273950-classic99-versus-classic99-head-to-head-turn-based-game-demo/

Share this post


Link to post
Share on other sites

One caveat with variables in data files.

 

If you use INTERNAL, you can do a simple PRINT #1:A$,B,C

 

If you use DISPLAY, you need to add commas to the output: PRINT #1:A$;",";B;",";C

 

The reason for this is when you use INPUT #1 in the second program and the file type is DISPLAY, you have to have them in the format that an INPUT from the keyboard expects them (with the commas separating the fields.)

 

Here's a sample program that demonstrates the problem:

10 OPEN #1:"DSK1.TEST",OUTPUT,INTERNAL,VARIABLE
20 A$="TEST RECORD"
30 B=45
40 C=1
50 PRINT #1:A$,B,C
60 CLOSE #1
70 STOP
100 OPEN #2:"DSK1.TEST",INPUT,INTERNAL,VARIABLE
110 INPUT #2:D$,E,F
120 PRINT D$,E,F
130 CLOSE #2

Run this - the program will create a sample file and then stop. Then RUN 100 and you'll see the data come back in. Next, change line 10 and 100 - replacing INTERNAL with DISPLAY. Repeat the test - RUN the program, then when it stops, RUN 100. It will fail with an I/O ERROR 25 IN 110.

 

Then change line 50 to: PRINT #1:A$;",";B;",";C

Repeat the test - RUN and then RUN 100 - this time it works.

 

You just need to be careful when using DISPLAY with disk files and then using INPUT # to retrieve the data - it needs to be PRINTed in the proper format. Using INTERNAL avoids all that.

 

For the record, most other computers of the era only had what TI calls "DISPLAY" format, so this method with the commas was required. Commodore BASIC for sure was one example that needed it.

Edited by Casey
  • Like 2

Share this post


Link to post
Share on other sites

I often pass integer values back and forth by loading them into memory at the 'bottom' of the PROGRAM space in expansion ram.

 

CALL LOAD(-24576,1,2,3,4,5) would load values 1,2,3,4,5 into locations -24576,-24575,-24574,-24573, -24572, respectively.

 

CALL PEEK(-24576,a,b,c,d,e) would retrieve the values.

 

The values are each 8-bit, meaning decimal 0-255. Larger numbers require some division and multiplication to store and retreive. You can even store strings by saving the length and each character to an address.

 

This works so long as your program and run-time numeric variable space do not consume the same memory - you'd have to write a very large program or use a large numeric array to do that.

 

Saving to disk works very well, too, but I find for simple values the memory works just fine.

  • Like 2

Share this post


Link to post
Share on other sites

I often pass integer values back and forth by loading them into memory at the 'bottom' of the PROGRAM space in expansion ram.

 

CALL LOAD(-24576,1,2,3,4,5) would load values 1,2,3,4,5 into locations -24576,-24575,-24574,-24573, -24572, respectively.

 

CALL PEEK(-24576,a,b,c,d,e) would retrieve the values.

 

The values are each 8-bit, meaning decimal 0-255. Larger numbers require some division and multiplication to store and retreive. You can even store strings by saving the length and each character to an address.

 

This works so long as your program and run-time numeric variable space do not consume the same memory - you'd have to write a very large program or use a large numeric array to do that.

 

Saving to disk works very well, too, but I find for simple values the memory works just fine.

Wow, this method works so well. Thanks so much! This is definitely what I'm going to use

Share this post


Link to post
Share on other sites

so piggybacking on this thread, if i wanted to make a program that defined musical frequencies and rests as variables, i could use a program to store the data and then load it from the program that plays the notes?

Share this post


Link to post
Share on other sites

Hey all,

 

I'm trying to make a really long program, so instead of actually wasting all my space with one program I have several programs daisy chained together in extended basic. So far I've had no problems, but things would be a lot less tricky if I was able to send variables between the programs.

 

From what I understand, whenever you start a new program, the variables are all wiped to zero, but you can save values in specific locations on the expanded memory (like 8199 or something like that). I also believe that you are supposed to use (in some combination) init, load, link and/or peek in order to do so, but I cannot figure out how.

 

Anyone know how to do this?

 

Thanks!

Now RXB since 2001 has had CALL BLOAD and CALL BSAVE that LOAD/SAVE the Lower 8K as Program Image files.

It is way faster then CALL LOAD or SYSTEX versions.

It is useful for loading or saving the SAMS memory or even with just a 32K allows mulitple loading or saving of Lower 8K.

 

Also I explain it has many other uses including saving variables.

 

Edited by RXB
  • Like 1

Share this post


Link to post
Share on other sites

so piggybacking on this thread, if i wanted to make a program that defined musical frequencies and rests as variables, i could use a program to store the data and then load it from the program that plays the notes?

Download "Chianti" from post 35 of "Extra large programs spanning multiple files" in TI99/4A development. This is thinking outside the box a little bit. Instead of storing variables and retrieving them later, using this method makes every variable and every string available to the new program immediately, without having to save and retrieve them. At some point soon I will revise "Chianti" with a fast loader and the ability to run a 30K long XB program.

  • Like 2

Share this post


Link to post
Share on other sites

oh, cool! i'll go over to the dev thread and check it out.

 

ive been trying to reverse-engineer some of my dad's stuff but i've got to analyze the process a little more.

 

apologies for thread-jacking!

Share this post


Link to post
Share on other sites

I have never looked closely enough to determine if these are possible in TI BASIC or Extended BASIC:

 

On the C64 I change the top of memory pointers to preserve variables. Before loading a new program I copy to start of variables pointers to another location (easy to do with PEEK and POKE) then set them to the top of BASIC, essentially eliminating the variable storage space so far as BASIC is concerned. Then after loading the new program I set those values back and there are all my variables. This was my idea but I could not get it to work properly, and I want to say I read an article in RUN or COMPUTE! magazine which showed me what I was doing wrong.

 

In my BBS program, since CBM BASIC memory is only ~37k in a 64k system, I initialize variables with default values and then copy the variable table to another section of RAM. I use the table copy to update itself or restore the variable table when necessary (also a way to cheat a fast garbage collection, just wipe everything out!)

Share this post


Link to post
Share on other sites

A RXB way is if you make all the XB programs 8K you can save them into Lower 8K using XBRAMDISK and run them in chains

using SAMS and CALL AMSBANK(#lowpage,#highpage) so with 960K available you could chain a ton of XB programs all from SAMS.

  • Like 1

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...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...