Apple II 6502 Applications in C - Recent Applications (Last 2 Years)
Bill Buckels
couple of years for the Apple //e or resurrected and bundled for
distribution are listed below. These were aritten in Aztec C. Anyone who
wishes to add to this list some other applications that they have written in
C for ProDOS 8 or DOS 3.3 please do so. Give your rationale for whatever C
compiler you chose to do the job.
Anyone who has not written and distributed new or resurrected applications
in C for the Apple //e in the last couple of years please refrain from
replying to this thread. This thread is results oriented and not about
vapourware. The applications below are documented and properly bundled and
not just some demo and I have refrained from listed that sort of thing
including CP/M 80 programs for the Apple II.
http://www.appleoldies.ca/steps.htm
http://www.aztecmuseum.ca/projects.htm
http://www.aztecmuseum.ca/samples.htm
Rationale:
In the last 2 years I have written or rewritten several trivial and
non-trivial Applications that run in ProDOS 8 and DOS 3.3 in Aztec C. As far
as I know, my applications comprise the bulk of new application development
that has taken place in C on these 2 platforms in the past couple of years.
In providing Aztec C to several online communities it has always been my
goal to make this development environment very simple to install and use for
the majority of the World (who also use Microsoft Windows).
I am biased for sure. However I have tried another 6502 compiler called cc65
but it was distributed as an unfriendly snapshot which was broken and
incomplete. I never got it to run and I would recommend staying away from it
if you use MS Windows unless you like to fiddle around. There are a bunch of
cc65 shills who like to spout but what most of them have done in C in ProDOS
8 and DOS 3.3 comparatively speaking doesn't amount to a hill of beans as
far as I know.
Linux users who don't like to fiddle see below:
http://www.aztecmuseum.ca/docs/linux.txt
In terms of performance, Aztec C may not be considered by some people as
quick for some things but emulators like AppleWin (ProDOS and DOS 3.3) and
WinVICE (Commodore 64) and Myz80 (CP/M 80) all run much quicker than an old
computer, and my Apple //e has an 8 MHZ Zip Chip so speed is not as critical
as it is with some old 1 MHZ machine. If speed were always so important
AppleSoft BASIC would not ever be used. And why not use a vintage compiler
on a vintage computer?
Aztec C is also very well documented and the runtime and tools and other
goodies that I have bundled with it make it very simple to use to get quick
and reliable results. Reports that say otherwise are questionable to say the
least. In particular there is one such questionable report for the Commodore
64 6502 cross-compiler (the compiler I recently configured to produce tiny
shell applications for Apple DOS 3.3) Some results of this compiler can also
be reviewed at the link below and would not even exist if it were hard to
impossible to use this compiler:
Anyway, must run.
Remember, only those who have actually done something should reply to this
thread.
Anyone who has not written and distributed new or resurrected applications
in C for the Apple //e in the past couple of years please refrain from
replying to this thread. This thread is results oriented and not about
vapourware.
Have Fun!
Bill Buckels
October 2009
http://en.wikipedia.org/wiki/User:Bill_Buckels
http://www.cpm8680.com/
http://www.appleoldies.ca/
http://www.c64classics.ca/
http://www.teacherschoice.ca/
http://www.clipshop.ca/
http://www.grindstoneharbour.com
mdj
> Remember, only those who have actually done something should reply to this
> thread.
>
> Anyone who has not written and distributed new or resurrected applications
> in C for the Apple //e in the past couple of years please refrain from
> replying to this thread. This thread is results oriented and not about
> vapourware.
Of course, it's highly likely that the 2 or 3 people actually
developing anything at all for the Apple //e are using other
languages. Perhaps you'll have more luck if you broaden the scope of
your search a little...
It's also worth noting that many "programmer types" enjoying writing
tools to enhance the development environment *more* than they enjoy
writing applications for end users. I'm in that category myself. The
majority of development going on in the Apple II arena is in this
'enabling technology' sphere; for example cc65, Michael's brilliant
NadaNet distributed computing tools, and yes, Aztec-C
Is this a bad thing? Depends on how you look at it. The nice thing
about not having any users is that there's very little support effort
involved :-)
Cheer up, Bill ;-)
Bill Buckels
>It's also worth noting that many "programmer types" enjoying writing tools
>to enhance the development environment *more* than they enjoy writing
>applications for end users.
That's probably similar to a tree falling in a forest when nobody is around.
Whether the tree falls quickly or slowly or whether a tree is large or small
matters naught... n'est-ce-pas?
Or perhaps that's more like using toilet paper in the privacy of one's own
bathroom. Generally the job gets done regardless of technique but I suppose
there are those who enjoy focusing exclusively on their technique and on
their performance and the width of skid marks and other metrics. It might be
a bad thing to prioritize the technique of wiping with toilet paper over
one's other daily accomplishments and to use that as the sole criteria to
judge the rest of the world on the basis of speed of wiping and size of wad
used...
However, thank goodness are also some folks like Brutal Deluxe (Tony) and
Ding Wen who actually create some kind of end-user product... and don't get
me wrong... I do my fair share of toolsmithing but that is a symphony that
has no audience IMO unless a public performance is also available.
Michael J. Mahon
> "mdj" <mdj...@gmail.com> wrote:
>
>> It's also worth noting that many "programmer types" enjoying writing tools
>> to enhance the development environment *more* than they enjoy writing
>> applications for end users.
>
> That's probably similar to a tree falling in a forest when nobody is around.
>
> Whether the tree falls quickly or slowly or whether a tree is large or small
> matters naught... n'est-ce-pas?
>
> Or perhaps that's more like using toilet paper in the privacy of one's own
> bathroom. Generally the job gets done regardless of technique but I suppose
> there are those who enjoy focusing exclusively on their technique and on
> their performance and the width of skid marks and other metrics. It might be
> a bad thing to prioritize the technique of wiping with toilet paper over
> one's other daily accomplishments and to use that as the sole criteria to
> judge the rest of the world on the basis of speed of wiping and size of wad
> used...
Hmmm. I don't think that's the kind of "end user" Matt had in mind...
;-)
-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
> On Oct 26, 8:04 pm, "Bill Buckels" <bbuck...@mts.net> wrote:
>
>> Remember, only those who have actually done something should reply to this
>> thread.
>>
>> Anyone who has not written and distributed new or resurrected applications
>> in C for the Apple //e in the past couple of years please refrain from
>> replying to this thread. This thread is results oriented and not about
>> vapourware.
>
> Of course, it's highly likely that the 2 or 3 people actually
> developing anything at all for the Apple //e are using other
> languages. Perhaps you'll have more luck if you broaden the scope of
> your search a little...
>
> It's also worth noting that many "programmer types" enjoying writing
> tools to enhance the development environment *more* than they enjoy
> writing applications for end users.
In my own case, I like writing code for which _I_ am the end user,
rather than for non-developer end users.
This has the considerable advantage that its much easier to do market
research and requirements analysis when you are your own "market". ;-)
mdj
> Bill Buckels wrote:
> > "mdj" <mdj....@gmail.com> wrote:
>
> >> It's also worth noting that many "programmer types" enjoying writing tools
> >> to enhance the development environment *more* than they enjoy writing
> >> applications for end users.
>
> > That's probably similar to a tree falling in a forest when nobody is around.
>
> > Whether the tree falls quickly or slowly or whether a tree is large or small
> > matters naught... n'est-ce-pas?
>
> > Or perhaps that's more like using toilet paper in the privacy of one's own
> > bathroom. Generally the job gets done regardless of technique but I suppose
> > there are those who enjoy focusing exclusively on their technique and on
> > their performance and the width of skid marks and other metrics. It might be
> > a bad thing to prioritize the technique of wiping with toilet paper over
> > one's other daily accomplishments and to use that as the sole criteria to
> > judge the rest of the world on the basis of speed of wiping and size of wad
> > used...
>
> Hmmm. I don't think that's the kind of "end user" Matt had in mind...
LOL - No, I'm not really a fan of abstract expressionism, but my
penchant for colourful metaphors leaves me somewhat 'torn' in this
regard...
Oliver Schmidt
>Anyone who
>wishes to add to this list some other applications that they have written in
>C for ProDOS 8 or DOS 3.3 please do so.
Contiki 1.x
http://en.wikipedia.org/wiki/Contiki
http://hitmen.c02.at/html/tools_contiki.html
Contiki 2.x
http://www.sics.se/contiki/
http://www.a2retrosystems.com/downloads.htm
NanoVM
http://www.harbaum.org/till/nanovm/index.shtml
http://nanovm.cvs.sourceforge.net/viewvc/nanovm/nanovm/vm/build/cc65/
Best, Oliver
Bill Buckels
"Oliver Schmidt" <ol...@web.de> wrote:
>applications that they have written in C for ProDOS 8 or DOS 3.3 please do
>so.
>Contiki 1.x
Not really an application for ProDOS or DOS 3.3
>Contiki 2.x
See above.
>NanoVM
>http://www.harbaum.org/till/nanovm/index.shtml
Apple II is not mentioned. Not really an application either.
Conclusion: cc65 is not being used by anyone in the world in past couple of
years or present to write end user applications for the ProDOS or DOS 3.3
Operating Systems on the Apple II family of computers. cc65 is Oliver
Schmidt's personal C compiler for the Apple II and is used by him alone for
writing computer sciency OS-type-things. Some other programming tools which
support cc65 on the Apple II are written for Oliver by others.
Of the rest of us who have been involved with Aztec C on the Apple II (Jeff
H.[rubywand], Mike T.[phoenyx], Frank [phade] and Me [bbuc...@mts.net]) I
am the only person in the world in past couple of years or present to write
end user applications for the ProDOS or DOS 3.3 OS's on the Apple II family
of computers in Aztec C.
No other programmers in the world are writing C programs of a non-trivial
nature for the Apple II except for Oliver and myself and Oliver is not
developing in entirety but working an applications that already exist and
porting them. No other C compilers besides these two are even in use for
anything serious anymore on the Apple II.
This is despite the fact that an even better native mode C compiler (Orca
C - Mike Westerfield) is available for the Apple GS.
The End.
Bill Buckels
> The nice thing about not having any users is that there's very little
> support effort involved :-)
And this is exactly why I call the Aztec C website a "Museum"...
Oliver and those Commodore boys that use cc65 really should call their
website a museum as well and quit pretending that Aztec C is too darned old
to be useful or too darned slow to be useful or why ever the heck they
decided to reinvent a perfect wheel and put square corners on it and
distribute broken copies that require additonal utilities to be of any use
for an obsolete platform anyway.
So the choice is clear:)
There are 2 people in the world that write C programs for the Apple //e that
are actually non-trivial. (Oliver and Me) Probably nobody uses their
programs.
One chooses to pretend that his state of the art compiler which has never
been really used for the Apple II outside of his computer-sciency-unixy
world is better than a compiler that actually fed the other person's family
when his kids were young.
And never the twain shall meet, so to call me a shill or DULL when I don't
call you names is... well... being a couple of REAL SH*THEADS which probably
makes 3 of us and anyone else who chooses to join-in like the Commodore 64
boy who can't even tell the difference between problems with a compiler and
with DosBOX and a make utility under whatever non-standard 'nix system he
chooses to play in.
>Cheer up, Bill ;-)
We all have good toys in our respective museums. That is reason enough to
rejoice.
The End.
John B. Matthews
"Bill Buckels" <bbuc...@mts.net> wrote:
> "Oliver Schmidt" <ol...@web.de> wrote:
>
> >applications that they have written in C for ProDOS 8 or DOS 3.3
> >please do so.
>
> >Contiki 1.x
>
> Not really an application for ProDOS or DOS 3.3
>
> >Contiki 2.x
>
> See above.
>
> >NanoVM
> >http://www.harbaum.org/till/nanovm/index.shtml
>
> Apple II is not mentioned. Not really an application either.
>
> Conclusion: cc65 is not being used by anyone in the world in past
> couple of years or present to write end user applications for the
> ProDOS or DOS 3.3 Operating Systems on the Apple II family of
> computers.
Please deconstruct my entry, too!
<http://home.roadrunner.com/~jbmatthews/apple2.html#rp1c>
[...]
> The End.
<http://en.wikipedia.org/wiki/Promises,_Promises> :-)
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Calibrator
>
> In my own case, I like writing code for which _I_ am the end user,
> rather than for non-developer end users.
>
> This has the considerable advantage that its much easier to do market
> research and requirements analysis when you are your own "market". ;-)
Ha ha - True!
Also: Nobody nags, nobody impedes progress, nobody pushes you.
And, if the product is good enough for other people, everybody wins.
bye
Marcus
Polymorph
> No other programmers in the world are writing C programs of a non-trivial
> nature for the Apple II except for Oliver and myself and Oliver is not
> developing in entirety but working an applications that already exist and
> porting them. No other C compilers besides these two are even in use for
> anything serious anymore on the Apple II.
Well, "nothing serious" is a little subjective for me. But I have
several projects, some started, some not, that I expect to write in
Orca/C. Just because people haven't announced projects, doesn't mean
that they don't exist. :-)
I didn't really want to buy into this argument as I have never really
tried either Aztec C or CC65, my programming has been confined to the
IIgs since I returned to the scene in 2006. But I for the life of me
can't see what all the fuss is about. We have two (or more)
individuals both contributing valuable tools and "hobbyist level"
support. Personally, I am happy to witness people still dedicated
enough to provide this for a vintage platform with a limited user base
(especially in the programming side). If I ever decide to port any of
my projects from the IIgs to the 8 bit Apples, I'll probably choose
either one of these solutions depending upon my own evaluation - not
whether someone tells me that "A" is better than "B" - and I think
that this is pretty consistent in most things in life. If through the
course of evaluation you find a preferred solution, take it and use
it, but do not criticise someone else for providing an alternative. If
people were always criticised for providing alternatives, progress in
this world would be pretty slow. Innovation and dedication should
always be applauded, even if it isn't perfect.
Anyway, that's my 2 cents worth.
Peace!
Cheers,
Mike
mdj
> I didn't really want to buy into this argument as I have never really
> tried either Aztec C or CC65, my programming has been confined to the
> IIgs since I returned to the scene in 2006. But I for the life of me
> can't see what all the fuss is about. We have two (or more)
> individuals both contributing valuable tools and "hobbyist level"
> support. Personally, I am happy to witness people still dedicated
> enough to provide this for a vintage platform with a limited user base
> (especially in the programming side). If I ever decide to port any of
> my projects from the IIgs to the 8 bit Apples, I'll probably choose
> either one of these solutions depending upon my own evaluation - not
> whether someone tells me that "A" is better than "B" - and I think
> that this is pretty consistent in most things in life. If through the
> course of evaluation you find a preferred solution, take it and use
> it, but do not criticise someone else for providing an alternative. If
> people were always criticised for providing alternatives, progress in
> this world would be pretty slow. Innovation and dedication should
> always be applauded, even if it isn't perfect.
Well said, Mike. Throughout this (mostly pointless) argument one thing
that is overlooked is the gigantic elephant in the room: if someone is
going to develop an application for an (8 bit) Apple II, is C a good
host language for their project?
The easiest way to answer this question is to do a pragmatic
comparison of C and the available alternatives. In the interests of
brevity and clarity, I'm going to try to keep the number of
dichotomies to a minimum and limit myself to the following question
about the theoretical program we're writing:
a) The program is trivial enough that performance isn't a primary
consideration
b) The program is complex enough that performance is a primary
consideration
Now, people will point out that the vast majority of programs fall
into a little of column a) and a little of column b) which
necessitates the inclusion of column...
c) (*wink* *wink*) Part of the program is performance sensitive,
probably the main loop where the actual work gets done, but much of it
is human interfacing code which only has to perform as well as a
human.
In general, problems in column a) are best solved using a language
that offers high degrees of abstraction since it usually results in
code that is both easier to maintain and occupies less memory. The
former being a universally desirable property, and the latter being of
high import when your target platform is an Apple II.
Problems in column b) are going to benefit from using a language that
allows you to exploit the particular characteristics of your target
architecture which on small machines means using assembler.
It's important to remember that the semantic gap between C and a good
macro assembler is actually much smaller than it appears, as people
who have written complex programs in assembler will attest. In
principle, there are only two important abstractions provided by C,
both of which can be achieved with assembler macros:
a) Generalisation of arithmetic expressions, which provides a large
degree of portability. *
b) Standardised function call interfaces, which facilitate reusable
code, and thus libraries.**
It's a particularly potent combination actually, since the
abstractions are so simple they're easy to implement, and thus a C
compiler is an easy thing to write. Best of all, it's close enough to
the metal in many cases that you can write the majority of an
operating system in it without losing too much efficiency, and be able
to bootstrap both the language and the operating system *very* quickly
on a new architecture. This is of course the principle reason why UNIX
is so prevalent; a UNIX-like kernel is, like C, a fairly simple piece
of software.
However when we apply these principles to the Apple II, the picture
doesn't look so rosy. You're throwing away the ability to write high
performance code by losing direct access to the 6502, and (perhaps
worse) your high-level code will be repeatedly including chunks of
code that really ought to exist in memory *once* in an interpreter. We
typically call the programs that make this mistake bloatware.
Of course, proponents of C will argue that it's possible, with
discipline, to write highly optimised code in C, and this of course
true, provided you're intimately familiar with the way your particular
C implementation generates code. The catch is, the same discipline and
knowledge can be used to produce an even faster routine in assembler
in a comparable amount of time. In addition, C programs that are
heavily optimised are generally no longer portable.
They will also argue that the language is extensible, so problems with
higher level abstractions such as strings can be solved with software
libraries. This is also true, but as of 2009, 10 years after the last
revision of the C standard, the library facilities provided for
strings are still modest, and still encourage programming idioms that
often result in code that can be exploited by buffer overruns. It's
also true that an implementation of the entire C99 standard library
won't fit into 64k of memory, and even the subset of it that is
applicable to small machines is going to leave you fairly short
changed compared to writing high level code in high level languages.
It will be argued by some that it's nice to write the entire solution
in the one language and whilst I sympathise I'm compelled to echo the
words of a certain language designer who said that "A foolish
consistency is the hobgoblin of small minds". Go down this path, and
your whole design will be a series of compromises. Solve the problem
you may, but you'll not solve any of it well. On an Apple II, you may
just find that you run out of resources before you're done, or that
your end result doesn't perform as well as the "C is an efficient
language" crowd convinced you it would. Language fanboyism has no
place in software development, and especially when it comes to small
machines your best bet is to choose a little of column a), a little of
column b) and avoid C altogether.
After rubbishing a language, I should probably point out that on
larger machines (like say, a PDP-11), much of what I've said about
*efficiency* is less true. On such architectures, most of the C
constructs translate to single instructions and result in assembly
code that resembles that of a disciplined assembler programmer.
Unfortunately, the hardware architecture of the 6502 was not the
target of the C designers, and simulating the large stack pointer,
stack relative addressing and automatic pointer increment/decrement
required to emit a compact machine representation of C comes at a big
cost in terms of memory footprint and execution speed. Precious
resources you can't afford to waste on an Apple II.
This should also not be construed as an attack on the cc65 project or
its members. Pissing into the wind can be fun, if only to see how far
you can get, and really, that's what most of us writing software for
the Apple II are actually doing. There are creative solutions to
*some* of the problems I've mentioned, and the journey is the reward
after all. Despite my disdain for C as an applications programming
language, I do find the project interesting, and it's fun reading the
news of improvements that have been made. I've also found the compiler
occasionally useful as an intermediate step whilst exploring an idea,
and it's a lot of fun running my old CS101 assignments on the Apple
II.
I'll close by saying that a lot of the things you hear about
programming languages (C is fast! Java is slow! LISP is truly the
language through which the Gods wrought the universe ***) are a bit
like the nutritional information cards in a McDonalds restaurant. They
may contain factual information, but their principle purpose is to
mislead you. When it comes to C on the Apple II, notice that the only
serious application written in it is precisely the same type of
program that C is good for on other platforms: an operating system.
Matt
* In reality C's data type abstraction falls short by only specifying
the *minimum* size of each data type, resulting in a lot of code that
makes incorrect assumptions about the size of data types, compromising
its portability. This was fixed in the C99 standard, closing the gate
only 20 years after the horse had bolted.
** Having too much diversity in the variety of function interfaces can
result in code that's difficult to reuse. It's interesting to note
this similarity in comparing C to Assembler and say, Java to C++.
History repeats itself, and most people don't notice.
*** If there were any gods, which there aren't, this statement might
actually be true.
Bill Buckels
>This should also not be construed as an attack on the cc65 project or its
>members. Pissing into the wind can be fun, if only to see how far you can
>get, and really, that's what most of us writing software for the Apple II
>are actually doing.
Now just a minute here... if you think the cc65 project is pissing into the
wind consider for a moment the Aztec C Museum... You can't ignore me Mutt! I
am definitely and infintely more urine-soaked than all the cc65 boys
together and even then I have gallon or two left in my galoshes just to be
sure. Again Aztec C wins hands-down over cc65, or even when speaking of
p'ing into wind against smoking hash while drinking beer which until Aztec C
became old and brittle really had the Pissing-Into-The-Wind Marketplace
cornered.
>When it comes to C on the Apple II, notice that the only serious
>application written in it is precisely the same type of program that C is
>good for on other platforms: an operating system.
That my friend is bullshit! That statement ruined the rest of your
thoroughly enjoyable rant like the proverbial "Great Eraser" *BUT* because
your post is made on "All Saints Day" and I am the patron saint of C (in
case you hadn't noticed) and because your post is made the day after "All
Hallows Eve" so obviously by your post you are in some kind of
hungover-from-yesterday Halloween drag as a computer expert, I shall forgive
your transgressions my son as we complang saints forgive those who trespass
against us.
Here then is your blessing Mate for ignoring my own serious work on the
Apple II in C:
THE HIPPOPOTAMUS
by: T.S. Eliot (1888-1965)
The broad-backed hippopotamus
Rests on his belly in the mud;
Although he seems so firm to us
He is merely flesh and blood.
Flesh-and-blood is weak and frail,
Susceptible to nervous shock;
While the True Church can never fail
For it is based upon a rock.
The hippo's feeble steps may err
In compassing material ends,
While the True Church need never stir
To gather in its dividends.
The 'potamus can never reach
The mango on the mango-tree;
But fruits of pomegranate and peach
Refresh the Church from over sea.
At mating time the hippo's voice
Betrays inflexions hoarse and odd,
But every week we hear rejoice
The Church, at being one with God.
The hippopotamus's day
Is passed in sleep; at night he hunts;
God works in a mysterious way--
The Church can sleep and feed at once.
I saw the 'potamus take wing
Ascending from the damp savannas,
And quiring angels round him sing
The praise of God, in loud hosannas.
Blood of the Lamb shall wash him clean
And him shall heavenly arms enfold,
Among the saints he shall be seen
Performing on a harp of gold.
He shall be washed as white as snow,
By all the martyr'd virgins kist,
While the True Church remains below
Wrapt in the old miasmal mist.
>History repeats itself, and most people don't notice.
Since I don't know most people I would say that this statement is about as
true as the rest of this thread. The question being of course "Which truth
isn't true?". You may quote me on that of course.
>*** If there were any gods, which there aren't, this statement might
>actually be true.
Nathaniel Hawthorne would have had you burned for your blasphemy:) OTOH I
would question whether your statements might not all be true for the most
part especially for most people.
Cheer up yerself!
Bill Buckels
"Polymorph" <polym...@hotmail.com> wrote:
>Well, "nothing serious" is a little subjective for me. But I have several
>projects, some started, some not, that I expect to write in Orca/C. Just
>because people haven't announced projects, doesn't mean
that they don't exist. :-)
Well said! What is serious to some may be trivial to others. For example
Mutt seems to think that the Apple II applications that I wrote in Aztec C
are not worthy of mention yet many of these were in their time and place
distributed widely in Canada and in use in the Canadian school system in
both official languages and just recently reworked for the Aztec C Museum
and my other websites. My use of Aztec C extends beyond support for
hobbyists but some folks have no room left for those thoughts despite their
oversized young minds.
Now about Orca/C... I am looking at Mike Westerfield's manual which has been
sitting directly in front of me with my other books for about a year or
maybe longer. Orca C is a native mode compiler and not a cross-compiler.
However, emulators make that not-such-a-big-deal.
Having said that, in every respect Orca/C is far beyond a command-line
compiler and a whole better class of programming tool than Aztec C which
comes from that whole previous generation of unix-like compilers. In short,
we are talking Apples and Bananas here with Aztec C and I believe also cc65
both being Bananas.
To see what I mean see below:
http://www.clipshop.ca/evolution.gif
Not having your experience on Apples all I can do is marvel at the rest of
your message and speak about Bananas.
To see what I mean see below:
http://www.appleoldies.ca/steps.htm
For a clearer picture:
http://www.appleoldies.ca/steps.htm#develop
And for a really clear picture:
http://www.appleoldies.ca/quapple.gif
The c64 perspective is also notable keeping in mind that the cc65 'nix boys
are adament that Aztec C tool is unusable which is where much of this
mirrored nonsense that you see part-of orginates from in the first place.
Please see below:
I have always felt that I should notch my level down to the lowest common
denominator when attempting to heard above the roar of the whole Charmin
Army or even the Aussies who used to be our allies before Mutt was born.
Since this is my thread and not Oliver's I will also say that if Mud is not
going to acknowledge the notability of these Apple II applications of mine
that were written in Aztec C as opposed to Commodore 64 programs that just
happen to end-up on the Apple II, he should be prepared to both point to his
own body of work for the Apple II and then to say specifically why my rather
large body of work is somehow inferior to his high-minded snottery.
The following clarifies specifically what I mean and I don't really think
anything less of Mate than I already did. He seems likable enough for
someone who thinks Summer is Winter.
See below:
http://www.aztecmuseum.ca/docs/linux.txt
Now I must run because Aztec C versions for many OS's and Target Platforms
keep coming-in from the World at Large and I am still scrambling for time to
bundle these and make them available for Windows Users (primarily) in as
user-friendly a format as I possibly can. I am sorry, but I can't see any
point in making this so hard that a hobbyist needs to have a computer
science degree to write an application for an old computer. However I agree
that probably nobody will ever use these but everyone needs several hobbies.
Cheers,
Bill
Bill Buckels
>Please deconstruct my entry, too!
<http://home.roadrunner.com/~jbmatthews/apple2.html#rp1c>
I think I did once already Dr. John but here goes (this version is written
in GWBASIC for the IBM-PC and called "ROD.BAS". I bought it on a mail order
shareware disk towards the latter part of the 1980's...) It is a demo of an
algorithm and not an application at all and completely trivial...
5 CLS
10 SCREEN 1,0
20 FOR W=3 TO 50
30 FOR I=1 TO 19
40 FOR J=0 TO 19
50 K=I+J
55 IX=I*8
60 IX8=IX+8
70 IY=I*5
80 KX=K*8
90 KY=K*5
100 IY5=IY+5
110 KX8=KX+8
120 KY5=KY+5
130 COL= (J*3/(I+3)+I*W/12) MOD 8
150 COL=COL MOD 4
160 LINE(IX,KY)-(IX8,KY5),COL,BF
170 LINE(KX,IY)-(KX8,IY5),COL,BF
180 LINE(319-IX,199-KY)-(319-IX8,199-KY5),COL,BF
190 LINE(319-KX,199-IY)-(319-KX8,199-IY5),COL,BF
195 LINE(KX,199-IY)-(KX8,199-IY5),COL,BF
196 LINE(319-IX,KY)-(319-IX8,KY5),COL,BF
197 LINE(IX,199-KY)-(IX8,199-KY5),COL,BF
198 LINE(319-KX,IY)-(319-KX8,IY5),COL,BF
240 NEXT J,I
250 NEXT W
260 GOTO 20
I later (1997) rewrote it in C, called it "Linoleum" and bundled it with as
one of a 6-pack of Windows 3.1 screen savers which were based-on the Screen
Saver that formed the Windows Version of the following (please see this
link):
http://www.yasara.org/modelsd2.htm
The paper for the above was published in Bioinformatics 18, 315-318,
copyright Oxford University Press.
Back to ROD...
The ROD (Linoleum) screensaver itself can found at the following link (as-is
or as-it-was):
Read This:
http://www.teacherschoice.ca/freesave.txt
Download This:
http://www.teacherschoice.ca/freesave.exe
Here's what I said about its orginally but since the above comes with source
you can take a look further:
ORIGIN
As noted, LINOLEUM is loosely based on an old GWBASIC program called
ROD.BAS.
I don't know where I obtained the original version of this program and I
last looked at this in the late 80's.
In its original state the program was a single panel and looked quite coarse
on the CGA 320 x 200 screen using only 4 colors in a single CGA palette.
At one point in the late 80's, I modified the program with few changes to
run on a true-color RGB video card (similar to a Targa Board), as a demo for
a commercial graphics library that I produced for a client.
I initially didn't have much hope for this program as a screensaver but it
survived the transformation. It won't be everyones cup of tea although it is
sort of interesting and does come-up with a pleasant geometric effect on
most displays.
There is little resemblance to its pregenitor.
As a Standard Windows Screen saver, and since it is compatible with Windows
3.1 or Windows 95, almost anyone will be able to use it.
And finally if you want to see whatever happend to VGAFan (Which is what
Linoleum AKA ROD was distributed with) just visit my ClipShop website and
download yourself a copy:
Keep in mind that you can also download clipshop and use it to create Apple
//e Graphics from Windows BMP's and the Windows Clipboard and other sources.
The End Again
Bill Buckels
"Bill Buckels" <bbuc...@mts.net> wrote:
>John B. Matthews
>trashgod at gmail dot com
><http://sites.google.com/site/drjohnbmatthews>
Sorry John,
My last post almost looks like it was signed with your name. That was quite
inadevertant... however best to say so.
Sorry,
Bill
Michael J. Mahon
> The c64 perspective is also notable keeping in mind that the cc65 'nix boys
> are adament that Aztec C tool is unusable which is where much of this
> mirrored nonsense that you see part-of orginates from in the first place.
Bill, I read csa2 pretty thoroughly, and I can't recall anyone taking a
swipe at Aztec C, particularly anyone from any "cc65 camp". There seems
to be no doubt that it can be used to produce efficient Apple II apps.
(Maybe you have encountered criticisms in some other community.)
Aztec is a fine native Apple II K&R C compiler, with many features to
permit one to craft applications well-suited to small machines. cc65
is a fine 6502 cross-compiler for a more ANSI-like C, with many features
that are quite useful to developers.
Neither compiler includes all the features of the other, but both are
well-engineered tools for their intended purposes. A developer should
consider each of their strengths and weaknesses before choosing one, or
both, or neither, to get a job done. End of story.
On the other hand, you seem singularly devoted to waging some imaginary
war against cc65 and its users, and, in fact, almost anyone whose
opinions differ from your own. (I'm probably now on that list, too. ;-)
If you actually wanted to know why anyone chose to use a particular
compiler, you should begin by asking them, not by telling them that they
have made a foolish choice. The question might result in some useful
dialog about features, resources, optimization, or usability. The
accusation merely results in bad feeling and misunderstanding.
I can only suppose that you enjoy controversy so much that you see it
everywhere, and like to jump in with fists flailing.
We're a pretty peaceful group here, and no one is taking shots at you
or your efforts. There has been occasional understated (even gracious)
criticism of some of your posts when they seem gratuitously offensive
to respected members of the community.
This is, perhaps, why some have suggested to you that a "chill pill"
would improve (at least) our experience of you on csa2.
This group has a long and rocky history, with extended periods of
destructive flaming as well as long periods of good-natured
discussion (still with plenty of _constructive_ disagreement).
I much prefer the constructive periods, and it seems evident that
diminishing the efforts of others is counterproductive. I find your
use of pejorative nicknames for people to be disrespectful and
dismissive of their opinions, not just playful.
You have made some very useful and helpful contributions to this small
community, and for that I am very appreciative. If you did not find it
necessary to put down the contributions of others in the name of some
imagined competition, I would appreciate it even more.
A newsgroup is like a group conversation in a pub--one that has been
going on since before most participants arrived, and will continue long
after many depart. The tone of the conversation is largely set by an
unstated consensus. It is always a good thing for a new-ish participant
to listen in for a while to check the tone and content before jumping
in. And it is good not to bring the tone of prior conversations into
a quite different one.
Anthony Lawther
Michael,
Once again you have very neatly represented my feelings (and quite
possibly the feelings of many others) on the matter under discussion.
Thank you so much.
Bill,
Please keep in mind that experiential knowledge is very difficult to
argue against.
The particular comments made about Aztec C that I have witnessed on the
cc65 mailing list related merely to the suitability of using the C64
version of Aztec C for benchmark comparisons and the difficulties they
experienced with that version.
Even if you consider arbitrary benchmark comparisons to be worthwhile,
to draw conclusions about the general usefulness of a compiler from the
benchmark results is like trying to determine the average colour of an
image by examining a single pixel.
We have all read of the difficulties you have had with getting cc65
going to your satisfaction. Nobody can gainsay it. This does not mean
all others will share them.
/me ducks incoming return fire
Regards,
Anthony.
mdj
> Now just a minute here... if you think the cc65 project is pissing into the
> wind consider for a moment the Aztec C Museum... You can't ignore me Mutt! I
> am definitely and infintely more urine-soaked than all the cc65 boys
> together and even then I have gallon or two left in my galoshes just to be
> sure. Again Aztec C wins hands-down over cc65, or even when speaking of
> p'ing into wind against smoking hash while drinking beer which until Aztec C
> became old and brittle really had the Pissing-Into-The-Wind Marketplace
> cornered.
This is almost completely true, Bill. I can't ignore you whilst you
continue to harass and ridicule members of our community for nothing
more than having the courage and pride to put their projects in the
public sphere where they can be appreciated by others. Unlike you, I
have a sense of respect and duty towards others and frankly your
behaviour here is beneath contempt. But fear not. It's contempt you
want, and you shall have it. Since you're fond of name dropping in
order to appear educated you may or may not be able to manage a wry
smile as I say hold onto your tits Bill. I'm done with generous. It's
time for some tat. (Nash Nash)
> >When it comes to C on the Apple II, notice that the only serious
> >application written in it is precisely the same type of program that C is
> >good for on other platforms: an operating system.
>
> That my friend is bullshit! That statement ruined the rest of your
> thoroughly enjoyable rant like the proverbial "Great Eraser" *BUT* because
> your post is made on "All Saints Day" and I am the patron saint of C (in
> case you hadn't noticed) and because your post is made the day after "All
> Hallows Eve" so obviously by your post you are in some kind of
> hungover-from-yesterday Halloween drag as a computer expert, I shall forgive
> your transgressions my son as we complang saints forgive those who trespass
> against us.
So as usual, you're too ignorant to come up with a legitimate argument
so you resort to petty insults. Fine. I call ad hominem, and once
again you're the loser.
> Here then is your blessing Mate for ignoring my own serious work on the
> Apple II in C:
*Work of literature snipped*
You're punching above your weight Bill, which is why you're
plagiarising instead of synthesising. Since you're conducting yourself
with the emotional maturity of a belligerent adolescent, you might
find the following from Lewis Carroll's "Through the Looking Glass" a
bit more your pace:
http://www.jabberwocky.com/carroll/walrus.html
> >History repeats itself, and most people don't notice.
>
> Since I don't know most people I would say that this statement is about as
> true as the rest of this thread. The question being of course "Which truth
> isn't true?". You may quote me on that of course.
At least this is just nonsense rather than being opening insulting. I
suppose that's an improvement.
> >*** If there were any gods, which there aren't, this statement might
> >actually be true.
>
> Nathaniel Hawthorne would have had you burned for your blasphemy:) OTOH I
> would question whether your statements might not all be true for the most
> part especially for most people.
Fortunately Tom Paine, Jefferson and James Madison would've fought for
my right to speak my mind and they were the ones who laid the
foundations. It's a pity that their profound respect for the
principles of Liberty are not manifest in you. You're far worse a
person for it.
Matt
mdj
> Since this is my thread and not Oliver's I will also say that if Mud is not
> going to acknowledge the notability of these Apple II applications of mine
> that were written in Aztec C as opposed to Commodore 64 programs that just
> happen to end-up on the Apple II, he should be prepared to both point to his
> own body of work for the Apple II and then to say specifically why my rather
> large body of work is somehow inferior to his high-minded snottery.
You really are nothing more than a common liar Bill. I have on more
than one occasion not only acknowledged but praised you for your work,
but it is not your work that is in question here. It is the fact that
you are continually abusing the respect you're accorded for it in
order to bully and undermine others and their work. Others Bill, who
unlike you, have build compilers, operating systems and even their own
custom hardware to run their software stacks on. Impressive
achievements Bill, worthy of not only respect, but admiration.
Respect for your achievements however will only get you so far, and as
far as *I* am concerned you've come to the end of that road. You're
nothing more than a small minded bigot, and whilst your achievements
show that you were once capable of rational thought, you're well past
it now.
You've been accused of being a shill, but really, that's respect for
your work talking. The reality is you've fallen past the status of
village idiot, and have taken up residence as a troll.
Matt
Bill Buckels
"mdj" <mdj...@gmail.com> wrote:
>The reality is you've fallen past the status of village idiot, and have
>taken up residence as a troll.
If either of those statements were irreversibly true you would not have
bothered to reply to this thread.
However even though I don't feel like an idiot the consensus in this group
and others seems to point to my single-minded promotion of Aztec C as being
irrational especially since I did not write the compiler, and my resulting
reaction to the experience of others as being combative and destructive when
it doesn't suit my purposes. Sadly this behaviour seems to come easily and
seems acceptable to me, so "anti-social" does sum-it-up after all.
I am going to take a break from posting in usenet (and all forums) at least
until January 1,2010. I am pretty sure I still have enough wits about me to
ignore troll-bait even from you Mutt, and I definetly have the integrity to
keep my promise on this one.
Perhaps a self-imposed exile will improve my disposition. I certainly would
prefer to lurk or even to unsubscribe than where I find I have led me so I
hope so. My last hiatus lasted almost 5 years... perhaps you are rid of me
for longer than January. Certainly for good if I don't miss it and at this
point I doubt if I will, since I disagree with just about anything that has
come-up here lately.
Now Mutt, as far as me punching above my weight, I am certain that you
believe your own bullshit as much as I believe mine, but I did want to leave
you with the following links and to simply say that I hope you enjoy playing
with yourself as much as I do because with the venom that flows from your
pen your future assuredly will contain moments a least as bleak as some my
own (not to say they will all be bleak but you will enjoy the contrast with
the happy ones):
Starting with Lewis Carroll:
http://health.groups.yahoo.com/group/hepsongs/message/213
Then T.S.Eliot:
http://health.groups.yahoo.com/group/hepsongs/message/200
And Edward Lear (Just for the funnery of it)
http://health.groups.yahoo.com/group/hepsongs/message/205
And in that venue alone here are 136 more (see below)
http://health.groups.yahoo.com/group/hepsongs/msearch?query=Buckels
Over and Out,
Bill
mdj
> Now Mutt, as far as me punching above my weight, I am certain that you
> believe your own bullshit as much as I believe mine, but I did want to leave
> you with the following links and to simply say that I hope you enjoy playing
> with yourself as much as I do because with the venom that flows from your
> pen your future assuredly will contain moments a least as bleak as some my
> own (not to say they will all be bleak but you will enjoy the contrast with
> the happy ones):
FWIW I've always considered myself to be full of doubts, and that the
contrariness flows from there. I can certainly empathise with the
loneliness felt through holding an unpopular opinion. Fortunately as
I've aged my life has slowly filled with kindred spirits... but this
digresses into a private conversation (that I'm more than happy to
have).
I hope you enjoy your hiatus and that you continue to curate your
museum. It's obvious from your passion that it brings you great joy,
and disagreements aside, I'm sure I can speak for everyone here when I
say that it brings us great joy too. No matter how diametrically
opposed our world views might be, we remain united in our love for the
Apple II, and that bond I hope will never be broken.
Matt
DaveSchmenk
>
snip
> I am going to take a break from posting in usenet (and all forums) at least
> until January 1,2010.
>
>
> Over and Out,
>
> Bill
Although this thread has been my main source of entertainment of late,
it has indeed run its course. As Matt said, we are all bound by our
dedication to the Apple II, so let's all keep that it mind. Bill,
while you're gone, maybe I'll port the CC65 project to compile under
Aztec C just to piss *everyone* off ;-)
Dave...
Michael J. Mahon
I, too, hope that your absence is temporary and enjoyable, and that
you return refreshed.
Your efforts to make Aztec C more available and useful are very much
appreciated, as are your applications showing how to use it to get
great results.
You are evidently a person with wide-ranging interests and skills, and
I thank you for being willing to share them enthusiastically with us.
Charlie
"Bill Buckels" <bbuc...@mts.net> wrote in message
news:WEzHm.15405$l67...@newsfe03.iad...
> I am going to take a break from posting in usenet (and all forums)
> at least
> until January 1,2010.
Bill, I hope this works out for you and I'd like to see you come
back. You have done good work and lots of it.
Charlie
Oliver Schmidt
First of all thanks for your post - I _fully_ agree with every single
aspect!!!
However I'd like to additionally comment on two sections...
>Bill, I read csa2 pretty thoroughly, and I can't recall anyone taking a
>swipe at Aztec C, particularly anyone from any "cc65 camp".
That's exactly what I tried to point out to Bill when his first posts
regarding cc65 showed up in this group.
>Neither compiler includes all the features of the other, but both are
>well-engineered tools for their intended purposes. A developer should
>consider each of their strengths and weaknesses before choosing one, or
>both, or neither, to get a job done. End of story.
Again, that's exactly what I wrote Bill in a private message by then.
My personal opinion I shared with him was:
- Aztec C is more focused on giving access to all the features the
machine has in order to create rather interactive "multimedia" apps.
Therefore it's no wonder that Bill has used it primarily to create
those type of apps.
- cc65 is more focused on portable, single source, cross machine (and
even cross toolchain) projects. Therefore it's no wonder that I used
it primarily to port projects running on up to 20 something different
targets - with a few being built with cc65.
As a result Bill had agreed to change his communication style to
better fit the style predominant here. And it worked out (more or
less) until the recent cc65 2.13.0 release announcements - which were
not directed against Aztec C and/or Bill at all - neither directly nor
indirectly...
Just my two cents, Oliver