Jump to content

Photo

'RUN' in a Program Line, XB

xb extended basic RUN

35 replies to this topic

#1 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • 1,055 posts

Posted Mon Jun 3, 2013 1:58 PM

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

#2 rocky007 OFFLINE  

rocky007

    Moonsweeper

  • 395 posts
  • Location:Belgium

Posted Mon Jun 3, 2013 3:09 PM

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 by rocky007, Mon Jun 3, 2013 3:19 PM.


#3 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,356 posts
  • Location:Germany

Posted Mon Jun 3, 2013 3:17 PM

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 by mizapf, Mon Jun 3, 2013 3:18 PM.


#4 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Mon Jun 3, 2013 3:39 PM

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

Thanks fellas!

#5 unhuman OFFLINE  

unhuman

    Stargunner

  • 1,207 posts
  • Location:Vienna, VA

Posted Mon Jun 3, 2013 3:49 PM

I remember what rocky remembers!

#6 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,356 posts
  • Location:Germany

Posted Mon Jun 3, 2013 3:57 PM

Here is the program. Texts are in German, but you should be able to figure out how it works.

Attached Files



#7 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Mon Jun 3, 2013 3:59 PM

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

#8 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Mon Jun 3, 2013 4:05 PM

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

#9 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Mon Jun 3, 2013 4:24 PM

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"

#10 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Mon Jun 3, 2013 4:36 PM

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

#11 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,356 posts
  • Location:Germany

Posted Mon Jun 3, 2013 5:16 PM

Luckily people did not try to file something like this as a patent. :-)

#12 RXB OFFLINE  

RXB

    River Patroller

  • 3,303 posts
  • Location:Vancouver, Washington, USA

Posted Mon Jun 3, 2013 6:43 PM

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

#13 RXB OFFLINE  

RXB

    River Patroller

  • 3,303 posts
  • Location:Vancouver, Washington, USA

Posted Mon Jun 3, 2013 6:47 PM

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

#14 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Mon Jun 3, 2013 9:14 PM

Nice trick but complicated as hell to remember. RXB has a single line that does it.
CALL XPPGM(F$)

Pretty slick, too :cool:

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

#15 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Mon Jun 3, 2013 11:04 PM

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

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 by RobertLM78, Mon Jun 3, 2013 11:09 PM.


#16 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,356 posts
  • Location:Germany

Posted Tue Jun 4, 2013 2:06 AM

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.

#17 kl99 OFFLINE  

kl99

    Dragonstomper

  • 842 posts
  • Location:Vienna, Austria

Posted Tue Jun 4, 2013 9:44 AM

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.

#18 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Tue Jun 4, 2013 12:23 PM

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

#19 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,241 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jun 4, 2013 1:58 PM

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

#20 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Tue Jun 4, 2013 2:41 PM

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

#21 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,241 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jun 4, 2013 2:55 PM

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

#22 RXB OFFLINE  

RXB

    River Patroller

  • 3,303 posts
  • Location:Vancouver, Washington, USA

Posted Tue Jun 4, 2013 3:44 PM

"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?

#23 RobertLM78 OFFLINE  

RobertLM78

    Stargunner

  • Topic Starter
  • 1,055 posts

Posted Tue Jun 4, 2013 6:31 PM

"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 :D).

#24 RXB OFFLINE  

RXB

    River Patroller

  • 3,303 posts
  • Location:Vancouver, Washington, USA

Posted Wed Jun 20, 2018 7:54 AM

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

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


#25 RXB OFFLINE  

RXB

    River Patroller

  • 3,303 posts
  • Location:Vancouver, Washington, USA

Posted Wed Jun 20, 2018 8:49 AM

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 by RXB, Wed Jun 20, 2018 8:52 AM.






Also tagged with one or more of these keywords: xb, extended basic, RUN

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users