Jump to content
IGNORED

CRU BUG???


Recommended Posts


100 CALL CLEAR
120 CALL LINK("STCR"):: CALL PEEK(14000,A,B):: DISPLAY AT(24,1):A;B;"STCR"
130 GOTO 120

 

I have been playing around with CRU access from XB, and have found a very perplexing problem. RXB has CALL IO which, among other things, can be used to scan special keys on the keyboard. Here is a simple program for RXB.

   100 CALL CLEAR
   110 CALL IO(2,16,3,A,B):: DISPLAY AT(23,1):A;B
   130 GOTO 110

For CRU access, the GPL instruction IO sets up an instruction in R9, then performs it with X R9. You can see this code in Intern from >05EA to >0606

 

Here is a test assembly program that does the same thing as CALL IO(2,16,3,A,B):

            DEF STCR

STCR    LI R2,>8300
            CLR *R2
            LI R9,>3412
            LI R12,>0006
            X R9
            MOV @>8300,@14000  will peek these bytes from XB and print on screen
            B *R11
            END

 

and the XB program that uses it:

   100 CALL CLEAR
   120 CALL LINK("STCR"):: CALL PEEK(14000,A,B):: DISPLAY AT(24,1):A;B;"STCR"
   130 GOTO 120

This video shows the results when you press and hold the alt key, then the tab key. You will see it oscillate between two different values.

This is running in standard XB, and just the tab and alt key do this; the others behave normally.

CRUBUG.GIF.d8861753b4244373201fbe14917debe1.GIF

Here is the file for assembly support

CRU29-O

 

So the $64,000 question is this: What is going on here. Why does the same code give different results???

 

(Edit after thinking some more) I have a feeling this is somehow caused by my computer setup. I am running Classic99 in Windows XP using Oracle virtual box running in a linux system. I suspect that the keyboard response is getting messed up on its way to Classic99 through all those layers. Oddly, running the same STCR assembly sub under RXB seems to work fine running the exact same code.

I would guess this works fine running on a real TI99.

 

Edited by senior_falcon
  • Like 2
Link to comment
Share on other sites

5 hours ago, senior_falcon said:


100 CALL CLEAR
120 CALL LINK("STCR"):: CALL PEEK(14000,A,B):: DISPLAY AT(24,1):A;B;"STCR"
130 GOTO 120

 

I have been playing around with CRU access from XB, and have found a very perplexing problem. RXB has CALL IO which, among other things, can be used to scan special keys on the keyboard. Here is a simple program for RXB.

   100 CALL CLEAR
   110 CALL IO(2,16,3,A,B):: DISPLAY AT(23,1):A;B
   130 GOTO 110

For CRU access, the GPL instruction IO sets up an instruction in R9, then performs it with X R9. You can see this code in Intern from >05EA to >0606

 

Here is a test assembly program that does the same thing as CALL IO(2,16,3,A,B):

            DEF STCR

STCR    LI R2,>8300
            CLR *R2
            LI R9,>3412
            LI R12,>0006
            X R9
            MOV @>8300,@14000  will peek these bytes from XB and print on screen
            B *R11
            END

 

and the XB program that uses it:

   100 CALL CLEAR
   120 CALL LINK("STCR"):: CALL PEEK(14000,A,B):: DISPLAY AT(24,1):A;B;"STCR"
   130 GOTO 120

This video shows the results when you press and hold the alt key, then the tab key. You will see it oscillate between two different values.

This is running in standard XB, and just the tab and alt key do this; the others behave normally.

CRUBUG.GIF.d8861753b4244373201fbe14917debe1.GIF

Here is the file for assembly support

CRU29-O 640 B · 2 downloads

 

So the $64,000 question is this: What is going on here. Why does the same code give different results???

 

(Edit after thinking some more) I have a feeling this is somehow caused by my computer setup. I am running Classic99 in Windows XP using Oracle virtual box running in a linux system. I suspect that the keyboard response is getting messed up on its way to Classic99 through all those layers. Oddly, running the same STCR assembly sub under RXB seems to work fine running the exact same code.

I would guess this works fine running on a real TI99.

 

Yes you are right using RXB 2023 in FinalGROM in Classic99 CALL IO and on a bare TI99/4A console works exactly the same.

 

  • Like 1
Link to comment
Share on other sites

In thinking about the difference between XB and RXB it may be XB and RXB and GKXB have different ROMs that handle interrupts differently.

Thus, if you have interrupts from devices like CRU access may be handled differently per the ROM.

I am probably wrong but just a thought.

  • Like 1
Link to comment
Share on other sites

This is getting even stranger. i assumed this was somehow caused by my system. But it turns out that my real TI also behaves this way.

The program below pokes in a short assembly program and then CALL LINK("X") runs it.

In Classic99, with no keys pressed the numbers are 95,255. Press and hold the Alt key (function) and you get alternating 95,239 and 223,255.

On my TI99, with no keys pressed the numbers are 18,255.  Press and hold the Alt key (function) and you get alternating 18,239 and 146,255.

I should add that this is not perfectly rhythmic, i.e. it is somewhat random in how long the numbers are displayed before toggling.

 

Can someone try this in Classic99 and on a real TI99 and see what results they get?

The X R9 is borrowed from Intern, in the rom at >0604

Is there something wrong with the assembly code? Maybe something needs to be cleared before STCR *R4,16?

My TI99 is a bare console with 32K installed on the 16 bit bus. I was using standard XB and the expansion box was not turned on.


10 CALL INIT
20 CALL LOAD(9460,2,4,39,16,2,9,52,20,2,12,0,6,4,137,4,91)
30 CALL LOAD(8192,36,244)
40 CALL CLEAR
50 CALL LINK("X"):: CALL PEEK(10000,A,B):: DISPLAY AT(24,1):A;B
60 GOTO 50

 

LI R4,>2710      10000 in decimal

LI R9,>3414      the instruction in R9 is STCR *R4,16

LI R12,>0006

X R9

B *R11

 

 

Edited by senior_falcon
Link to comment
Share on other sites

I thought it was necessary to set the keyboard 'column' first via LDCR and then read the bits.  I've only ever "stored" 8 bits from the keyboard, i.e., STCR *R4,8.

 

Thierry's /4a site has good intel but I don't have the link handy at the moment.  edit: here is a link https://www.unige.ch/medecine/nouspikel/ti99/keyboard.htm#quick scan

 

1 hour ago, senior_falcon said:

Is there something wrong with the assembly code? Maybe something needs to be cleared before STCR *R4,16?

 

  • Like 1
Link to comment
Share on other sites

You're reading bits 3 to 18. Even if you specify that bits 3-10 should read the keyboard (by writing the column to bits 18-20), I think it's difficult to predict what you will read from the other bits.

 

https://www.unige.ch/medecine/nouspikel/ti99/tms9901.htm#CRU interface

 

Bit R12 address Meaning when read Effect when written
0 >0000 Mode, should be 0 1: switch to timer mode
1 >0002 Value of the INT1* pin (#17) Set interrupt mask for pin INT1* (1:int)
2 >0004 Value of the INT2* pin (#18) Set interrupt mask for pin INT2*
3 >0006 Value of the INT3* pin (#9) Set interrupt mask for pin INT3*
4 >0008 Value of the INT4* pin (#8) Set interrupt mask for pin INT4*
5 >000A Value of the INT5* pin (#7) Set interrupt mask for pin INT5*
6 >000C Value of the INT6* pin (#6) Set interrupt mask for pin INT6*
7 >000E Value of the INT7*/P15 pin (#34) Set interrupt mask for pin INT7*/P15
8 >0010 Value of the INT8*/P14 pin (#33) Set interrupt mask for pin INT8*/P14
9 >0012 Value of the INT9*/P13 pin (#32) Set interrupt mask for pin INT9*/P13
10 >0014 Value of the INT10*/P12 pin (#31) Set interrupt mask for pin INT10*/P12
11 >0016 Value of the INT11*/P11 pin (#30) Set interrupt mask for pin INT11*/P11
12 >0018 Value of the INT12*/P10 pin (#29) Set interrupt mask for pin INT12*/P10
13 >001A Value of the INT13*/P9 pin (#28) Set interrupt mask for pin INT13*/P9
14 >001C Value of the INT14*/P8 pin (#27) Set interrupt mask for pin INT14*/P8
15 >001E Value of the INT15*/P7 pin (#23) Set interrupt mask for pin INT15*/P7
16 >0020 Value of the P0 pin (#38) Set output value of pin P0
17 >0022 Value of the P1 pin (#37) Set output value of pin P1
18 >0024 Value of the P2 pin (#26) Set output value of pin P2
Edited by Asmusr
  • Like 2
Link to comment
Share on other sites

I added a line or two to load this...

 

10 CALL INIT
15 CALL LOAD("DSK1.FIRE1O")
20 CALL LOAD(9460,2,4,39,16,2,9,52,20,2,12,0,6,4,137,4,91)
30 CALL LOAD(8192,36,244)
40 CALL CLEAR
50 CALL LINK("X"):: CALL PEEK(10000,A,B):: DISPLAY AT(24,1):A;B
60 GOTO 50


       DEF X
X      LI R4,>2710
       LI R9,>3414
       LI R12,>0006
       X R9
       B *R11
       END

 

I got the 95,255...
When I press ALT, I get the 95,239...
When I press ALT+TAB, WINDOWS, cycles through my open apps.

  • Haha 1
Link to comment
Share on other sites

In line 20, the CALL LOAD(9460,....) loads those lines of assembly code without having to use object code. 

8192 (>2000) contains a pointer to the a/l routine that searches the DEF table for a match. Line 30 changes that pointer to point to 9460 which is the start of the assembly code poked in by line 20.

CALL LINK("X") starts up the assembly routine directly, without searching the DEF table. It doesn't have to be "X", but does have to be some string. CALL LINK will not work, nor will CALL LINK("")

I did it this way so you could copy and paste into Classic99.

Bottom line is this: If you have lines 20 and 30 you don't need line 15. If you have line 15 you don't need lines 20 and 30. Either way works.

Edited by senior_falcon
  • Like 1
Link to comment
Share on other sites

On 6/6/2023 at 7:30 AM, senior_falcon said:


100 CALL CLEAR
120 CALL LINK("STCR"):: CALL PEEK(14000,A,B):: DISPLAY AT(24,1):A;B;"STCR"
130 GOTO 120

 

I have been playing around with CRU access from XB, and have found a very perplexing problem. RXB has CALL IO which, among other things, can be used to scan special keys on the keyboard. Here is a simple program for RXB.

   100 CALL CLEAR
   110 CALL IO(2,16,3,A,B):: DISPLAY AT(23,1):A;B
   130 GOTO 110

For CRU access, the GPL instruction IO sets up an instruction in R9, then performs it with X R9. You can see this code in Intern from >05EA to >0606

 

Here is a test assembly program that does the same thing as CALL IO(2,16,3,A,B):

            DEF STCR

STCR    LI R2,>8300
            CLR *R2
            LI R9,>3412
            LI R12,>0006
            X R9
            MOV @>8300,@14000  will peek these bytes from XB and print on screen
            B *R11
            END

 

 

 

 

 

Like @InsaneMultitasker said, your program is undefined if you don't load a column address before reading the keyboard row.

 

You see 5F EF or DF FF.

 

You're reading 16 bits when all you need is 8 to read back the keyboard row. You could change your program to read 8 bits from >0006 and 3 bits from >0024. (read the last column select)

 

Your most significant bit toggles 0 or 1, which is the least significant of the keyboard column that was most recently chosen.

 

I have a guess - in the absence of a full KSCAN, XB is testing for FCTN-4.  This requires it to set column 0 to check FCTN, then column 3 to check the 4.

 

5F EF has to be an even column, and in column 0 you get EF  from the FCTN key.

 

DF FF has to be an odd column.  Consistent with checking if the 4 key is pressed. If it were: DF EF.

 

Try pressing FCTN-4 and see what you get?  Oh right, you need to disable breakpoints to see anything.

 

95,239   the first byte is not keyboard data
223,255

        >24         16  14         06
5F EF      0101 1111     1110 1111          reading fctn col?
DF FF      1101 1111     1111 1111          reading 4 col?


The left 1 bit is the LS bit of column select (output)
To read the fctn key, you set column 
Reading from left to right:

24 0/1 least bit of column select
22 1/1 nc
20 0/0 nc
1E 1/1 alias bit at >2E = CS2 motor, output

1C 1/1 audio gate
1A 1/1 mic enabled
18 1/1 pull up
16 1/1 headphone in

14 1/1 nc   X C V B Z nc nc
12 1/1 ctrl W E R T Q nc nc
10 1/1 shft S D F G A nc nc
0E 0/1 fctn 2 3 4 5 1 up up

0C 1/1 nc   9 8 7 6 0 dn dn
0A 1/1 entr O I U Y P rt rt
08 1/1 spc  L K J H ; lf lf
06 1/1  =   . , M N / fi fi

 

  • Like 2
Link to comment
Share on other sites

Full disclosure: I personally have no interest in using cru access. I think my brain is not wired in a way so that I can understand this.

This discussion arises because there was a request to add cru access to XB 2.9 G.E.M. along the lines of CALL IO in RXB.

In the RXB manual on page I11 there is a sample program, part of which is this:

110 CALL IO(2,16,3,A,B) which my code mimics. However my results were slightly different for some of the keys pressed.

This naturally leads to the question of whether there is an error in my code, otherwise why would it behave differently.

I have a guess - in the absence of a full KSCAN, XB is testing for FCTN-4.

That is the clue that I needed. RXB has disabled the quit key. When I disable the quit key in regular XB or XB 2.9 G.E.M., then when I run my test program the behavior is the same as RXB

Now I am finally satisfied that my code is correct.

Thanks to all who helped me get to this point!

Edited by senior_falcon
  • Like 8
Link to comment
Share on other sites

4 hours ago, senior_falcon said:

Full disclosure: I personally have no interest in using cru access. I think my brain is not wired in a way so that I can understand this.

This discussion arises because there was a request to add cru access to XB 2.9 G.E.M. along the lines of CALL IO in RXB.

In the RXB manual on page I11 there is a sample program, part of which is this:

110 CALL IO(2,16,3,A,B) which my code mimics. However my results were slightly different for some of the keys pressed.

This naturally leads to the question of whether there is an error in my code, otherwise why would it behave differently.

I have a guess - in the absence of a full KSCAN, XB is testing for FCTN-4.

That is the clue that I needed. RXB has disabled the quit key. When I disable the quit key in regular XB or XB 2.9 G.E.M., then when I run my test program the behavior is the same as RXB

Now I am finally satisfied that my code is correct.

Thanks to all who helped me get to this point!

Wow great catch!

Yea that bit for the quit key is disabled, but that code was created by Miller Graphics for GK XB and I just incorporated that into RXB.

The CALL IO command is just 100% GPL command used in the OS and I just plug in the variables.

  • Like 2
Link to comment
Share on other sites

Crazy :) For what it's worth as far as Classic99's simulated keyboard works (remember you CAN enable the stock keyboard if you need closer-to-real behaviour)... TAB is FCTN-7 (so that it tabs in Editor/Assembler). I don't think it acts as a joystick fire button unless the system has actually scanned the joystick recently. (This is definitely the behaviour of the arrow keys, but I'm not sure offhand if the fire button acts that way. Most likely, though, since it needs to know whether to return FIRE or Fctn-7. ;) )

 

  • Like 3
  • Thanks 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...