Re: 65020 CPU? Look this...

["Charlie" <charlied at NOSPAM bboard dot com>]

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
GZednc6FU6vP5brfRVn-rQ@comcast.com">news:GZednc6FU6vP5brfRVn-rQ@comcast.com...
> Charlie wrote:
> > "Michael J. Mahon" <mjmahon@aol.com> wrote in message
> > 3IqdncETYKAOTbnfRVn-3A@comcast.com">news:3IqdncETYKAOTbnfRVn-3A@comcast.com...
> >
> >>Charlie wrote:
> >>
> >>>"Michael J. Mahon" <mjmahon@aol.com> wrote in message
> >>>q5adndT5WJr0477fRVn-vw@comcast.com">news:q5adndT5WJr0477fRVn-vw@comcast.com...
> >>>
> >
> >
> > < snip >
> >
> >>>>I have nothing against the Apple IIgs, but when it is not running in
> >>>>8-bit mode, it is nothing like an original Apple II.
> >>>
> >>>
> >>>I believe you are being way too hard on the Apple IIgs.  While not
> >
> > running
> >
> >>>in 8-bit mode it retains much of the the original Apple II (slots,
game
> >
> > I/O
> >
> >>>socket, speaker, NTSC output, GR/HGR/Text screens, most softswitches,
> >>>system monitor commands, etc.).  It can even be run at the original
> >
> > Apple
> >
> >>>II speed if you so desire.  Programming in the 16-bit mode is only
> >
> > slightly
> >
> >>>more complex than 8-bit.  You still have 1 byte opcodes that are for
> >
> > the
> >
> >>>most part 16-bit versions of the old 8-bit ones.  This seems pretty
> >
> > logical
> >
> >>>to me.  You do have a few new opcodes but they are not really that
> >
> > complex.
> >
> >>I agree that the logical complexity of the hardware is incremental
> >>with respect to the classic Apple II.
> >
> >
> > OK
> >
> >
> >>My concern with the IIgs hardware and its fidelity to the Apple II
> >>tradition is its large linearly addressable RAM.  As I noted in another
> >>reply, that is an invitation to programmers to abandon the discipline
> >>of their craft.  GSOS is simply a natural result of "too much RAM"
> >>(and many would say, not enough processor  ;-).
> >
> >
> > Yes, the IIgs has a large linearly addressable RAM where an original
Apple
> > II has a small linearly addressable RAM but I think this does not
justify
> > the statement:
> >
> > "... when it is not running in 8-bit mode, it is nothing like an
original
> > Apple II."
>
> OK, perhaps my statement should have been a bit more qualified--like,
> "when it is running GSOS, it is nothing like..."
>
> But for all practical purposes, the only time it's not running in 8-bit
> mode is when it is running GSOS.
>
> I know that one can write ProDOS programs that switch into 16-bit mode
> for their internal calculations, but since these are then incompatible
> with the Apple II line, I don't consider them very interesting.  (You
> may be surprised to learn that I don't use 65C02 instructions, either,
> and for the same reason.  Why give up universal Apple II compatibility
> for a few easily-avoided instructions?)

I do agree with you here, the 65C02 added instructions are not worth
incompatibility.

> > My reason for posting was not to change your mind about the IIgs (well
> > maybe just a little) but although I respect your knowledge in both
> > programming and hardware I think that statement sent the wrong message
to
> > someone who is considering buying their first Apple II.
> >
> > I do agree that the small RAM of the Apple II forced the programmer to
be
> > more disciplined but I never felt that was an advantage.  While I
certainly
> > admire the compact and elegant code of programmers like yourself, I
believe
> > that is more a reflection of your talent than the constraints of the
> > original Apple II.  I love programming (as a hobby) and did so on an
Apple
> > II+ from 1980 to 1987 for more hours than I would like to admit, but
I'm
> > still a mediocre programmer.  I think more people fall into this
catagory
> > and therefore more addressable memory is a blessing.  I loved my Apple
II+
> > but when I got my IIgs in 1987 I felt like I died and went to heaven.
I
> > still think that a IIgs is the best Apple II to buy. Of course at
today's
> > prices why not get one of each. <grin>
>
> I certainly agree that the IIgs is an interesting and useful machine,
> and one which many people love to use.  I wouldn't want to discourage
> anyone from experimenting with almost anything that takes their fancy.
> I have several, myself--but I find myself programming on my //e's!
>
> I really don't want to spend my time learning the ins and outs of
> a complex toolbox environment.  I'd rather spend my time imagining
> new things an Apple II might be able to do, and then trying to do
> them.  ;-)
>
> I'm not really down on the _concept_ of tools, but I resist the huge
> barrier to entry created by having a whole bushel of them dumped on
> me!  I prefer a simple tool environment, and, when the need arises,
> I prefer to write some of my own tools.  (I have little patience
> with what I regard as poor design.)

I like the concept of tools if well written documentation is easily
available.  I feel that Apple Computer didn't handle this area very well
with the IIgs.  The documentation should have come with the computer.

Learning the toolbox and the whole idea of "event driven" GUI programming
was very interesting and enjoyable to me.  I didn't know it at the time but
it also made the transition to Windows/API programming very easy.

> But here I am speaking of my own preferences and motivations, and I find
> that Applesoft is a very welcoming programming environment for beginners
> and experienced programmers alike.  Few programs must be fast to be
> useful, and very few are used frequently.
>
> I would think that 48KB is _huge_ for any beginning programmer.  And on
> the IIgs, Applesoft is still just an 8-bit, 48KB environment.
>
> 48KB sounds like plenty for any "proof of concept", and it's hard to
> imagine an Apple II as a realistic platform for an "important" app in
> the modern world.

Absolutely, I don't remember ever writing an 8-bit program that came close
to using up 48K (the larger programs though were written in assembly
language).  I do remember writing a program (again in assembly) for a
friend where I was afraid of problems with the small stack size of the
6502.

> If we consider programming in C, then the IIgs is _practically_ the only
> Apple II game in town, so there's no argument there--but most beginners
> find C and its tool enviroment daunting--enough so that in the Apple II
> world there is about one hobby C programmer for every ten thousand (or
> more) Applesoft programmers!

I learned C on a IIgs but didn't like it.  Although I wasn't a beginner by
then, I found parts of it confusing.  I went back to Applesoft and
assembler.
In the Windows world (where I do most of my programming today) I
unfortunately use C most of the time but that's another story.

> And while I appreciate the compliment, I think that a constrained
> programming environment is a virtue in learning to program well.
> Think of it as a way to learn the art of programming sonnets,
> rather than epics.  ;-)

I do understand where you are coming from.  I also agree that most
programmers are lax when it comes to writing compact code and they may well
have benefited from learning in a constrained environment.  Where we part
company is that eventually the programmer is no longer a beginner.  When I
moved to a larger environment I felt that it wasn't as important to shrink
the code down to the minimum possible as it was to provide the user with a
program that worked the way he wanted it to.  I realize that this can be
taken to extremes (if you use a Windows machine you don't have far to look
for examples) but I feel more comfortable spending time (and using
resources) on user requested features and documentation than unnecessarily
tight code.

> I have always said that our most important design tool is
> our wastebox--and it is much too little used!  When you can't
> see how to do something with little memory and few instructions,
> then _keep thinking_.  At the end of that process there are two
> possibilities: 1) you know that it can't be done, and exactly
> why, or 2) you know that it can be done, and how to do it.
>
> Of course, there may be "false stops", when it only _appears_
> that it can't be done.  That's when even more thinking is in
> order.  ;-)  BTW, I think with pencil and paper, so throwing
> away the not-so-good ideas/code is the thing that enables me
> to get to the beautiful realization.

I feel that if I used your method I would be spending so much time trying
to shrink the code that I wouldn't have enough time to do the other things
that I feel are even more important.
To use an analogy (no not classic cars this time), I worked for many years
in a maintenance machine shop.  When a part was needed some machinists
spent a lot of time making each dimensional size as accurate as possible
regardless of tolerances stated on the blueprint.  Doing this has the
effect of forcing the individual to a discipline that never accepts less
than perfection.  It also takes quiet a bit longer.  Other machinists
maintained the precision only where necessary and completed the job faster.
The end result (the finished piece) was functionaly the same.
Where time is not a consideration it is good to strive for perfection.  For
me time is always a consideration. <sigh>
By the way, I don't mean that we should tolerate programs that don't work
properly.  I'm speaking here only of the size of the code.

>
> Every poor or incomplete design I have seen could have been
> significantly better if the designer had been willing to
> discard his bad ideas to make space for the great ones.
>
> Another of my maxims:  If you haven't thrown at least two
> designs away, then there is a much better design waiting to
> be discovered.

On that we agree.  I usually find it very hard to "give up" on a design
that isn't working (in direct proportion to the amount of time I've spent
on it) but experience has shown me that it has to be done.

> >>>I think maybe your dislike of the Apple IIgs has more to do with the
> >>>GSOS/GUI part.
> >>>It is certainly true that writing a GUI program that conforms to the
> >
> > Apple
> >
> >>>guidelines and uses GSOS is complex and by its nature uses more memory
> >
> > but
> >
> >>>GSOS is just a program running on an Apple IIgs.  You can still use an
> >>>Apple IIgs in 8-bit or 16-bit (or even mixed) modes and anything you
> >
> > can do
> >
> >>>with GSOS and the Toolbox you can also do without them.  Of course
> >
> > you'll
> >
> >>>have to "roll your own".
> >>
> >>You are correct.  I lay much of the blame for complexity in programming
> >>the IIgs at the feet of GSOS.
> >>
> >>Again, don't get me wrong--as GUIs go, GSOS is wonderfully simple and
> >>clean.  But _all_ GUIs shift the programmers concerns from 90% function
> >>and 10% interface to 90% interface and 10% function.  (A bit like
> >>WYSIWYG editors, which cause memo writers to spend 1 minute on content
> >>and 10 minutes picking fonts. ;-)
> >
> >
> > I have found this to be true mostly when a person first programs in a
GUI
> > environment or for that matter uses a WYSIWYG editor.  Its the Wow!
factor
> > (Wow! Look what I can do).  For most people though the novelty wears
off
> > and after a while the memo writers pick a font they like and stick with
it
> > and the programmers write a reusable skeleton program to which they
"plug
> > in" their real function code.
>
> Yes, this is the standard way of dealing with GUIs--because anything
> else would be intolerable.

The GUI doesn't deliver real incremental value to the program but it does
to the user.  If you are writing a program just for yourself you already
know how it works so the command line saves space and time.  Also, if the
program is meant to perform one specific task then a command line interface
is the way to go.  I often use it myself in this case.  It is when
parameters must be passed at the command line that many users become
confused.
For me it's not the the graphics part of a GUI that makes it nice but the
standardization that frees the user from having to learn the basics for
each program.  When I wrote Apple II text based programs for my friends I
made them menu driven and one of the items on the menu was "Help".  Even
adding a menu interface and help display function can significantly
increase the size of a program over its core functions but I always thought
it was well worth it.  Its been a while since I've programmed anything on
my IIgs so I won't comment on the the size difference between GUI and
command line programs on that machine but I will certainly agree that the
differences on a Windows machine seem excessive.  I wonder if that is the
result of sloppy programming or something else.

> Although this conserves your time (except when compiling), it still
> usually means that the code of a simple program will be a factor of
> ten larger than the same program written for a command line interface.
> I find that offensive, when the GUI delivers no real incremental value
> to the program.
>
> >>When GSOS was produced, GUIs were thought to be superior to command
line
> >>interfaces in every way.  Most programmers, though, continue to use a
> >>command line interface while developing, because it's easier to do
> >>exactly what you want, and programming is mostly text entry anyway.
> >
> >
> > GUI verses command line has been an argument for some time and as you
may
> > have guessed I prefer a GUI environment for programming.  The main
reason
> > for me is the ease of disk/file functions.
>
> As one who has always used standard naming conventions to group files,
> I find I can do more, faster, with a command line, but I understand
> your preference.  FWIW, I also find that I spend a very small fraction
> of my time doing file operations, compared to pencil-pushing, text
> entry, and testing.

For me its more about the frustation of having to remember where the file
is and the exact spelling of the filename.  My memory was never good to
start with and as the years go by my memory (unlike todays computers) seems
to be getting smaller. <grin>

You mentioned testing.  This is the one area of programming that I don't
like but it is probably the most important.

> >>I don't dismiss GSOS entirely as Mac envy, but if you consider the
> >>embattled atmosphere of the tiny Apple II division when it was created,
> >>you know that it must have had a lot of "so there" motivation.
> >
> > Probably true.
> >
> >>Of course, all this happened long past the point where there was
> >>any real chance of the IIgs becoming a mass-market platform.  The
> >>personal computer industry/market had moved on, never to return.
> >>
> >>While I'm on the subject, I really like the fact that the Apple II
> >>is not the "computer for the rest of us".  I cherish the fact that
> >>it is a computer created by and for hobbyists, not "end users".
> >>
> >>Of course, Apple wanted to sell _lots_, so they encouraged lots of
> >>mass-appeal, eye candy applications for the Apple II, but, at its core,
> >>it remains a hacker's machine.
> >
> > In general I agree with you but I would like to add that some hobbyists
> > actually like to see their creations used by non-hobbyists. <grin>
>
> Agreed.  ;-)  But today, one must be satisfied merely with one's own
> effort, not with the validation provided by others--at least in the
> Apple II (small) world.

Yes, that's a big reason why I don't do much Apple II programming anymore.

> I was a bit surprised that _no one_ has corresponded with me about
> getting their own NadaNet running.  ;-(  Are they just completely
> self-sufficient, and happily networking away in silence?  Or is
> everyone (?) waiting for the IIgs native-speed-compatible version?
> Is the set of programmers with more than one running Apple II tiny?
> Or is no one interested enough to give it a try?
>
> I thought that constructing the two-transistor interface might be
> a barrier, so I added an illustrated construction article to my
> web site--but still no takers.  ;-(

I'm no help to you here.  I have only a IIgs and a IIe.  I gave my II+ away
in a fit of generousity some years ago (I've been kicking myself since).  I
truly believe that what you are seeing is the result of a VERY small Apple
II community.  Within that community a fair portion are using emulators
(their Apple IIs are packed away in the attic).  Although, I still have my
two Apple IIs up and running I must admit that I use emulators more.  I am
surprised that no one has corresponded with you about running their own
NadaNet but I guess I shouldn't be.  I wrote Fishwings about 5 or 6 years
ago and to date I can count the number of people who have corresponded with
me about it on my fingers and toes.  I could blame the lack of interest on
the fact that there are other programs that do the same thing and more such
as, AppleCommander and CiderPress, but the fact is even when Fishwings was
the "only game in town" very few people contacted me.

> At least a few have used my Sound Editor and DAC522, both for their
> own amusement and as a platform for some very creative work.  (BTW,
> I'm working on a synthesizer version of DAC522--one that could be
> an eight-voice synthesizer on an AppleCrate!  More soon.)
>
> >>As the community of Apple II enthusiasts ages (and I sense that it is),
> >>it is returning, proportionately, to its hobbyist roots.  I relish
that,
> >>not just for noatalgia's sake, but for the craft involved.
> >>
> >>
> >>>As a person who has owned and used both an original Apple II (OK, an
> >
> > Apple
> >
> >>>II+) and an Apple IIgs ROM 01 I will agree that the original is an
> >>>excellant machine in which to learn programming as well as computer
> >>>hardware architecture but I also feel the IIgs retains most of that
> >
> > while
> >
> >>>providing a logical 16-bit extension and some very nice extra
features.
> >>>
> >>>
> >>>
> >>>>As I have said
> >>>>before, I regard it as a Model T (a wonderful classic) fitted with a
> >>>>high-compression V8 engine and tailfins.  A fine "hotrod", but
neither
> >>>>truly classic (too many mods) nor truly modern (still has running
> >>>>boards).  ;-)
> >>>
> >>>
> >>>The analogy with cars doesn't work well with me.  I believe all Apple
> >
> > II
> >
> >>>models are classics.
> >>
> >>Ah, but some classics are more classic than others.  ;-)
> >
> >
> > I agree but I suspect we disagree on which one is the more classic.
<grin>
>
> Surely the _original_ must always win that contest.  ;-)

Ok, if you say so. <grin>

> BTW, Charlie, I'm really enjoying our conversation!  I suspect you're a
> very good programmer, yourself.  ;-)

I too have enjoyed our conversation and thank you for the compliment but I
know better. <grin>

> Maybe we are the usual poles of programming:  the application programmer
> and the system programmer...

I should have seen this earlier.  Much of what I have been arguing does not
apply to a system programmer.
I prefer application programming, probably because my understanding of the
hardware has never kept up with my programming.

Charlie