It's Time for Applesoft .... /GS!!!
Imagine being able to boot System 6 and start programming. No; I'm talking
about clicking an application icon for C, Pascal, etc. and then spending
the next fifteen minutes getting ready to get ready. Nor, do I refer to
hassling with silly, brain-damaged syntax rules, arcane Toolbox spells,
buggy de-buggers, and cumbersome compilers. I mean you start right off entering
instructions that do what you want to do and which both you and the computer
A novel concept? As II veterans will tell you, there once was a time when
'just any' Apple II user could fully access the power of his/her machine.
These pioneers used Applesoft, and, for 'fast stuff', they used calls to
machine code. Sure, plenty of programmers developed great wares entirely
in Assembler code; but, the point remains: Applesoft worked. It made it
easy for 'everyone' to take the helm and get things done.
It is hardly a secret that, with the arrival of the IIgs, approximately
95% of Apple II users ceased to be "real programmers". Applesoft
does not begin to command IIgs resources; and, few users have the time or
inclination to both learn a new language and steep themselves in Toolbox
lore spread through four weighty volumes. Indeed, one of the 'dirty little
secrets' of IIgs programming today is that, whatever the language you think
you're using, you must ultimately program in Toolbox to accomplish anything.
What the II world needs is an "Applesoft/gs". Installed in ROM,
it would let any user boot System 6 (or whatever) and be ready to create
Applesoft/gs would be interpreted; so, there would be no need to mess with
compilers (unless one wished to use an assembler to add fast-executing machine
code routines). Then, too, as TASC, Einstein, etc. allow compiling current
Applesoft programs for better speed, there would, no doubt, soon be compiler
options for A/gs.
What would Applesoft/gs look like? Probably, the best way to get started
is to have A/gs be an "Apple Option" or an "Extra".
Eventually, it might incorporate all Finder functions and replace Finder
as the standard OS interface.
Programmers would begin with a super-res window in which to enter A/gs statements--
like PRINT "Hello World" or TEXTCOLOR= Red or FONT= NARF.8-- and
would have full-window editing capabilities similar to those available via
Program Writer (i.e. you could list variables, etc.). As with current Applesoft,
you could do a RUN at any time to see how things work.
A/gs would have many new commands aimed at giving the user direct access
to IIgs graphics and sound capabilities. PLAYF "Bach Fugue Dm"
would play the music file named "Bach Fugue Dm". DISPANIMF "Big
Ship" would display the animation sequence file named "Big Ship".
MOVSPRITE Monster(N), X,Y would move the identified monster figure to screen
coordinates X, Y. ...
Too easy? Well, if you expect to jump through fifteen different hoops every
time you'd like to command your machine, then, Yes: "There are SOME
THINGS ordinary pissant users were not meant to KNOW, let alone DO!"
But, if you've about had it with this sort of sheep dip and you think that
a computer language is _supposed_ to be use-able by most users, then, Easy
is never Too Easy.
Having access to a 4MB machine with hard disk makes a big difference in
the features we can incorporate into A/gs. Aside from the expected enhancements--
optional line numbering, named subroutines, longer variable names, ...--
A/gs would be readily extendable. This means developers could create and
sell add-on command packages. Having lots of RAM also makes it possible
to optimize the new language for speedier execution of commands.
How will users get Applesoft/gs? It is likely to be a fairly large language
and, certainly, we do not want to tie up extra RAM. Also, we want A/gs to
be available without having to load it, and we want the language to be update-able.
(For one thing, there are certain to be a few bugs; for another, it will
be easier for a developer to launch A/gs if every desired feature does not
have to be present in the first release.) Finally, it would be very nice
to have a language that cannot be over-written and bombed. Having A/gs in
EEPROM is the solution.
Initially, users will probably install A/gs by plugging in a Mem Slot extender
into which both the EEPROM board and current memory board can be plugged.
Some kind of System patch software will allow starting the language from
the Finder. In time, memory card makers may routinely include a socket and
decoding for the A/gs chip; but, at the start, the price to the user for
the new A/gs EEPROM card system plus some kind of manual is likely to approach
the magic $99 figure.
Is A/gs doable? Off hand, I cannot think of any good reason why it should
not be. The Apple II's greatest resource has always been it's user base.
No single enhancement would contribute more to the power and enjoyment of
II computing than, at last, harnassing the creative power of _all_ Apple
Return to the GS
WorldView Index 'Parent Directory'