Re: 65020 CPU? Look this...

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

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
LY2dneM9K7YY7rTfRVn-uQ@comcast.com">news:LY2dneM9K7YY7rTfRVn-uQ@comcast.com...

<snip>

> >>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.
>
> Of course, the documentation is several volumes, so the cost increment
> would not be negligible.

Yes, the toolbox documentation came in three volumes (with some later
additions).  I bought them and used them extensively. They were not cheap
but what bothered me about them was they were needlessly bloated (the
similarity with the argument against GUI programs is not lost on me).
<grin>
Much of the information is duplicated in each volume and the hard binding
may look good on a bookshelf but isn't the best for referencing.

The spiral bound Apple ][ Reference Manual that came with my Apple II+ is
packed with information (and even a little humor) and it along with the
Applesoft BASIC Programming Reference Manual showed that Apple knew how to
produce good documentation and include it with the computer.  My second
biggest disappointment with Apple Computer was the nearly useless books
that came with the IIgs (the biggest disappointment of coarse was the way
Apple handled the Apple II line and their loyal customers).

At the very least Apple could have included toolbox documentation on disk.

> But even more important, practically no one would have read it.

Sadly, I have to agree with you.

<snip>

> >>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.
>
> Yes, 256 bytes seems small, but it actually only turns out to be
> an issue if the programming style is always pushing arguments on
> the stack.  Even then, it's unusual to get _very_ deep in call nesting.

If I recall correctly, the request was for a routine to find the full
pathname of a ProDOS file containing a given block.  I tried a couple ways
of doing this including a recursive routine that "walked" through the file
tree looking at each file's index blocks for a match.  My friend's machine
was an Apple IIc with a 3.5" Unidisk drive and in practice the recursive
routine always worked for him.  Still I could envision problems if someone
tested the limits of directory nesting.  I don't remember if I went with
this approach or not (it was about 15 years ago).

<snip>

> We are in agreement.  Solving real problems is the purpose of computers,
> and having a surplus of resources is a good insurance policy, and also
> opens up new possibilities.
>
> Unfortunately, it also opens the possibility of wasting those resources,
> to a degree almost unimaginable to the non-professional.  Have you ever
> looked at a trace of the instructions executed to, say, rename a file
> using a GUI?  It is enough to fill the Grand Canyon!  ;-)

I certainly can't argue with that.  Well, maybe not the Grand Canyon but I
know what you mean.

<snip>

> Of course, as a hobby programmer now, I enjoy constrained programming,
> since it turns many design issues into puzzles: how can I do this and
> still satisfy all these constraints?  I find that very enjoyable.
> And totally impractical!  ;-)

I can relate to that.  Although we look at it two different ways I have
always thought of programming as solving a puzzle.

> >>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.
>
> Actually, it's not usually about shrinking the code--it's about
> distilling the code to a point of crystalline simplicity:  that
> wonderful thing that happens when everything falls into place and
> one change 1) simplifies the code, 2) collapses what appeared to
> be multiple cases into a single case, 3) satisfies the constraints,
> and 4) WORKS!

"Shrinking the code" was a poor choice of words by me, because I did
understand what you meant.

> And, yes, people doing this to make a living and not for their
> own enjoyment don't have time to do this.
>
> > 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.
>
> I understand and agree.  That is a solid engineering approach which
> I work(ed) and live by.  The only exception I make is that when it is
> for my own enjoyment, I do what pleases me most.
>
> It is not surprising that some of the finest designs and implementations
> in the world are a product of just that mindset.  Woz's, for example.
>
> He was not working to any deadline except his own.  He could have put
> in separate DRAM refresh and video refresh circuits, but he saw that if
> he permuted the address lines just right, the video refresh would also
> refresh the DRAM, with no additional logic!
>
> He re-layed out the Disk ][ controller several times, and agan permuted
> the ROM address and data lines, to eliminate PC board vias.  He got it
> down to just two vias on the whole board--and I'll bet he lost a lot of
> sleep over whether it was possible to eliminate one or both of those!
>
> No one really cares about this except him--and a few who appreciate the
> passionate esthetics of his design, both logical and physical.

I have admired Woz's abilities from my first days of using an Apple II.

> But I have to say, I want a designer with this mindset to design the
> airplanes I fly in, the car I drive, the house I live in.  This is
> _uncompromising quality_, even though it is not strictly cost-effective.
>
> Of course, I'd like the manufacturing team to feel the same way.  ;-)

If only it were so.

> Most of the security problems we live with today are the result
> of an incomplete conception of the problem, coupled with poor
> structure and a lazy implementation.  Most programs, including
> system programs, do not have a structure that makes it clear
> exactly which module level is responsible for verifying the
> correctness of parameters passed in.
>
> This potential problem becomes real when C's delimited strings
> are passed at interfaces between trusted and untrusted modules.
> _Every_ copy operation at such an interface _must_ have a "counted"
> limit, to prevent buffer overflow, but this is not a primitive
> C concept.  How much simpler and safer it would have been to
> represent strings with a preceding length field.
>
> But I won't blame the creators of C, who were making a tool
> for professionals.

Yes, blaming the creators of any tool for its improper use makes no sense
to me.

> I blame the programmers who leave the
> safety railings off even on the finished building.

Apparently there are a lot of unprofessional programmers working for Bill
Gates. <grin>

<snip>

> The trouble with starting to write code immediately is that by the
> time you've written two pages worth, you've made hundreds of little
> decisions--picked identifiers, solved little coding problems, etc.--and
> it is the inertia created by these decisions that "commits" people to
> their first approach long before they have explored the problem space.
>
> BTW, there are some corollaries of this principle, on a larger scale.
> I (and others) often say, "Beware of version 1.anything or anything.0,
> because it is not fully baked".

Very good advise and I would like to add 0.anything is telling you that
even the programmer is not satisfied with it.

> In the same way, notice how some kinds of tools are usually kludges
> that only "mostly" work--like assemblers and linkers.  I hypothesize
> that this is so because they are almost invariably the first assembler
> or the first linker ever written by their authors.  These tools are
> regarded as so mundane that, for all practical purposes, no one ever
> writes another one!  They are like "sampler" projects for beginning
> programmers, and most experienced programmers consider them "beneath"
> them.
>
> >>>>>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.
>
> But not programmers--they eat, breathe, and live parameters!

Ok! Ok!  Even a GUI environment should have a way to enter a command line
if you really feel the need. <grin>

<snip>

> >>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>
>
> I find that a strong discipline of naming conventions helps a lot.
> But there's always the quick "catalog" if I'm unsure.  ;-)

My discipline isn't as strong as yours but I sure learned to type "catalog"
fast and quickly hit "ctrl-s". <grin>

> > You mentioned testing.  This is the one area of programming that I
don't
> > like but it is probably the most important.
>
> I consider it so essential that I place building a test "scaffold" for
> the modules of my programs is done in parallel with the construction of
> the modules themselves.
>
> In a complex program, it should be possible to make a change and fully
> regression test the module, and then the entire program, in about the
> same amount of time it takes to compile it.
>
> But my experience is that, even in industry, where the benefits are
> huge, this testing concept is considered an unrealistic luxury!
>
> (As lazy and stubborn as an individual can be, a group can be
> immeasurably worse.  I think they call it "culture".  ;-)

The abilities of individuals in a group are rarely additive.  More like an
average or even less.  My last experience with a group project (not
programming related) was so frustrating that I completely left the group
and did most of the work on my own.

<snip>

> >>>>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'm fortunate--I'm now retired, and my time is my own.

You're retired and have time of your own?  You are fortunate.
I am also retired but I have less time of my own than I did when I worked.
What's even worse, time moves faster these days. <grin>

>
> >>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.
>
> I hope I was one--I certainly used it until Andy's _tour de
> force_, CiderPress.  I notice that the Apple II font you created
> for Fishwings is still the "only game in town", but that may seem
> like faint praise.
>
> I appreciate your work.

Thank you, but I didn't really write Fishwings for praise.  I just wanted a
program with its functionality when I moved into the Windows world and
discovered Apple II emulators.  At the same time I was trying to learn how
to use the Windows API. So writing it was a learning experience.  It being
one of my earliest Windows programming attempts it falls into the kludge
category that you alluded to above.  I put it on the internet for download
because I thought that there would be a lot of Apple II people who, like
me, were using emulators.  My statements above were meant to back up my
belief that the Apple II community is much smaller than I initially
believed.  I would love to be proved wrong.  I don't have any way of
knowing how many people downloaded my program much less if they used it so
I could be way off base.  It would be interesting (at least to me) if
someone could come up with a "ballpark" figure of how many people are using
a real Apple II even sometimes and/or using an Apple II emulator.  I have
no idea how you could come up with a figure other than speculation.

<snip>

> I kind of came in the back door of programming, through electronics
> and physics.  This naturally inclined me toward system programming
> and computer architecture.
>
> In fact one of the first "real" programs I wrote (after writing my
> own assembler, of course ;-) was an interactive graphics program
> for doing data reduction of data collected in nuclear physics
> experiments.  So I can fully appreciate the value of graphical
> user interfaces.  ;-)  Of course, in this case, the data itself
> was a plot, and the user could directly draw on it with a light
> pen.  No "eye candy" here--the machine only had 5K words of
> memory!

Wow!  A GUI that uses only 5K words.  Now that is tight code. <grin>

> I knew I had done a good job when it became hard to sign up for
> time on the old (vacuum tube) computer that it ran on, because
> several other experimental physicists were signing up to use my
> program on their data.  My program (and I) even made the cover
> of the Caltech alumni magazine in 1965 or so!  ;-)

Great! I'm sure you deserved it.

> That, by the way, was when I made plans to leave physics for
> computer science.  I figured I could do physics more good by
> working with computers than by doing physics myself.

I'll bet it had even more to do with computers being more fun. <grin>

Charlie