Nukey Shay Posted April 20, 2004 Share Posted April 20, 2004 If it's in regards to the other thread (where another portion must be loaded from disk), I messed up in describing that one. The I/O channel being read (#1 in the example) MUST be opened first before a JSR is done to $E456...but I can't seem to remember how to do that in machine language. Quote Link to comment Share on other sites More sharing options...
Tezz Posted April 20, 2004 Share Posted April 20, 2004 Hi Nukey, no I am still stuck on the keypress problem, followed advice from pps and also tried some other locations out. I'm sure I'm missing something obvious here? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted April 20, 2004 Share Posted April 20, 2004 Yeah...possibly the entry point to your new routine. Is the spot where you entered the branch indeed a spot where nothing is happening? Or does the music program expect to be playing right then when it reaches that point? Another issue is that of ram usage. Are the programs that you are using leaving the addresses where your patch exists leaving those addresses alone? That's kinda why you might want to take a look at putting it into page 6, since most commercial programs don't ever use that page of memory...I've only run across 1 that did...Advan Basic I think. Or maybe it was something else. I gotta stop sniffing this glue Quote Link to comment Share on other sites More sharing options...
noteit Posted April 23, 2004 Share Posted April 23, 2004 The Atari has a keyboard buffer at some address. It holds several keys pressed. Think you might be able to pick off arrow keys there. Should be able to find the address in one of those books like mapping the atari by compute! Or you could just write a little program that searchs for a string of characters you type, and reports the address, and use that to locate the buffer for key press input. (not location peek 764) I did this one time years ago, and think I remember the key pressed input ends up in more than just one location, like they make a copy of the buffer? Quote Link to comment Share on other sites More sharing options...
noteit Posted April 23, 2004 Share Posted April 23, 2004 This time I wrote a lil program to test what location 764 can give on arrow keys, control keys, and shift keys. It does just fine on arrow keys, so I think you are maybe not converting the decimal number to hex that your assembler most likely uses correct. Try this in basic 10 print peek(764):goto 10 Run it, and push down any combination of key. you will find you get one number for a up arrow, another for a sift up arrow, and yet another for control shift up arrow etc. But if you want to use the atari keyboards arrow keys for a game, why make them push the shift or control key? Why not just detect for - = + * instead? You might do both, so the game would work no matter if they pressed a control key/shift key, or not. Peek (764) gives you results in decimal, so convert those results to hexadecimal, for assembly. Or if your assembler allows it, tag those numbers as decimal in your code. Quote Link to comment Share on other sites More sharing options...
pps Posted April 24, 2004 Share Posted April 24, 2004 Hi noteit, the arrows are detected, but not if pressed together with control & shift. For right and left arrow there should be a value of 206 & 207, if you combine the bits, but sadly the os - or better the keyboard controller - doesn´t give us these numbers 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.