Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #701 > unrolled thread

Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update "Bill Buckels" <bbuckels@mts.net> - 2013-04-08 21:34 -0500
    Re: Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update Egan Ford <datajerk@gmail.com> - 2013-04-09 17:47 -0400
      Re: Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update "Bill Buckels" <bbuckels@mts.net> - 2013-04-12 18:48 -0500
        Re: Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update Egan Ford <datajerk@gmail.com> - 2013-04-13 12:20 -0600
          Re: Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update Michael J. Mahon <mjmahon@aol.com> - 2013-04-13 18:06 -0500
            Re: Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update "Bill Buckels" <bbuckels@mts.net> - 2013-04-13 18:25 -0500
            Re: Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update Egan Ford <datajerk@gmail.com> - 2013-04-13 18:41 -0600

#701 — Announcing The Whole Meal Deal - AppleX Aztec C65 ProDOS 8 cross-compiler 2013 Update

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
bbuckels@mts.net







 

[toc] | [next] | [standalone]

#702

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.

[toc] | [prev] | [next] | [standalone]

#705

"Egan Ford" <datajerk@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 

[toc] | [prev] | [next] | [standalone]

#706

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 
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...

Ah, yes, I needed 80 columns so I could display the output to visually 
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 appreciated AppleX because I cannot develop directly on the Apple II. 
  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?

I see no reason to duplicate Orca C, it's actually really good.  And the 
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.

[toc] | [prev] | [next] | [standalone]

#707

Egan Ford <datajerk@gmail.com> wrote:
> 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
> 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...
> 
> Ah, yes, I needed 80 columns so I could display the output to visually
> 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 appreciated AppleX because I cannot develop directly on the Apple II. 
> 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?
> 
> I see no reason to duplicate Orca C, it's actually really good.  And the
> 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.

8-bit machines can certainly be targeted by compilers, but they are
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

[toc] | [prev] | [next] | [standalone]

#708

"Michael J. Mahon" <mjmahon@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".

The addendum to your corollary as far as performance is concerned would seem 
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:) 

[toc] | [prev] | [next] | [standalone]

#709

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 
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".

And given the complexity of modern system assembly isn't practical or 
fun.  But for 8-bit systems, it's perfect.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web