Jump to content
IGNORED

CTRL Key in XB after autoload doesn't work


wolhess

Recommended Posts

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.

 

Link to comment
Share on other sites

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 worked

did this next... new line 105... problem fixed... if not solved... waste of MEM+TIME!


100 CALL CLEAR
105 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 160
140 PRINT "CTRL 1-3 OK!"
150 GOTO 120
160 PRINT "KEY";K;"STATUS";S
170 GOTO 120

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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 by RXB
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

  • Like 3
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

  • Like 3
Link to comment
Share on other sites

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

  • Like 4
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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 by RXB
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...