From Newsgroup: comp.sys.apple2

I'm just thinking about this right now, because I don't know how well I'll
be able to pull it off.

For the Z80 and the 8086, Microsoft produced a far more advanced version
of BASIC than the 6502 version that FPBASIC was based on. This is
available, for example, on the Apple ][ port of CP/M, though it's a bit finicky.

I thought about the idea of translating the Z80 code for MBASIC 5.2 to
either 65SC02 (for an Enhanced Apple //e) or 65816 (for an Apple IIgs), to
run in the ProDOS-8 or GS/OS environment as a replacement for FPBASIC.
And then I got to thinking...

1. MBASIC is 24K large on a Z80. If both the HGR screen buffers are
reserved, then a //e would probably need the entirety of conventional
memory just for code; the program and variable data would need to be
entirely stored in AUXMEM.

2. And even AUXMEM could be constrained, if the DHGR screen buffers are
_also_ reserved. At most, you would be getting about 24K of program
memory, which is pretty tight, especially on a 128K machine. (Make that
40 if DHGR isn't needed, and 56 if HGR isn't needed.) Additionally, a
memory pager would be necessary to work around the fact that most of the program is NOT in the same memory bank as the user memory. (This assumes
that AUXLC memory is not available; that may free up as much as 16K
additional memory.)

3. Either way, it's not going to be as simple as "copy the kernel file and
one SYS file to a target disk" to make a turnkey system, as it is for
FPBASIC. It's gonna need to load itself in stages. That said, it could probably be simplified to two files - the loader and the actual content -
and the loader could relocate itself then pull in the pieces any way it
has to.

4. System-specific stuff... I'd like to be able to function as a "GW-BASIC
for Apple", but I'm not sure how well that could be done.

This may not be a simple one-person job...

-uso.
--- Synchronet 3.21a-Linux NewsLink 1.2