Introduction to to Graphics in C on the Apple II
Bill Buckels
following addition to the AppleOldies website:
http://www.appleoldies.ca/azgraphics33/index.htm
Please visit the above link.
Single and Double
Lo-Res and Hi-Res Graphics in the
C Programming Language
Introduction to to Graphics in C on the Apple II
The purpose of this page is to share some of my routines and working
programs for those of you who are interested in Apple II Graphics in
C. When I first started developing in C on the Apple II back in the
1980's, I expanded the ProDOS graphics library that came with my
compiler (the Aztec C Apple II C65 Cross-Development Environment for
MS-DOS).
Recently I expanded the Apple II DOS 3.3 graphics library for this
same compiler creating a simpler DOS 3.3 equivalent of my ProDOS
graphics library (which I call the "G3" library for DOS 3.3). The
first releases of the "G3" library provided support for Apple II Hi-
Res Mode Graphics only.
Having devoted most of my Apple II C language graphics programming
during that time back in the 1980's exclusively to Hi-Res mode, I
decided recently (December 2009) to explore some of the other graphics
modes available... Lo-Res, Double Lo-Res and Double Hi-Res modes. I
stopped short of the additional "secret" modes.
As a result I have put-together an Apple II DOS 3.3 Aztec C compiler
distribution for MS-DOS and Windows based both on my recent and past
work with Apple II Graphics which includes an updated "G3" link
library and a reasonably large number of demo programs. These demo
programs are detailed on this page and hopefully will prove
informative to the novice and expert alike (although nothing presented
here is particularly new or mind-boggling). But this is not just some
lame attempt at a DOS 3.3 target environment either... DOS 3.3 Text
and Binary File Operations like reading "slide-show" scripts and
loading and saving Apple II Images are also supported by this compiler
and the "G3" library making all of this reasonably effective to
actually do something.
These programs listed here with working disk images, source code and
the compiler are up for download at the Aztec C website:
Download Apple33 Aztec C DOS 3.3 Distribution
http://www.aztecmuseum.ca/Apple33.zip
Note: Everything on this page is included in the above distribution
including Apple II diskimages of all programs, the source code and
library routines for all programs, and of course the cross-compiler
and the build environment pre-configured to produce these as well as
your own Apple II DOS 3.3 Aztec C programs from the comfort of your
Windows or MS-DOS compatible computer or favourite MS-DOS emulator.
The idea here is to learn by example without wading through mounds of
"fakeware" technical documents.
In all of this I also dabble with vector graphics, but much of my work
focuses around converting bitmapped graphics between different
platforms and the Apple II (and working with these under DOS 3.3).To
this end I have written and provide several utility programs which are
also part of this distribution and which are also discussed here.
Several of the Utility programs for converting from PC Bitmapped
Graphics to Apple II Bitmapped Graphics are written in 16 bit
Microsoft C for MS-DOS. I have been using that compiler for over 20
years to write simple graphics conversion utilities with excellent
results. To use these Utility programs run in an MS-DOS emulator like
DOSBox if you can't run them raw.
If you are lucky enough to be a Windows User your best bet to handle
the various archives here is Andy McFadden's CiderPress and if you are
lucky enough to be a Windows User, the DOS 3.3 compiler distribution
is provided with shortcuts to make DOS 3.3 development a very simple
matter (as it is with the other Aztec C compilers that I provide
through the Aztec C Museum website). If you are not a Windows User you
have my deepest sympathy, and note that if absolutely necessary this
compiler runs under Unix in an MS-DOS Emulator, and although I much
prefer Windows, I have occasionally held my nose and run this under
Ubuntu without problems.
Finally, the demos provided here work nicely under Windows in the
AppleWin Emulator (as well as the emulator that comes with Apple II
Oasis) at their highest speeds. I have also run these on my real
Apple //e with the 8 MHZ Zip Chip where they also work nicely.
I should also note that I tested the Double Lo-Res and Double Hi-Res
graphics on both a composite monitor and an rgb monitor on my real
Apple //e. The composite monitor gave me the best results between the
two, although the AppleWin and Apple II Oasis emulators gave me the
best results of all (albeit the fact that the emulators are not
real:). And I made a strange discovery on my real Apple //e... after
running Double Lo-Res or Double Hi-Res programs, if I didn't turn-off
the Double Res mode, and then I attempted to display Hi-Res graphics
afterwards in some other program, and even if I had rebooted, the rgb
monitor will display "garbage" but the composite monitor will display
Hi-Res graphics in some strange and undocumented reduced color palette
which looks ok but doesn't work quite right. The moral here is to
clean-up when done:)
So without much further ado, please review and enjoy the code listings
on this website and feel free to download and work with this DOS 3.3
cross-compiler and its many demos and utilities. One final note... it
would be a simple matter to port these routines from DOS 3.3 to ProDOS
8... not much of a port really... but that exercise is left for the
reader or for another day:) as is porting to other compilers which may
create faster programs but don't do everything that Aztec C does.
A word or two of explanation... cc65 has become a popular compiler on
the Apple II and although at time of this writing no DOS 3.3 file
operations are supported directly in cc65, one can always add this
sort of thing. cc65 seems to produce faster code than Aztec C and
although my preference is biased towards Aztec C I am also providing
disk images of working Lo-Res demos in both compilers for those of you
who may be interested (even in porting code from Aztec C to cc65).
Happy New Year and Have Fun!
Bill Buckels
bbuc...@mts.net
January 2010
John B. Matthews
<efa1e6b1-7ab2-4e65...@m16g2000yqc.googlegroups.com>,
Bill Buckels <bbuc...@escape.ca> wrote:
> For your perusal and viewing pleasure I am pleased to announce the
> following addition to the AppleOldies website:
>
> http://www.appleoldies.ca/azgraphics33/index.htm
Well done! I've added links back to your site:
<http://home.roadrunner.com/~jbmatthews/apple2.html#rp1c>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Bill Buckels
>
> Well done! I've added links back to your site:
>
> <http://home.roadrunner.com/~jbmatthews/apple2.html#rp1c>
>
Ok then... here's another cc65 demo: Rod's Color Pattern for Hi-Res
Mode
http://www.appleoldies.ca/azgraphics33/rodhicc.htm
The cc65 demos that I have provided do not use any drivers and will
run either in ProDOS or DOS 3.3 without modification.
Bill
John B. Matthews
<ff2d852d-a587-41aa...@37g2000vbn.googlegroups.com>,
Bill Buckels <bbuc...@escape.ca> wrote:
> On Jan 6, 8:55 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> >
> > Well done! I've added links back to your site:
> >
> > <http://home.roadrunner.com/~jbmatthews/apple2.html#rp1c>
> >
> Hi Dr. John,
>
> Ok then... here's another cc65 demo: Rod's Color Pattern for Hi-Res
> Mode
>
> http://www.appleoldies.ca/azgraphics33/rodhicc.htm
Excellent!
> The cc65 demos that I have provided do not use any drivers and will
> run either in ProDOS or DOS 3.3 without modification.
And both optimize by using a base address lookup table. I wanted to
compare your approach with an example of using static linking in cc65; I
had the link, but forgot the example!
<http://home.roadrunner.com/~jbmatthews/a2/cross.html#sec5>
Both give a single-load binary and yours is fast and cross-OS. I would
say the results are exemplary. Thanks!
Bill Buckels
> And both optimize by using a base address lookup table. I wanted to
> compare your approach with an example of using static linking in cc65; I
> had the link, but forgot the example!
The lookup table trick avoided many calculations for me over the last
30 years. I highly recommend precalculating everything that one can.
This is probably just common-sense to most of us but I appreciate that
you have recognized how this technique can be applied to saving
precious instructions on these tiny processors:)
>
> Both give a single-load binary and yours is fast and cross-OS. I would
> say the results are exemplary. Thanks!
>
When one is using tiny processors (not only old C compilers) optimal
techniques seem to become honed razor-sharp as we also know. A good
example is the ballistic speed that cc65 works when compared to Aztec
C which was pretty damned good by the end of its life cycle.
I just wanted to post the alternative to that lookup table that you
refer to (see below)so I remember to make a note of this somewhere...
too many instructions... that's the thing for us to remember... this
is actually part of the code that I used in 1980-something to create
the table for the hi-res display:
/* provides base offset for hires scanlines */
/* does not bother to check whether we are in range */
/* gets the address as quickly as possible */
/* stays away from processor intensive mul and div */
gethibase(currentline,currentbase)
int currentline;
int *currentbase;
{
FILE *fp;
int ybase=0,z,a;
if(currentline >63)
{
if (currentline < 128)
{
ybase+=0x28;
currentline-=64;
}
else
{
ybase+=0x50;
currentline-=128;
}
}
z=(currentline>>3);
a = (z<<7)|ybase;
*currentbase = (currentline - (z<<3))<<10 | a;
/*
fp = fopen("hb.txt","a");
fprintf(fp,"%d,", *currentbase);
if (currentline%8 == 0) fprintf(fp,"\n");
fclose(fp);
*/
}
Having Fun,
Bill
Michael J. Mahon
> On Jan 7, 9:25 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
>
>>And both optimize by using a base address lookup table. I wanted to
>>compare your approach with an example of using static linking in cc65; I
>>had the link, but forgot the example!
>
>
> The lookup table trick avoided many calculations for me over the last
> 30 years. I highly recommend precalculating everything that one can.
> This is probably just common-sense to most of us but I appreciate that
> you have recognized how this technique can be applied to saving
> precious instructions on these tiny processors:)
And tables are an excellent example of the time-space tradeoff
in action. If space is more important than speed, calculation is
good.
I suspect the "base calculation" is both smaller and faster in
assembly language:
* Hi-res base address calculation. This comes from
* the HPOSN routine at $f411.
*
* Put the line in A. The result is placed in $26-27,
* offset from address 0. X and Y are not disturbed.
*
* You must OR $20 or $40 into $27 to select the hi-res
* page.
bascalc pha
and #$c0
sta hbasl
lsr
lsr
ora hbasl
sta hbasl
pla
sta hbash
asl
asl
asl
rol hbash
asl
rol hbash
asl
ror hbasl
lda hbash
and #$1f
sta hbash
rts
(From Andy McFadden's fast graphics routines, taken in turn from
the Applesoft HPOSN routine.)
Bit fiddling of this kind has always been the "poster child" for
high-level language inefficiency, though it is seldom needed in
practice. In Apple II graphics, it finds its way into the inner
loop (unless two pages of memory are used for a table)!
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."
sicklittlemonkey
> Bit fiddling of this kind has always been the "poster child" for
> high-level language inefficiency, though it is seldom needed in
> practice.
True, and Woz made perhaps the best effort in Disassembly Lines:
http://www.txbobsc.com/aal/1986/aal8612.html#a9
Cheers,
Nick.
Michael J. Mahon
Beautiful!
DaveSchmenk
> For your perusal and viewing pleasure I am pleased to announce the
> following addition to the AppleOldies website:
>
> http://www.appleoldies.ca/azgraphics33/index.htm
>
>
> Single and Double
> Lo-Res and Hi-Res Graphics in the
> C Programming Language
> Introduction to to Graphics in C on the Apple II
>
> Happy New Year and Have Fun!
>
> Bill Buckels
> January 2010
Bill-
I am impressed with the effort that went into these demos. I thought
I woke up in an alternate reality when I saw the cc65 versions ;-)
I had not seen this version either. Wow. Time to revisit this
routine again. Both the calculated address and table lookup address
routines have their place. Based on the type of graphics operation
I'm performing, I will decide to use the calculated address if it is
only a small percentage of the total time. Fill routines will
generally get the calculated version. Line drawing will generally get
the table lookup. Of course the line address calculation is only half
the equation. Let's not forget the divide-by-7 that is needed for
edges and horizontal offset. Again, there is the table vs.
calculation tradeoff. Fast hires graphics on the Apple II is one of
the most intriguing problems I've encountered in graphics programming.
Dave...
Bill Buckels
>I thought I woke up in an alternate reality when I saw the cc65 versions ;-)
My complaint with cc65 is primarily that it's not as easy for me to
use as Aztec C. I am still trying to wrap my head around the linker
and there are many things that I dislike outright like the way inline
assembly has been implemented.
However, the optimizer seems quite good and the compiler seems to
produce tighter and smaller code than Aztec C which is pretty hard to
argue with.
Later,
Bill
mdj
> On Jan 10, 9:48 am, DaveSchmenk <dschm...@gmail.com> wrote:
>
> >I thought I woke up in an alternate reality when I saw the cc65 versions ;-)
>
> My complaint with cc65 is primarily that it's not as easy for me to
> use as Aztec C. I am still trying to wrap my head around the linker
> and there are many things that I dislike outright like the way inline
> assembly has been implemented.
It *is* a bit odd, considering the 'normal' way seems easier to
implement. There's always external linking though I and I tend to find
things are either so small just leave em in C or big enough to
externally link but different strokes...
> However, the optimizer seems quite good and the compiler seems to
> produce tighter and smaller code than Aztec C which is pretty hard to
> argue with.
I suspect it's easier when you don't have floating point types to
worry about.
Welcome back, BTW
Matt
Bill Buckels
> I suspect it's easier when you don't have floating point types to
> worry about.
Hi Matt,
I think there is more to cc65's efficiency over Aztec C than merely
this small difference... subtleties... not that it really matters in
the grand scheme of things since the bulk of non-trivial Apple //e
development in C world-wide is so miniscule as to be less than
insignificant and I am but a fly on the leg of an elephant.
Q - What happened to the fly who sat on the elephant's leg?
A - He got pissed-off!
That notwithstanding, there are very few developers that have
experience with both compilers and I am determined that I will make
some effort to bring my knowledge level on cc65 close to my level on
Aztec C if for no other reason than to be able to point-out that
cc65's handling of inline assembly is not to my liking. Perhaps when I
know more it will be to my liking.
For example, how would I do the following in cc65 using inline
assembly? See both links below. Please rewrite in entirety using cc65,
test and debug, and repost to this thread for discussion if you will,
starting with this:
http://www.appleoldies.ca/azgraphics33/lores.c.txt
The link above uses Aztec C's zero page pseudo-registers which are
"always-on".
The total immediate goal here with your expert help on the above is to
rewrite the following program in its entirety in cc65 (not simply Dr.
John's portion which comprises Rod's Color Pattern):
http://www.appleoldies.ca/azgraphics33/lodemo.htm
Thanks. If this works out perhaps you can help me decipher cc65's
linker also. I want to avoid the hi-res page altogether for my hi-res
and double hi-res graphics stuff so I can port my Aztec C programs to
cc65 (not just some puny demos).
It may be something missing in the translation to English but the cc65
documentation is not easy for me to read and I need clear examples
like full rewrites of my Aztec C stuff for this to make sense to me.
RTFM is just not an acceptable answer... (gauntlet down:)
It would probably be a good idea for you to install Aztec C as well as
cc65 just to C what I C.
Bill
mdj
> For example, how would I do the following in cc65 using inline
> assembly? See both links below. Please rewrite in entirety using cc65,
> test and debug, and repost to this thread for discussion if you will,
> starting with this:
>
> http://www.appleoldies.ca/azgraphics33/lores.c.txt
Now you've lost me Bill. Didn't you already port them ?
> It may be something missing in the translation to English but the cc65
> documentation is not easy for me to read and I need clear examples
> like full rewrites of my Aztec C stuff for this to make sense to me.
> RTFM is just not an acceptable answer... (gauntlet down:)
How about RTFO, as in 'output' of compiler.
Bill Buckels
> >http://www.appleoldies.ca/azgraphics33/lores.c.txt
>
> Now you've lost me Bill. Didn't you already port them ?
>
See Oliver's response... and no I didn't port much and I documented
what I did and didn't document what I didn't do but I think I may have
already done more with cc65 than at least one lost soul even though I
haven't really done a thing yet:)
I'm off to try some of Oliver's stuff and have some more fun.
Bill