[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple video question?
- Subject: Re: Apple video question?
- From: Holger Picker <pickerh@uni-muenster.de>
- Date: Thu, 20 Feb 2003 12:09:22 +0100
- In-reply-to: <kT05a.99974$Q_1.2466755@news2.telusplanet.net>
- Newsgroups: comp.sys.apple2
- Organization: Westfaelische Wilhelms-Universitaet Muenster, Germany
- References: <kT05a.99974$Q_1.2466755@news2.telusplanet.net>
- Sender: "Holger Picker" <pickerh@uni-muenster.de>
- Xref: archiver1.google.com comp.sys.apple2:27605
On Thu, 20 Feb 2003, Dan Ritter wrote:
> Date: Thu, 20 Feb 2003 09:05:20 GMT
> From: Dan Ritter <dritter@angelfire.com>
> Newsgroups: comp.sys.apple2
> Subject: Apple video question?
>
> I was wondering how the Apple2 generated video? Is it all software driven?
> Because I remember playing some really good games on my old Apple. The
> video seemed very fast for software generated.
>
Hello,
yes, the graphic is all software driven. There is no hardware support for
the programmer: no sprites (as found on the C64), hardware acceleration
(like blitter), no raster interrupt etc. The speed of many games was indeed
surprisingly fast, although the programmers hade to cope with a rather
chaotic organisation of the video memory in addition. For example: For
positioning a so-called shape (i.e. a spaceship or a monster) to all 280
possible x coordinates you would need 14 different shapes. On the C64,
however, which had a more "logically" structured video ram, you would only
need 8 shapes for a resolution of 320 pixels. It was a demanding task to
find out the correct byte of the video memory and within this the correct
bit if you wanted to plot a single dot on the screen. (Most of the draw
line function found in the AppleII rom deals with just that.) Nevertheless,
the programmers were able to take advantage of this and combined the 14
different shapes with 14 different looking images so that, while moving the
shape around the screen, the shape was also animated.
(BTW.: Things were getting even worse with double hi-res. Here the bitmap
is split into two halves, and you need to switch between the two by poking at
special memory softswitches. This is the reason why double hi-res was seldom
used for action games. Programs like "Prince of Persia" or "Wings of Fury"
used double hi-res to display the title screen, but the arcade graphic was
still done by using the standard hi-res mode.)
Another thing was that you would also have to use huge lookup tables to
receive the start address of each screen line when drawing your shape. Of
course, you could have calculated it every time, but this would have been
far too slow. Many programmers went as far as writing code that directly
copies data to or within the video memory, i.e. they used absolute addressing
modes instead of indirect addressing. For example, take a look at the following
code taken from "Situation Critical, Phase II", a game that used horizontal
scrolling:
$80c/begin of loop
JSR $800; jump to subroutine that generates sound
LDA $2002,y; load byte from video memory
STA $2000,y; copy it to an address two bytes below,
thus scrolling the graphic 14 pixels to
the left.
LDA $2402,y; do the same thing for line 2 of the screen
STA $2400,y
LDA $2802,y; and line 3
STA $2800,y
LDA $2c02,y; and line 4...
STA $2c00,y
...
lots of code here, for every line you want to scroll do
LDA address+2,y
STA address,y
until finally
...
INY
CPY #$26; all bytes of one line copied?
BCC do_loop_again
finished here
do_loop_again: JMP $80c/begin of loop; this way of jumping was needed
since the loop was too big for
a simple relative branch
This very long copying loop had to be written twice: one for hi-res page 1
and one for hi-res page 2.
Please note also the trick the programmers invented here: They used the
scrolling loop as a delay loop for the sound generation. By combining sound
and scrolling loop, they were able to reduce the amount of clock cycles a
lot. (This technique was also used e.g. in "Boulder Dash".)
Many games ("Karateka", "Drol", "Wings of Fury" etc.) also used double
buffering, so the user could not see how the shapes were drawn to the
screen. Even if the frame rate dropped very low (e.g. with flight/space
simulators like "Flight Simulator II" or "Space Rogue"), the user would only
see finished pictures, but never how they were drawn. (If you've got one of
the following AppleII emulators for the PC, either ApplePC or Dapple, you
can take a look at this by switching the emulator output to double view i.e.
showing both hi-res pages at the same time.)
Another technique was dithering. Lots of games (especially graphic
adventures) used various patterns to create the impression of having more
than 6 colours on the screen. (A good example for this probably is "Death in
the Caribbean".)
All in all, I personally still admire the work that was done by the AppleII
programmers. Very creative, very inventive.
Kindest regards
Holger