RXB Posted March 8 Share Posted March 8 (edited) I was working on RXBI (RXB INTEGER ONLY) when it occurred to me a much easier way to speed up XB. Much of XB and TI Basic use VDP to store address and flags. Here is a VDP list: GROM 3 *********************************************************** * VDP addresses NLNADD EQU >02E2 New LiNe ADDress ENDSCR EQU >02FE END of SCReen address LODFLG EQU >0371 Auto-boot needed flag START EQU >0372 Line to start execution at SYMBOL EQU >0376 Saved symbol table pointer SPGMPT EQU >0382 Saved PGMPTR for continue SBUFLV EQU >0384 Saved BUFLEV for contiue SEXTRM EQU >0386 Saved EXTRAM for continue SAVEVP EQU >0388 Saved VSPRT for continue ERRLN EQU >038A On-error line pointer BUFSRT EQU >038C Edit recall start addr (VARW) BUFEND EQU >038E Edit recall end addr (VARA) TABSAV EQU >0392 Saved main symbol table ponte SLSUBP EQU >0396 Saved LSUBP for continue SFLAG EQU >0398 Saved on-warning/break bits SSTEMP EQU >039A To save subprogram program ta SSTMP2 EQU >039C Same as above. Used in SUBPRO MRGPAB EQU >039E MERGEd temporary for pab ptr PMEM EQU >03A0 UPPER 24K MEMORY *---------------------------------------------------------- * Added 6/8/81 for NOPSCAN feature PSCFG EQU >03B7 *---------------------------------------------------------- * RXB PATCH CODE SWAP CONFLG FOR CONSOLE MENU FLAG * Flag 0: 99/4 console, 5/29/81 * 1: 99/4A console CONFLG EQU >03BB *---------------------------------------------------------- * Temporary NOTONE EQU >0374 NO-TONE for SIZE in ACCEPT us * in FLMGRS (4 bytes used) ACCVRW EQU >03AC Temoporary used in ERRZZ, als * used in FLMGRS VALIDP EQU >03B0 Use as two values passing fro VALIDL EQU >03B2 VALIDATE code to READL1 OLDTOP EQU >03BC Temporary used in ERRZZ, also CRNBUF EQU >0820 CRuNch BUFfer address CRNEND EQU >08BE CRuNch buffer END RECBUF EQU >08C0 Edit RECall BUFfer VRAMVS EQU >0958 Default base of value stack CNSTMP EQU >0390 Use as temporary stored place VROAZ EQU >03C0 Temporary VDP Roll Out Are CHRCUR EQU >03F0 Definition of CURSOR GROM 4 *********************************************************** * VDP addresses SCRNBS EQU >02E0 Screen base addr for last lin NLNADD EQU >02E2 New LiNe ADDress ENDSCR EQU >02FE END of SCReen address LODFLG EQU >0371 Auto-boot needed flag START EQU >0372 Line to start execution at * Temporary NOTONE EQU >0374 NO-TONE for SIZE in ACCEPT us * in FLMGRS (4 bytes used) SYMBOL EQU >0376 Saved symbol table pointer SPGMPT EQU >0382 Saved PGMPTR for continue SBUFLV EQU >0384 Saved BUFLEV for contiue SEXTRM EQU >0386 Saved EXTRAM for continue SAVEVP EQU >0388 Saved VSPRT for continue ERRLN EQU >038A On-error line pointer BUFSRT EQU >038C Edit recall start addr (VARW) BUFEND EQU >038E Edit recall end addr (VARA) CSNTMP EQU >0390 Use as temporary stored place * or CSN TEMPORARY FOR FAC12 TABSAV EQU >0392 Saved main symbol table ponte AUTTMP EQU >0394 AUTOLD TEMPORARY IN SIDE ERRZ SLSUBP EQU >0396 Saved LSUBP for continue SFLAG EQU >0398 Saved on-warning/break bits SSTEMP EQU >039A To save subprogram program ta SSTMP2 EQU >039C Same as above. Used in SUBPRO MRGPAB EQU >039E MERGEd temporary for pab ptr PMEM EQU >03A0 UPPER 24K MEMORY INPUTP EQU >03AA INPUT TEMPORARY FOR PTR TO PR ACCVRW EQU >03AC Temoporary used in ERRZZ, als * used in FLMGRS * or temporary for @VARW, @VARA ACCVRA EQU >03AE TRY AGAIN VALIDP EQU >03B0 Use as two values passing fro * or PTR TO STANDARD STRING IN VAL VALIDL EQU >03B2 VALIDATE code to READL1 * or Length of string in validate SIZCCP EQU >03B4 SIZE TEMPORARY FOR CCPADR SIZREC EQU >03B6 SIZE TEMPORARY FOR RECLEN * Also used as temporary in RELO *---------------------------------------------------------- * Added 6/8/81 for NOPSCAN feature PSCFG EQU >03B7 *---------------------------------------------------------- ACCTRY EQU >03B7 ACCEPT "TRY AGAIN" FLAG SIZXPT EQU >03B8 Save XPT in SIZE when "try ag SAPROT EQU >03B9 PROTECTION flag in SAVE CSNTP1 EQU >03BA CSN TEMPORARY FOR FAC10 *---------------------------------------------------------- * Flag 0: 99/4 console, 5/29/81 * 1: 99/4A console CONFLG EQU >03BB *---------------------------------------------------------- OLDTOP EQU >03BC Temporary used in ERRZZ, also * or Old top of memory for RELOCA CPTEMP EQU >03BC CCPPTR, RECLEN temp in INPUT NEWTOP EQU >03BE New top of memory for RELOCA VROAZ EQU >03C0 Temporary VDP Roll Out Area CRNBUF EQU >0820 CRuNch BUFfer address CRNEND EQU >08BE CRuNch buffer END RECBUF EQU >08C0 Edit RECall BUFfer VRAMVS EQU >0958 Default base of value stack GROM 5 *********************************************************** * VDP addresses NLNADD EQU >02E2 New LiNe ADDress SPRSAL EQU >0300 Sprite attribute list LODFLG EQU >0371 Auto-boot flag START EQU >0372 Line to start execution at * Temporary SYMBOL EQU >0376 Saved symbol table pointer ONECHR EQU >0378 Used for CHRZ VRMSND EQU >0379 Sound blocks SPGMPT EQU >0382 Saved PGMPTR for continue SBUFLV EQU >0384 Saved BUFLEV for contiue SEXTRM EQU >0386 Saved EXTRAM for continue SAVEVP EQU >0388 Saved VSPRT for continue ERRLN EQU >038A On-error line pointer CSNTMP EQU >0390 Use as temporary stored place * or CSN TEMPORARY FOR FAC12 SLSUBP EQU >0396 Saved LSUBP for continue SFLAG EQU >0398 Saved on-warning/break bits SPNUM EQU >03AA Sprite number temporary CSNTP1 EQU >03BA CSN TEMPORARY FOR FAC10 VROAZ EQU >03C0 Temporary roll-out area SPRVB EQU >07FF Sprite velocity block. CRNBUF EQU >0820 CRuNch BUFfer address GROM 6 *********************************************************** * VDP addresses NLNADD EQU >02E2 New LiNe ADDress LODFLG EQU >0371 Auto-boot needed flag * Temporary * in FLMGRS (4 bytes used) SYMBOL EQU >0376 Saved symbol table pointer BUFSRT EQU >038C Edit recall start addr (VARW) BUFEND EQU >038E Edit recall end addr (VARA) MRGPAB EQU >039E MERGEd temporary for pab ptr PMEM EQU >03A0 UPPER 24K MEMORY *---------------------------------------------------------- * Flag 0: 99/4 console, 5/29/81 * 1: 99/4A console CONFLG EQU >03BB *---------------------------------------------------------- VROAZ EQU >03C0 Temporary roll-out area CRNBUF EQU >0820 CRuNch BUFfer address RECBUF EQU >08C0 Edit RECall BUFfer VRAMVS EQU >0958 Default base of value stack These are address used by GPL in GROM to but if were in SAMS memory instead should be way faster to access then VDP especially address like VDP STACK or CRNBUF >0820 in SAMS RAM instead of VDP which I would assume is way slower. Here is ROM list: ROM 1 * VDP variables SYMBOL EQU >0376 * Saved symbol table pointer ERRLN EQU >038A * On-error line pointer TABSAV EQU >0392 * Saved main symbol table ponter VROAZ EQU >03C0 * Temporary VDP Roll Out Area FPSIGN EQU >03DC CRNBUF EQU >0820 * CRuNch BUFfer address CRNEND EQU >08BE * CRuNch buffer END ROM 2 * VDP variables SYMBOL EQU >0376 * Saved symbol table pointer ERRLN EQU >038A * On-error line pointer TABSAV EQU >0392 * Saved main symbol table ponter VROAZ EQU >03C0 * Temporary VDP Roll Out Area FPSIGN EQU >03DC CRNBUF EQU >0820 * CRuNch BUFfer address CRNEND EQU >08BE * CRuNch buffer END Later to move the Symbol table from VDP to SAMS RAM would also be done. And also the VDP STACK moved to SAMS RAM. The 32K area would >B000 as >A000 has the Subroutine stack at >A000 to >A040 already and >FFF0 to >FFFF is taken by TI Debug hooks. The SAMS pages I would use is SAMS PAGEs 0, 1, 4, 5, 6, 7, 8, 9 of course I have to check with others who might be using these pages. What do you guys think as I would promote an excuse to buy the SAMS and would speed up XB considerably? Edited March 8 by RXB Spelling 6 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 8 Share Posted March 8 I'm still looking for an excuse to use my SAMS card. Go for it! 3 1 Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted March 8 Share Posted March 8 And those of us who don't have a real SAMS can check it out in emulation 2 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 8 Author Share Posted March 8 Just now, WhataKowinkydink said: And those of us who don't have a real SAMS can check it out in emulation True RXB 2020 on up to RXB 2024B supports up to a 16Meg SAMS. 1 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted March 8 Share Posted March 8 1 hour ago, RXB said: What do you guys think as I would promote an excuse to buy the SAMS and would speed up XB considerably? An Extended BASIC which uses the SAMS natively without any confabulation by the user? I am not certain how perceptible the increase in performance would be, but I say do it! At the very least, freeing up VDP RAM for other purposes could introduce new levels of functionality from within XB. Do it! 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 9 Author Share Posted March 9 38 minutes ago, OLD CS1 said: An Extended BASIC which uses the SAMS natively without any confabulation by the user? I am not certain how perceptible the increase in performance would be, but I say do it! At the very least, freeing up VDP RAM for other purposes could introduce new levels of functionality from within XB. Do it! Well RAM has to be faster than VDP as you have to use NOP often to use VDP or you outrun the VDP memory, not a problem with RAM. Running STACK from RAM instead of VDP STACK would also speed up XB as VPUSH and VPOP are using 64 bytes at >0958 so that alone would free up 64 VDP bytes. VPUSH and VPOP normally push 8 bytes onto or off the the VDP STACK, so that stack should be much faster. Crunch Buffer >0820 could could also be increased so a line could be more then 163 bytes so we could have full 255 byte XB lines of XB program code. Thus MERGE format files would be 255 format instead of 163 format. Mostly backward compatible as shorter lines would still run fine, thus would still run TI Basic programs just fine but way faster. As Crunch Buffer >0820 is running from RAM instead of VDP would also benefit as program lines are copied to VDP at >0820 in normal XB. All pointers and flags except for a few would be in RAM. For example >03C0 is the VDP ROLL OUT area and used constantly in XB, but RXB SAMS would use RAM instead thus big speed increase. I will run some tests to see the speed difference between VDP vs SAMS RAM when using GPL and ROM Assembly. 2 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted March 9 Share Posted March 9 And if we ever have a 16 bit Sam's this would be the fastest ever. One of the things that Myarc basic did was less vdp usage. Plus without using video ram for storage frees up vdp to support better graphics modes in basic without any issues. I see no reason at all to still limit ourselves to the 32k space now that you can even emulate a Sams via a pico pi. 2 Quote Link to comment Share on other sites More sharing options...
jrhodes Posted March 9 Share Posted March 9 I would love this. Had my 32k sidecar swapped out for the 1mb SAMS for awhile now. I guess if a 16mb sidecar board was ever made available I'd eventually swap it out for that. 4 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 9 Author Share Posted March 9 5 hours ago, Gary from OPA said: And if we ever have a 16 bit Sam's this would be the fastest ever. One of the things that Myarc basic did was less vdp usage. Plus without using video ram for storage frees up vdp to support better graphics modes in basic without any issues. I see no reason at all to still limit ourselves to the 32k space now that you can even emulate a Sams via a pico pi. Well problem is you need someplace in the 32K to put the stuff that was in VDP. Originally I was going to use >B000 but that opens a can of worms when the problem is using >B000 to >BFFF so deep six that idea. So after some thought I have changed it to >2000 to >4FFF with possibly 32K of 8 4K pages. This would allow for 28K of Strings or Numbers memory instead of the current 12K in XB now. Leaving a full 4K for stack memory, yea less then currently set up but when have you used 5K of stack? Now support for Assembly would still be there along with normal RXB CALL SAMS, so things that access these needs a kind of memory manager. Thus CALL LINK, CALL INIT, CALL LOAD, CALL PEEK, and CALL POKE will return lower 8K to normal functions when called. 3 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted March 9 Share Posted March 9 13 hours ago, RXB said: Well RAM has to be faster than VDP as you have to use NOP often to use VDP or you outrun the VDP memory, not a problem with RAM. Running STACK from RAM instead of VDP STACK would also speed up XB as VPUSH and VPOP are using 64 bytes at >0958 so that alone would free up 64 VDP bytes. VPUSH and VPOP normally push 8 bytes onto or off the the VDP STACK, so that stack should be much faster. Crunch Buffer >0820 could could also be increased so a line could be more then 163 bytes so we could have full 255 byte XB lines of XB program code. Thus MERGE format files would be 255 format instead of 163 format. Mostly backward compatible as shorter lines would still run fine, thus would still run TI Basic programs just fine but way faster. As Crunch Buffer >0820 is running from RAM instead of VDP would also benefit as program lines are copied to VDP at >0820 in normal XB. All pointers and flags except for a few would be in RAM. For example >03C0 is the VDP ROLL OUT area and used constantly in XB, but RXB SAMS would use RAM instead thus big speed increase. I will run some tests to see the speed difference between VDP vs SAMS RAM when using GPL and ROM Assembly. This is cool idea. I did some cheap and dirty experiments putting integers and strings in VDP RAM instead in normal RAM and running some simple benchmarks. I was surprised that the speed difference was only about 12% if I remember right. When you think about it, If you write code to set the VDP address and then read or write sequential data on the VDP chip it is just a normal memory read or write from the CPU. The VDP chip is handling the memory incrementing AND on TI-99 it is a full speed read/write operation because the VDP chip in on the motherboard. Read/writes to expansion RAM are throttled down to 8 bit chunks so not ideal. Of course read/writes to random locations in VDP RAM will be slower. Come to think of that I didn't do that test. I will give it try. So SAMS is a great alternative to VDP. It will be a hell of a neat BASIC system, but don't be shocked if it you don't see 2x performance. 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 9 Share Posted March 9 26 minutes ago, TheBF said: So SAMS is a great alternative to VDP. It will be a hell of a neat BASIC system, but don't be shocked if it you don't see 2x performance. It also depends on the overhead of switching SAMS pages. This could easily take up as many instructions as setting up a VDP address. 3 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted March 9 Share Posted March 9 I re-purposed a benchmark I found online years ago and made two versions. One uses a RAM variable (just an address in Forth) and the other uses a VDP variable. The difference showed VDP was 23% slower reading and writing an integer (2 bytes) than in expansion RAM. This was measured on real hardware, but I am using RS232 and terminal emulator for the Forth console. 23% will give you a nice performance boost on RXB. 1 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted March 9 Share Posted March 9 13 minutes ago, Asmusr said: It also depends on the overhead of switching SAMS pages. This could easily take up as many instructions as setting up a VDP address. For sure. If you lock down the RAM window for SAMS to one 8K chunk the code to page in SAMS is quite small but not insignificant. I did a brutal nesting benchmarking, sub-routines calling sub-routines calling sub-routines very deeply. I put each sub-routine in a different SAMS page. (cruel) The benchmark went from 2:30 to 10:00 . 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted March 9 Share Posted March 9 3 hours ago, TheBF said: 23% will give you a nice performance boost on RXB. Consider the speed increases @RXB has provided by changing GPL to assembly, then add, say, 20% speed increase putting the variable stack into SAMS. Sounds exciting. 2 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 9 Author Share Posted March 9 3 hours ago, Asmusr said: It also depends on the overhead of switching SAMS pages. This could easily take up as many instructions as setting up a VDP address. When you have a 32K normal XB puts the Numeric values in upper 24K starting at >FFE0 and goes downward which is why this reduces your program space. XB prescan looks for all variables and definitions and subs to set this up before a XB program is run. In normal XB in console without 32K Numeric values and Strings and XB programs are all in VDP. As I will make RXB SAMS work like normal XB but instead of VDP use SAMS RAM thus there will be less SAMS page switching the smaller the XB program. This also means much larger XB will be allowed as that space that was used by Numeric Variables in 24K will not be used making more space for XB programs. The routine in RXB since 2000 has always been a 18 byte program in Scratch Pad Fast RAM so that is why it is faster then a CALL LINK version used by others. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 9 Author Share Posted March 9 3 hours ago, TheBF said: For sure. If you lock down the RAM window for SAMS to one 8K chunk the code to page in SAMS is quite small but not insignificant. I did a brutal nesting benchmarking, sub-routines calling sub-routines calling sub-routines very deeply. I put each sub-routine in a different SAMS page. (cruel) The benchmark went from 2:30 to 10:00 . Pretty sure moving the VDP STACK to RAM should be way faster long term. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted March 9 Share Posted March 9 2 hours ago, RXB said: Pretty sure moving the VDP STACK to RAM should be way faster long term. With your strategy of minimizing paging in and out absolutely. But that paging will get in your face if it's too frequent. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 9 Share Posted March 9 (edited) Sorry for spamming, but this reminded me of some speculations about the best way to make SAMS available in BASIC that I made a few years ago. My idea was that BASIC would make SAMS available as arrays, and it would internally maintain a list of allocated areas (i.e. a memory manager). To the user it would make these subroutines available: CALL AMSDIM(ARR,N) // Allocate an array in SAMS of size N. Return reference to array in ARR. Default data type is number. CALL AMSGET(ARR,I,VAL) // Read entry I of array ARR into variable VAL CALL AMSSET(ARR,I,VAL) // Set entry I of array ARR to value VAL CALL AMSFILL(ARR,I,L,VAL) // Fill L entries of array ARR from index I with value VAL CALL AMSCOPY(ARR1,I1,ARR2,I2,L) // Copy L entries from ARR1 index I1 to ARR2 index I2 CALL AMSFREE(ARR) // Deallocate array // Data types CALL AMSDIM(ARR,"N",N) // number (default) CALL AMSDIM(ARR,"S",N,M) // string (fixed length M) CALL AMSDIM(ARR,"B",N) // byte CALL AMSDIM(ARR,"W",N) // word // Same as above for 2-dimensional arrays CALL AMSDIM(ARR,N,M) // Also with data types CALL AMSGET(ARR,I,J,VAL) // Read entry I, J of array ARR into variable VAL CALL AMSSET(ARR,I,J,VAL) // Set entry I, J of array ARR to value VAL CALL AMSFILL(ARR,I,J,L,M,VAL) // Fill a 'rectangle' at (I,J) size (L,M) CALL AMSCOPY(ARR1,I1,J1,ARR2,I2,J2,L,M) // Copy a 'rectangle' between arrays Just an idea, it could be implemented in any version of BASIC. Edit: and there could also be subroutines for copying byte data directly from SAMS to VDP. Edited March 9 by Asmusr 3 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 9 Author Share Posted March 9 Problem with TI Basic is it is so SLOOOW! Also TI Basic ONLY USES VDP, it never once uses RAM. RXB SAMS is designed to use SAMS RAM instead of VDP. VDP STACK will be in SAMS RAM String Variables will be in SAMS RAM not VDP Variable names will be in SAMS RAM not VDP The routines to copy from RAM to VDP or VDP to RAM are already built into XB ROMs. SAMS RAM is just a bonus to these routines already were in XB ROMs version 110 2 Quote Link to comment Share on other sites More sharing options...
MikeV Posted March 18 Share Posted March 18 By all means go for it! Also it would be great to be able to use variable length strings in SAMS without having to convert. It appears that all the info is there, i.e. "string length byte" to make this happen? Thanks. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 18 Author Share Posted March 18 Problems with Ryte Data GPL Assembler and RAG GPL Assembler and even Thierry GPL Assembler all crash for various reasons. None of these apparently are designed to deal with this project. Some commands just crash Ryte Data GPL Assembler due to 35 year old bugs. RAG GPL Assembler only lists to Printer so unusable to list to Disk or Hard drive Thierry GPL Assembler gives errors that are not defined or why it crashed as there is a error it just stops working with no clue what is wrong! With no list file to explain what is wrong it makes the Assembler totally useless, same exact problem I had with RAG GPL Assembler. So had Ralph help me install to use XGA99 on my PC to use it instead, but OMG still problems that thankfully Ralph is working on fixing. But some success as replacing many of the VDP Flags and Temp locations from VDP to RAM has shown this is going to work. I have yet to put the Crunch Buffer from VDP to RAM or the VDP STACK from VDP to RAM but that requires some XB ROM modifications first. (This is going to free up some XB ROM space for more features.) 3 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 3 Author Share Posted May 3 Well have disassembled mostly large portion of XB3.0 and going to work on XB3.1 next target. Anyway to compare other XB to RXB and XB3 or MyarcXB2 on SAMS or XBGEM. 90 ! ROUTINE SET UP SPRITES TEST SO NOT PART OF TIMING ROUTINE 100 CALL CLEAR 110 OPEN #1:"CLOCK" 120 INPUT #1:A$,B$,C$ 130 FOR C=1 TO 10000 140 ! ROUTINE INSERTED HERE TO TEST 150 NEXT C 160 INPUT #1:D$,E$,F$ 170 PRINT A$,D$:B$,E$,C$,F$ 180 END ********************************************************************************************* SAMS XB XB3.0 XB3.1 XBGEM MyarcXB2 RXB command --------------------------------------------------------------------------------------------- 11:5 9:10 9:10 3:11 5:6 3:21 CALL CHAR(65,"FFFFFFFF") 2:57:15 34:18 8:36 5:33 6:19 4:42 CALL CHAR(Z$,65) ! LENGTH 64 11:32 7:19 7:19 4:1 5:14 4:5 CALL CHARPAT(65,Z$) 32:44 33:6 33:4 1:11:47 5:1 4:8 CALL CHARSET 3:49 3:29 3:31 3:43 8:48 3:41 CALL CLEAR 6:25 6:25 4:20 6:24 7:22 6:19 CALL COINC(#1,20,20,8,Z) 3:0 3:0 2:6 3:0 4:3 3:4 CALL COINC(ALL,Z) 4:33 4:15 3:7 4:15 5:4 4:24 CALL COLOR(1,2,8) 3:9 3:9 2:12 3:9 4:6 2:36 CALL DELSPRITE(#1) 6:22 6:23 5:12 6:22 4:18 5:33 CALL DELSPRITE(ALL) 6:5 6:6 4:11 6:6 6:0 6:1 CALL DISTANCE(#1,20,20,Z) 6:6 3:7 3:6 4:10 5:9 4:2 CALL GCHAR(1,1,Z) 4:11 3:1 3:0 4:5 5:5 4:17 CALL HCHAR(1,1,65) 4:37:35 4:39:17 21:2 9:31 14:12 7:33 CALL HCHAR(1,1,65,768) 5:0 3:2 3:3 5:6 6:43 5:7 CALL JOYST(1,X,Y) 4:37 3:25 2:11 4:38 5:16 5:2 CALL KEY(1,K,S) 4:4 4:4 3:9 4:4 5:13 4:17 CALL LOCATE(#1,20,20) 2:17 2:11 2:8 2:14 3:45 2:14 CALL MAGNIFY(1) 4:44 4:44 3:24 4:44 6:42 4:41 CALL MOTION(#1,20,20) 3:8 3:17 2:24 3:17 5:27 3:4 CALL PATTERN(#1,66) 5:22 5:22 3:14 5:31 5:25 5:9 CALL POSITION(#1,X,Y) 3:44 2:11 2:12 2:6 4:3 2:17 CALL SCREEN(5) 5:9 5:8 4:7 5:9 6:30 5:7 CALL SPRITE(#1,65,2,10,10) 3:55 3.0 3:1 4:5 5:5 4:17 CALL VCHAR(1,1,65) 4:30:22 4:30:41 3:30:27 18:29 18:11 21:3 CALL VCHAR(1,1,65,768) 10:2 8:13 8:11 10:1 6:18 10:3 DISPLAY AT(9,9):C 21:10 13:41 12:18 11:49 11:29 12:13 DISPLAY AT(9,9):RND 8:22 6:43 6:38 8:22 6:17 8:21 DISPLAY AT(9,9):"TEST" 22:6 6:23 6:24 19:27 3:3 15:15 CALL INIT 1:48 2:30 2:30 12:12 3:40 2:9 A=LEN("TEST") 12:12 5:3 5:3 3:8 7:16 3:9 A=RND 1:26 1:14 2:46 1:26 3:26 2:34 A=ABS(C) 5:36 2:36 3:23 5:25 6:12 5:37 A=ATN(1) 3:5 2.0 2:2 3:25 5:30 3:7 A$=CHR$(65) 13:8 12:11 11:49 13:8 10:2 13:9 A=COS(.5) 14:27 11:14 10:46 14:27 14:36 14:28 A=EXP(1) 20:42 16:14 16:11 41:13 20:6 19:12 A=LOG(3.4) 2:37 2:10 2:8 2:11 4:9 2:42 A=MAX(C,99) 3:16 2:4 2:2 3:15 4:12 3:11 A=MIN(C,99) 2:36 1:13 1:2 1:24 3:14 1:23 A=PI 5:5 4:14 4:16 4:31 6:10 5:1 A=POS("PAN","A",1) 2:17:15 7:13 7:14 17:5 40:31 2:17:9 A$=RPT$("A",255) 5:27 3:6 3:25 55:25 7:13 5:30 A$=SEG$("TEST",2,3) 1:27 1:14 1:14 1:26 3:26 1:26 A=SGN(C) 12:4 11:50 11:3 11:56 15:3 12:4 A=SIN(30) 11:3 9:34 10:26 11:2 17:28 11:1 A=SQR(C) 4:19 3:7 2:51 3:41 11:8 4:16 A$=STR$(5) 44:19 23:13 23:14 25:16 29:16 35:15 A=TAN(.78) 4:19 3:0 3:1 4:19 4:7 4:12 A=VAL("5") 1:14 1:22 1:22 1:15 3:15 1:15 DATA 1 1:14 1:15 1:16 1:8 3:26 1:8 DEF A=C*C :51 :44 1:16 1.8 3:26 1:8 DIM A(100) 14:36 10:52 9:47 13:10 10:7 13:8 PRINT 13:14 9:23 10:37 14:46 11:9 15:19 DISPLAY 11:25 12:6 12:4 16:36 12:13 16:35 PRINT C 17:9 12:38 13:22 17:10 12:10 17:7 DISPLAY C 15:2 10:35 10:33 15:2 12:52 15:4 PRINT "TEST" 15:44 12:51 11:5 16:27 11:11 16:28 DISPLAY "TEST" 1:12 1:19 1:19 1:12 2:22 1:11 OPTION BASE 1 4:35 3:24 3:26 3:25 4:24 4:24 CALL PEEK(8192,A) 5:37 4:3 4:1 2:29 3:21 2:29 RANDOMIZE C 8:21 9:43 9:45 9:39 6:5 8:21 CALL SOUND(1,110,30) ********************************************************************************************* * RXB NEW COMMANDS TO EXTENDED BASIC PRINT PRINT PRINT PRINT PRINT 7:14 CALL SCROLLUP {PRINT} PRINT C PRINT C PRINT C PRINT C PRINT C 11:23 CALL SCROLLUP(1,C) {DISPLAY C} DISPLAY DISPLAY DISPLAY DISPLAY DISPLAY 10:33 CALL SCROLLUP(1,"TEST") {DISPLAY} DISPLAY DISPLAY DISPLAY DISPLAY DISPLAY 5:6 CALL HPUT(11,11,C) {DISPLAY AT} DISPLAY DISPLAY DISPPLAY DISPLAY DISPLAY 7:12 CALL HPUT(11,11,RND) {DISPLAY AT} DISPLAY DISPLAY DISPPLAY DISPLAY DISPLAY 4:29 CALL HPUT(11,11,"TEST") {DISPLAY AT} 14:17 10:10 10:11 15:42 16:16 11:50 CALL JOYLOCATE(1,X,Y,8,8,#1,RW,CL,K) GOTO 15:53 10:20 10:8 15:3 16:1 10:2 CALL JOYMOTION(1,X,Y,#1,9,9,K) GOTO 7:7 5:11 5:11 7:7 11:3 9:33 CALL ONKEY("ABC",1,K,S) GOTO 1,2,3 N/A N/A N/A N/A N/A 7:26 CALL COLLIDE(#1,20,20,8,X,Y) N/A N/A N/A 10:31 N/A 11:39 CALL MOVES("RR",1024,8192,12288) ********************************************************************************************* 80 ! JOYLOCATE FOR OTHERS 90 CALL SPRITE(#1,65,2,20,20) :: XL,YL=20 100 CALL CLEAR 110 OPEN #1:"CLOCK" 120 INPUT #1:A$,B$,C$ 130 FOR C=1 TO 10000 140 CALL JOYST(1,X,Y) :: CALL LOCATE(#1,X+XL,Y+YL) :: CALL KEY(1,K,S) :: IF K=18 THEN 150 150 NEXT C 160 INPUT #1:D$,E$,F$ 170 PRINT A$,D$:B$,E$,C$,F$ 180 END ***************************************************************************** 80 ! JOYMOTION FOR OTHERS 90 CALL SPRITE(#1,65,2,20,20) :: XL,YL=20 100 CALL CLEAR 110 OPEN #1:"CLOCK" 120 INPUT #1:A$,B$,C$ 130 FOR C=1 TO 10000 140 CALL JOYST(1,X,Y) :: CALL MOTION(#1,X*9,Y*9) :: CALL KEY(1,K,S) :: IF K=18 THEN 150 150 NEXT C 160 INPUT #1:D$,E$,F$ 170 PRINT A$,D$:B$,E$,C$,F$ 180 END **************************************************************************** 80 ! ONKEY FOR OTHERS 90 CALL SPRITE(#1,65,2,20,20) :: XL,YL=20 100 CALL CLEAR 110 OPEN #1:"CLOCK" 120 INPUT #1:A$,B$,C$ 130 FOR C=1 TO 10000 140 CALL KEY(1,K,S) :: IF K=65 THEN 150 ELSE IF K=66 THEN 150 ELSE IF K=67 THEN 150 ELSE 150 150 NEXT C 160 INPUT #1:D$,E$,F$ 170 PRINT A$,D$:B$,E$,C$,F$ 180 END **************************************************************************** 3 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.