wolhess Posted November 13, 2018 Share Posted November 13, 2018 Hi, I tried to make my own startmenue in XB. To change DSK1-3, I will use [ctrl]+1 for DSK1., [xtrl]+2 for DSK2 and [ctrl3]+3 for DSK3. If I start the small programm below with >OLD DSK1.PROG and >RUN, it works as expected. 100 CALL CLEAR 110 PRINT "KEY CHECK" 120 CALL KEY(0,K,S) 130 IF K>=177 AND K<=179 THEN 140 ELSE 160 140 PRINT "CTRL 1-3 OK!" 150 GOTO 120 160 PRINT "KEY";K;"STATUS";S 170 GOTO 120 If I autoload the programm (programm-name = load) in XB the programm doesn't accept [ctrl]+1-3! Normal key's and [FCTN]+key are working. What do I wrong in this case? Is anybody there who make it possible to use [CTRL]+1 after autoload? I tried this in RXB, XB2.5, XB2.7, stock TI and classic99, all the same problem. Thanks for any help, even if that does not work in XB. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 13, 2018 Share Posted November 13, 2018 Try keyboard mode 5. Just a quick guess. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted November 13, 2018 Share Posted November 13, 2018 Ahoy there... wolhess,I was not able to recreate your results using XB VER.110 on classic99 or real iron w/TIPI... "CTRL 1-3 OK!".Using RXB 2012 from classic99, I did realize the issue... if I BREAK with FCTN 4 then CONTINUE... CTRL keys work... "CTRL 1-3 OK!"(dark blue screen)hmm... processing...tried mizapf's idea... it workeddid this next... new line 105... problem fixed... if not solved... waste of MEM+TIME!100 CALL CLEAR105 CALL KEY(5,K,S)110 PRINT "KEY CHECK"120 CALL KEY(0,K,S)130 IF K>=177 AND K<=179 THEN 140 ELSE 160140 PRINT "CTRL 1-3 OK!"150 GOTO 120160 PRINT "KEY";K;"STATUS";S170 GOTO 120 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 13, 2018 Share Posted November 13, 2018 Here's an idea that might work. I don't know for sure because I am at work and cannot test it out until tonight. Save this one line program as LOAD 10 RUN "DSK1.MENU" And of course you need to save the menu program as MENU By avoiding autoload when loading MENU it may make the program respond as expected. Autoload can do funny things. I remember Bruce Harrison having problems with random numbers when autoloading a program. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 13, 2018 Share Posted November 13, 2018 The point is that keyboard mode 0 means: same mode as last time. Keyboard mode 5 is the BASIC mode. If I remember correctly, keyboard mode 3 is a TI-99/4-compatible mode without CTRL key. It seems as if the autoload feature of Extended Basic does not set the mode and keeps the mode from the master title screen. Surprisingly, I cannot reproduce the problem with MAME. The original program senses the CTRL key, unless I explicitly use mode 3. I wonder whether the difference is caused by a particular peripheral setup, or whether there is another version of the Extended Basic module. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 13, 2018 Share Posted November 13, 2018 (edited) The point is that keyboard mode 0 means: same mode as last time. Keyboard mode 5 is the BASIC mode. If I remember correctly, keyboard mode 3 is a TI-99/4-compatible mode without CTRL key. It seems as if the autoload feature of Extended Basic does not set the mode and keeps the mode from the master title screen. Surprisingly, I cannot reproduce the problem with MAME. The original program senses the CTRL key, unless I explicitly use mode 3. I wonder whether the difference is caused by a particular peripheral setup, or whether there is another version of the Extended Basic module. You know what you may be Right about that? RXB 2000 on all have Quit Key TURNED OFF on RXB start up: [3508] *********************************************************** [3509] 7A38 B6,80,C2 RXBRUN OR >10,@>83C2 QUIT KEY OFF 7A3B 10 [3510] 7A3C B2,45,F7 AND >F7,@FLAG Set flag [3511] 7A3F BD,04,7E DST @YPT,@VARY Save Row/Col values [3512] 7A42 04,01 BACK >01 [3513] 7A44 07,80 ALL >80 I wonder if turning off the Quit Key is also creating this problem? Edited November 13, 2018 by RXB Quote Link to comment Share on other sites More sharing options...
Casey Posted November 14, 2018 Share Posted November 14, 2018 I took some time tonight to experiment with this on my real iron 99/4A. I have a beige console with 1981 software, and first, I plugged in a beige V110 Extended BASIC cartridge, and then saved the program as DSK1.LOAD. The program ran as expected - CTRL1-3 were detected just fine when autoloaded. I then put in my FinalGROM99 and ran the V110 Extended BASIC from there. It also behaved the expected way. Next, I tried V100 Extended BASIC - it never detected CTRL 1-3, even if I changed the CALL KEY to key unit 5. Next, Extended BASIC V2.6 - it did not work when autoloaded, but breaking the program and then running the program produced the expected results. Next, RXB 2015 - same behavior. It did not work when autoloaded, but breaking the program and then running it produced the expected results. Next, Mechatronic Extended BASIC - it behaved correctly. Just some data points - not sure what exactly it means. I do know that in the past I've had differences in how things worked between different V110 Extended BASIC cartridges, so it could be something that was fixed later. I'd be curious how a black Extended BASIC cartridge behaves on real iron with this program. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted November 14, 2018 Share Posted November 14, 2018 I took some time tonight to experiment with this on my real iron 99/4A. I have a beige console with 1981 software, and first, I plugged in a beige V110 Extended BASIC cartridge, and then saved the program as DSK1.LOAD. The program ran as expected - CTRL1-3 were detected just fine when autoloaded. I then put in my FinalGROM99 and ran the V110 Extended BASIC from there. It also behaved the expected way. Next, I tried V100 Extended BASIC - it never detected CTRL 1-3, even if I changed the CALL KEY to key unit 5. Next, Extended BASIC V2.6 - it did not work when autoloaded, but breaking the program and then running the program produced the expected results. Next, RXB 2015 - same behavior. It did not work when autoloaded, but breaking the program and then running it produced the expected results. Next, Mechatronic Extended BASIC - it behaved correctly. Just some data points - not sure what exactly it means. I do know that in the past I've had differences in how things worked between different V110 Extended BASIC cartridges, so it could be something that was fixed later. I'd be curious how a black Extended BASIC cartridge behaves on real iron with this program. Ahoy there... wolhess, I was not able to recreate your results using XB VER.110 on classic99 or real iron w/TIPI... "CTRL 1-3 OK!". The cartridge reports version 110, is black... and was a gift with a hand written masking tape label. Quote Link to comment Share on other sites More sharing options...
wolhess Posted November 14, 2018 Author Share Posted November 14, 2018 Try keyboard mode 5. Just a quick guess. Thank You mizapf. This was the trick! 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted November 14, 2018 Author Share Posted November 14, 2018 Thank you all for your fast responses! The hint from Michael using CALL KEY(5,K,S) is working fine. I also tested the way to start the keycheck program from LOAD with RUN "DSK1.KEYCHECK". The result was the same as starting the program as autoload. I think the RUN statement and autoload uses the same way without CTRL-Key accepted. What I learned is we have in XB not only the key unit codes 0,1,2 as described on page 109 of the book "TI Extended Basic - For the TI-99/4 Home Computer" The numbers 3,4 and 5 are also accepted in CALL KEY. The CTRL-Keys are supported in key unit code 1 (with diffrent return codes), 4 and 5 with the correct return codes. It is amazing, every time I ask something in this forum I get the right answers in very fast time. Thank you again to all! 3 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 14, 2018 Share Posted November 14, 2018 The reason why nearly all BASIC programs use keyboard mode 0 is, in my view, because we learned it this way from the TI manuals. TI used this mode maybe for the sake of compatibility with 99/4 consoles. When you write programs with mode 0, they should run on all consoles; but on the 99/4A it means you keep the previous keyboard mode. If you use mode 5, they will not run on a 99/4 (just tried in MAME, only modes 0,1,2 are available). It would make more sense to use the explicit mode 5 setting at all times (or 1 or 2 for split keyboard). Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 14, 2018 Share Posted November 14, 2018 The keyboard modes are discussed in detail in §2.6.10 “KEY subprogram” and §3.3 “Keyboard mapping” in the TI-99/4A User’s Reference Guide. As has been pointed out by @mizapf, mode 0 specifies the last-used of modes 3, 4 and 5. The keyboard modes are described as follows: Mode Description ---- ----------- 0 Previously specified mode (3, 4 or 5) 1 Left side of keyboard or joystick 1 –character codes: 0 – 19 2 Right side of keyboard or joystick 2 –character codes: 0 – 19 3 Standard TI-99/4 mode –character codes: 0 – 127, but returned as all caps –FCTN codes: 1 – 15 –CTRL codes: none 4 Pascal mode –character codes: 0 – 127, upper and lower case –FCTN codes: 129 – 143 –CTRL codes: 1 – 31 5 Basic mode –character codes: 0 – 127, upper and lower case –FCTN codes: 1 – 15 –CTRL codes: 128 – 159, 187 What the above-referenced sections do not tell you is how the 4A keeps track of the previous (whole or unsplit) keyboard mode. The keyboard mode is specified to the keyboard scanning routine (KSCAN) by storing its value (0 – 5) at >8374. This is what “CALL KEY(mode,key,status)” does and you can do it explicitly, as you would need to do in Assembler. KSCAN decodes the byte at >8374 by testing first for mode 0. Failing that, KSCAN tests for modes 1 and 2, decrementing it and testing for 0 each time. If it is neither mode 1 nor 2, the final decrement yields 0, 1, 2 or a nonsense number. If the former, the reduced value is stored in >83C6 (MSB of console ISR workspace R3). It is >83C6 that tells the 4A which of modes 3, 4 and 5 was last specified for the keyboard. Whatever the value, KSCAN clears (sets to 0) >8374, so you can never discover the last keyboard mode by checking >8374. You can get this information the same way the console does by checking the byte at >83C6. By the way, for TI Basic and Extended Basic, the decimal addresses for >8374 and >83C6 are -31884 and -31802, respectively. ...lee 3 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 14, 2018 Share Posted November 14, 2018 I never really understood what advantage there was to using mode 0 given the potential pitfalls. It doesn't seem to have a speed advantage. Is there a tie-in with JOYST or some other routine(s)? Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 14, 2018 Share Posted November 14, 2018 I've always used "0" for every routine I've ever written. I don't know why, I just always have. 1 Quote Link to comment Share on other sites More sharing options...
Casey Posted November 14, 2018 Share Posted November 14, 2018 Same with me. I’ve always used mode 0 because everything else I saw always did. I don’t recall ever seeing a program in a magazine listing use anything other than 0, 1, or 2. Maybe on an occasion I’ve seen 3 used, but certainly never 4 or 5.... 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 14, 2018 Share Posted November 14, 2018 Well, the Extended Basic (XB) manual was written for the TI-99/4, which did not use anything but 0, 1 or 2 for keyboard mode. Under the description for “CALL KEY()”, modes 3, 4 and 5 are listed as “for future expansion”. So, for the TI-99/4, you could only use ‘0’ for full keyboard. The addendum to the XB manual does discuss use of modes 3, 4 and 5 for the TI-99/4A, which handles them as I indicated in my last post. Using mode 0 is usually to be preferred for default conditions because the system presumably gets set up for the proper whole keyboard mode. For the TI-99/4, it really is mode 0 and only mode 0 for the full keyboard. But, for the TI-99/4A, once you get into TI Basic or XB, it should be set up for mode 5, which you can show by checking the byte at >83C6 and adding 3 to it, i.e., >83C6 should have a value of 2. Barring a user change, the fact that there was anything other than ‘2’ at >83C6 after XB autoloaded “DSK1.LOAD” is a bug in XB, as far as I am concerned. ...lee 4 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 14, 2018 Share Posted November 14, 2018 I never really understood what advantage there was to using mode 0 given the potential pitfalls. It doesn't seem to have a speed advantage. Is there a tie-in with JOYST or some other routine(s)? No. When key-unit is 1 or 2 (left or right keyboard/joystick), the default, full keyboard mode indicated at >83C6 is not checked or changed. Only specifying a key-unit of 3, 4 or 5 will update >83C6 for the next invocation of key-unit 0. And, only on the TI-99/4A, of course. ...lee 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 14, 2018 Share Posted November 14, 2018 (edited) Well, the Extended Basic (XB) manual was written for the TI-99/4, which did not use anything but 0, 1 or 2 for keyboard mode. Under the description for “CALL KEY()”, modes 3, 4 and 5 are listed as “for future expansion”. So, for the TI-99/4, you could only use ‘0’ for full keyboard. The addendum to the XB manual does discuss use of modes 3, 4 and 5 for the TI-99/4A, which handles them as I indicated in my last post. Using mode 0 is usually to be preferred for default conditions because the system presumably gets set up for the proper whole keyboard mode. For the TI-99/4, it really is mode 0 and only mode 0 for the full keyboard. But, for the TI-99/4A, once you get into TI Basic or XB, it should be set up for mode 5, which you can show by checking the byte at >83C6 and adding 3 to it, i.e., >83C6 should have a value of 2. Barring a user change, the fact that there was anything other than ‘2’ at >83C6 after XB autoloaded “DSK1.LOAD” is a bug in XB, as far as I am concerned. ...lee The QUIT KEY disabled is why RXB gets this effect, but then it was a oddball way of finding it. No one likes accidently hitting QUIT KEY when using the TI99/4A and losing everything they were working on. This was a majority request for me from users. (First demoed on Miller Graphics GKXB) Edited November 14, 2018 by RXB Quote Link to comment Share on other sites More sharing options...
Opry99er Posted November 14, 2018 Share Posted November 14, 2018 I've always been curious about GKXB. I never had a copy, but is it essentially a predecessor to RXB? It required the GK to run it because we didn't have GROM emulation available in cartridge form? Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 14, 2018 Share Posted November 14, 2018 I've always been curious about GKXB. I never had a copy, but is it essentially a predecessor to RXB? It required the GK to run it because we didn't have GROM emulation available in cartridge form? Yes. I used it a lot, the addons are great, and fixing the quit key + there's some line editor changes too..very nice Quote Link to comment Share on other sites More sharing options...
RXB Posted November 15, 2018 Share Posted November 15, 2018 Well this is the reason RXB used Keyboard mode 0 and even XB sets Keyboard 5 then clears Keyboard mode to zero: *********************************************************** * START OF BASIC INTERPETER *********************************************************** * GROM Address >6372 TOPLEV AORG >0372 TOPLEV CLR V@LODFLG Initialize temp area * RXB PATCH CODE USER *********************************** * MOVE 77,V@LODFLG,V@LODFLG+1 * ST 5,@KEYBD Select full keyboard * SCAN * CZ @KEYBD * BR G6388 99/4A Console? * ST >01,V@CONFLG Select 99/4A console ST V@CONFLG,@FAC Save CONFLG MOVE 77,V@LODFLG,V@LODFLG+1 ST @FAC,V@CONFLG Restore CONFLG BR G6388 BR G6388 * G6388 CLR @KEYBD So need to fix this so it does the same as normal XB. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 15, 2018 Share Posted November 15, 2018 Ok FIXED RXB [0656] *********************************************************** [0657] * START OF BASIC INTERPETER [0658] *********************************************************** [0659] * GROM Address >6372 TOPLEV [0660] AORG >0372 [0661] 6372 86,A3,71 TOPLEV CLR V@LODFLG Initialize temp area [0662] * RXB PATCH CODE USER *********************************** [0663] * MOVE 77,V@LODFLG,V@LODFLG+1 [0664] * ST 5,@KEYBD Select full keyboard [0665] * SCAN [0666] * CZ @KEYBD [0667] * BR G6388 99/4A Console? [0668] * ST >01,V@CONFLG Select 99/4A console [0669] 6375 BC,4A,A3 ST V@CONFLG,@FAC Save CONFLG 6378 BB [0670] 6379 35,00,4D MOVE 77,V@LODFLG,V@LODFLG+1 637C A3,72,A3 637F 71 [0671] 6380 BC,A3,BB ST @FAC,V@CONFLG Restore CONFLG 6383 4A [0672] 6384 BE,74,05 ST 5,@KEYBD Select full keyboard scan [0673] 6387 03 SCAN [0674] * [0675] 6388 86,74 G6388 CLR @KEYBD Now it does exactly what XB 110 does. 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 15, 2018 Share Posted November 15, 2018 Ok FIXED RXB [0656] *********************************************************** [0657] * START OF BASIC INTERPETER [0658] *********************************************************** [0659] * GROM Address >6372 TOPLEV [0660] AORG >0372 [0661] 6372 86,A3,71 TOPLEV CLR V@LODFLG Initialize temp area [0662] * RXB PATCH CODE USER *********************************** [0663] * MOVE 77,V@LODFLG,V@LODFLG+1 [0664] * ST 5,@KEYBD Select full keyboard [0665] * SCAN [0666] * CZ @KEYBD [0667] * BR G6388 99/4A Console? [0668] * ST >01,V@CONFLG Select 99/4A console [0669] 6375 BC,4A,A3 ST V@CONFLG,@FAC Save CONFLG 6378 BB [0670] 6379 35,00,4D MOVE 77,V@LODFLG,V@LODFLG+1 637C A3,72,A3 637F 71 [0671] 6380 BC,A3,BB ST @FAC,V@CONFLG Restore CONFLG 6383 4A [0672] 6384 BE,74,05 ST 5,@KEYBD Select full keyboard scan [0673] 6387 03 SCAN [0674] * [0675] 6388 86,74 G6388 CLR @KEYBD Now it does exactly what XB 110 does. You do not need G6388 CLR @KEYBD to zero @KEYBD. SCAN does that for you for free when @KEYBD contains 3, 4 or 5. Of course, because it is labeled, perhaps you need it for something else, like allowing use by a TI-99/4, which does not allow any mode greater than 2 and must use mode 0 for the full keyboard. I have not seen KSCAN from a TI-99/4 console ROM, but I would guess it zeros @KEYBD, just like the TI-99/4A, when it finds an illegal mode. ...lee Quote Link to comment Share on other sites More sharing options...
RXB Posted November 16, 2018 Share Posted November 16, 2018 You do not need G6388 CLR @KEYBD to zero @KEYBD. SCAN does that for you for free when @KEYBD contains 3, 4 or 5. Of course, because it is labeled, perhaps you need it for something else, like allowing use by a TI-99/4, which does not allow any mode greater than 2 and must use mode 0 for the full keyboard. I have not seen KSCAN from a TI-99/4 console ROM, but I would guess it zeros @KEYBD, just like the TI-99/4A, when it finds an illegal mode. ...lee I agree but was in original XB code not what I put in....so yea I can remove it but just left it for 2 extra bytes. Problem I have with code is so many address have to remain the same for XB ROMs and people writing routines that continue to work. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 16, 2018 Share Posted November 16, 2018 I agree but was in original XB code not what I put in....so yea I can remove it but just left it for 2 extra bytes. Problem I have with code is so many address have to remain the same for XB ROMs and people writing routines that continue to work. Yeah—I keep running into code with double meanings in the console ROM. Witness these five gems marked by the original TI programmers as “nasty”: C025 EQU $+1 NASTY [$ is >0024, so ref. is >0025] C030 LI R0,>0020 C030 REFD (0200) NASTY [>0200 is the value of the instruction word] HX20 EQU $+1 =>20 (NASTY) [>20 is the value of the second byte of the following “MOVB” inst.] * = BR TABLE BRESET MOVB @STATUS,R4 IS CONDITION SET? HX06 DEC R5 MORE TO LOOK AT? REF IS NASTY [>06 is value of first byte of “DEC R5”] HX0300 LIMI 1 LABEL IS NASTY! [>0300 is value of “LIMI” instruction] ...lee 1 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.