KSCAN questions

[+retroclouds]

I'm currently refactoring Stevie for improving compatibility with keyboard debounce, USB keyboards and emulators (for example CPU overdrive mode in classic99).

Until now I rolled my own keyboard scanning routine that was based on the work of Simon Koppelmann. 

 

The idea is to just call the KSCAN routine as included in the console ROM. 

Before digging in, I looked at the documented source code TI-99/4A intern, ROM 0 disassembly of addresses 02B2-0496.

 

This is where the questions come in. For KSCAN to work I need to have scratchpad memory setup prepared.

 

One of the first things KSCAN does is a call BL @>0864 to save the GROM-address on the substack. At least that is what TI-Intern says.

 

Does the GROM-address need to be saved because it gets overwritten by setting the GROM address for things like CNTRL, FCTN, SHIFT, letters table?

 

What the best place to find some working KSCAN examples?

 

Is there anything special I need to worry about when calling KSCAN (besides the scratchpad memory locations as derived from console rom disassembly) ?

[+Lee Stewart]

3 hours ago, retroclouds said:

One of the first things KSCAN does is a call BL @>0864 to save the GROM-address on the substack. At least that is what TI-Intern says.

 

See TI-99/4A Operating System for what seems to be the TI original (commented) source code for the console ROM (ZIP file in first post).

 

...lee

[+retroclouds]

I have this weird issue on my TI-99/4a which must be related to KSCAN. 

 

The good news is that I switched to KSCAN in Stevie and in the editor everything is working as expected. Happy about that.

Now in Stevie I have the possibility to open a TI-Basic session, basically what happens is that I pick a session in Stevie, some setup is done for TI-Basic and you are in TI-Basic.

 

If you want to know more about it, related source code is here:

https://github.com/MirrorPusher/Stevie/blob/master/src/modules/tibasic.session.asm

 

Now here to the strange part:

If I press the FCTN key in TI-Basic, the cursor is blocked and the LEDs of all peripheral expansion cards (HDR, TIPI PEB, disk controller), light up. 

As soon as I release the FCTN key everything is back to normal, cursor blinks and LEDS are off again and the interpreter keeps on working.

Note that this behaviour happens on the real TI-99/4A only. In classic99 and js99er everything works as one might expect.

 

First I thought it was related to my ISR that I'm using for switching back to Stevie. But it's not that. Got the same when the ISR isn't setup.

Then I checked scratchpad locations for invalid setup, that still is a possibile cause. But haven't found anything yet.

 

The stupid thing is, that because of this "bug" I can't use the function arrow keys for editing in TI-Basic.

FCTN-Quit does work as expected and brings the TI Title screen again.

 

Any clues what this might be? Could this be a left-over of the keyboard not being properly setup during last CRU scan? It must have something to do with CRU I suppose.

Kinda lost here.

 

EDIT: Note that TI Basic behaves normally if I jump right into it from the TI selection screen.

 

Edited January 10, 2022 by retroclouds

[RXB]

I suspect this it tied to the GPL IO command and CRU to Keyboard in TI Basic.

Page 39 of TI INTERN address: >0CC8

 

Keep an eye on GPL Status byte and Error code that may be why key and I/O are being intertwined thru a single flag bit being set or unset.

 

Ran into this similar if not all files are closed as the DSR uses I/O command for file access/Keyscan and unclosed files really creates a mess.

 

 

Edited January 10, 2022 by RXB

[+retroclouds]

1 hour ago, RXB said:

I suspect this it tied to the GPL IO command and CRU to Keyboard in TI Basic.

Page 39 of TI INTERN address: >0CC8

 

Keep an eye on GPL Status byte and Error code that may be why key and I/O are being intertwined thru a single flag bit being set or unset.

 

Ran into this similar if not all files are closed as the DSR uses I/O command for file access/Keyscan and unclosed files really creates a mess.

 

 

 

Thanks Rich. That rings a bell somehow.

Might well be that my TI-Basic initialisation is not properly done. Have to do some more testing in the next days. Will let you know on the results.

[Stuart]

Is the KSCAN routine assuming that R12 is set to a particular value (>0000?), and it's not because you've used R12 to program the SAMS mapper? Have you tried saving the value of R12 before changing it for the mapper, then restoring the value?

 

Like in these places?

        li    r12,>1e00             ; \ Disable SAMS mapper (transparent mode)
        sbz   1                     ; / 
        ;-------------------------------------------------------
        ; Run TI Basic session in GPL Interpreter
        ;-------------------------------------------------------
        lwpi  >83e0
        li    r1,>216f              ; Entrypoint for GPL TI Basic interpreter
        movb  r1,@grmwa             ; \
        swpb  r1                    ; | Set GPL address
        movb  r1,@grmwa             ; / 
        nop
        b     @>70                  ; Start GPL interpreter

        li    r12,>1e00             ; \ Disable SAMS mapper (transparent mode)
        sbz   1                     ; / 
        ;-------------------------------------------------------
        ; Resume TI Basic interpreter
        ;------------------------------------------------------- 
        b     @>0ab8                ; Return from interrupt routine.
                                    ; See TI Intern page 32 (german)

 

Edited January 10, 2022 by Stuart

[HOME AUTOMATION]

Maybe if you initialize PAD, to the state it's normally in during the TI's selection menu, before starting the GPL interpreter.

[+retroclouds]

Took some time to look into this weird issue again. Was able to narrow down to this piece of extra code I used to detect the status of the alpha-lock key.
That code was basically part of my wrapper around kscan, as seen in the following commit:

 

https://github.com/MirrorPusher/spectra2/blob/facf40d83a4b11650aeb9ffcb50287a99dd01d98/src/modules/keyb_rkscan.asm

 

Here's the offending snippet:

        ;------------------------------------------------------
        ; (1) Check for alpha lock
        ;------------------------------------------------------ 
        li    r12,>002a             ; Address of alpha lock
        sbz   0                     ; Set wire low
        li    r12,>000e             ; Select keyboard row 5
        tb    0                     ; Test input wire (ALPHA-Lock key down?)
        sbo   0                     ; Set wire high
        jeq   rkscan.prepare        ; No, alpha lock is off
        blabla                      ; Yes, alpha lock is on, so
                                     

As far as I can tell, the problem was caused by the "sbo 0" instruction.

I looked at Thierry's site and I'm still unsure here. But it looks that by setting the bit I'm basically enabling interrupt on INT7*

That was not an issue in my Stevie editor itself, because I have "limi 0" there all of the time.

But in TI Basic interrupts are enabled. I presume that what happened was, that by pressing the FCTN key I trigger an interrupt that can't be recognized/handled in the interrupt service routine. Is that what happened?

As said, that's a behaviour that only happens on the real deal, not in classic99 nor in js99er. Haven't tested in MAME because Stevie doesn't work there.

 

In the console ROM (looked at TI intern) I found the following code for checking alpha lock:

        ;------------------------------------------------------
        ; (1) Check for alpha lock (same as in console rom. works)
        ;------------------------------------------------------ 
        clr   r12
        sbz   >0015                 
        tb    7
        jeq   rkscan.prepare        ; No, alpha lock is off
        blabla                      ; Yes, alpha lock is on

If I understand the code correctly:

1. "sbz >15" sets the output value of bit 21 to low, that is pin P5 attached to alpha lock column

2. "tb 7" is then used to check the status of the INT7*/P15 pin (that's the keyboard row with the keys FCTN, 2, 3, 4, 5, 1, (joy1-up, joy2-up, Alpha lock)

 

Is that correct?

 

It seems that as far as CRU is concerned, there are many ways to skin the cat when reading the keyboard.

Working with the CRU is kinda mind-boggling to me, probably because I haven't done any low-level HW/SW stuff before. But hey, I guess you are never too old to learn.

Edited January 16, 2022 by retroclouds

[+mizapf]

Here is my CRU map of the keyboard. P2 is bit >12, P3 is bit >13, P4 is bit >14, P5 is bit >15, relative to CRU base 0. You have to appropriately set these lines to 1 (P5 to 0) to select the column in this matrix. When you press a key of this column, the respective INT line will turn to 0. Note that TB copies the CRU bit into the EQ bit of the status register, so when you have a JEQ, it will jump when the line is 1 (not actuated). The INT inputs are active low (should actually read /INT5 ... /INT10).

 

[HOME AUTOMATION]

47 minutes ago, retroclouds said:

As far as I can tell, the problem was caused by the "sbo 0" instruction.

I looked at Thierry's site and I'm still unsure here. But it looks that by setting the bit I'm basically enabling interrupt on INT7*

Bit	R12 address	Meaning when read	Effect when written
0	>0000	Mode, should be 0	1: switch to timer mode

 

TMS9901 The TI-99/4A Tech Pages

 

As I recall, not much else works, when in timer mode.

[+retroclouds]

1 minute ago, HOME AUTOMATION said:

Bit	R12 address	Meaning when read	Effect when written
0	>0000	Mode, should be 0	1: switch to timer mode

 

TMS9901 The TI-99/4A Tech Pages

 

As I recall, not much else works, when in timer mode.

But R12 was set before as below, so it's not bit 0. If the CRU were to be switched to timer mode, than I would have expected more of a lockup?

li    r12,>000e

[HOME AUTOMATION]

Oops, got a little ahead of myself again.

 

Here's something else unrelated, that might not help either...

 

Understanding Microprocessors Radio Shack & Texas Instruments Learning Center

 

[Tursi]

5 hours ago, retroclouds said:

Here's the offending snippet:

        ;------------------------------------------------------
        ; (1) Check for alpha lock
        ;------------------------------------------------------ 
        li    r12,>002a             ; Address of alpha lock
        sbz   0                     ; Set wire low
        li    r12,>000e             ; Select keyboard row 5
        tb    0                     ; Test input wire (ALPHA-Lock key down?)
        sbo   0                     ; Set wire high
        jeq   rkscan.prepare        ; No, alpha lock is off
        blabla                      ; Yes, alpha lock is on, so
                                     

As far as I can tell, the problem was caused by the "sbo 0" instruction.

 

Note that your SBO is changing a different bit than the SBZ...

 

It's probably less confusing to leave R12 at 0 and set/clear the specific desired bit, but I suppose in the long run it shouldn't matter.

 

[+Lee Stewart]

6 hours ago, retroclouds said:

Here's the offending snippet:

        ;------------------------------------------------------
        ; (1) Check for alpha lock
        ;------------------------------------------------------ 
        li    r12,>002a             ; Address of alpha lock
        sbz   0                     ; Set wire low
        li    r12,>000e             ; Select keyboard row 5
        tb    0                     ; Test input wire (ALPHA-Lock key down?)
        sbo   0                     ; Set wire high
        jeq   rkscan.prepare        ; No, alpha lock is off
        blabla                      ; Yes, alpha lock is on, so

 

 

Here is the commented KSCAN snippet (related to your code above) from the TI source code (containing your quoted TI Intern code):

        CLR  R12
        MOV  R3,R3
        JEQ  C43E
        SBZ  21                PUT ALPHA LOCK STROBE DOWN
        SRC  R12,14            WAIT
        TB   7                 ALPHA LOCK DOWN?
        JEQ  C442              NO
 C43E   SB   @HX2000,R0        CHANGE TO UPPER CASE
 C442   SBO  21                RESET A/LOCK STROBE
 C444   MOV  R3,R3
        JNE  C456

 

As @Tursi implied, you are complementing the wrong CRU bit to reset Alpha lock. Furthermore, note that KSCAN has a wait between the SBZ and the TB. The wait is a 14-bit SRC of R12 that is possible because it contains 0. [Edit: As this is running on the 16-bit bus, perhaps your code does not need the delay or could get by with a smaller one.]

 

...lee

Edited January 17, 2022 by Lee Stewart
ADDITONAL INFO

[Tursi]

I've had success with no delay, but it's possible that delay is there for differences in hardware, or even the possibility of bounce when the 8 to 1 switches. it's probably wise to keep something.

 

[HOME AUTOMATION]

8 hours ago, retroclouds said:

li r12,>000e

This way makes it easy to program the address, as opposed to divide by 2, than convert to decimal. But I have found that this can become confusing.

 

I'll bet there's a tricky way to type the hex address into the editor and have the assembler resolve it for an SBO/SBZ instruction.

[Tursi]

Just use the bit column of the lookup tables, instead of the address column.

 

Does the hex symbol not work for SBO on the assembler you're using? I have to admit I've never tried it.

 

[apersson850]

On 1/17/2022 at 12:01 AM, Tursi said:

It's probably less confusing to leave R12 at 0 and set/clear the specific desired bit, but I suppose in the long run it shouldn't matter.

I'd say that's definitely preferred, since then you know for sure that SBO 0 is the same bit as SBZ 0 further down. When you keep R12 the same all the time, that is.