Interest in GS Applesoft compiler?

[nathan@cco.caltech.edu (Nathan Mates)]

In article <3okac8$b9t@acme.freenet.columbus.oh.us>,
Dave Althoff <dalloff@freenet.columbus.oh.us> wrote:
>Heck, I'd be happy to have a GS/OS version of BASIC.SYSTEM...to work just
>like the P8 version...er...SHOULD work (refer to my earlier vent about
>Reason #$9DBF to hate BASIC.SYSTEM) to allow me to take advantage of
>certain GS/OS features from Applesoft...specifically, access to the GS/OS
>file handling so that I can move files around through the GS/OS FST's. 
>Come to think of it, it would be BETTER than running from the Finder...

   The problem is, Applesoft programs assume they can do whatever they
darn well feel like in banks 0 & 1. They also lived in 8-bit emulation
mode.  Neither of which is true under GS/OS. Under GS/OS, programs
running in the background, like HardPressed, the HFS FST, or whatever
can reserve bank 0 space, and NOBODY is to touch those areas. Also,
what about all sorts of peeks, pokes, and calls that are done for
speed? A GS/OS program is really in a totally different environment,
and would require a ton of safety checks before each peek, poke or
call if it was to have a chance of coexisting with a jerk of a
Basic/ML program within a GS/OS system and not toast things.

   Bottom line: if this compiler project goes through, you can kiss
BASIC.SYSTEM, ProDOS 8 calls, and probably most 8-bit ML progies in
bank 0 (this includes & calls) unless they're rewritten. I'm doing
this for fun, not an attempt to perfectly emulate some space where you
could do whatever you felt like.


>ex:  From the Finder, if you have an Applesoft program living on an HFS or
>DOS 3.3 disk, you cannot run it directly because P8 must be loaded first. 
>But if you're already running in the BASIC shell, then there is no reason
>that GS/OS couldn't load the program directly!

   Why not just compile it into a GS/OS 16-bit app that follows the
rules, runs faster, and the like. Stuff BASIC.SYSTEM. It's a darn
good thing that there is no such thing as a GS/OS BASIC.SYSTEM; it'd
have to do cartwheels up the wazoo to run the simplest of programs
without toasting your computer.


>A GS/OS compiler would be nice, I'll admit.  'Course, I have a DOS 3.3
>compiler, and since Applesoft programs don't take advantage of 65816
>features, one could just compile under 8-bit, then use that compiled code
>(and libraries) as a starting point for creating GS/OS friendly code. 
>As for display modes, I'd just use the lo-res, HGR, DHR, and text screens
>rather than trying to emulate it all in SHR.  I mean, there is a reason
>why all that stuff is available directly on the GS, right? 8-)

  The problem is bank 0/1 space, mostly running out of it. In a
standalone GS/OS app, you can usually snag 00/2000.3FFF for HGR
1/2. But, since bank 0 is prime real estate for every program's
dp/stack area, getting it consistently might be asking way too
much. For example, I just booted into GNO. The kernel eats DP space
from 00/0800.1100, (text page 2, in case anyone bothers to use it)
initd 2 pages at 1600, and HardPressed 4 pages at 1800. NL grabbed
some at 2000, the start of free pages. After logging in, the shell ate
2400.2C00. Yeah, GNO eats up a chunk of bank 0, and unfortunately the
MMgr allocates from 0800 up, not 9500 down. I will be developing this
under GS/OS, and for now, it's far simpler to translate Hires graphics
calls into QDII calls. The colors and pixel sizes would most likely
get munged, but that'll work as a first solution. If you want to
deal with putting use of the HGR screen into my compiler, you can
write the code yourself.

   Another problem with DHR is that Applesoft doesn't have built-in
support for it, so you you normally have to load in your own ML
routines at wherever you compiled them to. What if your code wants
00/9500 up, which got eaten by the HFS fst, Loader and GS/OS. You're
SOL. Oh yeah-- I wasn't even planning to even attempt DHR; Applesoft
(which is what my project is, initially) doesn't even touch it either.

   From your other rants against Basic.System, you want to be able
to do Dos 3.3 stuff (aka take over the system, do whatever you want)
under ProDOS, including ML stuff. GS/OS and everything eat large
chunks of bank 0; if you think you could just link in your commands
("Patch out chrget and other system vectors" or patch up basic.system)
from within a GS/OS compiled system, you're highly mistaken as to
the nature of GS/OS, compilers, and the like.

   A compiler is not the same as a 16-bit GS/OS version of
BASIC.SYSTEM.  Sorry if I keep bashing this point in your face, but
this is planned to be a compiler for purely _Applesoft_ programs, not
Applesoft + whatever you darn feel like under Dos 3.3/ProDOS.  GS/OS
and 16-bit stuff in general put enough limitations on the system that
the free reign of Apple II "The lower 128K is MINE! I'll stomp all
over anything I darn well please" is a distant memory of our youth.

Nathan Mates
-- 
<*> Nathan Mates http://www.ugcs.caltech.edu/~nathan/      <*>
# And he said to them, "To you has been given the secret of the
# Kingdom of God, but for those outside, everything comes in 
# parables" Mark 4:11, NRSV