senior_falcon

I have played around with this a bit, hoping to come up with a way to get sprites that you can control with TI BASIC. The idea is that you could define a few sprites using CALL COLOR, and change the motion table with CALL CHAR(143) and higher. Start with this program: 10 A$="NOW IS THE TIME FOR ALL GOOD MEN TO COME T " I used the debugger to modify the space after the final T to be >10. This byte will wind up at >837A which is the maximum number of sprites in motion. For testing you could leave this as a space to allow movement of 32 sprites. Save it. 10+down arrow to edit line 10. Change A$ to B$ and enter. Then enter A= and the sprites will appear on the screen. Two important things have happened. v0300 is now F0 so now sprites are enabled, and >837A is >10 to allow sprite motion. Enter NEW. BASIC doesn't restore v0300 and >837A because it thinks they cannot be changed. The top of memory pointer at >8370 is wrong and needs to be reset. CALL FILES(1) or (3) will reset the memory pointer at >8370 CALL COLOR works as expected. But if you try CALL CHAR(143,"1111") you get an INCORRECT STATEMENT message. If you run 10 A$="Hello World" 20 GOTO 10 the debugger shows everything normally until the screen gets colorful. Evidently it is not doing the garbage collection and is just plowing through the color table and other VDP areas. So I have come to believe that not much useful can come from this. I suppose you could have a program that preloaded the color table and the pattern table to define sprites and their motion, then modify line 10 and do A= to demo some sprites. But I think BASIC is damaged enough to be unusable for anything but the simplest of programs.

"I can use XMLLNK >0006 instead of the GPLLNK >14 call" Is this XMLLNK available in XB?

I haven't totally worked through your program, but I'm pretty sure what is happening is that you are moving the 11 bytes of the string to the buffer at >A000, then writing the length byte to the first byte of the buffer. I believe there is a leading space in the string that you are overwriting with the length byte. I bet if you make the number negative, you will overwrite the minus sign and it will look like a positive number. You are moving the first byte of the string to >A000. It should be at >A001, with the length byte at >A000. Try it my way and I bet it works. As a side note, once you do the number to string conversion, move it into the buffer as soon as possible. The string is somewhere in the scratchpad, and who know what memory areas are used when you do the XMLLNK and the NUMASG. They could easily corrupt the string

Looks like there are a bunch of things that can cause this. Z$="ZZZZ a bunch of them ZZZZ" (Around 60 is the magic number) A=+ will crash it. Using the debugger, you can see the DO at v0300 becomes something else - B0 or F0, which allows sprites to appear. When it crashes, there is all sorts of activity in v0300 to v0400 and sometimes activity in v0400 to v0500 which makes the characters do strange things. This is not restricted to BASIC. XB, XB 2.9 G.E.M., and RXB also do this, although the screen looks a little different. It doesn't seem to be taking over the scratchpad. I suspect it is mostly a curiosity and not of practical use. I was trying to get the bug to enable the sprites by writing something other than D0 to v0300, but could find no way to regain control of the computer.

Now I see what is going wrong. I had one part of the answer, Lee had another, but wait, there's more. Here is your code: LI R1,PAD * CALC STRING A @FAC11,R1 * LOCATION LI R2,TXTBUF * COPY STRING MOVB @FAC12,R3 * TO TXTBUF LOOP MOVB *R1+,*R2+ DEC R3 JNE LOOP MOVB @FAC12,R4 * SET LEN BYTE SWPB R4 * FOR TXTBUF DEC R4 * STRING TO SWPB R4 * @FAC12-1 MOVB R4,@TXTBUF This should be: (I did not test this so there might be an error) LI R1,>0083 pad with bytes reversed MOVB @FAC11,R1 SWPB R1 now R1 points to string LI R2,TXTBUF MOVB @FAC12,R3 now length is in MSB of R3 MOVB R3,*R2+ put length byte at beginning of TXTBUF SRL R3,8 now length is in LSB of R3 and can use as a counter LOOP MOVB *R1+,*R2+ DEC R3 JNE LOOP Also, you do not need to store R11 and then restore it. As a side note, I do not like the use of RT because I feel it obscures what is actually happening. For me, B *R11 is much clearer. If you needed to store R11, you could MOV R11,R10 and when it is time to return just B *R10

I see one error in your code: LI R1,PAD * CALC STRING A @FAC11,R1 * LOCATION FAC11 is an odd address, so I think A @FAC11,R1 really does A @FAC10,R1 Various ways to handle this. One would be: CLR R1 MOVB @FAC11,R1 SWPB R1 AI R1,>8300 LI R1,>0083 MOVB @FAC11,R1 SWPB R1 or LI R1,PAD AB @FAC11,@WKSP+3 Here you need to know the workspace, which is a good thing to know anyway. My notes do not show any of the problems you report. I can test some tonight. Are you using this with XB. EA basic, or MiniMem basic?

314,000! I bow down before my master. Back in 1985, I wrote down my high scores in the manual 82,900 on 1/2/85 129,100 on 1/4/85 174,300 on 1/8/85 298,300 on 2/22/85 I never got close to that score again, and now I'd be lucky to get to 20,000. Always used the keyboard because of the need to select lift 1, 2, or 3.

Here BASIC has the speed advantage over XB: BASIC 1.49E-8 years Extended BASIC 1.88E-8 years

If I understand your question correctly, you want to pass a number from XB to an assembly subroutine, then convert it into an integer, do some operation on it, then convert back to floating point and return the number to XB If so, here is a simple example of how to do this. The assembly subroutine TEST gets NUMBER1 from XB, converts to integer, adds 99, converts to floating point, returns the number to XB as NUMBER2, then returns to XB CALL LINK("TEST",3.14159,X)::PRINT X (X will be 102) *test of CFI and CIF *CALL LINK("TEST",NUMBER1,NUMBER2) *NUMBER1 IS FETCHED BY ASSEMBLY ROUTINE, CONVERTED TO INTEGER *99 IS ADDED, CONVERTED BACK TO FLOATING, THEN RETURNED TO XB AS NUMBER2 XMLLNK EQU >2018 NUMREF EQU >200C NUMASG EQU >2008 FAC EQU >834A DEF TEST TEST LWPI WKSP CLR R0 LI R1,1 f irst item in argument list BLWP @NUMREF now number1 is in FAC as floating point BLWP @XMLLNK DATA >12B8 CFI now number is an integer LI R5,99 A R5,@FAC add 99 to integer BLWP @XMLLNK DATA >0020 CIF number is floating point here INC R1 second item in argument list BLWP @NUMASG send the number back to XB LWPI >83E0 B @>006A WKSP BSS 32 END

For CIF (Convert Integer to Floating Point) Page 261 of the E/A Manual says It is not loaded by the TI Extended BASIC Loader and may not be used in T I Extended BASIC. But in the TI Extended BASIC Equates on pages 415 to 418 of the E/A Manual shows that CIF EQU >20 (page 416) So I dunno. I never had occasion to use this.

That is a very TI99 type font, with the small capital letters instead of lower case.

You are right, it does not stop. With ON WARNING STOP then it halts when the number is too big. As you wrote the program it would take an estimated 1E-8 years.

I punched a few numbers into the calculator on my phone. With what I found there, and Tursi's estimate at the beginning of the thread, I would guess that it would take about 1/10000000 or 1E-7 years (edit) I misinterpreted line 120 in the program, so my answer is quite a bit off. If you make line 120 GOTO 110 then my answer is pretty close.

So it looks like you can get up to 99999999999999 before adding 1 has no effect. I didn't time it, but let's say the TI can add 1 and print 10x per second. (I didn't time this) At that rate it would take only 317,098 years to get there. There is hope, but be sure to have a good battery backup. I'd hate to see you get to 300,000 years and have the power go out.

Proof of concept. Running in CPU overdrive, but the program could be compiled and not need that.