Extra large programs spanning multiple files

[sparkdrummer]

I know one thing for sure, I emptied a wine bottle once and I got hammered.

[RXB]

Easy way is use CALL MOVES the numbers in memory to Lower 8K and then when other XB program loads puts them from Lower 8K into memory and adjusts the pointers.

 

Of course this is complicated and way past the idea of XB being easy to use.

 

Easy to understand version duplicates your example:

100 DIM X(24)
110 FOR I=1 TO 24
120 X(I)=SQR(I)
130 T$=STR$(X(I))
140 CALL MOVES("$R",LEN(T$),T$,8192+(I*)
150 NEXT I
160 RUN "DSK2.TEST2"

Loads this XB program next to print like you did:

100 FOR I=1 TO 24
110 CALL MOVES("R$",8,8192+(I*,T$)
120 PRINT T$
130 NEXT I

NO ASSEMBLY REQUIRED....

 

(Added bonus is I have a full empty Lower 8K to use for Storage)

Edited October 1, 2017 by RXB

[senior_falcon]

I know one thing for sure, I emptied a wine bottle once and I got hammered.

Just once?

[sparkdrummer]

Yeah, just once. Got nailed by the police.

[senior_falcon]

Easy way is use CALL MOVES the numbers in memory to Lower 8K and then when other XB program loads puts them from Lower 8K into memory and adjusts the pointers.

 

Of course this is complicated and way past the idea of XB being easy to use.

 

Easy to understand version duplicates your example:

100 DIM X(24)
110 FOR I=1 TO 24
120 X(I)=SQR(I)
130 T$=STR$(X(I))
140 CALL MOVES("$R",LEN(T$),T$,8192+(I*)
150 NEXT I
160 RUN "DSK2.TEST2"

Loads this XB program next to print like you did:

100 FOR I=1 TO 24
110 CALL MOVES("R$",8,8192+(I*,T$)
120 PRINT T$
130 NEXT I

NO ASSEMBLY REQUIRED....

 

(Added bonus is I have a full empty Lower 8K to use for Storage)

Thanks, I can see how this would work in RXB. Not to quibble, but you do not duplicate my example. You have only read the numbers as strings and not converted them back into numbers. You could include X(I)=VAL(T$). Yet another step and, oops, it crashes when converting the integers. I have no doubt that additional lines of code could take care of that glitch, but the point is that I cannot see how this is the proper tool to use for this application. For some other application it might be the perfect tool. I have a bunch of wood planes in my shop. Usually I grab the jack plane for general purpose use, but recently I have used a 24" jointer plane, a small rabbit plane, a block plane, a compass plane and a Stanley #45 plane. The point is that you choose the right tool for the job.

 

This method I have demo'd in the video is one tool, and as with all tools there are times when it would be appropriate and times when it would not be. (By the way, I have just greatly simplified it so it can be used just like RUN DSK1.PROGRAM at any point in the program, not just at the last line)

 

I am puzzled by your antipathy towards assembly subroutines. TI included that ability in XB for a reason, and to say it is like using a wine bottle as a hammer is just plain silly. It is tedious for the assembly programmer (me), but once put into a package it is just another simple tool for the XB programmer to use. When you turn on the TI and type PRINT 3.14159*7 you are using (gasp) an assembly routine.

 

Anyhow, I will throw together a simple package in the next few days so folks can test this out. This would be used to chain together large programs and one advantage is that there is no delay for the prescan when the second program starts up.

[RXB]

Thanks, I can see how this would work in RXB. Not to quibble, but you do not duplicate my example. You have only read the numbers as strings and not converted them back into numbers. You could include X(I)=VAL(T$). Yet another step and, oops, it crashes when converting the integers. I have no doubt that additional lines of code could take care of that glitch, but the point is that I cannot see how this is the proper tool to use for this application. For some other application it might be the perfect tool. I have a bunch of wood planes in my shop. Usually I grab the jack plane for general purpose use, but recently I have used a 24" jointer plane, a small rabbit plane, a block plane, a compass plane and a Stanley #45 plane. The point is that you choose the right tool for the job.

 

This method I have demo'd in the video is one tool, and as with all tools there are times when it would be appropriate and times when it would not be. (By the way, I have just greatly simplified it so it can be used just like RUN DSK1.PROGRAM at any point in the program, not just at the last line)

 

I am puzzled by your antipathy towards assembly subroutines. TI included that ability in XB for a reason, and to say it is like using a wine bottle as a hammer is just plain silly. It is tedious for the assembly programmer (me), but once put into a package it is just another simple tool for the XB programmer to use. When you turn on the TI and type PRINT 3.14159*7 you are using (gasp) an assembly routine.

 

Anyhow, I will throw together a simple package in the next few days so folks can test this out. This would be used to chain together large programs and one advantage is that there is no delay for the prescan when the second program starts up.

XB unlike Assembly is for the novice and is easy to debug, you are making a false claim that assembly is easy to use as XB, which it clearly is not.

 

I think Assembly is great and fast, but never ever was it easy to use or easy to understand and debug, it take tons of hours to learn and use Assembly unlike XB that is BASIC for a reason.

 

Remember a quote from the Author of the Hurt Report in a article on the Husqvarna Dirt Motorcycles:

 

"People dearly love to complicate things, no one is ever fascinated with a crescent wrench."

Edited October 2, 2017 by RXB

[senior_falcon]

XB unlike Assembly is for the novice and is easy to debug, you are making a false claim that assembly is easy to use as XB, which it clearly is not.

 

I have to admit that you are right. With "The Missing Link" one draws a circle using CALL LINK("CIRCLE",ROW,COL,RADIUS). I can't imagine the average XB programmer understanding how to use this - after all, it is so much more complex than the RXB equivalent: CALL CIRCLE(ROW,COL,RADIUS)

 

If you read my post more carefully you would have seen this: "It is tedious for the assembly programmer (me), but once put into a package it is just another simple tool for the XB programmer to use". How is that a false claim?

[RXB]

I have to admit that you are right. With "The Missing Link" one draws a circle using CALL LINK("CIRCLE",ROW,COL,RADIUS). I can't imagine the average XB programmer understanding how to use this - after all, it is so much more complex than the RXB equivalent: CALL CIRCLE(ROW,COL,RADIUS)

 

If you read my post more carefully you would have seen this: "It is tedious for the assembly programmer (me), but once put into a package it is just another simple tool for the XB programmer to use". How is that a false claim?

Hmm RXB does not have CALL CIRCLE(ROW,COL,RADIUS) you are thinking of some other XB not RXB.

 

I let other Assembly packages like TML or STAR or 40COL do things like that a using Assembly they are much faster doing this then GPL, I stick to what XB/GPL is very very good at....easy to use.

 

RXB has features like SAMS support, CALL IO for direct CRU controls not using assembly and things like CALL MOVES that moves any type of memory of any type of memory of any size.

 

Or useful features like SAVE DSK2.XBPGM,IV254 that saves any XB program to IV254 format.

 

And loading Assembly support is not simple to use as it is not BUILT INTO XB, all the features I put in RXB are built in for ease of use even in a Console alone with no Expansion Memory.

 

CALL IO and CALL MOVES and most of the RXB commands work from Console only with no expansion memory. So how is that for a honest claim of ease of use?

Edited October 2, 2017 by RXB

[+Vorticon]

My game Clear For Action (you can find it on the TI Gameshelf) uses 4 separate XB programs linked together and each program would chain run one of the other programs depending on the game needs. Think of it as modules. Since character definitions are preserved between programs, I just saved the important variables and game parameters to a disk file which was shared with all the XB programs and updated by each. It worked perfectly and seamlessly.

[senior_falcon]

Here's the loader program for folks to test out. It is called Chianti. Loading it is not so difficult as Rich would have you believe. RUN "DSK2.CHIANTI" will do the trick. With this you can load and run an XB program from another XB program, which makes it possible to chain two or more programs together. The neat thing is that it bypasses the prescan which means super fast start up time and that all the variables are carried into the newly loaded program. Here's how:

 

10 !XB program lines

20 CALL LINK("LOADIV","DSK2.TEST2") will load the program TEST2 from disk 2 It can also load a string variable if it is a legal file name

30 !LOADIV does not have to be at the end of the program

 

This will only load XB programs saved in IV254 format. Normally an XB program must be around 12K for XB to save in that format. You may want to do some testing with shorter programs. Here's how to do a save in IV254 format:

From the immediate mode: CALL LINK("SAVEIV","DSK2.TEST3") will save the current XB program as TEST3 onto DSK2. This will save any length XB program as IV254, even this one line program: 1 !

 

You may also want to chain programs but run them normally. CALL LINK("RUNIV","DSK2.TEST2") will do that. This is the same as RUN DSK2.TEST2 in XB except that you can use a string variable for the file name which could be helpful in a menu program.

 

There are a couple of things that are important when you use LOADIV:

1 - The initial program in the chain does not have to be saved as IV254

2 - The program being loaded must be in IV254 format

3 - The program being loaded cannot be longer than the original XB program at the beginning of the chain. If it is then the variables will be overwritten and the program will crash. A "Memory Full" error message will be issued if the chained program is too long.

4 - The chained programs cannot introduce new variables. They must all be in the first program. I believe that you could use the feature that turns prescan on and off to be able to see variables that are not in the first program.

 

 

 

CHIANTI.zip

[senior_falcon]

There is a neat trick that really improves this loader. In my original post I thought that the last line should be 30000 CALL LINK("LOADIV","DSK2.TEST2"). One issue with this is that line 30000 is in high memory and as soon as you load the new XB program you have overwritten line 30000. My suggested fix for this was to copy line 30000 to low memory. Then when you run that line it is out of the way and you don't overwrite the GOTO 1. That is one extra step, plus you don't know if the first line number is 1. Turns out there is a much slicker way to automatically handle this. The loader program contains two XB instructions in the assembly code:

GOTO1 DATA >8286,>C900,>0100 XB line :: GOTO 1

RUNPRG DATA >82A9,>0000 XB line :: RUN

After the assembly program has loaded the new XB program it reads the first line number and plugs that into GOTO1+3 after the C9. Then it places GOTO1 or RUNPRG into the token code pointer at >832C. When you return to XB the interpreter will automatically run the XB instructions GOTO1 or RUN, depending on whether you are using LOADIV or RUNIV.

Edited October 4, 2017 by senior_falcon