Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5390 > unrolled thread

Sensing keypresses on the IIgs

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Sensing keypresses on the IIgs James Kruth <james@kruth.org> - 2020-02-01 16:11 -0500
    Re: Sensing keypresses on the IIgs jgandersen@gmail.com - 2020-02-01 14:17 -0800
      Re: Sensing keypresses on the IIgs James Kruth <james@kruth.org> - 2020-02-01 23:10 -0500
        Re: Sensing keypresses on the IIgs kegs@provalid.com (Kent Dickey) - 2020-02-01 23:17 -0600
          Re: Sensing keypresses on the IIgs James Kruth <james@kruth.org> - 2020-02-08 22:30 -0500
            Re: Sensing keypresses on the IIgs kegs@provalid.com (Kent Dickey) - 2020-02-09 15:26 -0600
    Re: Sensing keypresses on the IIgs Andy McFadden <thefadden@gmail.com> - 2020-02-02 07:52 -0800
      Re: Sensing keypresses on the IIgs James Kruth <james@kruth.org> - 2020-02-03 00:10 -0500
        Re: Sensing keypresses on the IIgs Andy McFadden <thefadden@gmail.com> - 2020-02-03 07:52 -0800
    Sensing keypresses on the IIgs gids.rs@sasktel.net - 2020-02-02 13:07 -0800
      Re: Sensing keypresses on the IIgs James Kruth <james@kruth.org> - 2020-02-02 23:57 -0500
        Re: Sensing keypresses on the IIgs gids.rs@sasktel.net - 2020-02-02 21:25 -0800
        Re: Sensing keypresses on the IIgs kelvin@pro-kegs.uucp (Kelvin Sherlock) - 2020-02-05 00:06 -0500
          Re: Sensing keypresses on the IIgs James Kruth <james@kruth.org> - 2020-02-08 22:56 -0500

#5390 — Sensing keypresses on the IIgs

I've been writing some text based programs using ORCA/M on the IIgs to
learn about 65816 assembly and using the IIgs toolbox. Just using the
text tools I've managed to do a good deal of what I set out to
accomplish, but now I find myself a bit stuck when it comes to keyboard
input.

Specifically I'd like to sense when a key is pressed and act on it
rather than waiting for input. The text tools provide me with good tools
for dealing with synchronous user input, but neither the text tools or
the GS/OS .CONSOLE driver seem to handle asynch input, like what you
might expect in a game.

I've been reading the toolbox manuals and the event manager sounds like
it might provide what I need, but it's not clear if I can use it with
text based programs and I thought I'd ask here before coding up a test.

Thanks in advance for your help!

- James

[toc] | [next] | [standalone]

#5391

You can use the event manager.  By far the easiest thing to do is use $C010, and $C000, to detect when a key is pressed, and to read what the key is.   This is compatible with the rest of the ][ series.

This hopefully links to page in assembly lines, that explains how to do it.

https://books.google.com/books?id=JjIkDwAAQBAJ&pg=PA42&dq=lda+c010&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwiyuJzgsLHnAhXPpFkKHdmkAb4Q6AEwAHoECAAQAg#v=onepage&q=lda%20c010&f=false



On Saturday, February 1, 2020 at 4:11:18 PM UTC-5, James Kruth wrote:
> I've been writing some text based programs using ORCA/M on the IIgs to
> learn about 65816 assembly and using the IIgs toolbox. Just using the
> text tools I've managed to do a good deal of what I set out to
> accomplish, but now I find myself a bit stuck when it comes to keyboard
> input.
> 
> Specifically I'd like to sense when a key is pressed and act on it
> rather than waiting for input. The text tools provide me with good tools
> for dealing with synchronous user input, but neither the text tools or
> the GS/OS .CONSOLE driver seem to handle asynch input, like what you
> might expect in a game.
> 
> I've been reading the toolbox manuals and the event manager sounds like
> it might provide what I need, but it's not clear if I can use it with
> text based programs and I thought I'd ask here before coding up a test.
> 
> Thanks in advance for your help!
> 
> - James

[toc] | [prev] | [next] | [standalone]

#5392

jgandersen@gmail.com writes:

> You can use the event manager. By far the easiest thing to do is use
> $C010, and $C000, to detect when a key is pressed, and to read what
> the key is. This is compatible with the rest of the ][ series.

I've been trying to stick to toolbox access, but this might be far
easier than using the rather complicated event manager. I appreciate the
suggestion.

I'm wondering, since I'm operating in 16-bit mode, I imagine my keyboard
routines would have to save the data bank register, then set it to 0,
read the keyboard, and then return the data bank to it's previous state.
Am I missing anything?

- James

[toc] | [prev] | [next] | [standalone]

#5393

In article <8736btbpdr.fsf@wardenclyffe.jk7.org>,
James Kruth  <james@kruth.org> wrote:
>jgandersen@gmail.com writes:
>
>> You can use the event manager. By far the easiest thing to do is use
>> $C010, and $C000, to detect when a key is pressed, and to read what
>> the key is. This is compatible with the rest of the ][ series.
>
>I've been trying to stick to toolbox access, but this might be far
>easier than using the rather complicated event manager. I appreciate the
>suggestion.
>
>I'm wondering, since I'm operating in 16-bit mode, I imagine my keyboard
>routines would have to save the data bank register, then set it to 0,
>read the keyboard, and then return the data bank to it's previous state.
>Am I missing anything?
>
>- James

Just do a long access instruction:

	LDA $E0C000

which is the byte codes: AF 00 C0 E0.  No need to mess about with the bank
register.  Use bank $E0 or $E1, since the I/O ports are always mapped in
those banks.

There's long indirect accesses as well.  You decide if you want the slight
performance of using a 2-byte addresses with the DBR (and so changing the
DBR a lot would negate the performance generally), or the convenience of
long accesses.

Kent

[toc] | [prev] | [next] | [standalone]

#5402

kegs@provalid.com (Kent Dickey) writes:

> Just do a long access instruction:
>
> 	LDA $E0C000
>
> which is the byte codes: AF 00 C0 E0.  No need to mess about with the bank
> register.  Use bank $E0 or $E1, since the I/O ports are always mapped in
> those banks.
>
> There's long indirect accesses as well.  You decide if you want the slight
> performance of using a 2-byte addresses with the DBR (and so changing the
> DBR a lot would negate the performance generally), or the convenience of
> long accesses.

Thanks for making this suggestion. I'm new to 65816 and I'm still
getting used to the new addressing modes. One thing that occurred to me
is that unless I set the accumulator to be 8 bits, then that LDA
instruction will actually read from $E0C000 and $E0C001. Based on the
documentation I've found that doesn't look like a big deal. Likewise
clearing the strobe by writing to $C010 would also write to $C011 -
correct?

Are these things I can just ignore? Thanks!

- James

[toc] | [prev] | [next] | [standalone]

#5404

In article <87h800a13i.fsf@wardenclyffe.jk7.org>,
James Kruth  <james@kruth.org> wrote:
>kegs@provalid.com (Kent Dickey) writes:
>
>> Just do a long access instruction:
>>
>> 	LDA $E0C000
>>
>> which is the byte codes: AF 00 C0 E0.  No need to mess about with the bank
>> register.  Use bank $E0 or $E1, since the I/O ports are always mapped in
>> those banks.
>>
>> There's long indirect accesses as well.  You decide if you want the slight
>> performance of using a 2-byte addresses with the DBR (and so changing the
>> DBR a lot would negate the performance generally), or the convenience of
>> long accesses.
>
>Thanks for making this suggestion. I'm new to 65816 and I'm still
>getting used to the new addressing modes. One thing that occurred to me
>is that unless I set the accumulator to be 8 bits, then that LDA
>instruction will actually read from $E0C000 and $E0C001. Based on the
>documentation I've found that doesn't look like a big deal. Likewise
>clearing the strobe by writing to $C010 would also write to $C011 -
>correct?
>
>Are these things I can just ignore? Thanks!
>
>- James

In general, you should not "accidentally" access any $C0xx addresses.  So you
should change to 8-bit mode, do the access, and then restore 16-bit mode.

It's definitely a problem for $E0C010-C011: it will eat a pending keypress if
you do a 16-bit store to $C010.  I don't see doing a 16-bit read to $C000
causing any problems, but it's best just to avoid it.

If you're under GS/OS, it may have an interrupt task collecting keystrokes
(you may have to start a toolset to do this).  You should not access
$E0C000/C010 directly in that case.  I don't know how GS/OS works, so I
cannot give more details.

Kent

[toc] | [prev] | [next] | [standalone]

#5394

On Saturday, February 1, 2020 at 1:11:18 PM UTC-8, James Kruth wrote:
> Specifically I'd like to sense when a key is pressed and act on it
> rather than waiting for input. The text tools provide me with good tools
> for dealing with synchronous user input, but neither the text tools or
> the GS/OS .CONSOLE driver seem to handle asynch input, like what you
> might expect in a game.

If you really want to dig into it, see the Apple Desktop Bus chapters in toolbox ref volume 1, the firmware ref, and the hardware ref (start with the hardware reference).  It lets you fiddle with the configuration (enable/disable keyboard buffering, alter the repeat rate, etc.), receive key-up events, and other fun things.

[toc] | [prev] | [next] | [standalone]

#5397

Andy McFadden <thefadden@gmail.com> writes:

> If you really want to dig into it, see the Apple Desktop Bus chapters
> in toolbox ref volume 1, the firmware ref, and the hardware ref (start
> with the hardware reference). It lets you fiddle with the
> configuration (enable/disable keyboard buffering, alter the repeat
> rate, etc.), receive key-up events, and other fun things.

The ADB toolbox looks like it could be interesting - I'm going to keep
it in mind to look at after I give some of the other options a try.
Would you happen to know of an example of it being used to respond to
key presses?

- James

[toc] | [prev] | [next] | [standalone]

#5399

On Sunday, February 2, 2020 at 9:10:48 PM UTC-8, James Kruth wrote:
> The ADB toolbox looks like it could be interesting - I'm going to keep
> it in mind to look at after I give some of the other options a try.
> Would you happen to know of an example of it being used to respond to
> key presses?

The keyboard and mouse are ADB devices (unless you have a //e conversion kit), so it's the most direct way to interact with the hardware.  The function that sets up an async event callback seems like a better approach than polling if you want to work off an interrupt.

I never had a reason to use it directly -- I either used the console driver for shell commands or the GUI events -- so I don't have sample code for it.

[toc] | [prev] | [next] | [standalone]

#5395

You could probably set up an interrupt routine that polls the modifier softswitch at $C025 about 5 times per second.  It can tel you when a key has been pressed among other things.

[toc] | [prev] | [next] | [standalone]

#5396

gids.rs@sasktel.net writes:

> You could probably set up an interrupt routine that polls the modifier
> softswitch at $C025 about 5 times per second. It can tel you when a
> key has been pressed among other things.

This sounds very interesting. Is there something in the manuals that
outlines how I would set up an interrupt routine? Coming from the Apple
II, I find I'm still surprised there are interrupts!

- James

[toc] | [prev] | [next] | [standalone]

#5398

Most, if not all, the Technical reference manuals have a list of softswitches that can tell which ones can cause an interrupt.  The IIGS manual has a couple of softswitches not found on a IIe.

The Prodos 8 reference manual shows how to set up an interrupt through its MLI, and the IIGS Toolbox Reference manual shows how to us the Heartbeat interrupt.

[toc] | [prev] | [next] | [standalone]

#5400

You can use _SetVector and _IntSource to set up a handler to be called 
when a keypress is available (see Toolbox Reference #1, chapter 14 for
the toolcalls and chapter 7 for some example code).  In most cases,
it's probably easier just to check in your main run loop.

-------
ProLine: kelvin@pro-kegs

[toc] | [prev] | [next] | [standalone]

#5403

kelvin@pro-kegs.uucp (Kelvin Sherlock) writes:

> You can use _SetVector and _IntSource to set up a handler to be called 
> when a keypress is available (see Toolbox Reference #1, chapter 14 for
> the toolcalls and chapter 7 for some example code).  In most cases,
> it's probably easier just to check in your main run loop.
>
> -------
> ProLine: kelvin@pro-kegs

I just read the example code and that looks pretty easy - I do think
that I'll probably end up just checking in my main loop. Thanks for
pointing me in the right direction!

- James

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web