[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interest in GS Applesoft compiler?



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 addume they can do whatever they
darn well feel like on bank 0. 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 one if it was to
have a chance of coexisting a jerk of a Basic/ML program with 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
(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.


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

   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.

   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