RXB Posted June 7, 2017 Share Posted June 7, 2017 RXB 2017 or 2018 update progress: (Removing all commands so the XB commands are smaller in number for each CALL done, thus they do double or triple duty for more speed.) 1. Removed CALL XBPGM and now CALL XB or CALL XB("DSK#.FILENAME") replaced this command. 2. Removed CALL EAPGM, CALL EALR and CALL EAED now CALL EA or CALL EA("DSK#.FILENAME") replaced these commands. (Rich Editor Assembler figures out what kind of file is selected to loads and runs that menu automatically.) 3. Removed CALL AMSBANK and now CALL SAMS(lowbank#,highbank#) replaced this command. a. Removed CALL AMSON and now CALL SAMS("ON") replaced this command. b. Removed CALL AMSOFF and now CALL SAMS("OFF") replaced this command. c. Removed CALL AMSMAP and now CALL SAMS("MAP") replaced this command. d. Removed CALL AMSPASS and now CALL SAMS("PASS") replaced this command. 4. Removed CALL AMSINIT as now when RXB boots it sets up SAMS now. 5. Removed for lack of use: a. CALL DUPCHAR b. CALL DUPCOLOR c. CALL SWAPCHAR d. CALL SWAPCOLOR 6. Repaired CALL FCOPY("DEVICE PATH',"FILENAME","DEVICE PATH","FILENAME") introduced a error in source code I did not see. 3 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted June 7, 2017 Share Posted June 7, 2017 RXB 2017 or 2018 update progress: (Removing all commands so the XB commands are smaller in number for each CALL done, thus they do double or triple duty for more speed.) 5. Removed for lack of use: a. CALL DUPCHAR b. CALL DUPCOLOR c. CALL SWAPCHAR d. CALL SWAPCOLOR Rich, I think these commands have a lot of potential and should be preserved. My 2 cents. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 7, 2017 Share Posted June 7, 2017 (edited) Rich, I think these commands have a lot of potential and should be preserved. My 2 cents. Well I could make them 1 command: CALL CHAR(character-code,D or S,character-code) { "D" for Duplicate patterns or "S" for Swap character patterns} CALL COLOR(character-set,D or S,character-set) { "D" for Duplicate character-set colors or "S" for Swap character-set colors} or CALL COLOR(Spirte#,D or S,Sprite#) { "D" for Duplicate Sprite color and "S" for Swap Sprite colors} This would continue to reduce command numbers in list and not have a huge effect on performance for CHAR or COLOR. NOTE: It occurred I could add in R for REVERSE PATTERN in CALL CHAR, or I for INVERSE turning off pixels that are on and off pixels on. Example: CALL CHAR(character-code,R) or CALL CHAR(character-code,I) Edited June 7, 2017 by RXB 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 9, 2017 Share Posted June 9, 2017 Rich, I think these commands have a lot of potential and should be preserved. My 2 cents. Ok finished the new version sticking with your request kinda... Normal XB or RXB: CALL CHAR(char#,pattern-string) RXB 2012 introduced: CALL CHAR(ALL,pattern-string) ! The replaces all characters from 30 to 159 with the pattern-string RXB current beta CALL CHAR(DUPLICATE,char#,char#) ! You can use D or DUP or Duplicate the first letter only matters and this duplicates a string-pattern from first char# to second char# CALL CHAR(SWAP,char#,char#) ! You can use S or SWAP or Swap the first letter only matters and this swaps a string-pattern from first char# with second char# Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted June 9, 2017 Share Posted June 9, 2017 Great! Thanks! When will the new binaries be available? Quote Link to comment Share on other sites More sharing options...
RXB Posted June 9, 2017 Share Posted June 9, 2017 Great! Thanks! When will the new binaries be available? Well have a portion of XB ROMs that I am really puzzled about. You can find this section in the SOURCE of XB ROMs I posted several times now..... * R8 (CHAT) = 10 ? LN7F8C MOV R11,R3 *# Save Return address in R3 LN7F8E MOV R8,R0 * Put R8 into R0 LN7F90 LI R2,>000A * Put >000A into R2 (>000A = 10) LN7F94 AI R0,>FFD0 * Add >FFD0 into R0 LN7F98 C R0,R2 * R0 = R2 ? LN7F9A JL LN7FAC * Lower jump LN7F9C CLR R0 * Zero out R0 LN7F9E B *R3 * RETURN * LN7FA0 MPY R2,R0 *# Muliply R2 by R0 LN7FA2 MOV R0,R0 * Set status byte? LN7FA4 JNE LN7F48 * Not Equal Error LN7FA6 MOV R1,R0 * PUt R1 into R0 LN7FA8 A R8,R0 * Add R8 into R0 LN7FAA JLT LN7F48 * Lower Than jump LN7FAC BL @LN6FBA *# Put word at VARW at VDP Address in R15 LN7FB0 MOVB R1,*R4 Put MSB R1 into Address MSB R4 LN7FB2 JEQ LN7FC0 * Equal jump LN7FB4 AI R8,>FFD0 * Add >FFD0 into R8 LN7FB8 C R8,R2 * R8 = R2 ? LN7FBA JL LN7FA0 *# Lower jump LN7FBC DEC @VARW * VAR0 - 1 LN7FC0 CLR R8 *# Zero out R8 LN7FC2 MOV R0,R0 *# Set Status byte? LN7FC4 JEQ LN7F48 * Equal jump LN7FC6 B *R3 * RETURN * * TOKEN LIST LN7FC8 BYTE >81 *# (ELSE Token) 12 bytes Called from LN7D38 LN7FC9 BYTE >85 * (GO Token) LN7FCA BYTE >86 * (GOTO Token) LN7FCB BYTE >87 * (GOSUB Token) LN7FCC BYTE >88 * (RETURN Token) LN7FCD BYTE ?8E * (BREAK Token) LN7FCE BYTE >8F * (UNBREAK Token) LN7FCF BYTE >94 * (RESTORE Token) LN7FD0 BYTE >A5 * (ERROR Token) LN7FD1 BYTE >A9 * (RUN Token) LN7FD2 BYTE >B0 * (THEN Token) LN7FD3 BYTE >ED * (USING Token) * LN7FD4 BYTE >FF LN7FD5 BYTE >00 * # LN7FD6 DATA >020C LN7FD8 DATA >0528 LN7FDA DATA >0728 LN7FDE DATA >0828 LN7FE0 DATA >8200 LN7FE2 DATA >833C LN7FE4 DATA >9328 LN7FE6 DATA >9A3C LN7FE8 DATA >9D6C LN7FEA DATA >A15C LN7FEC DATA >A322 * LN7FD4 SOCB R0,*R12+ >FF00 '..' 7FD4 LN7FD6 LI R12,>0528 >020C,>0528 '...(' 7FD6 LN7FDA SETO @>0828(R8) >0728,>0828 '.(.(' 7FDA LN7FDE C R0,R8 >8200 '..' 7FDE LN7FE0 C *R12+,R12 >833C '.<' 7FE0 LN7FE2 CB @>9A3C(R8),R12 >9328,>9A3C '.(.<' 7FE2 LN7FE6 CB @>A15C(R12),*R5+ >9D6C,>A15C '.l.\' 7FE6 LN7FEA A @>FF00(R2),R12 >A322,>FF00 '."..' 7FEA LN7FEE ANDI R0,>0100 >0240,>0100 '.@..' 7FEE LN7FF2 JEQ >7FF8 >1302 '..' 7FF2 LN7FF4 SB @>7D65,*R4 >7520,>7D65 'u }e' 7FF4 LN7FF8 B *R11 >045B '.[' 7FF8 AORG >7FFE LN7FFE 7FFE LN7FFE MOV R12,*R10 >C68C '..' 7FFE SLAST END * ANDI R0,>0100 or Subract byte MSB from Address at R4 LN7FEE ANDI R0,>0100 *# Set only the 0's LN7FF2 JEQ LN7FF8 * Equal jump LN7FF4 SB @LN7D65,*R4 * Subtract >20 from Address at MSB of R4 LN7FF8 B *R11 *# RETURN * LN7FFA DATA >0000 LN7FFC DATA >0000 LN7FFE DATA >9226 SLAST END Really puzzled about this section and what is going on. Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 10, 2017 Share Posted June 10, 2017 That looks like the disassembler went off the rails somewhere.Are all entry points into that range accounted for? Well have a portion of XB ROMs that I am really puzzled about. You can find this section in the SOURCE of XB ROMs I posted several times now..... * R8 (CHAT) = 10 ? LN7F8C MOV R11,R3 *# Save Return address in R3 LN7F8E MOV R8,R0 * Put R8 into R0 LN7F90 LI R2,>000A * Put >000A into R2 (>000A = 10) LN7F94 AI R0,>FFD0 * Add >FFD0 into R0 LN7F98 C R0,R2 * R0 = R2 ? LN7F9A JL LN7FAC * Lower jump LN7F9C CLR R0 * Zero out R0 LN7F9E B *R3 * RETURN * LN7FA0 MPY R2,R0 *# Muliply R2 by R0 LN7FA2 MOV R0,R0 * Set status byte? LN7FA4 JNE LN7F48 * Not Equal Error LN7FA6 MOV R1,R0 * PUt R1 into R0 LN7FA8 A R8,R0 * Add R8 into R0 LN7FAA JLT LN7F48 * Lower Than jump LN7FAC BL @LN6FBA *# Put word at VARW at VDP Address in R15 LN7FB0 MOVB R1,*R4 Put MSB R1 into Address MSB R4 LN7FB2 JEQ LN7FC0 * Equal jump LN7FB4 AI R8,>FFD0 * Add >FFD0 into R8 LN7FB8 C R8,R2 * R8 = R2 ? LN7FBA JL LN7FA0 *# Lower jump LN7FBC DEC @VARW * VAR0 - 1 LN7FC0 CLR R8 *# Zero out R8 LN7FC2 MOV R0,R0 *# Set Status byte? LN7FC4 JEQ LN7F48 * Equal jump LN7FC6 B *R3 * RETURN * * TOKEN LIST LN7FC8 BYTE >81 *# (ELSE Token) 12 bytes Called from LN7D38 LN7FC9 BYTE >85 * (GO Token) LN7FCA BYTE >86 * (GOTO Token) LN7FCB BYTE >87 * (GOSUB Token) LN7FCC BYTE >88 * (RETURN Token) LN7FCD BYTE ?8E * (BREAK Token) LN7FCE BYTE >8F * (UNBREAK Token) LN7FCF BYTE >94 * (RESTORE Token) LN7FD0 BYTE >A5 * (ERROR Token) LN7FD1 BYTE >A9 * (RUN Token) LN7FD2 BYTE >B0 * (THEN Token) LN7FD3 BYTE >ED * (USING Token) * LN7FD4 BYTE >FF LN7FD5 BYTE >00 * # LN7FD6 DATA >020C LN7FD8 DATA >0528 LN7FDA DATA >0728 LN7FDE DATA >0828 LN7FE0 DATA >8200 LN7FE2 DATA >833C LN7FE4 DATA >9328 LN7FE6 DATA >9A3C LN7FE8 DATA >9D6C LN7FEA DATA >A15C LN7FEC DATA >A322 * LN7FD4 SOCB R0,*R12+ >FF00 '..' 7FD4 LN7FD6 LI R12,>0528 >020C,>0528 '...(' 7FD6 LN7FDA SETO @>0828(R8) >0728,>0828 '.(.(' 7FDA LN7FDE C R0,R8 >8200 '..' 7FDE LN7FE0 C *R12+,R12 >833C '.<' 7FE0 LN7FE2 CB @>9A3C(R8),R12 >9328,>9A3C '.(.<' 7FE2 LN7FE6 CB @>A15C(R12),*R5+ >9D6C,>A15C '.l.\' 7FE6 LN7FEA A @>FF00(R2),R12 >A322,>FF00 '."..' 7FEA LN7FEE ANDI R0,>0100 >0240,>0100 '.@..' 7FEE LN7FF2 JEQ >7FF8 >1302 '..' 7FF2 LN7FF4 SB @>7D65,*R4 >7520,>7D65 'u }e' 7FF4 LN7FF8 B *R11 >045B '.[' 7FF8 AORG >7FFE LN7FFE 7FFE LN7FFE MOV R12,*R10 >C68C '..' 7FFE SLAST END * ANDI R0,>0100 or Subract byte MSB from Address at R4 LN7FEE ANDI R0,>0100 *# Set only the 0's LN7FF2 JEQ LN7FF8 * Equal jump LN7FF4 SB @LN7D65,*R4 * Subtract >20 from Address at MSB of R4 LN7FF8 B *R11 *# RETURN * LN7FFA DATA >0000 LN7FFC DATA >0000 LN7FFE DATA >9226 SLAST END Really puzzled about this section and what is going on. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 10, 2017 Share Posted June 10, 2017 I would search for references to the section 7fd4 to 7fea. You may be looking at artifacts from the original assembly where space was reserved with BSS or by virtue of its address. Random code can be placed in these locations during linkage and loading. The code in its current forms doesn't make any sense, it's either unused or referenced for some purpose. The code from 7fee-7ff8 is testing one bit in R0 then returning or adjusting the address at R4 based on whether it was set(1) or reset(0). Without knowing what R0 and R4 represent, it's hard to determine the routine's purpose. (A personal preference I thought I'd mention for future: whenever I disassemble code, I use the second pass so that only the referenced addresses and labels are generated. Having labels on every line makes code more difficult to read, IMHO. The address is included at the end of each line, so you can keep things 'cleaner' this way. ) Quote Link to comment Share on other sites More sharing options...
RXB Posted June 10, 2017 Share Posted June 10, 2017 I have multiple places where I have disassembled to figure out and some worse then others for what is going on. Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 10, 2017 Share Posted June 10, 2017 I have multiple places where I have disassembled to figure out and some worse then others for what is going on. keep in mind it might be data. The FF at LN7FD4 is an end of table marker and the 00 that follows is probably filler to align to 16 bits. What are the values that precede that table up to LN7F9E? Quote Link to comment Share on other sites More sharing options...
RXB Posted June 10, 2017 Share Posted June 10, 2017 keep in mind it might be data. The FF at LN7FD4 is an end of table marker and the 00 that follows is probably filler to align to 16 bits. What are the values that precede that table up to LN7F9E The source has been posted several times now: The LN7F9E is in CODPAGE2 called from this: * CALLED FROM CRUNCH * LN7B88 MOV R11,R12 * Save Retrun Address in R12 LN7B8A MOVB *R13,R3 * GROM Data into MSB R3 (GROM AUTO INCREMENTS) LN7B8C BL @LN60F2 *# SUBSTACK+2,read GROM Data LN7B90 CLR @FAC * Zero out FAC LN7B94 LI R4,LR8 * PUt LR8 into R4 (LR8 is LSB of R8) LN7B98 CLR R8 * Zero out R8 LN7B9A BL @LN6FAC * Write VARW to Address int R15, R1 = >2000 ? LN7B9E MOVB R1,*R4 * Put MSB R1 into Address location MSB R4 LN7BA0 JEQ LN7C94 * Equal jump LN7BA2 SRL R3,8 * Strip High Byte from Word LN7BA4 JEQ LN7BB4 * Equal jump LN7BA6 LI R2,LN7E5A * Put >7E5A into R2 LN7BAA LI R10,LN7E28 * Load Return Address in R10 LN7BAE LI R7,LN7E7A * Load Return Address in R7 LN7BB2 JMP LN7BF2 * jump * LN7BB4 INC @BUFLEV *# BUFLEV + 1 LN7BB8 CLR @LENCST * Zero out LENCST LN7BBC MOVB R8,@PRGFLG * Put MSB R8 into MSB PRGFLG LN7BC0 BL @LN7F8C * R8 (CHAT) = 10 ? LN7BC4 MOV R0,@FAC * Put FAC into R0 LN7BC8 JEQ LN7BD2 * Equal jump LN7BCA BL @LN6FAC * Write VARW to Address int R15, R1 = >2000 ? LN7BCE MOVB R1,*R4 * Put MSB R1 into Address MSB R4 LN7BD0 JEQ LN7C94 * Equal jump LN7BD2 LI R7,LN7C1E * Put >7C1E into R7 LN7BD6 LI R6,LN7ED4 * Put >7ED4 into R6 LN7BDA JMP LN7BF2 * jump And called from here: LN7F08 MOV R8,R8 * Put R8 into R8 (Set Status bit) LN7F0A JEQ LN7F50 * Equal jump LN7F0C BL @LN7F8C * R8 (CHAT) = 10 ? LN7F10 MOV R0,R0 * Put R0 into R0 (Set status bit) LN7F12 JEQ LN7F28 * Equal jump LN7F14 LI R8,>00C9 * R8 = (Line Number Constant token) ? LN7F18 BL @LN7F6E * Check for Crunch Buffer end, Write R1 to VDP LN7F1C MOV R0,R8 * Put R0 into R8 LN7F1E SWPB R8 * Swap bytes in R8 LN7F20 BL @LN7F6E * Check for Crunch Buffer end, Write R1 to VDP LN7F24 SRL R8,8 * Strip High byte of word LN7F26 JMP LN7EA4 * jump As you can see there is a lot of code involved. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 21, 2017 Share Posted June 21, 2017 Update changes just finished instead of using strings I added tokens to XB for OFF, MAP, PASS for SAMS support. Also added DUP and SWAP for CALL COLOR and CALL CHAR support. Removed CALL AMSBANK and now CALL SAMS(lowbank#,highbank#) replaced this command. a. Removed CALL AMSON and now CALL SAMS(ON) replaced this command. b. Removed CALL AMSOFF and now CALL SAMS(OFF) replaced this command. c. Removed CALL AMSMAP and now CALL SAMS(MAP) replaced this command. d. Removed CALL AMSPASS and now CALL SAMS(PASS) replaced this command. Also allows you to do something like this CALL SAMS(ON,lowbank#,highbank#,OFF) More changes add XB tokens for DUP and SWAP: a. CALL DUPCHAR removed and replaced with CALL CHAR(DUP,char#,char#) b. CALL DUPCOLOR removed and replaced with CALL COLOR(DUP,colorset#,colorset#) c. CALL SWAPCHAR removed and replaced with CALL CHAR(SWAP,char#,char#) d. CALL SWAPCOLOR removed and replaced with CALL COLOR(SWAP,colorset#,colorset#) Add a new set of choices like CALL CHAR(128,"FF00FF",DUP,128,129,SWAP,43,87) The above puts "FF00FF" into character 128, duplicates that definition in 129, swaps character definitions 43 and 87 in one command. 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted June 22, 2017 Share Posted June 22, 2017 I have used ALL of the XB compilers and not a single one can you convert and compile with any speed, it is even slower than Assembly to do that as all the extra steps. XB is good for what it is designed for which is quickly type in a program and test as you go with the interpreter. Why are you even writing in XB if your goal is Assembly? I mean talk about doing something totally unnecessary to end up someplace else. Why not just write it in Assembly in the first place? Or for that matter C that is 100% designed around that idea in the first place. I'm a big fan of the XB256/BASIC Compiler package because it allowed my to increase the speed of my XB code 20-times. That's nowhere near the speed of Assembly code but still pretty good. Actually, a twenty times performance enhancement with zero knowledge of Assembly Language programming and zero required investment in TI-99/4 architecture knowledge is extremely impressive. The XB256 BASIC compiler workflow has also served as a nice bridge between BASIC and learning Assembly Language programming. It prepared me (a TI novice) by Introducing me to: A. Using an Assembler on Threaded Assembly code. B. Using modern PC based editors to edit code. C Learning the differences between assembly source code and an object file. D. Converting obj files to bin for FlashROM99 E. Exposure to Graphics II Mode and the TI's enhanced character and sprite capabilities. F. Exposure to multiple screen swapping. G. Memory management issues beyond what BASIC coding alone offers. Etc... Compiled BASIC opened up the entire Assembly paradigm for me. That's a big deal and may be why others may want to use it, even if "your goal is Assembly." As I learn more about system architecture and Assembly programming I consider my time spent with XB256 Compiled BASIC as invaluable. It rocked my world to see my BASIC code spring to life at speeds well beyond anything (known to me) short of Assembly Language itself. Best Part: The cost of entry for this non TI programmer elite -- minimal! "Why not just write it in Assembly in the first place?" Hopefully I've provided an answer. Using the compiler also motivated me to learn more and dig deeper into the TI-99/4A hobby. That's something? Hopefully this post can bring you down to my level for a moment. What may seem "unnecessary" to you was fascinating for me. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 22, 2017 Share Posted June 22, 2017 (edited) Hopefully this post can bring you down to my level for a moment. What may seem "unnecessary" to you was fascinating for me. Not ever did I say it was "unnecessary" so do not make up stuff I never once said please. I maintain that the Original XB or other versions of XB are faster to draft programs and test them, this is just a fact! Writing with compiler alone is many times slower for obvious reasons of the number of steps involved of using a compiler. Also XB256 is based on XB so you have it assbackwards on which one came first, XB came first by many years. Yea XB256 is a great way to make XB programs fast as it is Assembly, good fast product to use but it is compiled. And what is your level? RXB is a XB version how is this higher then your level of using Assembly? I write in GPL and Assembly all the time for RXB which is my product, do you suggest I should just quit? Just so you know RXB has been around since Rich GKXB was introduced in 1991. Edited June 22, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 22, 2017 Share Posted June 22, 2017 Rich, you keep repeating a misconception that you (and probably others) have about XB256. You are conflating XB256 and the compiler. They are separate, independent programs. XB256 is just that: Extended BASIC, but with two unique screens, one of which has all 256 characters available. Programs are written in Extended BASIC. Programs run in Extended BASIC. Programs are saved as XB and can be listed normally as in XB. It is fully compatible with Extended BASIC because it is Extended BASIC. It consists of a number of assembly language extensions that unlock much of the potential of the 9918A video processor but at its core it remains XB, warts and all. Floating point numbers? No problem. Named subprograms? No problem. Any faster than XB? Nope. It is not necessary, but if desired you can compile an XB program written using XB256. All the extra assembly routines are supported. Then you can get a 30-40x increase in speed, but then too the compiler restrictions kick in - no floating point numbers, no named subprograms, etc. 5 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 23, 2017 Share Posted June 23, 2017 True have not ever invested into research of XB256 and only ran a few demos so my misconceptions are outstanding or wrong. I have put quite a lot of time into TML and how it works. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 22, 2017 Share Posted July 22, 2017 Just to keep all my video on the same post of RXB I am also posting this here: Quote Link to comment Share on other sites More sharing options...
RXB Posted October 24, 2017 Share Posted October 24, 2017 Just a update on RXB next version I have eliminated commands CALL DUPCHAR(sprite#,sprite#) ! duplicates sprite definitions CALL SWAPCHAR(sprite#,sprite#) ! swaps sprite definitions CALL DUPCHAR(char#,char#) ! duplicates character definitions CALL SWAPCHAR(char#,char#) ! swaps character definitions CALL DUPCOLOR(sprite#,sprite#) ! duplicates sprite color CALL SWAPCOLOR(sprite#,spirte#) ! swaps sprite color CALL DUPCOLOR(char set,char set) ! duplicate character set color CALL SWAPCOLOR(char set,char ste) ! swap character set color Rolled into normal CALL CHAR and CALL COLOR new format addition: CALL COLOR(D,char set,char set) ! D indicates duplicate color set CALL COLOR(D,sprite#,sprite#) ! D indicates duplicate sprite color CALL COLOR(S,char set,char set) ! S indicates swap color set CALL COLOR(S,sprite#,sprite#) ! S indicates swap sprite color CALL CHAR(D,char#,char#) ! D indicates duplicate char definition CALL CHAR(S,char#,char#) ! S indicates swap char definition Of course this allows you to mix and match these formats in the same command; RXB: CALL COLOR(5,3,9,D,5,6,D,5,7,D,5,8,D,5,9) vs normal XB: CALL COLOR(5,3,9,6,3,9,7,3,9,8,3,9,9,3,9) As you can see the XB version is much harder to debug and read. RXB: CALL CHAR(55,"F87E651239AB4DCA",D,55,67) vs normal XB: Y$="F87E651239AB4DCA" :: CALL CHAR(55,Y$,67,Y$) As you can see XB version is forced to use a VDP String Variable and this will slow the program, also RXB version used 2 less bytes of program space. Other commands in RXB are going to be updated also. Quote Link to comment Share on other sites More sharing options...
RXB Posted October 25, 2017 Share Posted October 25, 2017 (edited) Just to continue with this list of progress other commands being eliminated from RXB and rolled into normal XB commands are: CALL PEEKV(address,variable) ! peek VDP address CALL PEEKG(address,variable) ! peek GRAM/GROM address CALL POKEV(address,byte value) ! poke VDP address CALL POKEG(address,byte value) ! poke GRAM address CALL POKER(VDP register number,byte value) These will be rolled into CALL LOAD and CALL PEEK using same method as previous post: CALL LOAD(V,address,variable) ! V indicates a VDP address CALL LOAD(G,address,variable) ! G indicates GRAM address CALL LOAD(R,VDP Register,variable) ! R indicates VDP Register to load CALL PEEK(V,address,variable) ! V indicates a VDP address CALL PEEK(G,address,variable) ! G indicates GRAM/GROM address Also CALL LOAD no longer needs a CALL INIT to load an Assembly Program as it checks to see if INIT has previously been called and if not does it for you. The reason for these changes are to cut back on the number of Subprogram names in RXB and speed up execution as the above approach has less cost for speed then scanning every subprogram name. See the only time the V, G, R is ever checked for is less then checking all 24 extra Subprogram names each time a subprogram is called and searched for to use. Also some future folding of RXB concepts into XB are like the Subprogram STR$("7.65") could be converted to use HEX and Binary: STR$(H,"FABC") = -1348 used strictly for Address in decimal for commands like CALL LOAD or CALL PEEK or other assembly support routines. STR$(B,"11100101") = 209 useful in RXB to use XB to manipulate bits in a XB program. This is a big deal to me as very little space is needed in RXB to make this work and has vast number of applications for Assembly support in the future. Edited October 25, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted October 25, 2017 Share Posted October 25, 2017 The reason for these changes are to cut back on the number of Subprogram names in RXB and speed up execution as the above approach has less cost for speed then scanning every subprogram name.See the only time the V, G, R is ever checked for is less then checking all 24 extra Subprogram names each time a subprogram is called and searched for to use. Have you actually tested this to find out if it is faster? A smaller table of subprograms would definitely speed things up, but you are adding one more item in the argument list (V,G or R) that has to be passed and that will take some time, plus you have a small lookup to find out if it is V,G or R. So it may work out to be no faster or even slower. Quote Link to comment Share on other sites More sharing options...
RXB Posted October 25, 2017 Share Posted October 25, 2017 (edited) The reason for these changes are to cut back on the number of Subprogram names in RXB and speed up execution as the above approach has less cost for speed then scanning every subprogram name.See the only time the V, G, R is ever checked for is less then checking all 24 extra Subprogram names each time a subprogram is called and searched for to use. Have you actually tested this to find out if it is faster? A smaller table of subprograms would definitely speed things up, but you are adding one more item in the argument list (V,G or R) that has to be passed and that will take some time, plus you have a small lookup to find out if it is V,G or R. So it may work out to be no faster or even slower. Only some Subprograms listed are being changed and the added comparison is not going to amount to much of a cost. Example of checking for V, G or R in CALL LOAD or CALL PEEK in GPL will not cost much speed unless the only command you use is CALL LOAD or CALL PEEK. And checking for only D or S in CALL COLOR or CALL CHAR is not going to be very noticeable. Also as shown originally post RXB versions take less space or are a shortcut vs XB normal methods. Do you have a suggestion to speed them up? After all the idea is to speed up XB not remove all of RXB as what is the point of my work? (It is very noticeable when you remove several Subprograms from the list of all of them remember RXB 5.58 had 40 additional commands and you could see a huge lag.) Edited October 25, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted October 25, 2017 Share Posted October 25, 2017 After all the idea is to speed up XB ..... And that is my question - have you confirmed that this actually speeds up XB? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 25, 2017 Share Posted October 25, 2017 Sounds like the lag that you mention happens as more subprograms are added. Does this also affect the user subprograms or are those searched differently? Seems a user subprogram would be at a disadvantage as more are added to the RXB table. I wonder if this is the same perceived slowness I saw with XB2.7, which was one reason I went back to standard XB for my BBS software. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted October 26, 2017 Share Posted October 26, 2017 NOTE: It occurred I could add in R for REVERSE PATTERN in CALL CHAR, or I for INVERSE turning off pixels that are on and off pixels on. Example: CALL CHAR(character-code,R) or CALL CHAR(character-code,I) 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted October 26, 2017 Share Posted October 26, 2017 After all the idea is to speed up XB ..... And that is my question - have you confirmed that this actually speeds up XB? Hmm yes like I said RXB version 5.58 had 40 more commands than normal XB and you could really see without even a timer it was affecting speed of XB overall performance. Everytime GPL had to search for a Subprogram like RXB CALL HPUT it was noticeably much slower with 39 more names to search through every command line. Just did a test and added these commands to normal XB: TITL 'SUBPROGRAM LIST TEST' *********************************************************** GROM >C034 *********************************************************** DATA LINK1 STRI 'FAKENAME1' DATA 0 LINK1 DATA LINK2 STRI 'FAKENAME2' DATA 0 LINK2 DATA LINK3 STRI 'FAKENAME3' DATA 0 LINK3 DATA LINK4 STRI 'FAKENAME4' DATA 0 LINK4 DATA LINK5 STRI 'FAKENAME5' DATA 0 LINK5 DATA LINK6 STRI 'FAKENAME6' DATA 0 LINK6 DATA LINK7 STRI 'FAKENAME7' DATA 0 LINK7 DATA LINK8 STRI 'FAKENAME8' DATA 0 LINK8 DATA LINK9 STRI 'FAKENAME9' DATA 0 LINK9 DATA LINKA STRI 'FAKENAMEA' DATA 0 LINKA DATA LINKB STRI 'FAKENAMEB' DATA 0 LINKB DATA LINKC STRI 'FAKENAMEC' DATA 0 LINKC DATA LINKD STRI 'FAKENAMED' DATA 0 LINKD DATA LINKE STRI 'FAKENAMEE' DATA 0 LINKF DATA LINKF STRI 'FAKENAMEF' DATA 0 LINKG DATA LINKH STRI 'FAKENAMEG' DATA 0 LINKH DATA LINKI STRI 'FAKENAMEH' DATA 0 LINKI DATA LINKJ STRI 'FAKENAMEI' DATA 0 LINKJ DATA LINKK STRI 'FAKENAMEJ' DATA 0 LINKK DATA LINKL STRI 'FAKENAMEK' DATA 0 LINKL DATA LINKM STRI 'FAKENAMEL' DATA 0 LINKM DATA LINKN STRI 'FAKENAMEM' DATA 0 LINKN DATA LINKO STRI 'FAKENAMEN' DATA 0 LINKO DATA LINKP STRI 'FAKENAMEO' DATA 0 LINKP DATA LINKQ STRI 'FAKENAMEP' DATA 0 LINKQ DATA LINKR STRI 'FAKENAMEQ' DATA 0 LINKR DATA LINKS STRI 'FAKENAMER' DATA 0 LINKS DATA LINKT STRI 'FAKENAMES' DATA 0 LINKT DATA LINKU STRI 'FAKENAMET' DATA 0 LINKU DATA LINKV STRI 'FAKENAMEU' DATA 0 LINKV DATA LINKW STRI 'FAKENAMEV' DATA 0 LINKW DATA LINKX STRI 'FAKENAMEW' DATA 0 LINKX DATA LINKY STRI 'FAKENAMEY' DATA 0 LINKZ DATA LINK 0 ******************************************** END Running this program in modified XB: 100 OPEN #1:"CLOCK" 110 INPUT #1:A$,B$,C$ 120 PRINT A$;B$;C$ 200 CALL FAKENAMEZ(33,X$) 210 X=X+1 220 IF X<99999 THEN 200 300 INPUT #1:A$,B$,C$ 310 PRINT A$;B$;C$ 400 GOTO 200 And normal XB: 100 OPEN #1:"CLOCK" 110 INPUT #1:A$,B$,C$ 120 PRINT A$;B$;C$ 200 CALL CHARPAT(33,X$) 210 X=X+1 220 IF X<99999 THEN 200 300 INPUT #1:A$,B$,C$ 310 PRINT A$;B$;C$ 400 GOTO 200 Took over 2 hours but the slower one was using more commands. 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.