[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wall Defence game for Apple II



mmphosis wrote:
On Apr 24, 4:33 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
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.

-michael

NadaNet 3.0 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Very cool.  Key up detection of sorts.  Below is a relocatable polling
routine.  Press Reset to exit.

:AD 10 C0 85 1E 20 DA FD AD 10 C0 C5 1E F0 F9 D0 F2

	LDA STROBE ; $C010
STOREANDPRINT
	STA OLDSTROBE ; $1E unused zero page location
	JSR PRBYTE ; $FDDA print byte in hex
ANYKEYDOWN
	LDA STROBE
	CMP OLDSTROBE
	BEQ ANYKEYDOWN
	BNE STOREANDPRINT

This routine should behave differently on the original Apple II and
Apple II+.

It sure will!  When $C010 is read on a ][ or ][+, it either reads the
keyboard port or it reads the undriven bus (which would return the last
byte read by the video scanner).

If it is the former case, it will ignore multiple presses of the same
key, but will detect and record the first press of a different key.

If it is the latter case, it will "detect a key" many times, as
the "phantom" data continues to change.

I think that there is a bug in AppleWin 1.17.2.0 because AKD works for
Apple II and Apple II+.

There certainly is.

BTW, there is a subtle timing effect on the //e and later, since AKD
goes true (and the key code changes) some milliseconds before the strobe
is set in the keyboard port ($C000).  This interval is the debounce
interval of the encoder.

-michael

NadaNet 3.0 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."