[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Complete Basic?
Michael Kent wrote:
Michael J. Mahon <mjmahon@aol.com> wrote:
Charlie wrote:
"David Schmenk" <dschmenk@sbcglobal.net> wrote in message
news:bC2Gi.33748$RX.21877@newssvr11.news.prodigy.net...
Michael J. Mahon wrote:
Charlie wrote:
"Michael J. Mahon" <mjmahon@aol.com> wrote in message
5PqdnVXUWsYfRnvbnZ2dnUVZ_rDinZ2d@comcast.com">news:5PqdnVXUWsYfRnvbnZ2dnUVZ_rDinZ2d@comcast.com...
As I've observed before, a GUI means that almost any program you want
to write will be 10% your functionality and 90% GUI wrangling. That's
a heck of a tax!
Your numbers seem to be off. With GSoft BASIC (and apparently Complete
Pascal from what I read of Chye Thean's site) you can write a desktop
program in just a few dozen lines of code. That's the magic of the
toolbox.
Actually, what you are writing is a full-screen graphics app, with
no pull-down menus or widgets. A GUI app would be one that conforms
to Apples human interface guidelines. They are always event loop
driven.
Certainly true (and I'm someone who likes GUI programming). There are
non-GUI tools in the IIgs toolbox but text based programs were pretty
rare on the IIgs. Merlin 16+ is one I used (and liked) a lot and it is
GSOS/text. The Orca text shell is another.
By far the most powerful, IMO, is GNO/ME -- a text-based multi-tasking
shell for GS/OS that provides access to GS/OS's drivers, filesystems,
and desktop applications. It was a decent attempt at 16-bit Unix for
the IIgs.
That would also get my vote for the most versatile text-based
IIgs shell. Of course, GNO was nowhere near a user's out-of-the-box
IIgs experience, nor did Apple intend it to be.
True, but only developers used text-based apps on the IIgs.
Not true. Many non-developers used AppleWorks, ProTERM, Applesoft,
ProSel, Davex, GNO/ME etc. on the GS. AppleWorks and ProTERM appealed
to non-programming users for obvious reasons, while power users liked
more powerful tools like GNO/ME. Those power users -- mostly college
kids and hacker types -- were the same type of people writing AppleSoft
and machine language programs on the IIe just a few years before. The
IIgs allowed them to expand into a modern environment.
Appleworks was certainly popular. But all of those uses were not
actually IIgs experiences--they were //e experiences!
The original Apple II "idea" was that its considerable capabilities
were accessible out-of-the box to anyone who was patient and could
read--a true "bicycle for the mind."
And that idea is carried much further on the GS than the classic Apple II.
I disagree. The Apple IIgs, as supplied by Apple, doesn't allow the
*casual programmer* to do any more than could be done with a //e and
ProDOS.
Of course, the user can run canned applications, but that is certainly
not a "bicycle for the mind", since the user cannot easily adapt any
of them with his own code.
As you can see, I put *user programmability* high on the list of what
makes an Apple II an Apple II--in fact, the adaptability even extends
to creating one's own hardware extensions--that can even have "drivers"
written in BASIC!
I still say that the IIgs, like the III, departed radically from the
original Apple II idea of *accessible computer power*, and having Woz's
signature on the case of the first 50,000 or so was irony.
The IIgs is every bit as accessible as the other slot-based II's. Even
more so. (And much more so than the IIc and IIc+.)
From a hardware point of view, there's no argument regarding the
"closed systems" of the //c series.
But the primary component of accessibility is easy programmability--
even with PEEKs and POKEs from BASIC--that can put the machine through
all its paces, without layers of overlaying complexity.
Having just looked over the softswitch architecture of the //c and //c+,
I'd say that they took on a very high complexity burden for relatively
little additional functionality. That's a very non-Woz tradeoff.
The GS has the same
slots as the classic II's, which accept nearly all the same cards (Disk
II controller cards, Super Serial cards, slinky RAM cards, etc.). It has
Monitor, AppleSoft, and most of the II firmware built in. It can switch
video modes using the same soft switches as the classic II's, read the
keyboard at the same address, and be programmed in the same AppleSoft as
the others using the same peeks and pokes. It can even load Integer
into the langauge card just like older Apple II's.
Of course the IIgs is "almost completely" compatible with earlier
Apple II's, for marketing if not for idealistic reasons, but saying
that a subset of the IIgs is simple is no justification for its
complexity--which is its inaccessibility. I'm talking about
*conceptual* accessibility.
Tens of thousands of Apple II users understood their machines down
to the gnats eyebrow, but I would guess than only a few hundred ever
acquired the same level of understanding of the much more complex IIgs.
What's more, the GS can be accessed at the bare metal of the system in
ways 8-bit Apple II's can't. Nearly any program on the GS -- 8-bit or
16-bit -- can be stopped at anytime with a command-ctrl-esc, and the
user can instantly access the Monitor with said program frozen in place.
Any byte in RAM, ROM, or on any card in any slot can be read, and any
byte in RAM can be written -- total God-like accessibility -- and the
program then continued by just exiting the CDA menu. "Visit Monitor"
is built-in to every Apple IIgs.
True. Of course, to synchronize entry into the CDA to make a meaningful
observation or change is still difficult, and best done with a BRK, just
like on an Apple II.
It's nice to have at least part of a built-in debugger, but the monitor
also provides a quite useful debug environment for machine code.
To say the IIgs is not accessible like an Apple II is just plain wrong.
It *is* an Apple II -- at the CPU level, at the bus level, at the slot
level, at the Monitor level, at the firmware level, and at the AppleSoft
level. It then adds more functionality and more accessibility on top
of that.
I don't want to belabor the point, but what it adds most of is
complexity--and that is the antithesis of accessiblity. It presents
a would-be programmer with a shear cliff and practically no documents
or tools to master it. Those will cost another couple hundred bucks,
and will probably have to be mail-ordered.
Whatever simplicity it presents to the would-be programmer is a legacy
from the Apple II, not a contribution of the IIgs designers. The IIgs
is the first step in the direction of the "appliance computer" which is
intended to run prepackaged applications and not to be programmed by its
user.
Oh, and the Apple IIgs was designed by Woz -- or rather the design was
started by Woz -- himself back when it was known as the Apple IIx. That's
probably why the machine remained so open at the time all of the other
computers put out by Apple (starting with the Lisa and including the
IIc and IIc+) were closed boxes.
I'd like to know more about Woz's interactions with the design of
the IIgs. I think that most of its openness can be explained as
compatibility with the existing Apple II add-ons, but it would be
nice to know that Woz made that happen specifically.
I do think that the IIgs was intended to replace the //e, which the
//c could never do. And, ironically, the IIgs failed to replace the
//e as well, and the //e was produced long after the discontinuance
of the IIgs.
The Apple /// was also intended to replace the II and II+, and failed
to do so, for a number of reasons (first and foremost being lack of
reliability). One major reason that the /// could never have replaced
the II is that it was not an open system that anyone could develop for,
let alone being friendly toward user-programmers.
The Apple II wasn't just a collection of chips--it was the embodiment
of the hacker ideal of minimal, efficient logical design with great
malleability for simple adaptation to any task.
Proving that the Apple IIgs is a true Apple II.
Not considering the "simple" part.
"Beauty = Function / Complexity", and by that measure, the Apple II
was at least a "10". ;-) The II line continued to hold the record
until the IIgs, at which point complexity increased much more than
functionality, causing a big dip in engineering beauty.
Functionality increased way more than complexity. With the IIgs near-
photographic quality graphics was possible, as was near CD-quality
music (the Ensoniq can duplicate nearly any sound except human-quality
voice through wave-table synthesis). A usable desktop-based graphical
user interface was available -- in color -- as was a pre-emtive multi-
tasking shell. Multi-gigabyte storage, modern computer languages,
multiple filesystems (such as HFS, High Sierra, ISO-9660, and MS-DOS),
AppleTalk networking, laser and inkjet printers, Apple Desktop Bus,
TCP/IP-based networking, true-type fonts, and much more all became
available to the user at whatever level -- from novice to expert -- he
chose to use that particular functionality at.
At what price did all this functionality cost? None if you didn't use
it. The IIgs is at its core an Apple II. Or you could start using the
16-bit opcodes they added to the 6502, or speed your bus up to 2.8 MHz,
or start using the firmware instead of the softswitches, or the ADB
instead of the keyboard bytes, or the Ensoniq instead of toggling the
speaker directly, etc.
Unless you define "complexity" as "functionality", the IIgs wins this
comparison hands-down compared to its 8-bit brothers (and even its
32-bit cousins).
Come on, no one was forced to use the GUI on an Apple IIgs or the toolbox or
managers either.
Indeed--the "French connection" proved that--but it wasn't easy, like
Applesoft!
The IIgs has Applesoft. And GSoft BASIC.
But as noted here several times recently, its Applesoft is for its
//e genes, and GS BASIC was not provided with the machine, nor was
it capable of imlementing the "native GUI" applications of the IIgs.
The 65816 is a horrible kludge of a processor architecture, particularly
in contrast to the clean, spare 6502.
The 65816 is a 6502 with 16-bit opcodes added, the address bus expanded,
and a few other things.
And the addition is *ugly* in my opinion (and I've designed some
architectures). I hate to say it, but it reminds me of nothing more
than of the x86 architecture--except that the x86 wasn't even a pretty
baby. ;-)
This program:
300: 20 58 FC 60
clears the screen on the IIgs just like on any other Apple II.
Again, with the 65816 emulating the 6502. Saying a subset of a design
is prettier than the whole design is actually an indictment--for the
crime of "featureitis".
The Ensoniq chip is a universe
unto itself, completely "tacked on" to the IIgs design.
True, but the capability it brought to the Apple II was unmatched by
any other personal computer for about seven years or so.
Yes, but that doesn't make it "fit". If the Ensoniq had been allowed
to share RAM with the processor, it would have been conceptually simpler
(though it would have required more multiplexing). As it is, it reminds
me of the "Genius" music card for the II, which was a synthesizer on a
card that could be "played" by sending codes from the Apple II--making
it a complete "sidecar" to the Apple. I contrast that with the Mountain
Music System, which, like the Ensoniq, played back wavetable sound using
16 channels, but unlike the Ensoniq, used DMA to access wavetables in
memory that the processor could update directly, and which could be
the subject of I/O operations.
I'm not talking about absolute capability here--I'm talking about
design taste, esthetics, *conceptual simplicity*--which bear directly
on the degree to which a design is accessible to casual programming.
The SHR modes
are distinctly non "Apple II", even having a different pixel clock!
But they have higher resolution, many more colors, a fill mode, and
linear addressing (so in some ways are less complex than classic Apple II
video modes).
Yes, non-linear addressing is a bullet one bites for simpler hardware,
at the cost of table lookup in the software. (If I had been doing it,
I think I might have spent a couple more chips to linearize the space,
but I haven't actually tried the design...)
I guess I don't think of 640 as much greater than 560, so I'd rather
have seen more color depth added to the 560x192 Apple II modes. Given
what was current at the time, it's easy to see why 640 seemed like a
better number (especially to marketing), but from a practical point of
view, 14% more pixels seems hardly worth all the differences.
No one would complain about having a fill mode in 560. ;-)
It, like the Mac, symbolizes the shift of Apple away from the hobbyist
machine toward a consumer machine.
It is a hobbyist machine to its core. But it adds much of the function-
ality of a consumer machine that enables hobbyists to get things done as
well as have fun.
It's interesting to consider it as a tradeoff between its 8-bit hobby-
programmable nature and its 16-bit "IBM PC competitor" nature. I must
admit that I don't often think of it as a "contender" in the world in
which it was introduced.
I suspect that then, as now, the "task" needs of most users are met
by a simple integrated "Office-like" application. Appleworks is, I
think, the preeminent program in the Apple II universe for helping
people get their work done.
It is interesting, then, that there never was an "Appleworks" for
the IIgs that was as bulletproof and trustworthy as plain old
Appleworks--the same one I use on my //e (with a meg of RAM).
It would seem that Apple never figured out what the market opportunity
was for the IIgs.
If you were an Apple II user, it offered a cartload of new features
that were nothing like what you were used to (as well as having a
friendly "//e mode" that denied easy access to those features).
If you were a "new" computer user, the compatibility with the past
gave bragging rights to thousands of 8-bit programs, and the hardware
capabilities offered the possibility of colorful and musical apps to
come--but few were there, and even fewer were serious tools.
The IIgs did truly "sit between two chairs"...
A shift that was inevitable if the
company was to survive and prosper, but one deserving of a lament from
hobbyists, at least.
I just don't understand the lament from the 8-bitters, unless it's the
extra functionality that gets your goat. Nearly everything you can do
with a IIe I can do with a IIgs -- hardwarewise as well as softwarewise.
And then there's boatloads of things a IIgs can do that a IIe can't.
I have never wanted to do any of those things with a IIgs.
Maybe it goes back to the earlier "tweener" observation.
I most enjoy resource-constrained programming--"running light without
overbyte"--and the //e (and earlier) seem a good match to my aspirations
and abilities. My programming on the //e is best compared to a digital
sketchbook, to which it is perfectly suited.
When I have "heavy lifting" to do, the IIgs is, of course, no match
for it. I need megapixels and gigabytes for my power tools for digital
photography and video.
So for me, the IIgs is "too much" to be a fun challenge, and "too
little" to be a useful tool.
Why, when I was a youngster I learned to program by typing hex code into
the monitor!
And the IIgs has the same Monitor and accepts the same hex code as the
8-bit Apple II's.
(Yes--I didn't say that. My first machine language was typing
decimal into an IBM 1620 typewriter. ;-)
I still love sitting down after supper and dashing off a 50-line
program to try something and provide it with graphical display of
the results! ;-) Sometimes that's the end of it, and sometimes
it results in a (completely different) full-blown program--but it's
always great fun, and the computer is seldom in the way of the
problem I'm focusing on. The computer? A //e with Applesoft!
A IIgs has the same Applesoft as the IIe. Plus you can put the keyboard
on your lap!
;-)
Like I said before, I just don't understand the disdain the GS receives
from the 8-bit Apple II users. I'd say it's envy, but come on! Both
the 8-bits and the GS are the same price these days -- essentially free.
It's not envy, and it's not cost, its esthetics--AND accessibility!
The esthetic part:
I don't like the idea that the IIgs is deploying many times as many
transistors to do the same thing that the //e does, when it's doing
what a //e does--and that's what I like it to do.
As a system designer, the IIgs is too much like "ten pounds in a
five-pound bag". ;-)
In contrast, the Apple II was "five pounds of function with only
a pound of parts".
The accessibility part:
I can't (or maybe with Complete Pascal, I *can* ;-) just sit down
after dinner and use the additional capablities of the IIgs for
anything that interests me. For that, I need tools that are not
built-in, or are much harder than Applesoft to use, and documentation
that is too heavy for me to pick up in one armload!
Again, there's no disputing taste... ;-)
I don't want to seem like I'm giving the "silent treatment" (though
that might be a welcome relief ;-), but I'm about to leave town for
a couple of weeks to marry off a daughter ;-), so I may be a little
"hit or miss" over the next few days...
-michael
NadaPong: Network game demo for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."