Groups | Search | Server Info | Login | Register


Groups > comp.sys.apple2 > #49221

Building a better beast...er...BASIC

From Steve Nickolas <usotsuki@buric.co>
Newsgroups comp.sys.apple2
Subject Building a better beast...er...BASIC
Date 2025-10-20 01:09 -0400
Organization A noiseless patient Spider
Message-ID <alpine.DEB.2.21.2510200057360.17410@sd-119843.dedibox.fr> (permalink)

Show all headers | View raw


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.

Back to comp.sys.apple2 | Previous | Next | Find similar


Thread

Building a better beast...er...BASIC Steve Nickolas <usotsuki@buric.co> - 2025-10-20 01:09 -0400

csiph-web