Jump to content
IGNORED

keyboard interrupt or ?


fernan
 Share

Recommended Posts

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

 

 

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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).

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by drac030
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by drac030
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 4 weeks later...

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...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...