[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 65020 CPU? Look this...
Charlie wrote:
"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.
Of course, the documentation is several volumes, so the cost increment
would not be negligible.
But even more important, practically no one would have read it.
The designers of the IIgs and GSOS knew very well that the machine
was much too difficult to program for the average user. Like all
other GUI machines, it was designed to be programmed by professionals.
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.
Yep, one GUI is pretty much like another--they are all rewrites of
the original GUI design! ;-)
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.
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 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.
C is a fine language. But it is not a language for casual or
occasional use. It is a professional tool.
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.
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! ;-)
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 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!
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.
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. ;-)
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. I blame the programmers who leave the
safety railings off even on the finished building.
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.
Exactly--and good for you (and all your users!) that you have discovered
this and have the discipline to do it.
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".
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!
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.
I also agree that GUIs are great for casual users, and convenient
for everyone. The standardization that they (finally) brought to
application interfaces is welcome--and very likely a precondition
for broad acceptance of computers.
But I still consider a GUI an unacceptable burden for my own code,
and a prodigious consumer of computer resources (but who cares on
a 3GHz, 1GB machine?).
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>
I find that a strong discipline of naming conventions helps a lot.
But there's always the quick "catalog" if I'm unsure. ;-)
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". ;-)
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'm fortunate--I'm now retired, and my time is my own.
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.
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.
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!
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! ;-)
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.
-michael
New Applesoft BASIC interface for NadaNet networking!
Home page: http://members.aol.com/MJMahon/