Re: Wall Defence game for Apple II

[mmphosis <markwstock@yahoo.com>]

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+.
I think that there is a bug in AppleWin 1.17.2.0 because AKD works for
Apple II and Apple II+.