CamTheBridge Posted January 18, 2018 Share Posted January 18, 2018 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! 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 18, 2018 Share Posted January 18, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 18, 2018 Share Posted January 18, 2018 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 . . . Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 18, 2018 Share Posted January 18, 2018 It erased my quotation marks, but you get the idea. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 18, 2018 Share Posted January 18, 2018 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 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 18, 2018 Share Posted January 18, 2018 (edited) 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 January 18, 2018 by senior_falcon 4 Quote Link to comment Share on other sites More sharing options...
CamTheBridge Posted January 18, 2018 Author Share Posted January 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 18, 2018 Share Posted January 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
Sinphaltimus Posted January 18, 2018 Share Posted January 18, 2018 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/ Quote Link to comment Share on other sites More sharing options...
Casey Posted January 18, 2018 Share Posted January 18, 2018 (edited) 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 January 19, 2018 by Casey 2 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 19, 2018 Share Posted January 19, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 19, 2018 Share Posted January 19, 2018 ^^thats the coolest way to do it^^ No doubt. Quote Link to comment Share on other sites More sharing options...
CamTheBridge Posted January 19, 2018 Author Share Posted January 19, 2018 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 Quote Link to comment Share on other sites More sharing options...
digdugnate Posted January 19, 2018 Share Posted January 19, 2018 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? Quote Link to comment Share on other sites More sharing options...
RXB Posted January 19, 2018 Share Posted January 19, 2018 (edited) 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 January 19, 2018 by RXB 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 19, 2018 Share Posted January 19, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
digdugnate Posted January 19, 2018 Share Posted January 19, 2018 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! Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 19, 2018 Share Posted January 19, 2018 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!) Quote Link to comment Share on other sites More sharing options...
RXB Posted January 20, 2018 Share Posted January 20, 2018 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. 1 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.