Xref: utzoo comp.sys.apple:23796 comp.sys.apple2:317
Path: utzoo!attcan!uunet!cs.utexas.edu!usc!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple,comp.sys.apple2
Subject: Re: GS (What you want _requires_ moving closer to the Amiga...)
Message-ID: <1990Mar21.134215.21944@spectre.ccsf.caltech.edu>
Date: 21 Mar 90 13:42:15 GMT
References: <90030820242943@masnet.uucp> <1990Mar9.205605.2836@spectre.ccsf.caltech.edu> <1160.2600f4c1@miavx1.acs.muohio.edu> <1990Mar17.122507.18534@spectre.ccsf.caltech.edu> <1162.2603c187@miavx1.acs.muohio.edu> <1990Mar19.114428.19230@spectre.ccsf.cal <1166.26066
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 79

jwwalden@miavx1.acs.muohio.edu (Darc Tangent) writes:

[ on the value and convenience of a built-in Basic ]

>    I felt that way at first when I first used another machine regularly after
>using my Apple II+, but I hate BASIC so much and it's difficult to put a C
>compiler in ROM (and certainly to keep it up to date - I want a C++ compiler!
>(currently cannot afford one)).

I can understand that. I happen to like Basic, because in its own ways it is
as compact and elegant as C. The way boolean expressions are handled has
allowed me to often do in one line of Basic something that would take quite
a bit of code in Pascal (or even C). The fact that it is interpreted is what
I value the most; if it were possible to put a C interpreter in ROM I would
use that instead. A properly updated Basic that was native to the GS would be
unbeatable for quickie desktop programming and would open up the machine to a
new generation of hackers.

>   I do like the monitor, but don't really feel it to be a necessity if I
>have another software tool that will do the same thing without the ability to
>mess around before you reboot (it is nice though).

Unfortunately when the full O/S is up and running a monitor-style environment
is risky at best. I got used to this fact and found that the //e compatibility
box in the GS made an excellent compromise. (You run a Prodos program and it
allocates the lower 128K exclusively for your use, minus the memory reserved
for Prodos. When you only need the low 48K as I usually do it works great.)
After I get my algorithms (Bresenham's, LZW for a giffer, and rapid fill mode
drawing is what I'm working on right now) debugged in this 'cradle' environment
I can throw them into more serious programs and spend almost no time debugging
when debugging really hurts.

>> Ah well, it's spring break at Caltech so guess what I'll be doing.

>   Building an Apple IIf in your garage?  :-)

I wish. Got a CAD workstation I can design gate arrays on?

>   To expand the original topic, do you think the Apple IIGS would have been
>better if it had been built with a 68000 procesor, with a 6502/AppleII
>coprocessor board?  That is what I wanted with the GS - being free from prior
>systems as much as possible helps greatly in how far you can go.

Ouch! Don't ask me this one. I personally don't like working in 68K assembler
and Apple assembly is what I like most about the machine. Such as, mere mortals
can remember the entire instruction set and even some of the opcodes!
(No flames please, I'm biased and I admit it.)

The GS was actually very free 'from prior systems', in everything that was
specific to it. It's just the gate array implementation that, for non-technical
reasons, was forced to handle the compatibility issue in a very inappropriate
and performance-sapping manner. I.E. they wanted to scrap the Mega II and do
it properly but management wouldn't let them -- budget, probably.

Apple also took care to warn everybody to use the toolbox, and "use a read-
modify-write sequence when modifying this byte" and so on.

The 65816 was, for all its "faults", very well designed from a software
perspective. Relocatable code was painless if not trivial. Software
emulation of 65832 opcodes should be fairly easy to do (compiler switch at
worst) and CPU improvements dealing with on-chip caching and pipeling of
direct page & stack would largely address the need for more registers. I agree
more modular programming functions would be a good idea (like a stack crash
detector that doesn't require a PMMU!!) but what we have now is adequate for
GS/OS. It just needs to run faster.

After seeing a Transwarped GS running finder I'm convinced that the 65816 isn't
what was lacking at all -- it was Mensch an his inability to get the damn mask
working at higher speeds.

Having a 68000 w/ a 6502 card would have costed far more than having one 65816,
especially after all the extra circuitry gets figured in. For that reason
alone I am glad they did it the way they did.

I just wish Apple had shoved a poker up Mensch's rear end years ago so
we wouldn't have any reason to be discussing the question!!

Todd Whitesel
toddpw @ tybalt.caltech.edu