Wall Defence game for Apple II
drHirudo
after doing my Wall Defence game for the Commodore Vic-20, I decided
to port it to the Apple II as well. I used most of the time the same
assembler code from the Vic-20 version, except for the graphic and
sound routines, plus total remap of the zero page variables. The port
went straight forward and was easier than I thought. The Apple version
of the game is not as colorful and fast as on the VIC-20, however the
game on the Apple II is in highres mode and the screen is wider.
Joystick is recommended, but keyboard with the keys Z-X-K-Space will
work as well. Hope you like it.
The game for Apple II with description and links to the other versions
can be found on
http://www.hirudov.com/apple/WallDefence.php
regards
bloomer_au
platform porting... nice work.
Just tried Wall Defence, but not for too long as I have RSI :) It's
pretty cool.
Is it meant to be that when you tap the joystick to the side the guy
keeps running that way? You can make him stop by pushing up.
I got the game running on Virtual II emulator. It didn't seem to work
on Sweet16, the other emulator I tried.
- Wade
rich12345
>
> Is it meant to be that when you tap the joystick to the side the guy
> keeps running that way? You can make him stop by pushing up.
>
My guess would be yes. Using Keyboard mode, the guy
keeps on running until you press the "pick up" button.
Rich
drHirudo
> I like your site. I don't see many people doing all that cross-
> platform porting... nice work.
Thanks for your comments.
I easily do crossplatform porting when using assemblers like dasm and
WLA-DX, where conversion for different platforms is sometime only a
matter of changing defines. C code is easier for crossplatform, but on
the 8 bit machines, the code gets clumsy and there is not much
control. I made Colorix for Apple II using C (with some inline
assembler).
> Just tried Wall Defence, but not for too long as I have RSI :) It's
> pretty cool.
Glad you like it. Warm feedback motivates me to develop more.
> Is it meant to be that when you tap the joystick to the side the guy
> keeps running that way? You can make him stop by pushing up.
As rich12345 suggested it is this way to keep on par with the Keyboard
control mode. You can stop it with pick or throw.
> I got the game running on Virtual II emulator. It didn't seem to work
> on Sweet16, the other emulator I tried.
I have tested the game on Apple2000e, SDDApple (on AmigaOne) and then
on Apple2Go (On MacOS X Tiger). It worked fine on these emulators, but
I did not test it on IIGS emulator. I remember there were some IIGS
specific initializations for particular variables, where I assumed
they are zeroed like on the Apple II machines. Must look at my old
notes and sources to be sure what must be changed in order to work on
the entire II range.
Regards
rich12345
> I have tested the game on Apple2000e, SDDApple (on AmigaOne) and then
> on Apple2Go (On MacOS X Tiger). It worked fine on these emulators,
it runs great on AppleWin
Rich
mmphosis
keys Z-X-K-Space
I am running AppleWin on Windows on VirtualBox on Mac OS X. And, it
works except when using the Apple II+ emulation in AppleWin because
the game is expecting lower case keys: z-x-k. The original Apple II
and Apple II+ didn't have lower case keyboards! Otherwise, the game
works with Apple //e emulation works under AppleWin. I had to slow
the emulator down to play. Is that cheating?!?
:)
Great work!
--------------------
Keyboard controls:
z - move left
x - move right
k - reach for and get a stone, you must be underneath the stone piles
on either the left or right side
Space - stop and drop
bloomer_au
The game booted, and responded to 'space to start', but then I
couldn't move with the keyboard. Perhaps it's related to the lower
case issue -- I think I tried both upper and lowercase, but can't be
sure.
Then I switched to Virtual II and played with a gamepad standing in
for a joystick.
- Wade
drHirudo
> I just read this important part of your posting:
>
> keys Z-X-K-Space
>
> I am running AppleWin on Windows on VirtualBox on Mac OS X. And, it
> works except when using the Apple II+ emulation in AppleWin because
> the game is expecting lower case keys: z-x-k. The original Apple II
> and Apple II+ didn't have lower case keyboards!
Ooops, I forgat about this detail, using only Apple IIe emulation. I
could have used the arrow keys, but I remember that the older Apple II
models did not have left and right arrows as well, and Ctrl+H and Ctrl
+U were used instead. Also the up and down arrow keys were only in the
later Apple II models, so if I use arrows + up arrow and space, it
will work whenever the Caps lock. But joystick will work in all the
cases.
> Otherwise, the game
> works with Apple //e emulation works under AppleWin. I had to slow
> the emulator down to play. Is that cheating?!?
> :)
There is also way to cheat by using the Joystick and the keyboard, but
I will not tell how :)
> Great work!
Thanks
> --------------------
> Keyboard controls:
>
> z - move left
>
> x - move right
>
> k - reach for and get a stone, you must be underneath the stone piles
> on either the left or right side
>
> Space - stop and drop
I easily can change the keys, but on Apple 2e models, I think the
people shall be instructed somehow to turn the Caps on, or they may
let to believe that the keys are not working.
Or just add code to read the alternative key combinations. I hope it
will not slow down much this way.
Will work on improving the code in the next days.
Regard
mmphosis
> models did not have left and right arrows as well, and Ctrl+H and Ctrl
> +U were used instead. Also the up and down arrow keys were only in the
> later Apple II models, so if I use arrows + up arrow and space, it
> will work whenever the Caps lock. But joystick will work in all the
> cases.
All models of Apple II had the left and right arrow keys, I know this
because we wore those keys out playing games. I like your choice of z
and x for left and right. It feels more retro on the Apple II because
modern flash games use z and x.
getkey:
LDA $C000
BPL getkey
BIT $C010 ; clear keyboard strobe and put bit 6 of keypress into
oVerflow flag
BVC skip ; skip the next instruction if the oVerflow flag is
clear
AND #$DF ; clear bit 5 to upcase the character
skip:
Alternatively, the last line could be this:
ORA #$20 ; set bit 5 to lowercase the character
eriknoc
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.
Steve Nickolas
][+ had left and right but not up and down.
You can actually identify the firmware of any Apple supporting caps lock:
PEEK(-1101)=6. Generally I think it's safe to assume caps lock down.
-uso.
mmphosis
This computer
http://www.old-computers.com/museum/computer.asp?c=956&st=1
doesn't appear to have left and right arrow keys on
it's keyboard
http://www.old-computers.com/museum/photos/Pravetz_Imko_Keyboard_s1.jpg
Michael J. Mahon
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.
-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."
Michael J. Mahon
It's hard to tell what those strange-colored keys are, but, in any case,
it's not an actual Apple computer--its keyboard is *very* non-standard.
Many early programs for the Apple II required the left and right arrow
keys to be used, so omitting them would require substituting cumbersome
control key combinations.
Bill Garber
"Michael J. Mahon" <mjm...@aol.com> wrote in message news:t4ydnXoSQamaqE7W...@giganews.com...
> mmphosis wrote:
>>> I could have used the arrow keys, but I remember that the older Apple II models did not have left and right arrows as well, and
>>> Ctrl+H and Ctrl +U were used instead.
>>
>> This computer
>>
>> http://www.old-computers.com/museum/computer.asp?c=956&st=1
>>
>> doesn't appear to have left and right arrow keys on
>>
>> it's keyboard
>>
>> http://www.old-computers.com/museum/photos/Pravetz_Imko_Keyboard_s1.jpg
>
> It's hard to tell what those strange-colored keys are, but, in any case, it's not an actual Apple computer--its keyboard is *very*
> non-standard.
Which is the reason for the clone's page saying "almost 100% compatible".
winston19842005
_vCdnZJ7Qblbrk7W...@giganews.com, "Michael J. Mahon"
<mjm...@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?
Michael J. Mahon
On the //e and later machines, the encoder's "Any Key Down" level
is readable by the processor. On earlier machines, it is not.
This allows a program to determine when no key is pressed. If keys
are pressed in an "overlapping" fashion, so that there is always some
key pressed, then AKD does not allow key releases to be detected--only
"no key pressed" can be detected.
mmphosis
wrote:
> On 4/24/10 2:09 PM, in article
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?
mmphosis
> winston19842005 wrote:
> > On 4/24/10 2:09 PM, in article
Okay, I think that answers my question: there is no "key up"
detection.
winston...@yahoo.com
Ok, I thought you'd just keep history of what was pressed before and
look for a change.
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?
sicklittlemonkey
> "Michael J. Mahon" <mjma...@aol.com> wrote in messagenews:t4ydnXoSQamaqE7W...@giganews.com...
> > It's hard to tell what those strange-colored keys are, but, in any case, it's not an actual Apple computer--its keyboard is *very*
> > non-standard.
It's the Bulgarian Pravetz clone that AppleWin emulates, and what the
author of the Wall Defence game grew up using.
One of the keys is a Latin/Cyrillic toggle.
> Which is the reason for the clone's page saying "almost 100% compatible".
>
> http://www.old-computers.com/museum/computer.asp?st=1&c=956
There are other differences: in the firmware ROMs and character ROMs;
some softswitch differences for detecting Latin/Cyrillic status. Also
I suspect the video scanner might be different based on some debugging
I did of a Bulgarian game.
Cheers,
Nick.
Michael J. Mahon
Not in the sense that a PC keyboard or MIDI provides, where
"key up" is a key-specific event just like "key down", making
them "chordable" keyboards.
Michael J. Mahon
If only one key is pressed at a time, then AKD going false is "key up".
If multiple keys are pressed, then only the *final* "key up" can be
detected.
AKD must be polled to detect it going false.
My RT.SYNTH program uses AKD polling to provide "piano-like" keyboard
response and legato playing
Michael J. Mahon
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.
mmphosis
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+.
winston...@yahoo.com
Just to clarify, the TI requires polling. But I've never seen it cause
a problem with writing a game that requires a key to be pressed to
move and lifting up on it to stop moving? Even in Basic this is not an
issue. A missed keypress, yes, if you are not checking often enough.
But in an assembly game I can't think it would be an issue.
There have been attempts at adding a "keyboard buffer" via an
interrupt routine that does the polling, but two attempts come to mind
- UCSD Pascal, where every disk access causes the interrupt to be
skipped (and there are a lot of disk accesses), and TI Logo, where
some longer than usual pauses are caused, I believe by large garbage
collections that apparently don't allow interrupts often enough...
vladitx
> On Apr 25, 6:25 am, "Bill Garber" <willy4...@garberstreet.com> wrote:
>
> > "Michael J. Mahon" <mjma...@aol.com> wrote in messagenews:t4ydnXoSQamaqE7W...@giganews.com...
> > > It's hard to tell what those strange-colored keys are, but, in any case, it's not an actual Apple computer--its keyboard is *very*
> > > non-standard.
>
> It's the Bulgarian Pravetz clone that AppleWin emulates, and what the
> author of the Wall Defence game grew up using.
Yep, Pravetz-82. That's why we're little bit uneasy with the left/
right arrows. ;-)
It is a direct clone of the Apple II+ with some hacked cyrillic. Why
there were no left/right arrows? Beats me, but at least got corrected
in later models.
> One of the keys is a Latin/Cyrillic toggle.
Cyrillic was just the lowercase latin. So these are simply Shift and
CapsLock.
AFAIR CapsLock also changes the number keys - not very comfortable.
> There are other differences: in the firmware ROMs and character ROMs;
The character ROM is hacked to replace lowercase latin with uppercase
cyrillic.
The only firmware ROM change that I remember is the "Apple ][" boot
message replaced,
> some softswitch differences for detecting Latin/Cyrillic status.
None that I know of.
> Also I suspect the video scanner might be different based on some debugging
> I did of a Bulgarian game.
It should be just the Apple II+ with Euro video timing - more blank
lines.
Nick - very good knowledge of some obscure machine you probably never
saw. ;-)
Cheers,
-- Vlad
drHirudo
> 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.
I know about this issue, but as mentioned on other posts, on the Apple
II you can read single keypress, but you can not check if the key is
released or not. I think this is an issue in the keyboard controller
of the Apple II.You can not read more keypresses from the same key, or
not until the repeat process starts, where you receive keypresses even
if you clear the strobe. But this introduces keyboard response lag,
which in fast games like Wall Defence it is unacceptable. That's why
there is the joystick control implemented, where you can read the
joystick position anytime, and even different position for the
directions - half and full right for example. I believe this keyboard
problems were the reason some Apple II games where joystick only.
These games were the reason I had Joystick with my Apple 2 clone. On
the other hand I saw some Joystick only games hacked to work with
keyboard, but this was rare.
> 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.
It is this way on the Vic-20. When I port some game, I don't just do
straight port. I take into account the pecularities of the machine and
take advantage of the them. Unfortunally, with different machines,
some features had to go, or other new features are added. For example
I will not make graphics for CPM game, because there is no standard
graphic output there. Only texts with some control characters, despite
the different terminals available.
> That would make more sense to me
> anyways.
I remember the game Montezuma's Revenge on the Apple II was kind of
able to read exact keypress and keyreleases. When I asked an assembler
guru some twenty years ago, how it was done for this particular game,
his answer was: Because the game is slow, you can not see the
difference when the key-repeat had started, so you beleive that it can
detect keyrelease.
drHirudo
The Imko and the Pravetz-82 computers, which we had at school, did not
had left and right arrow keys, so I assumed that the older Apple II
models, of which the bulgarian computers were almost exact clones,
also lack these keys. I stand corrected.
These computers were the reason I knew about the Ctrl+H and Ctrl+U
keys combinations. On the other hand, the Pravetz-8C, which I had at
home, had all the direction keys, plus F1 and F2 and upper and lower
case letters (Latin and Cyrillic, switchable with hardware switch). F1
and F2 were mapped to the Joystick buttons 1 and 2 - very handy for
pinball games and games with lots of shooting, where a friend can help
you with the shooting by pressing F1 on the keyboard.
winston19842005
dfb72c7d-4b57-4df7...@b6g2000yqi.googlegroups.com, "drHirudo"
<drhi...@gmail.com> wrote:
> On 24 Апр, 08:58, eriknoc <erik...@yahoo.com> 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.
>
> I know about this issue, but as mentioned on other posts, on the Apple
> II you can read single keypress, but you can not check if the key is
> released or not. I think this is an issue in the keyboard controller
> of the Apple II.You can not read more keypresses from the same key, or
> not until the repeat process starts, where you receive keypresses even
> if you clear the strobe. But this introduces keyboard response lag,
> which in fast games like Wall Defence it is unacceptable. That's why
> there is the joystick control implemented, where you can read the
> joystick position anytime, and even different position for the
> directions - half and full right for example. I believe this keyboard
> problems were the reason some Apple II games where joystick only.
> These games were the reason I had Joystick with my Apple 2 clone. On
> the other hand I saw some Joystick only games hacked to work with
> keyboard, but this was rare.
Ah, I'm starting to catch on a little here.
The TI has a lag time between pressing a key and auto-repeat. But this
doesn't present itself in the key read routine, it is part of the Basic
routines to read input.
And some of the early emulator writers emulated this in both modes, so
game-play was really messed up on those.
Steve Nickolas
> The Imko and the Pravetz-82 computers, which we had at school, did not
> had left and right arrow keys, so I assumed that the older Apple II
> models, of which the bulgarian computers were almost exact clones,
> also lack these keys. I stand corrected.
>
> These computers were the reason I knew about the Ctrl+H and Ctrl+U
> keys combinations. On the other hand, the Pravetz-8C, which I had at
> home, had all the direction keys, plus F1 and F2 and upper and lower
> case letters (Latin and Cyrillic, switchable with hardware switch). F1
> and F2 were mapped to the Joystick buttons 1 and 2 - very handy for
> pinball games and games with lots of shooting, where a friend can help
> you with the shooting by pressing F1 on the keyboard.
The Apple //e and later had the same functionality as your F1/F2 in Cmd/Opt
(or Open Apple/Solid Apple in earlier models). Not having it on the ][+
frustrated me to no end since some programs make it impossible to reboot
without powering down!
-uso.
sicklittlemonkey
> Yep, Pravetz-82. That's why we're little bit uneasy with the left/
> right arrows. ;-)
Heh, good one. ;-)
> Nick - very good knowledge of some obscure machine you probably never
> saw. ;-)
All I "know" is what Stannev implemented in AppleWin's Pravetz
emulation. There is definitely a softswitch change, one bit in C060 I
think, maybe for a later model than the '82.
The Bulgarian game I looked at was "Walking in the town" which uses
the floating bus to keep track of game time. I tried several
variations (II or //e, PAL or NTSC) but the game would sometimes speed
up, slow down, or hang.
Cheers,
Nick.
Michael J. Mahon
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 J. Mahon
It will always be an issue in the sense that polling must occur
frequently enough so that key state changes are not missed.
Sometimes this is easy, and sometimes it is difficult.
You could think of the Apple keyboard latch as a 1-key typeahead
buffer, and clearing the keyboard strobe as "emptying" the buffer.
> There have been attempts at adding a "keyboard buffer" via an
> interrupt routine that does the polling, but two attempts come to mind
> - UCSD Pascal, where every disk access causes the interrupt to be
> skipped (and there are a lot of disk accesses), and TI Logo, where
> some longer than usual pauses are caused, I believe by large garbage
> collections that apparently don't allow interrupts often enough...
Exactly. And the fix for these cases is to continue to poll *during*
long operations, with a sufficient frequency to avoid losing keypresses.
The disk access code could (possibly) incorporate keyboard polling, and
the garbage collector certainly could.
Explicit polling is preferred in any timing-dependent operation, since
the time for polling can be completely accounted for, whereas interrupts
would be unpredictable and possibly disruptive.
Michael J. Mahon
> On 24 Рпр, 08:58, eriknoc <erik...@yahoo.com> 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.
>
> I know about this issue, but as mentioned on other posts, on the Apple
> II you can read single keypress, but you can not check if the key is
> released or not. I think this is an issue in the keyboard controller
> of the Apple II.You can not read more keypresses from the same key, or
> not until the repeat process starts, where you receive keypresses even
> if you clear the strobe. But this introduces keyboard response lag,
> which in fast games like Wall Defence it is unacceptable. That's why
> there is the joystick control implemented, where you can read the
> joystick position anytime, and even different position for the
> directions - half and full right for example. I believe this keyboard
> problems were the reason some Apple II games where joystick only.
> These games were the reason I had Joystick with my Apple 2 clone. On
> the other hand I saw some Joystick only games hacked to work with
> keyboard, but this was rare.
This capability was added in the Apple //e and later machines, as noted
elsewhere in this thread.
Michael J. Mahon
Of course, the Ctl-Open Apple-Reset reboot was a new feature of the //e
ROM, and had no counterpart on the ][ or ][+.
A non-power-cycling reboot of the ][ or ][+ required a Reset to get into
the monitor or into BASIC, and doing a "s^P" or "PR#s". Since a program
could block the Reset, there was often no easy alternative to power-
cycling--which was the intent of intercepting Reset: to prevent the
examination or capture of the program code.
The Autostart ROM even clobbered bytes in each page of memory upon
Ctl-OA-Reset, for a similar copy-discouraging reason.
vladitx
> All I "know" is what Stannev implemented in AppleWin's Pravetz
> emulation. There is definitely a softswitch change, one bit in C060 I
> think, maybe for a later model than the '82.
That should be for a later model based on the //e (8E/8A/8C).
> The Bulgarian game I looked at was "Walking in the town" which uses
> the floating bus to keep track of game time. I tried several
> variations (II or //e, PAL or NTSC) but the game would sometimes speed
> up, slow down, or hang.
I remember the II/II+ and //e video timing was different in some small
details. It's also probable the emulator is giving the problem.
sicklittlemonkey
> I remember the II/II+ and //e video timing was different in some small
> details. It's also probable the emulator is giving the problem.
The floating bus code is based on Sather's logic equations. I'm pretty
sure it's correct, but do have a look if you're interested. ;-)
Cheers,
Nick.