Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update
75 views
Skip to first unread message
Bill Buckels
Apr 8, 2013, 10:34:37 PM4/8/13
to
As promised! A less than modest C cross-Compiler for the Apple IIe!
http://www.aztecmuseum.ca/AppleX.zip
No installation necessary. Just unzip anywhere that MS-DOS (or DOSBox) runs
and you are ready to go! Comes complete with Windows XP shortcuts, and
should run out-of-the-box as it does on my Windows XP box!
It has been several years since the AppleX cross-compiler distribution of
Aztec C65 for the Apple IIe and ProDOS 8 was updated. Much has been added...
This update was just completed within the hour... and some additional
documentation will still be added in the coming days, but it is otherwise
complete. Before I pass-out from exhaustion, here is a brief synsopsis of
what we have here, and please feell free to download this and make sure I
haven't messed-up royally... feedback welcome! Who knows when I'll have time
to update this again...
Overview
This is a "customized version" of the Manx Aztec C65 Version 3.2b MS-DOS
cross-development environment for an Apple IIe with 128K of memory running
PRODOS 8. It is targetted specifically at writing PRODOS SYS programs, and
programs that run under the Aztec C ProDOS Unix-like Shell. Programs are
written and compiled on the IBM-PC and then moved to an Apple IIe or to an
emulator disk image to be run. A modified Graphics link library is provided
which has been extended to support the use of bit-mapped graphics images,
sound routines, and the use of auxiliary memory. The build environment has
been configured to run under Windows XP and a pre-configured shortcut has
been provided for this purpose as well as a make utility program and some
additional programs to be used in conjunction with make.
Release Notes Summary
Additional Directory Structure - AppleX\PROGRAMS
For the AppleX 2013 update, I have separated the directory structure for
non- trivial Graphics and other non-trivial Demo Programs and placed them
under AppleX\PROGRAMS. None of these were ever included in AppleX before
now, and all have been written since late Fall of 2012 with the exception of
a couple of the utilities and some demos from the Apple33 DOS 3.3 Aztec C65
cross-compiler distribution. Those have been completely rewritten and are
much improved.
Graphics Mode Support Extended
AppleX now Supports LGR - Lo-Res, DLGR - Double Lo-Res, HGR - Hi-Res Color
and Monochrome, DHGR - Double Hi-Res Color and Monochrome. 4 of the
subdirectories in the AppleX\PROGRAMS directory are related to the 4 main
graphics modes of the Apple II (see above), and each contains source code,
programs, utilities, documentation, and disk images related to working with
the AppleX Aztec C65 distribution and Graphics on the Apple II. AppleX
provides image loaders, line drawing routines, and font routines and so
forth for all 4 modes.
And most importantly (to me), AppleX comes with documented methodology and
tools to aquire bit-mapped graphics from a variety of sources including
Windows, Apple II Native Format, and Hybrid Sources like
AppleWin Screen Captures of running programs that make obtaining graphics
for use in your own programs easy if not too easy.
Robust Documentation Much Expanded
Please read the source code and documentation, and run the demos and
programs you find in each AppleX\PROGRAMS\subdirectory as well as any
documentation you find laying about for more information.
The immensely expanded source code in the AppleX\GRAPHICS directory is also
a good reference for more information. This is the source code for the G2
(Graphics) library, which also includes the source code from the original
Aztec C65 G.lib.
Comprehensive documentation for Aztec C itself and its original toolchain
has been available in pdf format user's manuals from the Aztec C website at
www.aztecmuseum.ca for a number of years now. But with this release of
AppleX and with many pdf "tutorials" and users manuals being very much
expanded-on especially for Apple II graphics programming, new life has been
breathed into this old compiler, taking its capabilities far beyond the
Apple II Community's "Retro-Compiler" perception... until AppleX, all that
was available was a previous ProDOS native-mode shell version that does not
even support creating floating point SYS programs, so if this perception is
not clearly incorrect, it is somewhat.
When it comes to documentation and usability Aztec C more than holds its
own, even today, 25 or so years later, and AppleX more than compensates for
whatever inefficiencies it mat have by providing a stable
and feature-rich environment which includes the documentation by Manx
Software (available from the website at www.aztecmuseum.ca) supplemented
with what AppleX provides.
Tools and More Tools
The AppleX\TOOLS directory also contains many utilities. Some are also
related to Graphics, but some were written long ago. The utilities in the
subdirectories under the AppleX\PROGRAMS directory have all been
recently written, and are more specifically targetted at today's working
environment.
ProDOS Directory Services
The AppleX\PROGRAMS directory also contains a subdirectory called LISTDIR
which demonstrates and implements G2 library routines related to reading
ProDOS disk catalogues and finding files and so forth.
Command Line and Unix-Like Programs for ProDOS
Another expansion of the AppleX distribution is the production of programs
that run under the Aztec C Shell for ProDOS 8. Shell Versions of SYS
programs, which are PCODE mixed with native 6502 code. allow command line
arguments and wildcard expansion and so forth, while being able to run at
the same speed of execution as their SYS program counterparts in time
critical operations like graphics and floating point calculations.
Previous Updates and Brief History
Since making AppleX available I have kept adding to it.
Website
I also built a website called www.aztecmuseum.ca for AppleX and many other
Aztec C compilers for other platforms, and time permitting I have done my
best to keep the website up to date.
Full Blown Aztec C Projects with Source Code
After building the website, I made selected Full-Blown non-trivial
"Projects" in Aztec C65 part of the distribution. They are in the PROJECTS
directory. Two of these projects (METOO and TIME) use overlays
and auxiliary memory extensively and should prove informative. I also have 3
additional overlay projects that I will someday make available if time
permits.
Mixing the Old with the New
As I have done in the 2013 update with the PROGRAMS subdirectory, I kept
these projects in the PROJECTS directory, separate from the SAMPLES
directory that comprised the first AppleX distribution.
I also provided DOSBox support for Aztec C65 and included this with AppleX,
not that it took me much work. With Windows 7 displacing WIndows XP, it
turns-out this was a good idea. Along the way I also tested in
Ubuntu in another DOS emulator, without problem.
I have discovered through all this that there doesn't seem to be anything I
can't do with this old compiler...
Apple33 Aztec C65 for DOS 3.3
Along the way, I also created a smaller distribution of Aztec C65 for
building Apple II DOS 3.3 programs.
Then for a couple of years or so, until Fall of 2012, I didn't do much with
AppleX or Apple33.
Permission to Distribute Aztec C65
Someone pointed-out to me at some point that I have never indicated in this
distribution that I have permission to distribute Aztec C65. This is simply
because I never updated the read me.
Copyright Clarification - Copyright and Conditions of Use
Harry Suckow (the Copyright holder for Aztec C) has given permission to
redistribute Manx Software Systems discontinued Aztec C compilers for
now-obsolete platforms.Your use must be Fair as it applies to Manx's
Copyright on these compilers. They are not for sale at any price!
Bill Buckels
bbuc...@mts.net
http://www.aztecmuseum.ca/AppleX.zip
No installation necessary. Just unzip anywhere that MS-DOS (or DOSBox) runs
and you are ready to go! Comes complete with Windows XP shortcuts, and
should run out-of-the-box as it does on my Windows XP box!
It has been several years since the AppleX cross-compiler distribution of
Aztec C65 for the Apple IIe and ProDOS 8 was updated. Much has been added...
This update was just completed within the hour... and some additional
documentation will still be added in the coming days, but it is otherwise
complete. Before I pass-out from exhaustion, here is a brief synsopsis of
what we have here, and please feell free to download this and make sure I
haven't messed-up royally... feedback welcome! Who knows when I'll have time
to update this again...
Overview
This is a "customized version" of the Manx Aztec C65 Version 3.2b MS-DOS
cross-development environment for an Apple IIe with 128K of memory running
PRODOS 8. It is targetted specifically at writing PRODOS SYS programs, and
programs that run under the Aztec C ProDOS Unix-like Shell. Programs are
written and compiled on the IBM-PC and then moved to an Apple IIe or to an
emulator disk image to be run. A modified Graphics link library is provided
which has been extended to support the use of bit-mapped graphics images,
sound routines, and the use of auxiliary memory. The build environment has
been configured to run under Windows XP and a pre-configured shortcut has
been provided for this purpose as well as a make utility program and some
additional programs to be used in conjunction with make.
Release Notes Summary
Additional Directory Structure - AppleX\PROGRAMS
For the AppleX 2013 update, I have separated the directory structure for
non- trivial Graphics and other non-trivial Demo Programs and placed them
under AppleX\PROGRAMS. None of these were ever included in AppleX before
now, and all have been written since late Fall of 2012 with the exception of
a couple of the utilities and some demos from the Apple33 DOS 3.3 Aztec C65
cross-compiler distribution. Those have been completely rewritten and are
much improved.
Graphics Mode Support Extended
AppleX now Supports LGR - Lo-Res, DLGR - Double Lo-Res, HGR - Hi-Res Color
and Monochrome, DHGR - Double Hi-Res Color and Monochrome. 4 of the
subdirectories in the AppleX\PROGRAMS directory are related to the 4 main
graphics modes of the Apple II (see above), and each contains source code,
programs, utilities, documentation, and disk images related to working with
the AppleX Aztec C65 distribution and Graphics on the Apple II. AppleX
provides image loaders, line drawing routines, and font routines and so
forth for all 4 modes.
And most importantly (to me), AppleX comes with documented methodology and
tools to aquire bit-mapped graphics from a variety of sources including
Windows, Apple II Native Format, and Hybrid Sources like
AppleWin Screen Captures of running programs that make obtaining graphics
for use in your own programs easy if not too easy.
Robust Documentation Much Expanded
Please read the source code and documentation, and run the demos and
programs you find in each AppleX\PROGRAMS\subdirectory as well as any
documentation you find laying about for more information.
The immensely expanded source code in the AppleX\GRAPHICS directory is also
a good reference for more information. This is the source code for the G2
(Graphics) library, which also includes the source code from the original
Aztec C65 G.lib.
Comprehensive documentation for Aztec C itself and its original toolchain
has been available in pdf format user's manuals from the Aztec C website at
www.aztecmuseum.ca for a number of years now. But with this release of
AppleX and with many pdf "tutorials" and users manuals being very much
expanded-on especially for Apple II graphics programming, new life has been
breathed into this old compiler, taking its capabilities far beyond the
Apple II Community's "Retro-Compiler" perception... until AppleX, all that
was available was a previous ProDOS native-mode shell version that does not
even support creating floating point SYS programs, so if this perception is
not clearly incorrect, it is somewhat.
When it comes to documentation and usability Aztec C more than holds its
own, even today, 25 or so years later, and AppleX more than compensates for
whatever inefficiencies it mat have by providing a stable
and feature-rich environment which includes the documentation by Manx
Software (available from the website at www.aztecmuseum.ca) supplemented
with what AppleX provides.
Tools and More Tools
The AppleX\TOOLS directory also contains many utilities. Some are also
related to Graphics, but some were written long ago. The utilities in the
subdirectories under the AppleX\PROGRAMS directory have all been
recently written, and are more specifically targetted at today's working
environment.
ProDOS Directory Services
The AppleX\PROGRAMS directory also contains a subdirectory called LISTDIR
which demonstrates and implements G2 library routines related to reading
ProDOS disk catalogues and finding files and so forth.
Command Line and Unix-Like Programs for ProDOS
Another expansion of the AppleX distribution is the production of programs
that run under the Aztec C Shell for ProDOS 8. Shell Versions of SYS
programs, which are PCODE mixed with native 6502 code. allow command line
arguments and wildcard expansion and so forth, while being able to run at
the same speed of execution as their SYS program counterparts in time
critical operations like graphics and floating point calculations.
Previous Updates and Brief History
Since making AppleX available I have kept adding to it.
Website
I also built a website called www.aztecmuseum.ca for AppleX and many other
Aztec C compilers for other platforms, and time permitting I have done my
best to keep the website up to date.
Full Blown Aztec C Projects with Source Code
After building the website, I made selected Full-Blown non-trivial
"Projects" in Aztec C65 part of the distribution. They are in the PROJECTS
directory. Two of these projects (METOO and TIME) use overlays
and auxiliary memory extensively and should prove informative. I also have 3
additional overlay projects that I will someday make available if time
permits.
Mixing the Old with the New
As I have done in the 2013 update with the PROGRAMS subdirectory, I kept
these projects in the PROJECTS directory, separate from the SAMPLES
directory that comprised the first AppleX distribution.
I also provided DOSBox support for Aztec C65 and included this with AppleX,
not that it took me much work. With Windows 7 displacing WIndows XP, it
turns-out this was a good idea. Along the way I also tested in
Ubuntu in another DOS emulator, without problem.
I have discovered through all this that there doesn't seem to be anything I
can't do with this old compiler...
Apple33 Aztec C65 for DOS 3.3
Along the way, I also created a smaller distribution of Aztec C65 for
building Apple II DOS 3.3 programs.
Then for a couple of years or so, until Fall of 2012, I didn't do much with
AppleX or Apple33.
Permission to Distribute Aztec C65
Someone pointed-out to me at some point that I have never indicated in this
distribution that I have permission to distribute Aztec C65. This is simply
because I never updated the read me.
Copyright Clarification - Copyright and Conditions of Use
Harry Suckow (the Copyright holder for Aztec C) has given permission to
redistribute Manx Software Systems discontinued Aztec C compilers for
now-obsolete platforms.Your use must be Fair as it applies to Manx's
Copyright on these compilers. They are not for sale at any price!
Bill Buckels
bbuc...@mts.net
Egan Ford
Apr 9, 2013, 5:47:30 PM4/9/13
to
On 4/8/13 10:34 PM, Bill Buckels wrote:
> As promised! A less than modest C cross-Compiler for the Apple IIe!
Thanks Bill.
> As promised! A less than modest C cross-Compiler for the Apple IIe!
Bill Buckels
Apr 12, 2013, 7:48:45 PM4/12/13
to
"Egan Ford" <data...@gmail.com> wrote:
> Thanks Bill.
I updated AppleX with some additional documentation today. But sadly, my
creative writing project is over for the most part and I am in post-partum
mode now, so if you want a snapshot, tomorrow would be a good time. Unlikely
to change much for another 3 years though:)
You probably would have appreciated this about 3 or so years ago. I
disappeared after I got too busy with my fishing business around the time
you were trying Orca C. (How did that go by the way?)
The ranks have thinned considerably around here, but I still needed to get
the Double-Res Graphics stuff done to a reasonable level even if I am the
last Aztec standing. Somebody needed to write it down in one place for the
archaelogists. I gues I am the archaelogist too, come to think of it.
There were some loose ends that I needed to tie-up and some of them had to
do with your old quest about 80 column mode...
1. How does a C programmer work with 80 column text and Hi-Res (HGR)
graphics in a SYS program?
2. How does a C programmer work with 80 column text and Double Hi-Res (DHGR)
in a SYS program?
3. How does a C programmer work with Double Lo-Res Graphics (DLGR) and 80
column text in Mixed Text and Graphics Mode in a SYS program?
And More...
On top of which...
4. How does a programmer read and display a ProDOS directory and indeed use
ProDOS file services?
The screen capture stuff was also an interesting exercise which led to some
burning discoveries:
5. The monochrome bitmap displayed in DHGR is exactly the 4-bit color values
of the pixels since colors in DHGR do not use the high-bits.
6. When in DLGR Auxiliary memory, the Lo-Res color index requires a
circular shift.
Ironically as well, it was my omission of monochrome DHGR and the request of
a Apple II programmer who isn't even a teenager yet that triggered whatever
point of completion I achieved this go-round.
So thanks for thanking me. You're welcome I think, but I also think you're
just being polite... and now comes the burning question... should I be
firing-up my GS and looking at Orca C or should I duplicate what I have done
with Aztec C65 in cc65, or should I grab a Raspberry Pi or two and muck with
that, or pursue some 6502 assembly, or all of the above? It's rather like a
smorg... but I'll be busy with my fishing business soon and I'll be
disappearing again.... and maybe not soon enough for some folks:)
Bill
> Thanks Bill.
I updated AppleX with some additional documentation today. But sadly, my
creative writing project is over for the most part and I am in post-partum
mode now, so if you want a snapshot, tomorrow would be a good time. Unlikely
to change much for another 3 years though:)
You probably would have appreciated this about 3 or so years ago. I
disappeared after I got too busy with my fishing business around the time
you were trying Orca C. (How did that go by the way?)
The ranks have thinned considerably around here, but I still needed to get
the Double-Res Graphics stuff done to a reasonable level even if I am the
last Aztec standing. Somebody needed to write it down in one place for the
archaelogists. I gues I am the archaelogist too, come to think of it.
There were some loose ends that I needed to tie-up and some of them had to
do with your old quest about 80 column mode...
1. How does a C programmer work with 80 column text and Hi-Res (HGR)
graphics in a SYS program?
2. How does a C programmer work with 80 column text and Double Hi-Res (DHGR)
in a SYS program?
3. How does a C programmer work with Double Lo-Res Graphics (DLGR) and 80
column text in Mixed Text and Graphics Mode in a SYS program?
And More...
On top of which...
4. How does a programmer read and display a ProDOS directory and indeed use
ProDOS file services?
The screen capture stuff was also an interesting exercise which led to some
burning discoveries:
5. The monochrome bitmap displayed in DHGR is exactly the 4-bit color values
of the pixels since colors in DHGR do not use the high-bits.
6. When in DLGR Auxiliary memory, the Lo-Res color index requires a
circular shift.
Ironically as well, it was my omission of monochrome DHGR and the request of
a Apple II programmer who isn't even a teenager yet that triggered whatever
point of completion I achieved this go-round.
So thanks for thanking me. You're welcome I think, but I also think you're
just being polite... and now comes the burning question... should I be
firing-up my GS and looking at Orca C or should I duplicate what I have done
with Aztec C65 in cc65, or should I grab a Raspberry Pi or two and muck with
that, or pursue some 6502 assembly, or all of the above? It's rather like a
smorg... but I'll be busy with my fishing business soon and I'll be
disappearing again.... and maybe not soon enough for some folks:)
Bill
Egan Ford
Apr 13, 2013, 2:20:17 PM4/13/13
to
On 4/12/13 5:48 PM, Bill Buckels wrote:
> You probably would have appreciated this about 3 or so years ago. I
> disappeared after I got too busy with my fishing business around the time
> you were trying Orca C. (How did that go by the way?)
At the time I was exploring the relative performance of various popular
> You probably would have appreciated this about 3 or so years ago. I
> disappeared after I got too busy with my fishing business around the time
> you were trying Orca C. (How did that go by the way?)
8-bit bus CPUs (6502, 8088, z80, 65816). Not knowing assembly language
I opted to use C. The problem was, that even on the same platform,
different compilers had a high degree of variability. I expected this,
but the difference was too great. So I switched to Forth. Same
problem. Ultimately I decided that if I really wanted to understand the
difference between 8-bit processors I'd have to learn their assembly
languages and make a best effort benchmark program for each processor.
I started that work last summer. I've completely my survey of the 8008,
8080, 8085, z80, 8088, 6502, 6800, 6809, TMS9900, 65816, and 68008
processors (one processor, one weekend/month avg), but I learned much
more than expected, and trying to distill that into an interesting
article is going to take some time--possibly 10 more months.
Short answer, Orca C is good, but not a substitute for assembly.
> There were some loose ends that I needed to tie-up and some of them had to
> do with your old quest about 80 column mode...
validate the results. The asm snippets you gave me filled that gap.
Thanks again.
> So thanks for thanking me. You're welcome I think, but I also think you're
> just being polite...
I've spent too many years with vi/make/X11. I have not developed on a
terminal with 40x24 or 80x24 characters since the '80s.
I read an interesting article (cannot find it) that argued (with data)
that a programmer will have less bugs if a greater number of code lines
can be displayed. I know this is true for me, I often printed out my
code in the '80s on 132 column green bar, grabbed a pen, a large cup of
coffee, and then debugged.
IMHO, for posterity, AppleX should remain an plausible option.
> and now comes the burning question... should I be
> firing-up my GS and looking at Orca C or should I duplicate what I have done
> with Aztec C65 in cc65, or should I grab a Raspberry Pi or two and muck with
> that, or pursue some 6502 assembly, or all of the above?
IIGS is powerful enough to execute C programs for many types of
applications. However, I would find a portable open source IIGS cross
compiler very compelling.
cc65 already has a portable graphics library with a set of drivers for
various platforms, however I do not know if it has all your latest Aztec
enhancements. It may be nice to have better II graphics support in
cc65. For me, I'll probably never use C again on 8-bit processors,
assembly is too much fun.
Raspberry Pi is on my list of things to get, but I have not thought of a
use case for it. I've already got a few other Linux-based ARM embedded
systems that I use to cross develop for years ago. The Pi would just be
yet-another-thing-I-have-no-time-to-play-with.
Good luck and safe fishing. And thanks again for your Aztec
preservation work.
Michael J. Mahon
Apr 13, 2013, 7:06:22 PM4/13/13
to
difficult to generate good code for.
8-bit processors have too few registers and on many they are not wide
enough for general addressing.
Assembly language programmers are able to choose data structures and
representations that use the architecture to best advantage in a way that
the generalized representations of a compiler cannot.
Assembly language usually can achieve between 2x and 10x improvements in
critical code over that produced by even excellent compilers.
This advantage is blurred as the number and width of registers increases.
In fact, for modern 32-bit architectures, compilers can often out-code
assembly coders, because they are capable of large "optimization windows".
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Bill Buckels
Apr 13, 2013, 7:25:58 PM4/13/13
to
"Michael J. Mahon" <mjm...@aol.com> wrote:
> In fact, for modern 32-bit architectures, compilers can often out-code
> assembly coders, because they are capable of large "optimization windows".
to be a distributed architecture with embedded components that can be more
efficiently optimized by free-thought and human beings... this sounds
familiar but I can't quite place it:)
Egan Ford
Apr 13, 2013, 8:41:32 PM4/13/13
to
On 4/13/13 5:06 PM, Michael J. Mahon wrote:
> Assembly language usually can achieve between 2x and 10x improvements in
> critical code over that produced by even excellent compilers.
That is something I've been tracking as well. E.g. my Aztec C benchmark
> Assembly language usually can achieve between 2x and 10x improvements in
> critical code over that produced by even excellent compilers.
takes about 36 minutes to run on the 6502, and in assembly about 2
minutes. ~18x faster. With 8088 Turbo C vs assembly, assembly it's 17x
faster. 65816 Orca C vs assembly, assembly ~10x faster. With the
68000, performance starts to improve and the difference between Think C
and assembly is about 6-7x.
> This advantage is blurred as the number and width of registers increases.
> In fact, for modern 32-bit architectures, compilers can often out-code
> assembly coders, because they are capable of large "optimization windows".
fun. But for 8-bit systems, it's perfect.
0 new messages