Bones-69

Try CALL LOAD(-31931,0)

What I usually do is write a piece of code and increment a variable in a loop for a minute or so. When the minute is up I stop the program and examine the value of the variable. I will then re-write the code a few times with different ideas and do the same test. Sometimes I am very surprised by the results and can pick-up 20% speed from writing something differently, even though I thought the first code was pretty slick. I am not sure how much difference this makes once the program is finished and is executed, but I guess as a cumulative effect throughout the program it should be noticeable.

I stand corrected!!

Not sure how to take this one. I am an Aussie and my threshold offence level is calibrated at quite a distasteful high.

I agree, DISPLAY AT rocks. RXB has something similar called HPUT but it allows you to use the additional 4 screen characters that XB DISPLAY AT doesn't. Even better, RXB HGET & VGET (similar to GCHAR but can fetch 255 characters in a single command), combined with HPUT & VPUT really opens the doors for some creative BASIC programming. I totally dig RXB and wish this was TI's version of XB. There are only a handful of additional commands in RXB but is makes so much difference to what you are able to do with BASIC programming. Oooops... Off topic.

Tombstone City was my first ever TI cartridge. As much as I try, I could never hate that game.

This question is right out of my league but if it was/is possible it would have rocked the world of a lot of early TI users with basic set-ups.

That is mad. I SO have to learn assembly one of these days....

Good catch. thanks for that.

Whoops! * Attachment gone wrong.

I managed to speed it up a little. Almost smooth now, but at the cost of a little more memory... 100 ! XB-SCROLL-2 110 ! BONES 120 DIM C$(32) :: CALL CLEAR :: DISPLAY AT(2,11):"XB-SCROLL" :: CALL CHAR(128,RPT$("F",16),129,"00C0E0FEC778") 130 FOR I=96 TO 127 STEP 4 :: READ A$ :: CALL CHAR(I,A$) :: A=A+1 :: FOR D=0 TO 3 :: B$(A)=B$(A)&CHR$(I+D) :: NEXT D :: NEXT I 140 DISPLAY AT(16,1):RPT$(B$(1),7);RPT$(CHR$(128),224) :: A=0 150 FOR I=1 TO 8 :: B$(I)=SEG$(B$(I),2,3)&SEG$(B$(I),1,1) :: A=A+1 :: C$(A)=RPT$(B$(I),7) :: IF A=32 THEN 170 160 NEXT I :: GOTO 150 170 FOR I=1 TO 32 :: DISPLAY AT(16,1):C$(I) :: NEXT I :: GOTO 170 180 DATA 0000001D3F7FFFFF002078FDFFFFFFFF000E3FFFFFFFFFFF0000C0E0F0FEFFFF,0000003B7FFFFFFF0040F0FBFFFFFFFF001C7FFFFFFFFFFF000080C0E0FCFFFF 190 DATA 00000177FFFFFFFF0080E0F7FFFFFFFF0038FFFFFFFFFFFF00000080C0F9FFFF,000103EFFFFFFFFF0000C1EFFFFFFFFF0070FEFFFFFFFFFF0000000081F3FFFF 200 DATA 000207DFFFFFFFFF000083DFFFFFFFFF00E0FCFEFFFFFFFF0000000103E7FFFF,00040FBFFFFFFFFF000107BFFFFFFFFF00C0F8FCFEFFFFFF0000000307CFFFFF 210 DATA 00081E7FFFFFFFFF00030F7FFFFFFFFF0080F0F8FCFFFFFF000000070F9FFFFF,00103CFEFFFFFFFF00071FFFFFFFFFFF0000E0F0F8FFFFFF0000000E1F3FFFFF

I suspect I could speed the scrolling up, and therefore the smoothness, by at least double (maybe more) - at the cost of a longer program initialisation and using more memory by converting the entire process to strings in advance and then just calling each string in a loop rather than calculating the display each time. I will throw something together later as an example.... In a program environment (if memory allowed), it would certainly be the better way to do it.

I can't compete with you Assembly gurus but here is a little XB routine that I developed to use with a game I am developing at the moment (on and off anyway....). For the purpose of this thread I named it XB-SCROLL. This is my best attempt at "high res" smooth scrolling in BASIC. 1 ! XB-SCROLL 100 CALL CLEAR :: DISPLAY AT(2,11):"XB-SCROLL" :: CALL CHAR(128,RPT$("F",16),129,"00C0E0FEC778") 110 FOR I=96 TO 127 STEP 4 :: READ A$ :: CALL CHAR(I,A$) :: A=A+1 :: FOR D=0 TO 3 :: B$(A)=B$(A)&CHR$(I+D) :: NEXT D :: NEXT I 120 DISPLAY AT(16,1):RPT$(B$(1),7);RPT$(CHR$(128),224) :: CALL SPRITE(#1,129,16,100,30) 130 FOR I=1 TO 8 :: DISPLAY AT(16,1):RPT$(B$(I),7) :: B$(I)=SEG$(B$(I),2,3)&SEG$(B$(I),1,1) :: NEXT I :: GOTO 130 140 DATA 0000001D3F7FFFFF002078FDFFFFFFFF000E3FFFFFFFFFFF0000C0E0F0FEFFFF,0000003B7FFFFFFF0040F0FBFFFFFFFF001C7FFFFFFFFFFF000080C0E0FCFFFF 150 DATA 00000177FFFFFFFF0080E0F7FFFFFFFF0038FFFFFFFFFFFF00000080C0F9FFFF,000103EFFFFFFFFF0000C1EFFFFFFFFF0070FEFFFFFFFFFF0000000081F3FFFF 160 DATA 000207DFFFFFFFFF000083DFFFFFFFFF00E0FCFEFFFFFFFF0000000103E7FFFF,00040FBFFFFFFFFF000107BFFFFFFFFF00C0F8FCFEFFFFFF0000000307CFFFFF 170 DATA 00081E7FFFFFFFFF00030F7FFFFFFFFF0080F0F8FCFFFFFF000000070F9FFFFF,00103CFEFFFFFFFF00071FFFFFFFFFFF0000E0F0F8FFFFFF0000000E1F3FFFFF

I came in after the SSGC concept. We so need to do this again!

I agree, strings are bloody awesome! I simply can't imagine programming anything now without manipulating these in some form or another. In regards to your RXB comments, I hear what you say but I do believe writing the program with RXB will produce a much better end prouct - in particular I am extensively using; CALL HPUT (simlar to XB DISPLAY AT but allows access to rows 1 & 2 plus 31 & 34) CALL HGET (which allows you to do screen grabs) Access to use of characters 143-159 The DOS like functions With a couple of years work already sunk into LGB I have come too far to turn back now. My single use of HPUT would mean having to redesign hundreds of hours of work for example... On the up side, RXB is freely available for WIN99/4a which is what I am writing it with. I realise for many this is not the TI emulator of choice but this was the first one I found and the one I started using from day one. I actually remember in the early days sitting down with RXB, Super XB, Mechatronix XB2 and standard XB (all which were available with WIN99/4a). and going through each additional function trying to work out which BASIC would serve my project best. RXB came out the winner. * CALL HONK & CALL BEEP are built in RXB routines.

I have really struggled with memory (stack and program space) since starting this program. Being a rather complex and large adventure game I am demanding a lot from the memory. It's a case of milking every last bit I can. However, from my testing along the way the current method is not at all a bad one.... There is really no compromise in execution speed and I still end up saving some precious memory. In my earlier testing where this data was stored in a strings it was like somebody pulled the plug on my stack space.

I read my post again and wasn't completely happy with the clarity so thought an example might be better. Obviously this example is missing much of the backbone and won't work when typed in, but most XB users should be able to get the gist of it. Just going from memory here.. Hope there are no silly mistakes. 10 READ S(1),S(2), S(3), S(4) 100 A=S(2) :: GOSUB 500 110 BLAH BLAH BLAH 120 A=S(1) :: GOSUB 500 130 BLAH BLAH BLAH 140 FOR X=1 TO 4:: A=S(X)::GOSUB 500::NEXT X 150 END 500 A$=STR$(A) 510 B=VAL(SEG$(A$,1,4))-1000 !DEFINE STARTING REC NUMBER 510 C=VAL(SEG$(A$,5,2)) !DEFINE NUMBER OF LINES TO READ 520 D=VAL(SEG$(A$,7,2)) !DEFINE STARTING ROW FOR DISPLAY 530 E=VAL(SEG$(A$,9,1)) !DEFINE SOUND 540 F=VAL(SEG$(A$,10,1)) !DEFINE DELAY 550 FOR I=B TO B+C :: INPUT #1, REC I:B$ :: CALL HPUT(D+G,1,SEG$(B$,1,32)):: G=G+1 :: NEXT I 560 IF E=1 THEN CALL HONK ELSE IF E=2 THEN CALL BEEP 570 FOR I=1 TO F*320::NEXT I 580 G=0 :: RETURN 1000 DATA 1050320100, 1120101019, 1350051200, 1240012419 * REC I contains screen data to be displayed on each line

OK… Your token comment has answered all. That now makes complete sense! Thank-you. In regards to the 100 characters of parameters… this is not the case. I probably wasn’t clear enough. S(n) actually refers to the screen to be drawn (where n is screen 1). So S(100) is screen 100. Screens can be drawn from scratch or individual sections of the screen can be updated/re-drawn as required. In any case, each instance of S(n) contains enough data to draw 1 or all 32 lines to the screen. S(n) will be defined as part of the program initialization process. In the instance of S(100) where the value is equal to -1010071012, the program will process the data something like the following. * If the value is <0 then graphical processing is required (handled later in routine) * Convert ABS(S(100)) to a string, so A$=”1010071012” * Start splitting string up and allocating values with the following uses; Value 1010-1000 *First/starting REC (10 in this example), to read from DSK1 Value 07 *Number of Records to read (or number of lines to display). Really just sets up the loop to read and display each rocord/line. Value 10 *First Row to start HPUT command Value 1 * HONK (1) or BEEP (2) or NONE (0) after last line displayed on screen Value 2 * Delay loop after last line displayed. (FOR/NEXT delay where delay loop is value x 320. Value determines seconds. 0 is no delay) Additional graphical information (if required), is flagged by the contents of the record read. Effectively this method allows me to display infinite screens of data (full screens or partial screens), for the price of a single 10 digit variable which only costs me a few bytes of RAM. Not sure if this method is clear but I have found it to be very RAM conservative, occupy very little program space and executes pretty quickly (the slowest part is the time it takes to read each line from DSK1 - not the actual program processing time as variables are only defined and processed once during each new screen). About the only real cost is the data in the DSK1 record which is always 32 characters long. This is resulting in quite a large DSK1 data file but I don't consider this too wasteful. I see this whole idea as working well for my application. In many instances I will be able to set up several screens in a loop (with a CALL KEY between screen draws), while other times I can simply recall a complete screen re-draw or partial update from a single line anywhere in my program by simply specifying the value of the S array and branching to the GOSUB subroutine.

Research and back-ground work continues on my LGB project (which BTW is quickly growing out of hand!). Right now I am working on some of the repetitive subroutines that will be used during the game. One routine in particular is required many times during the game and will be called from a lot of different program line numbers, in fact - it is used everytime a line of text is displayed. This particular subroutine is responsible for reading a text string from DSK1, deciding where to display it, actually displaying the string on the screen (using the CALL HPUT command from RXB), beeping, honking, plus a few other cool functions which also include importing basic graphics to the displayed line when required. Everything is controlled by a single 10 digit variable. A typical example of a variable used would be: S(100)=-1010071012 The logical choice was to use a custom SUB routine which I had defined as "CALL T" and used a single parameter list. An example of this would be; CALL T(S(100)) After fooling around with this idea and improving the routine a few times, it became desirable for my SUB routine to also be able to access existing string variables which were used outside of the SUBroutine in the main program (which is not possible without complicating the subroutine with additional parameters and having to specify each everytime CALL T was used OR I found myself in a situation where I was "double handling" information to get around the problem which just slows things down too much). For this reason I have no real choice but to flick my subroutine and call the entire routine using a GOSUB command - which is more freindly when wanting to use variables specified elsewhere in the main program. My main concern with using a GOSUB command in leu of a SUB routine was the additional program space this would incur - especially when it is being repeated many many times during the program. So to get a feel of how much program space I would loose/waste using this method I did the following basic test; 100 CALL T(S(100)) Using a SIZE command advised this program line used a total of 21 bytes of program space The alternative GOSUB command would need to be specified as follows; 100 A=S(100) : : GOSUB 1000 When listing and compared on screen, the program line with the GOSUB command seems to occupy an 8 additional spaces over the SUBroutine (by spaces I actually mean 8 additional characters). However, when checking this expectation using the CALL SIZE command I was pleasantly surprised to discover that the GOSUB line actually only occupied 1 additional byte of program space. This is really good news for what I need the GOSUB command to do as I am struggling to save every single byte, but it begs the question of what is going on? Why only 1 byte difference between the two lines of code? Obviously my very basic understanding of how the TI stores program data is flawed but I just can't make sense of how two vastly different length lines of program data occupy roughly the same program space. 100 A=S(100) :: GOSUB 1000 100 CALL T(S(100))12345678

Agreed. I have made almost zero progress on my new game since Magellan came out. All I seem to be doing now is looking for perfection in my screen designs. Don't know how many times I have re-done them, but it would be a lot!

Correct...! Didn't fully engage brain before keyboard.

To be honest I didn't find the edit pan distracting. I was quite comfortable with it. I think what the world of TI sprite editors needs is a good function for creating multi-level (so multi coloured) - 64x64 sprite animations. Something where you can swap characters and mess around with timing would just plain rock.

Took me a little while to work out how to change the sprite colours but that is A-W-E-S-O-M-E! Bloody fantastic work. Are you taking suggestions at this stage or just gathering general interst? Either way this is a great multi-layered sprite editor.

I have also had several shots over the years with a few books and the assembler tutorials found in the old TI club mags... For whatever reason the pieces have never fallen into place for my brain to grasp even the basics. I like to think of myself as still being quite a good XB programmer (I always found it quite natural), but assembly.... It's like the whole world is laughing at me every time I try and read an assembler article.

I haven't stopped using this program. It is really allowing me to create something that would otherwise not only be very difficult and time consuming, but it is allowing me to create something that will be of higher quality when it is done. I seriously can't thank you enough Codex for throwing this awesome tool together. Right now I am having to manipulate the data into strings before I can use it in my program. It's no big deal it just adds an additional step to creating my files, but would it be possible to have an export option that exports strings directly from Magellan? So currently we have this; DATA 33,65,48,32,97,122,33,128,33 .............. Would this also be a possible option for export? DATA "!A0 az! !............."