+TheBF Posted November 17, 2017 Share Posted November 17, 2017 I was reading on the keyboard on the Nouspikel site and found this little gem that I had never noticed before. *--------------------------------------------- * Calling the built-in Fctn-4 test in console ROM *--------------------------------------------- TESTF4 BL @>0020 R12 will be modified JEQ CLEAR Fctn-4 was pressed JNE NOCLR It wasn't I coded up a version for my Forth system to time it. It puts a true/false flag in R4 and it only takes 170 micro-seconds, measured using the 9901 internal timer. Wow! that is a much better way to interact with the user while in a loop than anything I have coded and it's almost 7X faster than KSCAN. I didn't look at FB-Forth code yet, but maybe that's how the ?TERMINAL routine is coded? CODE: FNCT4? ( -- ?) \ 170uS 16 bit ROM speed TOS PUSH, TOS CLR, 0020 @@ BL, \ R12 will be modified @@1 JNE, \ It wasn't pressed TOS SETO, @@1: NEXT, END-CODE 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 18, 2017 Share Posted November 18, 2017 I was reading on the keyboard on the Nouspikel site and found this little gem that I had never noticed before. *--------------------------------------------- * Calling the built-in Fctn-4 test in console ROM *--------------------------------------------- TESTF4 BL @>0020 R12 will be modified JEQ CLEAR Fctn-4 was pressed JNE NOCLR It wasn't I coded up a version for my Forth system to time it. It puts a true/false flag in R4 and it only takes 170 micro-seconds, measured using the 9901 internal timer. Wow! that is a much better way to interact with the user while in a loop than anything I have coded and it's almost 7X faster than KSCAN. I didn't look at FB-Forth code yet, but maybe that's how the ?TERMINAL routine is coded? CODE: FNCT4? ( -- ?) \ 170uS 16 bit ROM speed TOS PUSH, TOS CLR, 0020 @@ BL, \ R12 will be modified @@1 JNE, \ It wasn't pressed TOS SETO, @@1: NEXT, END-CODE fbForth’s ?TERMINAL calls the following fbForth system routine (inherited from TI Forth) in low RAM: ;[*== ?TERMINAL routine CODE = -8 ================= * scan for <clear> press * QTM EQU $LO+$-LLVSPT <---NOTE: resolves to low RAM address of next instruction (>3424) LI R12,>0024 Load CRU keyboard select CLR R4 Column 0 LDCR R4,3 SRC R12,7 Take time(?) LI R12,>0006 STCR R12,8 Fetch all of column 0 from CRU LI R3,>1000 CZC R3,R12 Fctn key? (>1000) JNE QTERM1 LI R12,>0024 CRU 2nd key LI R4,>0300 Column 3 (left byte) LDCR R4,3 SRC R12,7 Take time(?) LI R12,>0006 STCR R12,8 Fetch all of column 3 from CRU CZC R3,R12 '4' key? (>1000) QTERM1 STST R0 Store status in R0 ANDI R0,>2000 EQU set? B @BKLINK ;]* This is pretty much the same code as what you called in the console ROM. Except for a couple of the instructions in the console routine, I would think your FNCT4? faster due to its running on the 16-bit bus. ...lee [EDIT: See note at QTM label in above code. Other edits in this color.] 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 18, 2017 Author Share Posted November 18, 2017 Ok. Well I am changing my name to ?Terminal to match yours. It was what I always used in old DOS Forths too. I am removing my ^C? Word too. It was slower and bigger and not very TI99ish. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 18, 2017 Share Posted November 18, 2017 Here is the console code for checking for FCTN-4: C020 B @C4B2 . . . C4B2 LI R12,>24 POINT TO KBD LDCR @HX0008,3 PNT TO CTL/SHFT ETC SRC R12,7 WAIT LI R12,6 POINT TO KBD INPUTS STCR R12,8 READ ALL 8 I/PS CZC @HX1000,R12 FUNCTION DOWN? JNE C4DC YES, EXIT LI R12,>24 POINT TO KBD LDCR @C074,3 POINT TO '4' LINE SRC R12,7 WAIT LI R12,6 POINT TO I/PS STCR R12,8 GET DATA CZC @HX1000,R12 '4' DOWN? C4DC RT Note that a label beginning with ‘C’ has the hex address of its line following the ‘C’, e.g., ‘C020’ is console address >0020. ...lee Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 18, 2017 Author Share Posted November 18, 2017 Here is the console code for checking for FCTN-4: C020 B @C4B2 . . . C4B2 LI R12,>24 POINT TO KBD LDCR @HX0008,3 PNT TO CTL/SHFT ETC SRC R12,7 WAIT LI R12,6 POINT TO KBD INPUTS STCR R12,8 READ ALL 8 I/PS CZC @HX1000,R12 FUNCTION DOWN? JNE C4DC YES, EXIT LI R12,>24 POINT TO KBD LDCR @C074,3 POINT TO '4' LINE SRC R12,7 WAIT LI R12,6 POINT TO I/PS STCR R12,8 GET DATA CZC @HX1000,R12 '4' DOWN? C4DC RT Note that a label beginning with ‘C’ has the hex address of its line following the ‘C’, e.g., ‘C020’ is console address >0020. ...lee Thanks! Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 27, 2017 Author Share Posted November 27, 2017 Here is the console code for checking for FCTN-4: C020 B @C4B2 . . . C4B2 LI R12,>24 POINT TO KBD LDCR @HX0008,3 PNT TO CTL/SHFT ETC SRC R12,7 WAIT LI R12,6 POINT TO KBD INPUTS STCR R12,8 READ ALL 8 I/PS CZC @HX1000,R12 FUNCTION DOWN? JNE C4DC YES, EXIT LI R12,>24 POINT TO KBD LDCR @C074,3 POINT TO '4' LINE SRC R12,7 WAIT LI R12,6 POINT TO I/PS STCR R12,8 GET DATA CZC @HX1000,R12 '4' DOWN? C4DC RT Note that a label beginning with ‘C’ has the hex address of its line following the ‘C’, e.g., ‘C020’ is console address >0020. ...lee By the way... Is there a reason this console ROM routine is not used by TI-Forth/FB-Forth? 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 27, 2017 Share Posted November 27, 2017 By the way... Is there a reason this console ROM routine is not used by TI-Forth/FB-Forth? That's a good question. Not only would it save 40+ bytes, it should execute faster (16-bit bus and all). H-m-m-m...perhaps I will change that with the upcoming fbForth 2.0:11. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 27, 2017 Share Posted November 27, 2017 (edited) One of the uglier things in KSCAN is this: 038E 1302 JEQ >0394 0390 06A0 BL @>0498 ... 0498 020C LI 12,>04E2 Loop counter 049A 04E2 049C 060C DEC 12 049E 16FE JNE >049C 04A0 045B B *11 (taken from TI intern) So the KSCAN routine deliberately burns cycles. And the delay subroutine is called from more than one position. Edited November 27, 2017 by mizapf Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 27, 2017 Share Posted November 27, 2017 0366 MOV 1,3 0368 SLA 3,3 036A DEC 3 036C INC 3 036E SLA 4,1 Here's another one from KSCAN. Why the DEC followed by the INC? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 27, 2017 Share Posted November 27, 2017 One of the uglier things in KSCAN is this: 038E 1302 JEQ >0394 0390 06A0 BL @>0498 ... 0498 020C LI 12,>04E2 Loop counter 049A 04E2 049C 060C DEC 12 049E 16FE JNE >049C 04A0 045B B *11 (taken from TI intern) So the KSCAN routine deliberately burns cycles. And the delay subroutine is called from more than one position. The delay loop is called in only two places in KSCAN and then only when a key press is detected. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 27, 2017 Share Posted November 27, 2017 0366 MOV 1,3 0368 SLA 3,3 036A DEC 3 036C INC 3 036E SLA 4,1 Here's another one from KSCAN. Why the DEC followed by the INC? Here is the TI source for that plus some surrounding code: C354 SZC R0,R4 JEQ C37A MOV R1,R1 ON LAST STROBE ? JNE C360 NO MOV R5,R5 PLAYER 0? JNE C37A NO C360 MOV R2,R2 1ST TIME ROUND LOOP JNE C37A NO SETO R2 SET 'NOT FIRST TIME ROUND' FLAG MOV R1,R3 MOVE LOOP (STROBE NO) TO R3 SLA R3,3 MPY BY 8 DEC R3 COMP FOR FOLLOWING INC C36C INC R3 SLA R4,1 JNC C36C * R3= 8*KBD STROBE+BIT POSITION MOV R1,R1 LAST STROBE? JEQ C37A YES LI R1,1 ...lee Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 27, 2017 Author Share Posted November 27, 2017 That's a good question. Not only would it save 40+ bytes, it should execute faster (16-bit bus and all). H-m-m-m...perhaps I will change that with the upcoming fbForth 2.0:11. ...lee I will send you my consultation invoice. Don't worry it's only Canadian dollars. But for sure you could do a lot with 40 extra bytes I'm sure. 3 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 27, 2017 Share Posted November 27, 2017 The delay loop is called in only two places in KSCAN and then only when a key press is detected. ...lee If I calculated it correctly for 0 wait states in 16-bit console ROM and scratchpad RAM, the delay loop takes 8.33 ms each time it is invoked—presumably for key debounce. ...lee Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted November 27, 2017 Share Posted November 27, 2017 I will send you my consultation invoice. Don't worry it's only Canadian dollars. But for sure you could do a lot with 40 extra bytes I'm sure. I would charge per byte saved 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 28, 2017 Share Posted November 28, 2017 By the way... Is there a reason this console ROM routine is not used by TI-Forth/FB-Forth? That's a good question. Not only would it save 40+ bytes, it should execute faster (16-bit bus and all). H-m-m-m...perhaps I will change that with the upcoming fbForth 2.0:11. ...lee After changing the system code that ?TERMINAL calls to call the console routine, I found that both that code and the older, somewhat slower code copied from the console ROM are too fast. The terminal input routine catches the <break> as an extra keystroke and displays it. Upon checking the TI Forth source code, I find that I had changed it in fbForth from this: *== ?TERMINAL ROUTINE CODE= -8 ============================ * QTM BLWP @KSCAN MOVB @KYCHAR,R0 SRL R0,8 CI R0,>2 JEQ QTERM1 CLR R0 QTERM1 B @BKLINK Obviously, calling KSCAN has sufficient delay (~8.33 ms) after detecting a keystroke to avoid the “extra keystroke”. I guess I will need to add a debounce loop or go back to the old TI Forth code—plus, it is shorter. ...lee Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 28, 2017 Author Share Posted November 28, 2017 After changing the system code that ?TERMINAL calls to call the console routine, I found that both that code and the older, somewhat slower code copied from the console ROM are too fast. The terminal input routine catches the <break> as an extra keystroke and displays it. Upon checking the TI Forth source code, I find that I had changed it in fbForth from this: *== ?TERMINAL ROUTINE CODE= -8 ============================ * QTM BLWP @KSCAN MOVB @KYCHAR,R0 SRL R0,8 CI R0,>2 JEQ QTERM1 CLR R0 QTERM1 B @BKLINK Obviously, calling KSCAN has sufficient delay (~8.33 ms) after detecting a keystroke to avoid the “extra keystroke”. I guess I will need to add a debounce loop or go back to the old TI Forth code—plus, it is shorter. ...lee I didn't look at how you use it exactly, but I created a break word that calls the ROM routine once looking for key pressed and then waits in a loop until the key is released. That works very reliably. If you don't like the action to happen on key release, then the key release loop could include a countdown timer. Since calling the routine is just one BL , you might still save space by including the fancy key release timer loop. My 2 cents Canadian (only worth 1.6 cents USD ) B Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 28, 2017 Share Posted November 28, 2017 I didn't look at how you use it exactly, but I created a break word that calls the ROM routine once looking for key pressed and then waits in a loop until the key is released. That works very reliably. If you don't like the action to happen on key release, then the key release loop could include a countdown timer. Since calling the routine is just one BL , you might still save space by including the fancy key release timer loop. My 2 cents Canadian (only worth 1.6 cents USD ) B OK...Here is some pretty tight code with a debounce loop that calls the same 16-bit console code as the initial call: ;[*== ?TERMINAL routine CODE = -8 ================= * scan for <clear> press * QTM EQU $LO+$-LLVSPT MOV LINK,R5 save return BL @>0020 branch to console's test for FCTN+4 STST R0 store status in R0 JNE QTM2 exit if not <clear> QTM1 BL @>0020 check for <clear> again JEQ QTM1 loop until not <clear> QTM2 MOV R5,LINK restore return ANDI R0,>2000 keep only EQU bit B @BKLINK return to caller ;]* I am tempted to BL directly to >04B2 in the console, thus avoiding the extra B to that address from >0020. The only thing stopping me is remembering that there are a couple of minor variants of the console ROM code out there that could mess that up if there is an address offset before >04B2. ...lee Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 28, 2017 Author Share Posted November 28, 2017 OK...Here is some pretty tight code with a debounce loop that calls the same 16-bit console code as the initial call: ;[*== ?TERMINAL routine CODE = -8 ================= * scan for <clear> press * QTM EQU $LO+$-LLVSPT MOV LINK,R5 save return BL @>0020 branch to console's test for FCTN+4 STST R0 store status in R0 JNE QTM2 exit if not <clear> QTM1 BL @>0020 check for <clear> again JEQ QTM1 loop until not <clear> QTM2 MOV R5,LINK restore return ANDI R0,>2000 keep only EQU bit B @BKLINK return to caller ;]* I am tempted to BL directly to >04B2 in the console, thus avoiding the extra B to that address from >0020. The only thing stopping me is remembering that there are a couple of minor variants of the console ROM code out there that could mess that up if there is an address offset before >04B2. ...lee That was quick. So that is about 18..20 bytes ? So you save 24 or so. If it works like you need it to, that sounds like a winner. Quote Link to comment Share on other sites More sharing options...
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.