RXB Posted October 26, 2017 Share Posted October 26, 2017 (edited) I see this could be pretty handy, but also handy to be able to perform the action on a range of characters or a character set. RXB does have CALL INVERSE already but I suppose better way would be to include I for inverse of CALL CHAR(I,char#) This would just INVERSE the character values like CALL INVERSE does now in RXB. Or CALL CHAR(R,char#) for reverse string. This would reverse the character definition "AE" _*_*_*** would become "75" ***_*_*_ Edited October 26, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted October 26, 2017 Share Posted October 26, 2017 I am surprised the GPL search for sub-programs in TI Extended BASIC does not use a hash table. How difficult would it be to implement that in RXB? Would it be worth the trouble? Quote Link to comment Share on other sites More sharing options...
RXB Posted October 26, 2017 Share Posted October 26, 2017 I am surprised the GPL search for sub-programs in TI Extended BASIC does not use a hash table. How difficult would it be to implement that in RXB? Would it be worth the trouble? The TI Basic and XB search are built into the TI OS. And it would not be worth the trouble to implement this. But a updated TI GROM OS like the old SOB board would be a great idea. SOB had a many useful and better features and fixes. Quote Link to comment Share on other sites More sharing options...
RXB Posted October 28, 2017 Share Posted October 28, 2017 Well now that I have the XB ROM Source Code I am looking at fixing some stuff it, but also seems logical to add more banks of Assembly also: 1) The main goal is to speed up XB but be backwards compatible with TI Basic and XB yet have more features. 2) So some of the additional features to add are replace some slower routines with assembly versions such as COINC, DISTANCE, KEY, JOYST, POSITION, RTP$ 3) Make Value Stack and Buffers like Redo/Edit Bufferr and VDP Roll out and Crunch Buffers movable possibly. (This would allow compatibility with TML or other programs that need to move things.) 4) Add in more SAMS support in XB and increase XB programs space and Variable space into SAMS (Possibly a SAMS only version also exciting with 4 Meg SAMS on way.) 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 28, 2017 Share Posted October 28, 2017 How about a subroutine to globally disable and enable sprite motion? This would allow you to set up layered multicolor sprites and move all layers together. Quote Link to comment Share on other sites More sharing options...
kl99 Posted October 28, 2017 Share Posted October 28, 2017 Well now that I have the XB ROM Source Code I am looking at fixing some stuff it, but also seems logical to add more banks of Assembly also: 1) The main goal is to speed up XB but be backwards compatible with TI Basic and XB yet have more features. 2) So some of the additional features to add are replace some slower routines with assembly versions such as COINC, DISTANCE, KEY, JOYST, POSITION, RTP$ 3) Make Value Stack and Buffers like Redo/Edit Bufferr and VDP Roll out and Crunch Buffers movable possibly. (This would allow compatibility with TML or other programs that need to move things.) 4) Add in more SAMS support in XB and increase XB programs space and Variable space into SAMS (Possibly a SAMS only version also exciting with 4 Meg SAMS on way.) Nice ideas. You might also take a look into the Source Code of Extended Basic 2 for the 99/8 where some speedup improvements were done. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted October 29, 2017 Share Posted October 29, 2017 How about a subroutine to globally disable and enable sprite motion? This would allow you to set up layered multicolor sprites and move all layers together. Hmm XB already had CALL DELSPRITE(ALL) And RXB has CALL MOTION(STOP) or CALL MOTION(GO) for stopping all spite movements or go for giving all sprites movement. I even have a demo that shows what you requested and how to do it on Video and part of the RXB CALL USER demo that comes with RXB. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted October 29, 2017 Share Posted October 29, 2017 Nice ideas. You might also take a look into the Source Code of Extended Basic 2 for the 99/8 where some speedup improvements were done. Thanks will take a look at that. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 29, 2017 Share Posted October 29, 2017 Hmm XB already had CALL DELSPRITE(ALL) And RXB has CALL MOTION(STOP) or CALL MOTION(GO) for stopping all spite movements or go for giving all sprites movement. I even have a demo that shows what you requested and how to do it on Video and part of the RXB CALL USER demo that comes with RXB. Somehow I knew you would say that. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 11, 2017 Share Posted November 11, 2017 (edited) Update did some Testing for new versions of next version of RXB using a test look of 10,000 passes with Classic99 showing times of start to finish. EXAMPLE of RXB 2015 vs RXB 2017 100 CALL CLEAR 110 OPEN #1:"CLOCK",INPUT 120 INPUT #1:A$,B$,C$ 130 PRINT A$;B$;C$ 140 ! RXB EXAMPLE CALL COLOR(D,#value,#value) CALL CHAR(D,char,char) 150 A(0)=-1 :: A(1)=1 :: CALL MOTION(GO) 160 CALL MAGNIFY(2) :: CALL SCREEN(15) 170 FOR S=1 TO 28 180 CALL SPRITE(#S,64+S,INT(RND*16)+1,20+S,50+S,INT(A(RND*1))*INT(RND*20),INT(A(RND*1))*INT(RND*20)) 190 NEXT S 200 CALL COLOR(D,#INT(RND*28)+1,#INT(RND*28)+1) 210 CALL CHAR(D,INT(RND*28)+64,INT(RND*28)+64) 220 Z=Z+1 :: IF Z<10000 THEN 200 230 INPUT #1:A$,B$,C$ 240 PRINT A$;B$;C$ RXB 2015 RXB 2017 TIME WINNER ___________________________________________________________________________________ CALL SWAPCHAR(charset#,#charset#) vs CALL CHAR(S,charset#,#charset#) 1.14 RXB 2015 CALL SWAPCOLOR(#sprite,#spirte) vs CALL COLOR(S,#sprite,#spirte) 2.81 RXB 2015 CALL DUPCOLOR(#sprite,#sprite) vs CALL COLOR(D,#sprite,#spirte) 1.05 RXB 2017 CALL DUPCHAR(char#,char#) vs CALL CHAR(D,#char,#char) .95 RXB 2015 DUP & SWAP both used vs D and S both used 1.14 RXB 2015 XB RXB 2017 CALL CHAR & CALL COLOR vs CALL CHAR & CALL COLOR .84 XB So this new version seems to be a dead end. Adding more commands slows GPL down but this new approach also does not help at all. I did get a speed up in CALL DUPCOLOR(#sprite,#sprite) vs CALL COLOR(D,#sprite,#spirte) but all the rest were slower sometimes by to much to be tolerated. Thus I may have to use a new approach that is a combination of the two or stick with original RXB 2015 way of command and see if I can remove some of them for speed. Also make more use of the XB ROM assembly routines that can avoid GPL as Assembly is always faster but just always takes up more program space to do same thing. Edited November 11, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted November 11, 2017 Share Posted November 11, 2017 (edited) Depending on what you want to do, you could also expand the number of Assembly routines too, Rich. You'd have to use more than the original two banks of ROM, but that is easily done using current cartridge formats (and can be tested on several emulators too). That may help eliminate some of the speed issues. Edited November 11, 2017 by Ksarul Quote Link to comment Share on other sites More sharing options...
RXB Posted November 11, 2017 Share Posted November 11, 2017 Depending on what you want to do, you could also expand the number of Assembly routines too, Rich. You'd have to use more than the original two banks of ROM, but that is easily done using current cartridge formats (and can be tested on several emulators too). That may help eliminate some of the speed issues. Yea that is what needs to be done. 4 banks or more as with more a 80 column version of XB is possible with SAMS support even a memory manager. What kind of banking method? Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted November 11, 2017 Share Posted November 11, 2017 Banking in the modern cartridges is actually just an extension of the banking already used in Extended BASIC, with one slight difference. XB switches half of each 8K bank (simulated in new cartridges by replicating the 4K that stays the same into both 8K banks), whereas the new cartridges switch the whole 8K. Banking is done by writing a byte to >6000, >6002, >6004, >6006, etc., and this method works on both Inverted and non-Inverted cartridge boards (the banking addresses are always the same, just the order of the stack in the EPROM changes to always place the correct bank into the desired bank address). Quote Link to comment Share on other sites More sharing options...
RXB Posted November 12, 2017 Share Posted November 12, 2017 Banking in the modern cartridges is actually just an extension of the banking already used in Extended BASIC, with one slight difference. XB switches half of each 8K bank (simulated in new cartridges by replicating the 4K that stays the same into both 8K banks), whereas the new cartridges switch the whole 8K. Banking is done by writing a byte to >6000, >6002, >6004, >6006, etc., and this method works on both Inverted and non-Inverted cartridge boards (the banking addresses are always the same, just the order of the stack in the EPROM changes to always place the correct bank into the desired bank address). Can I use GPL to write to >6000 or >6002 or >6004 or >6006 and switch banks to use or do I have to use an Assembly routine loaded into Scratch to do this? Example GPL: ST >FF,@>6006 Assembly I would have to load a routine into scratch pad and then use XML >FO to run from >8300 ? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 12, 2017 Share Posted November 12, 2017 Can I use GPL to write to >6000 or >6002 or >6004 or >6006 and switch banks to use or do I have to use an Assembly routine loaded into Scratch to do this? Example GPL: ST >FF,@>6006 Assembly I would have to load a routine into scratch pad and then use XML >FO to run from >8300 ? Since you are ultimately using the Assembly Language of the GPL Interpreter to perform the actual “write” to ROM, I should think GPL could effect the bank switching just fine. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted November 12, 2017 Share Posted November 12, 2017 Lee is correct, Rich. I suspect the existing code is already doing that to some extent by just bouncing to the 4K of static ROM for the pointers to each routine and then the existing assembly is doing the bank switching to execute, but there is absolutely no reason to keep the trampolines locked into that space. You could just as easily identify the routine in GPL space and bounce to it directly with a return routine to bring things back to the GPL space and continue program execution from there once you were done. You might have to do some register protection/restoration as part of each routine to make sure nothing else is accidentally impacted, but again, that's what the existing Assembly subprograms are doing, so you have a usable template for subprogram behavior. Quote Link to comment Share on other sites More sharing options...
RXB Posted November 12, 2017 Share Posted November 12, 2017 Yea in the XB ROMS Source you see R11 is the PGM Counter and R8 & R7 is mostly used for saving a Return address for a BL routine it branches to it it does two deep BL routines. Registers R0 to R7 are used for all the XB ROM routines. While R15 to R10 are uses for various things like GROM ADDRESS or VDP ADDRESS or CRU selection or DSR counters for searches. So cool I can still use slightly modified XB ROMs but will have to fix the FILE XML359 that is the page selector: ******************************************************************************** AORG >6000 TITL 'XML359' * PAGE SELECTOR FOR PAGE 1 PAGE1 EQU $ >6000 C2 DATA 2 0 * PAGE SELECTOR FOR PAGE 2 PAGE2 EQU $ >6002 C7 BYTE >00 CBH7 BYTE >07 2 CBHA BYTE >0A CBH94 BYTE >94 4 C40 DATA 40 6 C100 DATA 100 8 C1000 DATA >1000 A DATA 0 C FLTONE DATA >4001 E ************************************************************* * XML table number 7 for Extended Basic - must have * * it's origin at >6010 * ************************************************************* * 0 1 2 3 4 5 6 DATA COMPCG,GETSTG,MEMCHG,CNSSEL,PARSEG,CONTG,EXECG * 7 8 9 A B C D DATA VPUSHG,VPOP,PGMCH,SYMB,SMBB,ASSGNV,FBSYMB * E F DATA SPEED,CRNSEL ************************************************************* * XML table number 8 for Extended Basic - must have * * it's origin at >6030 * ************************************************************* * 0 1 2 3 4 5 6 7 DATA CIF,CONTIN,RTNG,SCROLL,IO,GREAD,GWRITE,DELREP * 8 9 A B C D E DATA MVDN,MVUP,VGWITE,GVWITE,GREAD1,GWITE1,GDTECT * F DATA PSCAN * Determine if and how much ERAM is present GDTECT MOVB R11,@PAGE1 First enable page 1 ROM *-----------------------------------------------------------* * Replace following line 6/16/81 * * (Extended Basic must be made to leave enough space at * * top of RAM expansion for the "hooks" left by the 99/4A * * for TIBUG.) * * SETO R0 Start at >FFFF * * with LI R0,>FFE7 Start at >FFE7 *-----------------------------------------------------------* MOVB R11,*R0 Write a byte of data CB R11,*R0 Read and compare the data JEQ DTECT2 If matches-found ERAM top *-----------------------------------------------------------* * Change the following line 6/16/81 * * AI R0,->2000 Else drop down 8K * LI R0,>DFFF Else drop down 8K *-----------------------------------------------------------* MOVB R11,*R0 Write a byte of data CB R11,*R0 Read and compare the data JEQ DTECT2 If matches-found ERAM top CLR R0 No match so no ERAM DTECT2 MOV R0,@RAMTOP Set the ERAM top RT And return to GPL CNSSEL LI R2,CNS JMP PAGSEL CRNSEL LI R2,CRUNCH * Select page 2 for CRUNCH and CNS PAGSEL INCT @STKADD Get space on subroutine stack MOVB @STKADD,R7 Get stack pointer SRL R7,8 Shift to use as offset MOVB R11,@PAD0(R7) Save return addr to GPL interpeter MOVB @R11LB,@PAD1(R7) MOVB R11,@PAGE2 Select page 2 BL *R2 Do the conversion MOVB R11,@PAGE1 Reselect page 1 MOVB @STKADD,R7 Get subroutine stack pointer DECT @STKADD Decrement pointer SRL R7,8 Shift to use as offset MOVB @PAD0(R7),R11 Restore return address MOVB @PAD1(R7),@R11LB RT Return to GPL interpeter GETCH MOVB @R6LB,*R15 NOP MOVB R6,*R15 INC R6 MOVB @XVDPRD,R8 GETCH1 SRL R8,8 RT GETCHG MOVB R6,@GRMWAX(R13) MOVB @R6LB,@GRMWAX(R13) INC R6 MOVB *R13,R8 JMP GETCH1 GETCGR MOVB *R6+,R8 JMP GETCH1 * CBHFF EQU $+2 POPSTK LI R5,-8 MOVB @VSPTR1,*R15 LI R6,ARG MOVB @VSPTR,*R15 A R5,@VSPTR STKMOV MOVB @XVDPRD,*R6+ INC R5 JNE STKMOV RT * PUTSTK INCT @STKADD MOVB @STKADD,R4 SRL R4,8 MOVB @GRMRAX(13),@PAD0(R4) MOVB @GRMRAX(13),@PAD1(R4) DEC @PAD0(R4) RT * GETSTK MOVB @STKADD,R4 SRL R4,8 DECT @STKADD MOVB @PAD0(R4),@GRMWAX(R13) MOVB @PAD1(R4),@GRMWAX(R13) RT ******************************************************************************** Quote Link to comment Share on other sites More sharing options...
RXB Posted November 13, 2017 Share Posted November 13, 2017 Freaking amazing fact in XB I was looking to test XB ROM routines from GPL and this routine called GVWITES ******************************************************************************** AORG >7FDA TITL 'GVWITES' * Move data from ERAM to VDP (RAM to VDP) * @GSRC : Source address where the data stored on ERAM * @DEST : Destination address on VDP * @BCNT3 : byte count GVWITE MOV @DEST,R2 VDP address MOVB @R2LB,*R15 LSB of VDP address ORI R2,WRVDP Enable VDP write MOVB R2,*R15 MSB of VDP address MOV @GSRC,R3 ERAM address GV$1 MOVB *R3+,@XVDPWD Move a byte DEC @BCNT3 One less to move JNE GV$1 If not done, loop for more RT Return AORG >7FFE DATA >9226 ******************************************************************************** Not a single call used from XB GPL at all yet it has a GPL XML value of >8A that is never used...why even put it as a XML at all if it is never ever used in XB ROMs? Also not a single routine in XB ROMs calls it ever? So TI put in a section of XB Assembly in XB ROM that is never used or called and has a XML assigned to it? Now in EA manual is does have VGWITE >34 which obviously is not in XB ROMs as that would be >6? or >7? or >8A in the ROMs? 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 13, 2017 Share Posted November 13, 2017 Freaking amazing fact in XB I was looking to test XB ROM routines from GPL and this routine called GVWITES ******************************************************************************** AORG >7FDA TITL 'GVWITES' * Move data from ERAM to VDP (RAM to VDP) * @GSRC : Source address where the data stored on ERAM * @DEST : Destination address on VDP * @BCNT3 : byte count GVWITE MOV @DEST,R2 VDP address MOVB @R2LB,*R15 LSB of VDP address ORI R2,WRVDP Enable VDP write MOVB R2,*R15 MSB of VDP address MOV @GSRC,R3 ERAM address GV$1 MOVB *R3+,@XVDPWD Move a byte DEC @BCNT3 One less to move JNE GV$1 If not done, loop for more RT Return AORG >7FFE DATA >9226 ******************************************************************************** Not a single call used from XB GPL at all yet it has a GPL XML value of >8A that is never used...why even put it as a XML at all if it is never ever used in XB ROMs? Also not a single routine in XB ROMs calls it ever? So TI put in a section of XB Assembly in XB ROM that is never used or called and has a XML assigned to it? Now in EA manual is does have VGWITE >34 which obviously is not in XB ROMs as that would be >6? or >7? or >8A in the ROMs? As you know, the XML signature’s first hex digit (nybble), after doubling, is an offset into XMLTAB at >0CFA in the console ROM. This is a pointer to a second table of subroutine pointers. The second nybble, after doubling, is an offset into this second table. For XML signatures beginning with >8, this second table is located at >6030 in XB ROM space. >8A references >6030 + >14 = >6044, which contains >7FC0—not the >7FDA of your GVWITES routine. That routine’s address is in the next word, which has an XML signature of >8B. I am guessing that >8A actually points to VGWITE. [EDIT: The code in your previous post actually shows this to be the case.] For the E/A cartridge, the XML signatures for VGWITE and GVWITE are >34 and >36, respectively. The first nybble, after doubling, points to XMLTAB + 6 = >0D00, which contains >3FC0 in low ex[ansion RAM. For VGWITE, the address of its code is pointed to by >3FC0 + 8 = >3FC8. The pointer for GVWITE is at >3FC0 + C = >3FCC. These routines are for TI Basic support and are in the file BSCSUP (on one of the E/A disks), which must be loaded in TI Basic to be used. ...lee Quote Link to comment Share on other sites More sharing options...
RXB Posted November 13, 2017 Share Posted November 13, 2017 Lee Yea I know this as this is the XB ROM source code I am posting. And I went into XB and RXB looking for anything that ever used GVWITE and not a single time was it ever used, even as a subroutine of some XB ROM routine as in GVWITE or GV$1 and even looked for it in Debug in Classic99. The TI Basic version of EA support created by me and placed in TI Basic from >3800 to >3FFF and >4800 to >5FFF and many people use it so no EA cart is needed for TI Basic Assembly support. I think the video and ZIP are still on AtariAge. My point was that TI created some routines in XB ROMs that are never used as I think there were either for future versions or just bad management. See routine like MVDN does exactly the same thing but can move from RAM to Scratch Pad or VDP and is used quite a bit from GPL XML to MVDN. (They just never removed what was never used?) ******************************************************************************** AORG >7F7E TITL 'MVDNS' * (VDP to VDP) or (ERAM to ERAM) * WITHOUT ERAM : Move the contents in VDP RAM from a lower * address to a higher address avoiding a * possible over-write of data * ARG : byte count * VAR0 : source address * VARY2 : destination address * WITH ERAM : Same as above except moves ERAM to ERAM MVDN MOV @ARG,R1 Get byte count MOV @VARY2,R5 Get destination MOV @VAR0,R3 Get source MVDN2 MOV @RAMTOP,R7 ERAM or VDP? JNE MV01 ERAM, so handle it JMP MV05 VDP, so jump into loop MVDN1 DEC R5 DEC R3 MV05 EQU $ MOVB @R3LB,*R15 Write out read address MOVB R3,*R15 MOVB @XVDPRD,R7 Read a byte MOVB @R5LB,*R15 Write out write address ORI R5,WRVDP Enable VDP write MOVB R5,*R15 MOVB R7,@XVDPWD Write the byte DEC R1 One less byte to move JNE MVDN1 Loop if more to move RT MV01 EQU $ MVDN$1 MOVB *R3,*R5 Move a byte DEC R3 Decrement destination DEC R5 Decrement source DEC R1 One less byte to move JNE MVDN$1 Loop if more to move RT ******************************************************************************** One of the issues I have is GPL spends a stupid amount of time loading the source, byte count and destination just to move 2 stupid bytes? When a GPL DST source,destination could do the same thing. It wastes 24 bytes of GPL to call a Assembly routine that moves 2 bytes??? Freaking insane! GPL get slowed to a crawl by idiotic things like this. Quote Link to comment Share on other sites More sharing options...
RXB Posted November 16, 2017 Share Posted November 16, 2017 (edited) In case no one saw this is the XB ROM source code this is from GROM6 >C000 to >DFFF from CALL LOAD * MVUP WAS USED TO TRANSFER DATA FROM CPU RAM TO ERAM * SINCE IT WAS NOT KNOWN AT FIRST THAT THE MOVE * INSTRUCTION COULD TRANSFER FROM CPU RAM TO ERAM * (PROVIDED THAT >8300 IS SUBTRACTED FROM THE ADDRESSES) *********************************************************** MVUP was tested vs GPL MOVE command and MVUP is faster but requires more memory to set up then GPL MOVE Example: MVUP and MVDN both XML Assembly routines in XB ROM have set Variables: ******************************* DST 2,@ARG * BYTE COUNT DST >1000,@VAR0 * SOURCE ADDRESS DST >3000,@VARY2 * DESTINATION ADDRESS XML MVDN * ASSMBLY MOVE IT BR LNKRT2 * Return to GPL Set variable address ARG (>835C), VAR0 (>8300) and VARY2 (>8306) Thus if these variables are in other locations have to copied to these set variables thus takes more memory to use and access as then they need to be transferred. On the other hand GPL MOVE does not care what variables: MOVE @VAR3,@TEMP1,@>830E Assembly is faster but requires more work to make work. So incase you did not know many routines in XB ROMs only exist from lack of communication between GPL programmers and Assembly programmers teams. Edited November 16, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
RXB Posted November 16, 2017 Share Posted November 16, 2017 (edited) CONFIRMED sometime GPL is faster than XML Assembly routines in XB ROMs: 100 CALL CLEAR 110 OPEN #1:"CLOCK",INPUT 120 INPUT #1:A$,B$,C$ 130 PRINT A$;B$;C$ 140 CALL ATEST ! Assembly XML or CALL MTEST used for GPL 150 X=X+1 160 IF X<>100000 THEN 140 170 INPUT #1:A$,B$,C$ 180 PRINT A$;B$;C$ Results are Assembly XML in XB ROMs 29.29 and for GPL MOVE 23.45 for a difference of 6 minutes & 24 seconds. Example code of XB ROM routines: 0790] *************** LOAD DATA INTO ERAM *********************** [0791] * LOAD FRESTA, FREEND from ERAM [0792] C097 BF,16,20 DST FSLOC,@VARB Source C09A 02 [0793] C09B BF,00,83 DST FRESTA,@VAR0 Destination C09E 08 [0794] C09F BF,5C,00 DST 4,@ARG # of bytes to move C0A2 04 [0795] C0A3 0F,89 XML MVUP (TOTAL BYTES USED TO SET UP XML MVUP 11 BYTES AND 3 DST GPL COMMANDS BEFORE XML USED) RXB REPLACEMENT: [4213] CCC4 35,00,04 MOVE 4,@FSLOC,@FRESTA GPL MOVE IT CCC7 20,9D,00 CCCA 8F,08,00 (TOTAL BYTES USED TO SET UP GPL MOVE 0 BYTES AND 1 GPL MOVE COMMAND WITH 9 BYTES USED) Now this is only in cases where numerous GPL commands have to be used to call a XML Assembly routine like MVUP or MVDN are used. I will use as many XML Assembly XB ROM routines as possible in RXB 2017 but some are just slower and memory hogs so more code needs to be looked into and timed. Edited November 16, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 16, 2017 Share Posted November 16, 2017 When you tested this were you replacing MTEST with ATEST so they would be in exactly the same place in the table when CALL looks up the name? If the subroutines ATEST and MTEST were both available at the same time then whichever one CALL comes to first would have a speed advantage. GPL runs on the 16 bit bus and the XB ROMS are on the 8 bit bus so it may well be that there are times when GPL could be faster. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 16, 2017 Share Posted November 16, 2017 (edited) When you tested this were you replacing MTEST with ATEST so they would be in exactly the same place in the table when CALL looks up the name? If the subroutines ATEST and MTEST were both available at the same time then whichever one CALL comes to first would have a speed advantage. GPL runs on the 16 bit bus and the XB ROMS are on the 8 bit bus so it may well be that there are times when GPL could be faster. Right and I timed this too. Know what it came out to for 100,000 times? (12 seconds and that was with 36 names between them, not one behind to the other like this test .) When I tested them one after the difference even at 100,000 loops was not even 1 second, that second just never showed up in the results on the clock. So add 1 second to the Assembly one and I guess it would be 6 minutes 23 seconds instead of 6 minutes 24 seconds for a true result. I can give you the GROM5 is you want to test it on Classic99. I even ran these tests on XB instead and a slight improvement but XB has many less commands than RXB. As for the ROMs being on the 8 bit bus that is why it uses the Scratch Pad for everything as much as possible, or as it is called in the XB ROM and GPL Source code ERAM. Edited November 16, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
RXB Posted November 16, 2017 Share Posted November 16, 2017 (edited) Just finished the XB ROMs Assembly: SOURCE is source code in one huge text file LIST is listing of the assembled file. XBROMS.zip Edited November 17, 2017 by RXB 1 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.