winston19842...@yahoo.com wrote:
On Apr 24, 3:51 pm, mmphosis <markwst...@yahoo.com> wrote:
On Apr 24, 11:49 am, winston19842005 <bjjlya...@NOSPAMbellsouth.net>
wrote:
On 4/24/10 2:09 PM, in article
_vCdnZJ7Qblbrk7WnZ2dnUVZ_gSdn...@giganews.com, "Michael J. Mahon"
<mjma...@aol.com> wrote:
eriknoc wrote:
I like the idea of porting games to the Apple II series. Nice work,
except it's very difficult to aim & control because he keeps moving,
and fast, and having to press another direction or key to make him
stop takes some of the fun away from playing the game IMHO. Is this
how it works on ports to all the other systems? I would have made it
to where letting go of a key or direction would make you stop and
holding it down would make you go. That would make more sense to me
anyways.
That kind of control can be implemented on the Apple //e and later
machines, but the ][ and ][+, like many other computers of the day,
cannot sense when a key is released.
I'm trying to get my head around this statement...
Why not? What does the keyboard return after you stop pressing a key?
Does it not return a special value for "no key"?
Signed,
Confused?
I think that Michael J. Mahon is referring to this:
STROBE = $C010 ;clear bit 7 of keyboard data ($C000)
If read, it also provides an "any key down" flag in bit 7, with
the keycode in the remaining bits. (These features only apply to
the IIe and later machines.)
http://home.swbell.net/rubywand/csa2pfaq.html#004
Althought, this note doesn't mention "key up" only "any key down."
Can you really detect "key up" on Apple IIe and later models? And if
you can, how is this done? Documentation?
Ok, I thought you'd just keep history of what was pressed before and
look for a change.
This produces the effect in the current game, where a previously
pressed key continues to "act" pressed until another key is pressed.
AKD polling allows the program to cease a prior key-caused action
when the key is lifted (provided no other key is also pressed).
I'm a TI-er, and we use CALL KEY (or usually the assembly KSCAN
routine, which it more or less directly calls), and it returns two
values. One is the ASCII key-code of the key currently held down (-1
if none), the 2nd returns a 0 if no key pressed, 1 for key pressed and
-1 for key held down. Is that similar to the "any key down" thing, or
am I just not following?
Yes. And it also requires regular polling of the keyboard to detect
a keypress, plus record keeping to ensure that only a *change* is
treated as a keypress, as opposed to multiple polls finding the
same key down.
In the Apple, this function is done in hardware, with the "strobe"
recording an as-yet-unprocessed key down. When the key is read, the
strobe is cleared to mark that it is no longer an unprocessed key
down. The keyboard latch will hold a keypress indefinitely until
another key is pressed, so you don't have to constantly poll to avoid
missing keypresses.