It's Time for Applesoft .... /GS!!!



by Rubywand


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 understand.

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 Real programs!

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 II users!

Return to the GS WorldView Index 'Parent Directory'