keyboard interrupt or ?

[fernan]

hi all

 

anybody have a tutorial to catch keyboard interrupts using atari basic??

 

i modified my sio2arduino to also include a serial port interface to my linux machine.

so now i can use my 600xl as a ps2/serial keyboard.

Initially i tried to do the atari/ps2 translation on the atari 600, but it seemed too slow and kept missing keys.

 

regards

fernan

 

 

[Rybags]

You can't process interrupts using Basic - too slow and interrupt routines have to be assembler code.

 

There's a few ways to process keys in Atari Basic - generally it can be a bit harder than other computers since there's not an INKEY$ function but once you know how it's not too bad.

 

If it's not a realtime situation you can use CIO OPEN and GET from the "K:" device. But the problem there is when you do a GET it'll wait forever if necessary until a valid key is pressed. Another problem is that there's plenty of invalid key combinations that'll generate a click but not return a value or in fact return to your program e.g. CTRL 4 thru 9.

And also you get a keyclick sound which isn't wanted in most non-realtime situations.

 

The other mainly used method is PEEK(764) which returns the internal keycode. Generally you POKE 764,255 initially and again whenever you detect and process a key press.

The system IRQ as well as the VBlank processing which does auto-repeat on keys will populate the keycode value there.

The internal keycode isn't related to ASCII at all, it's more related to row/column returns by Pokey's key scan. There's plenty of tables you should be able to find with the key values.

L=0 J=1 ;=2 RETURN=12 (sample values)

[drac030]

If it's not a realtime situation you can use CIO OPEN and GET from the "K:" device. But the problem there is when you do a GET it'll wait forever if necessary until a valid key is pressed. Another problem is that there's plenty of invalid key combinations that'll generate a click but not return a value or in fact return to your program e.g. CTRL 4 thru 9.

And also you get a keyclick sound which isn't wanted in most non-realtime situations.

 

The other mainly used method is PEEK(764) which returns the internal keycode. Generally you POKE 764,255 initially and again whenever you detect and process a key press.

One can also combine the two methods, i.e. OPEN "K:", then keep monitoring 764. When PEEK(764) returns something different than 255 (and perhaps few other keycodes which may be blocking), call GET from the channel which has previously been opened for "K:". This way you spare youself the pains of keycode->ASCII conversions and still have nonblocking keyboard input. The keyclick can be disabled by storing a nonzero value to $02DB (731 dec, or so).

[Rybags]

The top 2 bits of the internal keyboard reflect CTRL and SHIFT state. A simple way to reject most invalid keycodes is to only accept ones with values between 0 and 191.

But that still leaves CTRL-4 thru CTRL-9 and 0. And CTRL-3 can be problematic as it generates an EOF condition, though you can TRAP that.

[fernan]

i wil read up the GET command...

 

i will try to describe how i have it set up here, just in case any improvements can easily be seen.

 

as i type this i am running the following

500 on peek(753)<>3 goto 500

600 key=peek(53769)

710 gosub 1000

720 on peek(753)=3 goto 720

810 gosub 1000

820 goto 500

1000 open #1,8,0."P:"

1010 put #1,key

1020 close #1

1030 return

 

in the arduino i am reading the atari key codes and sending them out to linux as ps2 scan codes. this setup seems to work well enough

and i can use my atari as my linux keyboard.

 

i am just wondering if there was a better way to capture keys from the atari and send it out faster.

[drac030]

1. put OPEN "P:" and the corresponding CLOSE call out of the loop

 

2. use Turbo BASIC XL. If still too slow, compile the program

[Rybags]

Unless there's some specific need it's probably best to OPEN the P: and leave it open instead of OPEN/CLOSE for every output operation.

 

In a wait for key situation in Basic, like I said before, easiest to POKE 764,255 then wait for PEEK(764) < 192.

Similar to leaving the P: open you could OPEN K: just the once.

 

If you didn't want to use K: you could probably setup a table of internal keycode to ASCII to translate the keys for you.

[fernan]

thanks for checking my code. a few more questions

 

1, according to this http://www.atariarchives.org/c3ba/page004.php- i should do peek(53769) if i want it as fast as possible. is this article wrong? i tried both 764 to be delayed a bit not sure.

2. i initially tried the open p: outside the loop, but put does send the key code untill i close the p: device. is there a way to flush the device??

3. why do i need to translate to ascii?? the arduino accpets atari key codes based on the same article above

[drac030]

As for "P:", sending the EOL (ASCII 155) should flush the buffer. If not, stay with the current solution.

 

53769 aka $d209 is the hardware register containing scancodes. 764 is the corresponding shadow which is set by the keyboard interrupt. Unless I am missing something, there should be no perceptible diffrence between them in the response time.

 

The 764 has the advantage of being writable. Thus after receiving the scancode from there (via PEEK) you can write a 255 there, and when this value changes, you will know that a key was pressed.

 

You do not need to translate to ASCII, if you do not want to.

Edited September 18, 2017 by drac030

[fernan]

cool !!! put #1,key:put#1,155 worked....seem to be better.

 

now i am thinking it would be even better if it was in machine code.

can anybody help me with a quick assembly of the same code??

i have started a machine code version, but i would think it would be done by now if an atari expert did it.

[drac030]

Just mimic in assembly what you are doing in BASIC. It will be excellent exercise for you and doing things so you will become an expert yourself some day.

 

Here are code examples for OPEN/CLOSE/GET/PUT/STATUS calls in assembly. The commentary is in Polish but the code examples should be understandable by themselves.

 

http://atariki.krap.pl/index.php/Dostęp_do_plików

Edited September 18, 2017 by drac030

[Rybags]

You could speed the program up using normal Basic optimizations like stacking statements and subroutine for once used stuff at the start.

 

 

10 GOSUB 1000
20 K=PEEK(764) : IF K > 191 THEN 20
30 PUT #1,K : POKE 764,255 : GOTO 20
1000 OPEN #1,8,0,"P:" : RETURN

[1050]

Not the same code by far, but I can cheat since I

expect the keyboard is already open in machine

language and do something as simple as this.

 

LDA $E425
PHA
LDA $E424
PHA
RTS

This is the equivalent to doing a JSR GET_KEY

and it will wait in the OS routine until it

gets a key pressed. The key will return in

register A at the code following that snippet

above. Mapping Atari pg 145 and 146 shows

these OS vectors in open, close, get byte,

put byte, status and XIO special order.

 

They do say assembler is pretty hard, but

sometimes the simplicity of it is stunning.

[drac030]

This method is ok except that it bypasses the HATABS. If someone is a beginner, it is better to show him the proper methods, leaving cheating for later, when the student knows exactly what is wanted and what are possible pros and cons.

[fernan]

1050

 

thanks i wll try this. i am slowly moving my atari -> arduino -> ps2keyboard away from the P: handler. I wrote a new handler, so that i

dont need to worry about flushing, P:'s 40 byte buffer also the ctrl-6 problem.

 

 

regards

fernan

[dmsc]

Hi!

 

You could speed the program up using normal Basic optimizations like stacking statements and subroutine for once used stuff at the start.

 

 

10 GOSUB 1000
20 K=PEEK(764) : IF K > 191 THEN 20
30 PUT #1,K : POKE 764,255 : GOTO 20
1000 OPEN #1,8,0,"P:" : RETURN

 

Or, you could use my FastBasic compiler, download from this post

 

Type "FB" to load the IDE, type CONTROL-N and ESC to start a new program, and type your program, for example:

 

OPEN #1,8,0,"P:"
IF ERR() > 1
 ? "Error opening P:"
 END
ENDIF

? "Type keys, BREAK ends"
REPEAT
 GET KEY
 PUT #1,KEY
UNTIL ERR() > 1

CLOSE #1

Then, you can save the program with CONTROL-S, run with CONTROL-R and write an executable file with CONTROL-W, if you name the resulting program with a ".COM" extension it can be loaded directly from the DOS prompt.

[fernan]

dmsc

 

thanks for the suggestion. not sure if fastbasic will work on my 16k 600xl and cassette.

anyway i have fixed my problem. i now have an atari branded ps2 keyboard and im very happy

[dmsc]

Hi!

 

dmsc

 

thanks for the suggestion. not sure if fastbasic will work on my 16k 600xl and cassette.

anyway i have fixed my problem. i now have an atari branded ps2 keyboard and im very happy

Yes, the IDE needs at least 24K RAM, mainly because DOS uses about 6K. But the compiled program will run ok in your 600XL.

[Kyle22]

Why are you using P: instead of Concurrent mode R:? R: would be much better if acting as a keyboard terminal. Really, the easiest thing would to use BobTerm.