RobertLM78 Posted June 3, 2013 Share Posted June 3, 2013 Howdy TIers. I hate to start a new thread, but I couldn't find a good place for it. So, I am working on a proof of concept for launching programs from a program: 100 CALL CLEAR 110 INPUT "FILENAME:":FL$ :: IF FL$="" THEN 110 120 RUN "DSK1."&FL$ But this gives * SYNTAX ERROR IN 120. However, if I change 120 to 120 PRINT "DSK1."&FL$ I get the expected string printed on the screen (i.e., if I type in LOAD for the input, I get DSK1.LOAD printed on the screen). Why does RUN not like this syntax? Is this possible through XB, or am I just wasting my time? Thanks for reading! Quote Link to comment Share on other sites More sharing options...
rocky007 Posted June 3, 2013 Share Posted June 3, 2013 (edited) if i remember well, RUN command don't accept variable, but it's possible : i remember a little directory program in XB that could start any program...The program modified the memory location of RUN "DSK1.xxxxxx" by the final program name. Edited June 3, 2013 by rocky007 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 3, 2013 Share Posted June 3, 2013 (edited) You cannot use RUN FILE$ inside a program. This may be due to RUN cleaning the variable space, so the string is lost before it can be passed to RUN. There are some specific utilities that try to fix this problem. One approach is to use a command like RUN "DSKx.XXXXXXXXXX" with a fixed string, and the actual drive number and the file name is CALL LOADed into the fixed string. Edited June 3, 2013 by mizapf Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 3, 2013 Author Share Posted June 3, 2013 You cannot use RUN FILE$ inside a program. This may be due to RUN cleaning the variable space, so the string is lost before it can be passed to RUN. There are some specific utilities that try to fix this problem. One approach is to use a command like RUN "DSKx.XXXXXXXXXX" with a fixed string, and the actual drive number and the file name is CALL LOADed into the fixed string. Interesting, I think I'm seeing what needs to be done. Incidentally, I ran the program as written with the RUN command, got the error, and then typed PRINT FL$ which printed the correct string, so if RUN cleans the variable space, it must not have been done so yet. Too bad this doesn't work like I have written- seems like it would be a really simple way of doing it, theoretically, at any rate... Well, I'll play around and see what I can come up with - I think it would be a really useful thing to figure out . Thanks fellas! Quote Link to comment Share on other sites More sharing options...
unhuman Posted June 3, 2013 Share Posted June 3, 2013 I remember what rocky remembers! Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 3, 2013 Share Posted June 3, 2013 Here is the program. Texts are in German, but you should be able to figure out how it works. apesoft.txt Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 3, 2013 Author Share Posted June 3, 2013 I remember what rocky remembers! Hmmm, so this is possible, approaching it differently. Admittedly though, I'm not quite following the 'how' here in 'modifying the memory location' (my apologies for being so thick ). Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 3, 2013 Author Share Posted June 3, 2013 Here is the program. Texts are in German, but you should be able to figure out how it works. Oh, cool.. whoops on that last post - I didn't see you'd posted this (no worries about the text - I know a little Deutsch). Thank you man! Pretty clever program that is! (I was starting to think of something along the lines of INPUTing the disk catalog like this ). Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 3, 2013 Share Posted June 3, 2013 830 CALL INIT :: CALL PEEK(-31952,A,B) :: CALL PEEK(A*256+B-65534,A,B) 840 C=A*256+B-65534 :: A$=D$&PG$(K) :: CALL LOAD(C,LEN(A$)) 850 FOR I=1 TO LEN(A$) :: CALL LOAD(C+I,ASC(SEG$(A$,I,1))) :: NEXT I :: CALL LOAD(C+I,0) 860 RUN "DSK?.-@APESOFT-" If I'm remembering my scratchpad address correctly, line 830 reads the pointer to the end of the line number table. then the next CALL PEEK reads the pointer to the actual contents of the last line. Line 840 computes C which points to DSK?.-!APESOFT- Then A$ is concatenated to make the string you want to run - let's say it is DSK1.PROGNAME Then CALL LOAD(C,LEN(A$)) writes the length byte of the string Line 850 writes the string to memory and ends by writing a zero byte. If you break the program at this point you would see that line 860 is now: 860 RUN "DSK1.PROGNAME" 1 Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 3, 2013 Author Share Posted June 3, 2013 - thanks for the analysis. It'll be useful as I break this utility down to adopt it. There are a few more things I need to learn to do in XB before moving to Assembly, and LOADing and PEEKing are at the top that list Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 3, 2013 Share Posted June 3, 2013 Luckily people did not try to file something like this as a patent. :-) Quote Link to comment Share on other sites More sharing options...
RXB Posted June 4, 2013 Share Posted June 4, 2013 Howdy TIers. I hate to start a new thread, but I couldn't find a good place for it. So, I am working on a proof of concept for launching programs from a program: 100 CALL CLEAR 110 INPUT "FILENAME:":FL$ :: IF FL$="" THEN 110 120 RUN "DSK1."&FL$ But this gives * SYNTAX ERROR IN 120. However, if I change 120 to 120 PRINT "DSK1."&FL$ I get the expected string printed on the screen (i.e., if I type in LOAD for the input, I get DSK1.LOAD printed on the screen). Why does RUN not like this syntax? Is this possible through XB, or am I just wasting my time? Thanks for reading! Ok RXB here is how it works: 100 CALL CLEAR 110 INPUT F$ :: IF F$="" THEN 110 120 CALL XBPGM(F$) But a better one in RXB is this one: 100 CALL CLEAR 110 INPUT F$ :: IF F$="" THEN 110 110 PRINT "TYPE: 1=XB 2=EA5 3=EA3" 130 CALL ONKEY("123",0,K,S) GOTO 150,160,170 140 GOTO 130 150 CALL XBPGM(F$) 160 CALL EAPGM(F$) 170 CALL EALR(F$) This RXB program runs EA5, EA3 (Load and Run) and XB or BASIC programs. Rich Quote Link to comment Share on other sites More sharing options...
RXB Posted June 4, 2013 Share Posted June 4, 2013 830 CALL INIT :: CALL PEEK(-31952,A,B) :: CALL PEEK(A*256+B-65534,A,B) 840 C=A*256+B-65534 :: A$=D$&PG$(K) :: CALL LOAD(C,LEN(A$)) 850 FOR I=1 TO LEN(A$) :: CALL LOAD(C+I,ASC(SEG$(A$,I,1))) :: NEXT I :: CALL LOAD(C+I,0) 860 RUN "DSK?.-@APESOFT-" If I'm remembering my scratchpad address correctly, line 830 reads the pointer to the end of the line number table. then the next CALL PEEK reads the pointer to the actual contents of the last line. Line 840 computes C which points to DSK?.-!APESOFT- Then A$ is concatenated to make the string you want to run - let's say it is DSK1.PROGNAME Then CALL LOAD(C,LEN(A$)) writes the length byte of the string Line 850 writes the string to memory and ends by writing a zero byte. If you break the program at this point you would see that line 860 is now: 860 RUN "DSK1.PROGNAME" Nice trick but complicated as hell to remember. RXB has a single line that does it. CALL XPPGM(F$) Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 4, 2013 Author Share Posted June 4, 2013 Nice trick but complicated as hell to remember. RXB has a single line that does it. CALL XPPGM(F$) Pretty slick, too Luckily people did not try to file something like this as a patent. :-) LOL - indeed! Although I'm definitely going to need to make changes if I want it to work as I'd like, so even if it was patented, my version would do things a bit differently . (Not really a fan of the catalog listing and then having to type a corresponding number, I'm looking to input a disk number and then simply type a filename, but I think I can get that going with the help of APE LOADER hahaha (APE LOADER - for all your ape loading needs. So easy even an APE can do it LOL). Thanks again for sharing that gem . Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 4, 2013 Author Share Posted June 4, 2013 (edited) It turns out it is ridiculously easy to change the code to get to work as wanted. I set up a FOR loop to check each element in PG$ if it's a match to the ACCEPTed input, FL$. If so, it goes on to 820, if there's no match, it CLOSEs the file and returns to 670, ready to ask for the drive number again . Awesome! Thanks Mizapf . Edit: This does beg a question though: why does such a seemingly simple operation require such intensive code? I think we can conclude that the variable space hasn't been cleared yet at the time the original program errs, so is this just "bug"/lack of ability in RUN? Edited June 4, 2013 by RobertLM78 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 4, 2013 Share Posted June 4, 2013 BTW, to make it clear this code is not from my fingers but from @APESOFT, if I recall correctly, Anna and Johann Peschetz from Austria, who were pretty productive in those times. Learned a lot from them. 1 Quote Link to comment Share on other sites More sharing options...
kl99 Posted June 4, 2013 Share Posted June 4, 2013 The man behind Apesoft Dr. Johann Peschetz actually attended the TI-99 Austria Club Meeting in May 2013. He was very kind and full of stories. He still has his whole equipment, even the TI Professional computer, that flopped afterwards. So maybe we will see some Apesoft unreleased/prototype Software. That would be nice. 2 Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 4, 2013 Author Share Posted June 4, 2013 BTW, to make it clear this code is not from my fingers but from @APESOFT, if I recall correctly, Anna and Johann Peschetz from Austria, who were pretty productive in those times. Learned a lot from them. The man behind Apesoft Dr. Johann Peschetz actually attended the TI-99 Austria Club Meeting in May 2013. He was very kind and full of stories. He still has his whole equipment, even the TI Professional computer, that flopped afterwards. So maybe we will see some Apesoft unreleased/prototype Software. That would be nice. Neat bit of history there - and I'm glad to see he's still got his equipment, as well. The program is really quite clever, so it would be great to see what other treasures they have in store . Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 4, 2013 Share Posted June 4, 2013 Edit: This does beg a question though: why does such a seemingly simple operation require such intensive code? I think we can conclude that the variable space hasn't been cleared yet at the time the original program errs, so is this just "bug"/lack of ability in RUN? I don't think there's any explicit reason, it's just the way they coded it. The parser needs to do a lot more work to handle strings or variables or combinations thereof than to just accept a literal string, and the programmer probably thought to himself "not worth the effort" (or the modern equivalent, "Why would anyone want to do that?"). As users, we disagree, of course. 1 Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 4, 2013 Author Share Posted June 4, 2013 I don't think there's any explicit reason, it's just the way they coded it. The parser needs to do a lot more work to handle strings or variables or combinations thereof than to just accept a literal string, and the programmer probably thought to himself "not worth the effort" (or the modern equivalent, "Why would anyone want to do that?"). As users, we disagree, of course. Makes sense enough to me: "not worth the effort" or "why would anyone want to do that?" - and of course, hindsight is always 20/20. Still, too bad it isn't as simple as passing a string along - made sense to me, at any rate . I've nearly gotten the APE LOADER adopted completely - there is one small problem left though: it appears color and character settings from the program I've folded the function into are being passed to the newly RUN program. So now I have to figure out how to set those back to defaults before the new program RUNS, if that's even possible... Line 840 computes C which points to DSK?.-@APESOFT- It turns out any generic string of length 10 will do (e.g., DSK?.---------- works just fine). Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 4, 2013 Share Posted June 4, 2013 I've nearly gotten the APE LOADER adopted completely - there is one small problem left though: it appears color and character settings from the program I've folded the function into are being passed to the newly RUN program. So now I have to figure out how to set those back to defaults before the new program RUNS, if that's even possible... "CALL CHARSET" will reset your character definitions (I think excluding lowercase, though...). You'll have to do colors on your own though (CALL SCREEN, and a loop with CALL COLOR will do). It can be a useful feature.. I had one program I wrote that did all the character definitions and colors in one program, then launched a new one to run the game itself (so more memory was available). Quote Link to comment Share on other sites More sharing options...
RXB Posted June 4, 2013 Share Posted June 4, 2013 "CALL CHARSET" will reset your character definitions (I think excluding lowercase, though...). You'll have to do colors on your own though (CALL SCREEN, and a loop with CALL COLOR will do). It can be a useful feature.. I had one program I wrote that did all the character definitions and colors in one program, then launched a new one to run the game itself (so more memory was available). You mean like my BLOAD that loads the entire VDP Character sets and Screen and Colors in 1 line code of RXB? Not to mention even all the Variables loaded with values before the program starts as I can save the pointer by doing that also in the RXB program. An example is save all the VDP with RXB CALL BSAVE then when you run the program with CALL BLOAD all the variables can already preloaded using Pre-Scan before the CALL BLOAD. Unless you can show me anyone else that has pulled this off I think RXB stands out ahead of all the rest. I demo this with some of the Videos I have posted. Maybe I need to do another on this function of RXB? Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted June 5, 2013 Author Share Posted June 5, 2013 "CALL CHARSET" will reset your character definitions (I think excluding lowercase, though...). You'll have to do colors on your own though (CALL SCREEN, and a loop with CALL COLOR will do). It can be a useful feature.. I had one program I wrote that did all the character definitions and colors in one program, then launched a new one to run the game itself (so more memory was available). Too bad CHARSET doesn't reset lower case letters - I thought I'd try and see if it did anyway as an "undocumented feature" but, it works exactly as you recalled (and just as the manual states, as well). Hopefully I can use these suggestions to get rid of this 'glitch'. (I do know one can just type RUN "DSK#.PROGNAME" at any time from the XB prompt (so long as the disk is in the drive), but there is something that's just cool about "launching" something from something else, specifically a file directory utility like this one that has all the program filenames right there in an array that can be searched ahead of time ). 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 20, 2018 Share Posted June 20, 2018 Too bad CHARSET doesn't reset lower case letters - I thought I'd try and see if it did anyway as an "undocumented feature" but, it works exactly as you recalled (and just as the manual states, as well). Hopefully I can use these suggestions to get rid of this 'glitch'. (I do know one can just type RUN "DSK#.PROGNAME" at any time from the XB prompt (so long as the disk is in the drive), but there is something that's just cool about "launching" something from something else, specifically a file directory utility like this one that has all the program filenames right there in an array that can be searched ahead of time ). RXB has CALL CHARSETALL this does characters 30 to 159 reset to default. (Yes RXB allows characters from 143 to 159 like TI Basic, but will interfere with sprites, but you can mix and match if careful.) Sorry to necro a old post but was working on making a new command in RXB: X$="DSK5.TESTPGM" :: RUN X$ Found token >C7 is the problem: STRINZ EQU >C7 " QUOTED STRING" But XB has defined token >C8 as: UNQSTZ EQU >C8 UNQUOTED STRING like X$ NUMZ EQU >C8 ALSO NUMERICAL STRING like 54.8 NUMCOZ EQU >C8 ALSO UNQUOTED STRING like THIS IS A TEST Quote Link to comment Share on other sites More sharing options...
RXB Posted June 20, 2018 Share Posted June 20, 2018 (edited) Ok found exactly where it crashed and why. Crash is SYNTAX ERROR but really can't figure out a workaround on this: 4370 * The LINE NUMER TABLE 4371 * All tokens which appear in the table must have numerics 4372 * which follow them crunched as line numbers. 4373 7FC8 81 LNTAB BYTE ELSEZ 4374 7FC9 85 GOZTOK BYTE GOZ 4375 7FCA 86 BYTE GOTOZ 4376 7FCB 87 BYTE GOSUBZ 4377 7FCC 88 BYTE RETURZ 4378 7FCD 8E BYTE BREAKZ 4379 7FCE 8F BYTE UNBRKZ 4380 7FCF 94 BYTE RESTOZ 4381 7FD0 A5 BYTE ERRORZ 4382 7FD1 A9 BYTE RUNZ 4383 7FD2 B0 BYTE THENZ 4384 7FD3 ED BYTE USINGZ 4385 7FD4 FF BYTE >FF Indicate end of table 4386 EVEN 4387 ************************************************************ 4388 * Table of specially crunched statements 4389 * 2 bytes - special token 4390 * Byte 1 - token value 4391 * Byte 2 - "address" of special handler 4392 * Offset from label OFFSET in this assembly of 4393 * the special case handler 4394 ************************************************************ 4395 7FD6 02 SPECTB BYTE LISTZ,CRU57-OFFSET 7FD7 0C 99/4 ASSEMBLER CRUNCHS PAGE 0099 4396 7FD8 05 BYTE OLDZ,CRU58-OFFSET 7FD9 28 4397 7FDA 07 BYTE SAVEZ,CRU58-OFFSET 7FDB 28 4398 7FDC 08 BYTE MERGEZ,CRU58-OFFSET 7FDD 28 4399 7FDE 82 BYTE SSEPZ,CRU53-OFFSET 7FDF 00 4400 7FE0 83 BYTE TREMZ,CRU74-OFFSET 7FE1 3C 4401 7FE2 93 BYTE DATAZ,CRU58-OFFSET 7FE3 28 4402 7FE4 9A BYTE REMZ,CRU74-OFFSET 7FE5 3C 4403 7FE6 9D BYTE CALLZ,CRU66-OFFSET 7FE7 6C 4404 7FE8 A1 BYTE SUBZ,CRU65-OFFSET 7FE9 5C 4405 7FEA A3 BYTE IMAGEZ,CRU54-OFFSET 7FEB 22 4406 7FEC FF BYTE >FF 4407 EVEN 4408 * 4409 * TRANSFER LOWERCASE CHARACTER TO UPPERCASE CHARACTER 4410 * R0 - Last digit indicates whether this character is a 4411 * lowercase character 4412 7FEE 0240 LOWUP ANDI R0,CPLOW*256 Is lowercase prop set? 7FF0 0100 4413 7FF2 1302 JEQ LU01 No, just return 4414 7FF4 7520 SB @CBH20,*R4 Change lower to upper 7FF6 7D65 4415 7FF8 045B LU01 RT 4416 7FFE AORG >7FFE 4417 7FFE C68C DATA >C68C 4418 ************************************************************ 4419 END Line 4382 when >C8 is used it must be followed by a line number and nothing else. If I take out Line 4382 in XB ROMs then RUN LINE NUMBER will not work???? Any ideas? Edited June 20, 2018 by RXB 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.