Re: Exciting developments in Commodore world -- Ideas for GS dev?

[Rubywand <rubywand@swbell.net>]

Nathan Mates writes ...
> 
> In article <1998033106014500.BAA09613@ladder03.news.aol.com>,
> Supertimer <supertimer@aol.com> wrote:
> >There is more development for these units than for the GS!  Their new
> >OS can provide ideas for possible GS development.  I saw this in the
> >comp.sys.cbm newsgroup...
> 
>    Ideas are a dime a dozen.

     This is a fairly common misconception. Ideas are based upon years
of education and other experiences unique to the individuals presenting
the ideas. Ideas are where progress begins.
 

> What's needed is programmer time, effort,
> and an audience more receptive to new stuff than those who'll
> mindlessly gripe over a bug in the ROM code.

     If users did not gripe about ROM code bugs there would be little
incentive for anyone to spend time fixing them.

     IIgs programmer time and effort to develop new software is,
certainly, of value. It was the absence of essential software (e.g. a
good IIgs OS and a good IIgs BASIC) which significantly limited
opportunities for user base expansion following the introduction of the
machine in 1986.

     On the other hand, we have reached a point where programmer efforts
can do little to advance GS development. Our problem is the hardware.
One way or another, the hardware _must_ be upgraded. The C64/128
approach is worth examining. Indeed, lots of ideas are worth examining--
the more the better.



> I'd really recommend
> trading in any form of pompoms and other cheerleader-type crud and
> actually starting to work on something-- that's FAR more productive in
> the long run than vapor hardware and software ideas.
>

     Yes; there is much to be said for having something concrete, say, a
new 20MHz motherboard or a 'New GS' plug-in board, which you can plop
down on a table and demo at KFest. It is not such an easy thing to do.

     That programmers, yearning to produce new GS products, may be
impatient with hardware types is understandable. Yet, just as
programmers are unlikely to be enthusiastic about fixing ROM code bugs
if nobody cares, hardware designers are unlikely to produce an upgrade
prototype without some indication that users will be interested in the
approach taken.

     The pompoms and cheerleading are part of the process of stimulating
interest and promoting ideas. This, in turn, helps generate a consensus
regarding the best approach for breaking the hardware bottleneck.



Rubywand