![]() |
|
MW BASIC program to check keyboard - Printable Version +- Discussion Forum for all things Microbee (https://microbeetechnology.com.au/forum) +-- Forum: Microbee Forum (https://microbeetechnology.com.au/forum/forum-1.html) +--- Forum: Microbee Software and Documentation (https://microbeetechnology.com.au/forum/forum-7.html) +--- Thread: MW BASIC program to check keyboard (/thread-264.html) |
MW BASIC program to check keyboard - g67wjjk - 10-01-2021 Trying to write a simple program to check each key switch on the keyboard as I'm not sure keys like ESC, LF, etc. are working and just don't do anything in BASIC or they aren't working. Idea is something like this: 10 a$=key$:if a$="" then goto 10 20 print "ASCII code: ";asc$(a$):print "" 30 goto 10 I basically swiped this from p133 of the 16K MW Basic manual I found online: KEY{$} KEY$ returns a string depending on whether or not a key on the keyboard has been pressed. If no key has been pressed since the last KEY$ call (or line input), the null string (length 0) is returned. If a key has been pressed, the one-character string corresponding to that key is returned. The characters which are received using the KEY$ function are NOT automatically displayed on the screen, allowing such things as "TURTLE GRAPHICS" and real time games which do not require the RETURN key to pressed and don’t stop when waiting for a key. Because the time taken to look at the keyboard is very short, the KEY$ function is usually examined in some sort of loop. Example: 00100 A0$="" : REM clear string to accumulate 00110 A1$=KEY$ : IF A1$="" THEN 110 : REM get key 00120 A0$=A0$+A1$ : REM add this key to A0$ 00130 IF ASC(A1$)<> 32 THEN 100 : REM wait for a space 00140 PRINT A0$ : REM view captured string On Amstrad's Locomotive BASIC I would've used INKEY$ so I assume KEY$ is the equivalent. But on my MW BASIC 5.10 it doesn't like line 10 ... "integer string error". So I changed it to ... a=key$ ... even though KEY$ returns a string, and then got an "unknown function error". Okay, so that makes sense ... MW BASIC 5.10 doesn't have that function I guess? Reading through the manual I didn't see any version number it related to. I'm going to search more online for a manual, but in case anyone can point out a simple solution ...
RE: MW BASIC program to check keyboard - ChickenMan - 10-01-2021 Microworld Basic v5.10 has a built in keyboard, rom, memory, ports tester. Hold down the S key and the Reset at the same time for 4sec then release the Reset key while still holding the S down. The first test is the Keyboard and starts with the ESC, then 1, then 2 across the top row, then the second row, etc. RE: MW BASIC program to check keyboard - ChickenMan - 10-01-2021 Oh, A is for integers and A0$ is for strings, so your program will work with 10 a0$=key:if a0$="" then 10 20 print "ASCII code: "asc(a0$) 30 goto 10 RE: MW BASIC program to check keyboard - g67wjjk - 10-01-2021 Ahhh, okay very good. So the inbuilt test shows exactly the same failures as yours, but my program ... with numbered string variables instead of just string variables ... seems to indicate all keys are working perfectly ... ?!Even testing CTRL showed it was working by trying CTRL+G, etc., and SHIFTed characters showed the correct values. I did try loading software via digital recorder today - 16 bit, 44.1kHz stereo WAV files - I tried load"" and load"xxxx" ... I could see the header but nothing more. I was assuming my playback level was too high ... max was 30 but went down to 5 and still didn't work. (10-01-2021, 07:56 PM)ChickenMan Wrote: Oh, A is for integers and A0$ is for strings, so your program will work with I'm a little confused ... I tried a$ and it wasn't happy ... but a0$ is okay ... So MW BASIC requires string variables to be numbered? RE: MW BASIC program to check keyboard - someone - 10-01-2021 Different implementations of BASIC have different naming schemes. Rather than Microsoft's method of using 2 letters to define variables of any type, the MWB uses:
The history behind this is that the MWB evolved from an integer only Tiny BASIC and the simplistic [A-Z][0-7] naming made it simple and quick to find the variables in memory. Apart from the RESET key, all of the keys are all assigned unique scancode. The microbee scans its keys into different ways. One method is the free run scanning where the VDU character address register which incremented is used to provide the keycode scan address and when the LPEN signal is triggered the 6545 holds the VDU Character address as the keyscan code. The other method is to use the R6545's R31 Update Register to check the state of a specified key. The MWB keyboard driver uses a combination of both these methods. The keys are wired up so that each key is assigned to a block of 16 VDU character addresses. From the scancodes and separately polled modifier keys, the keyboard driver converts them into ASCII codes for MWB to use. Here is a a small demonstration code snippet that was written by Monte Chan that was very useful for writing games that needed to sense multiple keypresses quickly. It loads a tiny machine code hook that allows keys to be scanned by their scancode. The K variable is the keycode to be scanned. This value can be changed as required. The screen dump value of 2 is the 'B' key. The keycodes are listed on the microbee schematic diagram by reading the keyboard matrix from the top left hand corner down each column and then across from left to right with the SHIFT key being last at 63. The driver returns a result of 0 if the key is pressed and -1 if not pressed. The machine code driver is loaded at 8192 but is totally relocatable. Someone tried it on MWB 5.10 and it works. It should also work on MWB 5.22e Go on, try it and have fun in the process. RE: MW BASIC program to check keyboard - g67wjjk - 11-01-2021 Ahh, thanks for the explanation. I did try that code snippet and it does indeed work on 5.10. I added a FOR loop to check all scan codes but it was a bit slow, as you might expect. Using the KEY$ function, I've confirmed that all the keys are indeed working, including ESC, TAB, LF ... but I'm not happy with the hard force needed on a few so will be replacing those as well. |