Groups | Search | Server Info | Login | Register
Groups > comp.sys.apple2 > #49221
| 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) |
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
Building a better beast...er...BASIC Steve Nickolas <usotsuki@buric.co> - 2025-10-20 01:09 -0400
csiph-web