a464@mindlink.UUCP (Bruce Dawson) (02/08/90)
Don't write down the code and qualifier for each key. Open the console device and use the RawKeyTranslate function to go from code/qualifier to ascii. VERY IMPORTANT because translations vary from machine to machine. .Bruce.
rogers@iris.ucdavis.edu (Brewski Rogers) (02/08/90)
For a game I am working on, I need to be able to read the keyboard without having a window open. I already have a routine that intercepts input events before intuition sees them, but before I write down the code and qualifier for each key, I'd like to know if there is an easier way, or if someone has already written it. While the game DOES multitask, the current interface with intuition is a total kludge, and we are trying to make it cleaner/more reliable. -thanks in advance... ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ "My brain is on fire!" \________/ Quark!
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/09/90)
In article <6675@ucdavis.ucdavis.edu> (Brewski Rogers) writes: >For a game I am working on, I need to be able to read the keyboard >without having a window open... If you open a SIMPLE_REFRESH + BORDERLESS + BACKDROP + NOCAREREFRESH (no I'm not screaming) on the screen you can have intuition send you keyboard events through it. This takes very little overhead to do. If you are morally opposed to this method .. > ... I already have a routine that intercepts input events before > intuition sees them, but before I write down the code and qualifier > for each key, I'd like to know if there is an easier way, or if > someone has already written it. Yes, look up RawKeyConvert/DeadKeyConvert in the new ROM Kernel manual. It shows how you can take the input events that the input device is sending you and convert them into real keys. The will also make sure that when you get 'z' it will be the 'z' key on a US as well as on a German keyboard. > While the game DOES multitask, > the current interface with intuition is a total kludge, and we are trying > to make it cleaner/more reliable. Sometimes it is useful to have intuition just provide the input for you, in which case the borderless backdrop approach works well. It doesn't take up hardly any memory (just the sizeof(struct Window)). --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
rogers@iris.ucdavis.edu (Brewski Rogers) (02/09/90)
In article <131451@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >Sometimes it is useful to have intuition just provide the input for you, >in which case the borderless backdrop approach works well. It doesn't >take up hardly any memory (just the sizeof(struct Window)). > >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM Ah, but the problem is that I have a custom-copper list that's not connected to a screen.(It intercepts <amiga>[m|n] to seem like a screen.) since there's no screen, where would I put a window? ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ "My brain is on fire!" \________/ Quark!
rogers@iris.ucdavis.edu (Brewski Rogers) (02/09/90)
In article <1076@mindlink.UUCP> a464@mindlink.UUCP (Bruce Dawson) writes: > Don't write down the code and qualifier for each key. Open the console >device and use the RawKeyTranslate function to go from code/qualifier to ascii. >VERY IMPORTANT because translations vary from machine to machine. >.Bruce. Unfortunately, the (old) version of the RKM I have doesn't mention RawKeyTranslate. Is this in the newest one? -Bruce ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ "My brain is on fire!" \________/ Quark!
addison@pollux.usc.edu (Richard Addison) (02/09/90)
In article <6677@ucdavis.ucdavis.edu> rogers@iris.ucdavis.edu (Brewski Rogers) writes: >Ah, but the problem is that I have a custom-copper list that's not connected >to a screen.(It intercepts <amiga>[m|n] to seem like a screen.) since there's >no screen, where would I put a window? Are you sure you can't integrate your custom-copper list into a screen? Granted there are some features that could be supported better within intuition screens, but it is still possible to do many things without tossing out intuition. It's unfortunate that the descriptions of the copper are in the hardware manual and there isn't a good description of how to incorporate copper lists with intuition. --Rich
a464@mindlink.UUCP (Bruce Dawson) (02/09/90)
I assume that RawKeyTranslate is documented in the recent RKMs. It has been documented for many years in the autodocs, which you should get if you don't have. .Bruce.
justus@tko-sony-7.hut.fi (Juhana R{s{nen) (02/09/90)
In article <6675@ucdavis.ucdavis.edu> rogers@iris.ucdavis.edu (Brewski Rogers) writes: >For a game I am working on, I need to be able to read the keyboard >without having a window open. I already have a routine that intercepts >input events before intuition sees them, but before I write down the >code and qualifier for each key, I'd like to know if there is an easier >way, or if someone has already written it. While the game DOES multitask, >the current interface with intuition is a total kludge, and we are trying >to make it cleaner/more reliable. One (quite brutal) way to do this is to read the keyboard input register directly. The address is (I belive) $bfec01, and there you'll see the latest keyboard event (both presses and releases). I'm not quite sure about the keycodes, they don't seem to correspond to the raw key codes you get from intuition. Reading an address constantly to decide whether something has happened or not is rather a clumsy thing to do, a better way would be to install an interrupt server that is invoked by PORTS-interrupt, which occurs (at least) every time a key is pressed or released. The interrupt-routine should peek into the keyboard register and then, if necessary, send a signal to the main program that there's a keypress available in a common memory area. However, this requires assembly programming and a firm knowledge of what one is doing (to keep the multitasking alive). >------------------------------------------------------ Quantum _\/_ >2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) >Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ >916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ >"My brain is on fire!" \________/ Quark! Juhana Rasanen / justus@niksula.hut.fi
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/10/90)
In article <6677@ucdavis.ucdavis.edu> (Brewski Rogers) writes: > Ah, but the problem is that I have a custom-copper list that's not connected > to a screen.(It intercepts <amiga>[m|n] to seem like a screen.) since there's > no screen, where would I put a window? The beauty of it is, that you don't need a real screen. You can open your borderless backdrop window in the workbench screen and make it the active window (use the ACTIVATE flag in the window struct). Then build your custom copper list, and display your game. Your A-M/A-N handler need only pass the rawkey events through to intuition and your program will get them on it's message port. Windows do not have to be in _front_ to be active. So the sequence goes something like : install_handler(); win = OpenWindow(borderless backdrop); ... MrgCop(); LoadView(); /* At this point Intuition still thinks your window is "in front and active. */ play_game(); LoadView(oldview); CloseWindow(win); remove_handler(); See? --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/10/90)
AAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHH! In article <6675@ucdavis.ucdavis.edu> (Brewski Rogers) wrote: > For a game I am working on, I need to be able to read the keyboard > without having a window open. In article <1990Feb9.150945.29787@santra.uucp> (Juhana R{s{nen) writes: > One (quite brutal) way to do this is to read the keyboard input register > directly. The address is (I belive) $bfec01, and there you'll see the > latest keyboard event (both presses and releases). WRONG!WRONG!WRONG!WRONG!WRONG There are so many *SUPPORTED* ways to do this without some bogus reading of an Address that may or may not be there in a different model that this sort of approach should never ever even be considered except in jest. Then to add insult to injury he continues : >Reading an address constantly to decide whether something has happened or not >is rather a clumsy thing to do, a better way would be to install an >interrupt server that is invoked by PORTS-interrupt, which occurs (at least) >every time a key is pressed or released. The interrupt-routine should >peek into the keyboard register and then, if necessary, send a signal to >the main program that there's a keypress available in a common memory area. >However, this requires assembly programming and a firm knowledge of what >one is doing (to keep the multitasking alive). Which I understand to mean "don't peek until you get an interrupt." Which is still wrong, the correct answer is *DON'T PEEK EVER*. I hate to generalize to "europeans" but this kind of answer seems to constantly originate on your side of the Atlantic, Why? At the very least you can call AddHandler(). This is *easy* to do compared to peeking and polling and all that other stuff you suggested. Just call AddHandler and *poof* keyboard events will be passed to your program via calls to this handler. And you don't even need a "firm knowledge of what one is doing" to keep multitasking alive! And think of all the code space you will save in your program because you are using the routines in the ROMs instead of in RAM, and gee it will work on any Amiga and it is still JUST AS FAST as your code is, cuz it's in assembler too! Don't you guys get the documentation? Don't you read it? European games are looked at derisively here, not because they aren't creative or sexy, but because they always seem to work on only one type of Amiga, whatever type it was that the developer happened to have. Please spread the word that you don't have to reinvent the wheel every time you want to read a key from the keyboard. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
p554mve@mpirbn.UUCP (Michael van Elst) (02/11/90)
In article <6675@ucdavis.ucdavis.edu> rogers@iris.ucdavis.edu (Brewski Rogers) writes: >For a game I am working on, I need to be able to read the keyboard >without having a window open. I already have a routine that intercepts >input events before intuition sees them, but before I write down the >code and qualifier for each key, I'd like to know if there is an easier >way, or if someone has already written it. While the game DOES multitask, >the current interface with intuition is a total kludge, and we are trying >to make it cleaner/more reliable. Hmm, if the game multitasks, it should conform to the intuition paradigm. There is no reason to NOT have a window open since windows can be made completely invisible. If your games display is on the workbench, it would be better to use a keyboard to avoid user confusion. If your games display uses an Intuition screen, then you can easily open an BACKDROP|BORDERLESS window and use it only for gathering input. If your games display uses a custom built View then you can open a small screen (small to spare memory) with a window. Note that a screen cannot be made too small since some rendering (Title bar, screen gadgets) is done through the screen's rastport. However this display method isn't quite comfortable. Michael van Elst uunet!unido!mpirbn!p554mve
rogers@iris.ucdavis.edu (Brewski Rogers) (02/11/90)
In article <131573@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <6677@ucdavis.ucdavis.edu> (Brewski Rogers) writes: >> Ah, but the problem is that I have a custom-copper list that's not connected >> to a screen.(It intercepts <amiga>[m|n] to seem like a screen.) since there's >> no screen, where would I put a window? >The beauty of it is, that you don't need a real screen. You can open your >borderless backdrop window in the workbench screen and make it the active >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM Oh damn. That would EXCEPT I wanted to have an option for people with small amounts of RAM to be able to close the workbench. cool idea though. ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ "My brain is on fire!" \________/ Quark!
navas@cory.Berkeley.EDU (David C. Navas) (02/11/90)
In article <6690@ucdavis.ucdavis.edu> rogers@iris.ucdavis.edu (Brewski Rogers) writes: >Oh damn. That would EXCEPT I wanted to have an option for people with >small amounts of RAM to be able to close the workbench. > >cool idea though. Okay -- close WB, open a one line, lo-res, single-bitmap screen and a backdrop window which is activated... TA DA!! [Very low memory usage as well.] David Navas navas@cory.berkeley.edu
deven@rpi.edu (Deven T. Corzine) (02/11/90)
On 9 Feb 90 14:42:29 GMT, a464@mindlink.UUCP (Bruce Dawson) said: Bruce> I assume that RawKeyTranslate is documented in the recent Bruce> RKMs. It has been documented for many years in the autodocs, Bruce> which you should get if you don't have. The actual name of the function is RawKeyConvert, which is called by opening the console.device and using the Device vector as a library base (which, of course, it is) by copying the (initialized) io_Device to the variable ConsoleDevice. This is documented in the new 1.3 Libraries and Devices RKM on page 662. There is a full example using this function on page 194 in the Intuition: Mouse and Keyboard section of the same manual. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
peter@sugar.hackercorp.com (Peter da Silva) (02/12/90)
In article <6677@ucdavis.ucdavis.edu> rogers@iris.ucdavis.edu (Brewski Rogers) writes: > Ah, but the problem is that I have a custom-copper list that's not connected > to a screen.(It intercepts <amiga>[m|n] to seem like a screen.) since there's > no screen, where would I put a window? Why not set up a dummy screen and attach your copper list to it? -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
root@kunivv1.sci.kun.nl (Privileged Account) (02/13/90)
In article <131583@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: > >Which I understand to mean "don't peek until you get an interrupt." Which is >still wrong, the correct answer is *DON'T PEEK EVER*. I hate to generalize >to "europeans" but this kind of answer seems to constantly originate on your >side of the Atlantic, Why? To be more specific, most such programmers seem to be located in Germany. ((One example: a disk optimizer on a relatively recent Fish disk was 'improved' by some German programmer. He removed all symbolic names of offsets in disk blocks, recursively called the main loop in case of errors, and somehow the original version worked while the 'improved' one didn't.)) If you insist on generalizing, just generalize to "Germans", but leave the rest of Europe out of it. There are people here who *do* read all the manuals. Really. And there are even programmers who can write readable programs. >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM >These opinions are my own and no one elses, but you knew that didn't you. >"If it didn't have bones in it, it wouldn't be crunchy now would it?!" -Olaf Seibert.
root@kunivv1.sci.kun.nl (Privileged Account) (02/13/90)
In article <1036@kunivv1.sci.kun.nl> root@kunivv1.sci.kun.nl (Privileged Account) writes: [everything deleted] >-Olaf Seibert. Hm, interesting. I didn't know I was root... The original From: line looked more like From: ovb11@cs.kun.nl (Olaf 'Rhialto' Seibert) -Olaf Seibert.
p554mve@mpirbn.UUCP (Michael van Elst) (02/13/90)
In article <131573@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <6677@ucdavis.ucdavis.edu> (Brewski Rogers) writes: >> Ah, but the problem is that I have a custom-copper list that's not connected >> to a screen.(It intercepts <amiga>[m|n] to seem like a screen.) since there's >> no screen, where would I put a window? > >The beauty of it is, that you don't need a real screen. You can open your >borderless backdrop window in the workbench screen and make it the active >window (use the ACTIVATE flag in the window struct). If you use backdrop window on a public (WB) screen you have to intercept mouse clicks too since you might hit another window that's in front of the backdrop window. Now, a 2 color, LORES, 10 rows high screen will use 400 bytes chip memory. I don't think that it is too much memory wasted, if you attach your borderless window onto this screen. Michael van Elst uunet!unido!mpirbn!p554mve
p554mve@mpirbn.UUCP (Michael van Elst) (02/13/90)
In article <21982@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU.UUCP (David C. Navas) writes: >Okay -- close WB, open a one line, lo-res, single-bitmap screen and a backdrop >window which is activated... TA DA!! [Very low memory usage as well.] Could YOU get a one line screen to open without crash ???? I've always needed 10 lines and I think that's the menubar layer that is fixed size. Michael van Elst uunet!unido!mpirbn!p554mve
justus@robin.hut.fi (Juhana R{s{nen) (02/13/90)
In article <131583@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >AAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHH! SSSSSSSSSSSSSSSSSSSSSOOOOOOOOOOOOOOOOOORRRRRRRRRRRRRRRRRYYYYYYYYYYYYYYYY! >In article <1990Feb9.150945.29787@santra.uucp> (Juhana R{s{nen) writes: >> One (quite brutal) way to do this is to read the keyboard input register >> directly. The address is (I belive) $bfec01, and there you'll see the >> latest keyboard event (both presses and releases). > >WRONG!WRONG!WRONG!WRONG!WRONG >There are so many *SUPPORTED* ways to do this without some bogus reading of >an Address that may or may not be there in a different model that this sort >of approach should never ever even be considered except in jest. OK, OK, agreed. I wasn't quite suggesting THIS and perhaps my suggestion of adding an custom interrupt handler wasn't the most sensible when you consider that maybe someone else would like to use your program. But I hope the fact that it wasn't me who was making the game relieves you even a bit. I only told what I would have done in all my stupidness. >I hate to generalize >to "europeans" but this kind of answer seems to constantly originate on your >side of the Atlantic, Why? Well, every continent seems to have some very own bad habits. What annoys me on YOUR side, are the numerous programs that don't support national keyboards, and this problem is ancient compared with ours (as you can see when you see my name, the braces should be 'a's with dots). 7-bit ASCII has annoyed for decades countless Germans, Scandinavians and others having other alphabets than found in English in their language. And even on Amiga, which has all means to avoid national problems, you see programs that ignore keymap settings and use the standard UK or USASCII keyboard. (For example, the version of LSE which came with Lattice C 5.00. The problem has been corrected now.) But please, let's not make a war between continents of this. >Don't you guys get the documentation? Don't you read it? Sometimes I wonder this myself. It seems to take much more time for a manual than information of all new features and promises to cross the Atlantic. When you know that your manual (that costs money!) will be old by the time you get it into your hands, you decide to wait for the new version. You see, we have to live in the future here! >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM >These opinions are my own and no one elses, but you knew that didn't you. >"If it didn't have bones in it, it wouldn't be crunchy now would it?!" Juhana R{s{nen / justus@niksula.hut.fi -- .... C'mon Joker...... Sing me a song......
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/14/90)
In article <1990Feb13.140718.26883@santra.uucp> (Juhana R{s{nen) writes: >Well, every continent seems to have some very own bad habits. What annoys me >on YOUR side, are the numerous programs that don't support national keyboards, >and this problem is ancient compared with ours (as you can see when you see my >name, the braces should be 'a's with dots). You're correct, hopefully the version of MicroEMACS I did will find its way over there in both source and executable form and you will find you can write to your heart's content in whatever language your keymap supports and have it represented correctly on the screen. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
mks@cbmvax.commodore.com (Michael Sinz - CATS) (02/14/90)
In article <1990Feb13.140718.26883@santra.uucp> justus@niksula.hut.fi (Juhana R{s{nen) writes: >In article <131583@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >>AAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHH! > >SSSSSSSSSSSSSSSSSSSSSOOOOOOOOOOOOOOOOOORRRRRRRRRRRRRRRRRYYYYYYYYYYYYYYYY! AAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGHHHHHHHHHHHHHH!! (Thanks Chuck... Gee, Charlie Brown, this is interesting...) So, howmany of you want to do this with the rest of the system not working. Lets say you have taken down intuition and input.device (which is the other half of intuition in a way) you can do the simple (and documented) thing of opening and reading from the keyboard.device. See the RKM on methods. There are even ways of finding the key matrix in a bit array which tells which keys are down and which are not. The matrix can even be used while intuition is running. Now, remember that this is not the system friendly way to do things. It should always be attempted to do it via a window and IDCMP messages or console.device attached to a window and device I/O. If that can not be done, then you must have taken down the system and now need to work in a new way. (This excludes hot-key programs which become clients of the input.device or of the commodeties exchange.) /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// When people are free to do as they please, | | \XX/ they usually imitate each other. | \----------------------------------------------------------------------/
usenet@cps3xx.UUCP (Usenet file owner) (02/20/90)
In article <131780@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <1990Feb13.140718.26883@santra.uucp> (Juhana R{s{nen) writes: >>Well, every continent seems to have some very own bad habits. What annoys me >>on YOUR side, are the numerous programs that don't support national keyboards, >>and this problem is ancient compared with ours (as you can see when you see my >>name, the braces should be 'a's with dots). ^^ umlauds? :) > >You're correct, hopefully the version of MicroEMACS I did will find its [...] >--Chuck McManis [...] Is it impossible to have a keymap that will accept multiple keypresses to construct the various foreign characters? Then in foreign countries there would only be one keypress (I assume -- haven't really seen foreign keyboards) to get those characters. That way, the foreign characters would be available on any US program that uses the CON: handler, right??? Troubles would only appear when the keyboard is accessed directly, right??? _ /| \`o.O' Chris Dailey =(___)= dailey@cpsin.cps.msu.edu U - "Meow."
navas@cory.Berkeley.EDU (David C. Navas) (02/22/90)
In article <557@mpirbn.UUCP> p554mve@mpirbn.UUCP (Michael van Elst) writes: >In article <21982@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU.UUCP (David C. Navas) writes: >>Okay -- close WB, open a one line, lo-res, single-bitmap screen and a backdrop >Could YOU get a one line screen to open without crash ???? >I've always needed 10 lines and I think that's the menubar layer >that is fixed size. Um, so SCREENQUIET [or whatever] doesn't do it, eh? Hmm, so that's why JazzBench crashes.. :) :) Seriously, though, the idea was, of course, to open a *small* screen... Sorry I got my sizes messed up -- thanks for the correction, though! David Navas navas@cory.berkeley.edu
deven@rpi.edu (Deven T. Corzine) (02/23/90)
On 13 Feb 90 14:07:18 GMT, justus@robin.hut.fi (Juhana R{s{nen) said:
cmcmanis> Don't you guys get the documentation? Don't you read it?
Juhana> Sometimes I wonder this myself. It seems to take much more
Juhana> time for a manual than information of all new features and
Juhana> promises to cross the Atlantic. When you know that your
Juhana> manual (that costs money!) will be old by the time you get it
Juhana> into your hands, you decide to wait for the new version. You
Juhana> see, we have to live in the future here!
Sorry, guy. Doesn't fly. Even with out of date manuals, if you read
them carefully, AND followed the guidelines, you would be in the
clear. A favorite example is Mindwalker... written under 1.0, but
following the guidelines (imagine that!) so it worked with FAST ram,
under 1.1, 1.2, 68020 & 68030, 1.3 and undoubtably 1.4 as well.
But, if you can get your grubby little paws on the 1.3 RKM's (Includes
& Autodocs and Libraries & Devices, especially) [you guys are FAR too
into the hardware already...] then DO SO. The 1.3 RKM's were VERY
well done, and "worth their weight in gold". Well maybe not, but they
definitely are the Amiga system programming "bible" just as K&R's book
is for the C language. [Yes, it's hefty praise, and well deserved.
Kudos, CATS!]
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.UH2@psuvm.psu.edu (Lee Sailer) (02/24/90)
>But, if you can get your [hands] on the 1.3 RKM's (Includes >& Autodocs and Libraries & Devices, especially) > then DO SO. The 1.3 RKM's were VERY >well done, and "worth their weight in gold". Which brings to mind a couple of suggestions for Commodore and the Amiga community.... In the Mac's early days, didn't Apple actively *encourage* that people make copies of the manuals? (Weren't they called Inside Macintosh? I remember that in 1985 it seemed like *every* freshman at CMU had a copy 8-). It seems to me that it would be to Commodore's advantage (fewer Gurus == better rep- uatation) to flood the programming community with the RKM's. For example, Commodore could subsidize Lattice, Manx, and the other language vendors so that they could include the RKM's in their compiler docs. (That way, even I'd have a copy 8-) A second idea is for americans to look for opportunities in Europe. It is pretty clear that a lot of talented programmers are working on Amiga software and that there English is probably better than mine. But do American publishers distribute the RKM's, Rob Peck's book, Mortimer's books, and so on in Europe? And, for real impact, who is translating the RKM's into French, German, Finnish, Dutch, and Russian? I imagine a scenario where one of the European Amiga wizards with good English and an American (with good English) are brought together by Commodore to translate for a few months, and get paid. In fact, hire a consultant from the Summer Linguistics Institute, too, to make sure that the subsequent translations can be done with high efficiency. Here's a scary thought. The German edition of the RKM's is more up to date, includes better examples, and thus becomes required reading for the American Amiga community. In 1995, the Germans complain that the Americans always seem to write for the obsolete 1.3 version of the OS, because they cannot read but one obsolete language. See you all after 1992 8-) 8-) 8-) lee
cmcmanis@stpeter.Sun.COM (Chuck McManis) (02/24/90)
In article <6529@cps3xx.UUCP> dailey@cpsin2.UUCP (Chris Dailey) writes: > Is it impossible to have a keymap that will accept multiple keypresses > to construct the various foreign characters? No, this is the way the usa1 keymap constructs foreign characters. You type Alt-k a and get an a with Umlads on it. EMACs also likes to use the Alt character as a replacement for Meta so I made one of the alt keys the "compose" character and the other the "meta" character. > Then in foreign countries > there would only be one keypress (I assume -- haven't really seen > foreign keyboards) to get those characters. Correct, in foreign countries it is possible to put the foreign characters on a key so that a single key press (like shift-A or something) would give you the a umlad character. > That way, the foreign > characters would be available on any US program that uses the CON: > handler, right??? Troubles would only appear when the keyboard is > accessed directly, right??? Correct and correct. If your program interprets the scan codes then your interpretation will be of the keys will be incorrect on different keyboard layouts. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
a464@mindlink.UUCP (Bruce Dawson) (03/01/90)
> > > If you hold down a key it begins to repeat, I want to ignore the messages > sent to me by the autorepeat after you have lifted your finger from the > key. How do I do that if they come faster than I can process them ? > > If there is a better, more supported way please tell me! > > > >/--------------------------------------------------------------------- -\ > >| /// Michael Sinz -- CATS/Amiga Software Engineer | > >| /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | > >| /// | > >|\\\/// When people are free to do as they please, | > >| \XX/ they usually imitate each other. | > >\-------------------------------------------------------------------- --/ > > Asaph. > asaph@taurus.bitnet asaph@math.tau.ac.il Using the keymatrix function sounds like a valid way of dealing with auto-repeat, and dealing with auto-repeat to avoid run on is certainly a valid thing to do (understatement of the year, I HATE programs that don't properly deal with auto-repeat). However, I happen to use a different method. Psuedo code is: ; if (AuxValid) /* If a previous message is cached */ ; Copy AuxMessageBuffer to MessageBuffer ; else ; if GetMsg() ; { ; Copy message to MessageBuffer ; Reply to message. ; } ; else ; Exit(FALSE); ; AuxValid = FALSE. ; /* now deal with auto-repeat. */ ; StillAutoRepeating:; ; while (GetMsg) ; { ; Copy message to AuxMessageBuffer ; if (AuxMessageBuffer.Qualifier & IEQUALIFIER_REPEAT) ; goto StillAutoRepeating; ; else ; { ; AuxValid = TRUE; ; Exit(TRUE); ; } ; } ; Exit(TRUE); ; ; If this routine returns true, look for a message in MessageBuffer. Basically, after getting a message, keep reading message until you run out of messages or until you read in a message that doesn't have the auto-repeat bit set. Cache the last message read so that you can use it next time. It works. .Bruce Dawson.
asaph@TAURUS.BITNET (03/02/90)
In article <9670@cbmvax.commodore.com> mks@cbmvax.cbm.commodore.com (Michael Sin >half of intuition in a way) you can do the simple (and documented) thing >of opening and reading from the keyboard.device. See the RKM on methods. >There are even ways of finding the key matrix in a bit array which tells which >keys are down and which are not. The matrix can even be used while intuition >is running. > >Now, remember that this is not the system friendly way to do things. It should Why not ? Whats wrong with opening the keyboard.device for an intuition program ? I do this to get the currect state of a key via READMATRIX. Which I want so I can know whether a key is pressed NOW as opposed to when the message was sent. Otherwise I have to deal with the messages one by one and if one takes longer to process then to key in, the next keys will already be buffered/remebered events. These aren't events I always want to process. If you hold down a key it begins to repeat, I want to ignore the messages sent to me by the autorepeat after you have lifted your finger from the key. How do I do that if they come faster than I can process them ? If there is a better, more supported way please tell me! >/----------------------------------------------------------------------\ >| /// Michael Sinz -- CATS/Amiga Software Engineer | >| /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | >| /// | >|\\\/// When people are free to do as they please, | >| \XX/ they usually imitate each other. | >\----------------------------------------------------------------------/ Asaph. asaph@taurus.bitnet asaph@math.tau.ac.il
alex@bilver.UUCP (Alex Matulich) (03/04/90)
>................ > If you hold down a key it begins to repeat, I want to ignore the messages > sent to me by the autorepeat after you have lifted your finger from the > key. How do I do that if they come faster than I can process them ? The way I do it is simple, provided the keystrokes are being read from the console. I wrote a little function called clearkbd(), which uses the function ConMayGetChar() found in the RKM Libraries manual. It looks like this: char inkey() /* get a keypress, or return 0 if no key has been pressed */ { char key; key = ConMayGetChar(consoleReadPort, consoleReadMsg, &keybuffer[0]); return key; } void clearkbd() /* clear out the keyboard buffer */ { char key; while ((key = inkey()) != '\0'); } clearkbd() is called to clear out all unused keystrokes from the keyboard buffer before getting the next keystroke. The effect of this is that auto-repeats will only go as fast as my program gets characters. -- /// Alex Matulich /// Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 \\\/// alex@bilver.UUCP ...uunet!tarpit!bilver!alex \XX/ From BitNet use: bilver!alex@uunet.uu.net
a464@mindlink.UUCP (Bruce Dawson) (03/04/90)
> alex writes: > > > clearkbd() is called to clear out all unused keystrokes from the keyboard > buffer before getting the next keystroke. The effect of this is that > auto-repeats will only go as fast as my program gets characters. > > -- > /// Alex Matulich > /// Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 > \\\/// alex@bilver.UUCP ...uunet!tarpit!bilver!alex > \XX/ From BitNet use: bilver!alex@uunet.uu.net It wasn't clear from your code fragment, does your routine clear out ALL unused keystrokes from the keyboard buffer, or does it only clear out those produced by auto-repeat? This is an important distinction. If I hit a key ten times, I want the action repeated exactly ten times, even if the program can't keep up. But, if I hold down the key I do want the program to stop as soon as I release it. .Bruce.