+retroclouds Posted January 6, 2022 Share Posted January 6, 2022 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) ? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 6, 2022 Share Posted January 6, 2022 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 2 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 10, 2022 Author Share Posted January 10, 2022 (edited) 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 Quote Link to comment Share on other sites More sharing options...
RXB Posted January 10, 2022 Share Posted January 10, 2022 (edited) 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 1 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 10, 2022 Author Share Posted January 10, 2022 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. 2 Quote Link to comment Share on other sites More sharing options...
Stuart Posted January 10, 2022 Share Posted January 10, 2022 (edited) 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 4 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted January 10, 2022 Share Posted January 10, 2022 Maybe if you initialize PAD, to the state it's normally in during the TI's selection menu, before starting the GPL interpreter. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 16, 2022 Author Share Posted January 16, 2022 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 16, 2022 Share Posted January 16, 2022 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). 1 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted January 16, 2022 Share Posted January 16, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 16, 2022 Author Share Posted January 16, 2022 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 2 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted January 16, 2022 Share Posted January 16, 2022 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 2 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 16, 2022 Share Posted January 16, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 16, 2022 Share Posted January 16, 2022 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 17, 2022 Share Posted January 17, 2022 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. 3 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted January 17, 2022 Share Posted January 17, 2022 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. 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 17, 2022 Share Posted January 17, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted January 31, 2022 Share Posted January 31, 2022 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. 4 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.