Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.sys.apple2    |    Discussion about Apple II micros    |    56,720 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 56,701 of 56,720    |
|    Steve Nickolas to All    |
|    Building a better beast...er...BASIC    |
|    20 Oct 25 01:09:49    |
      From: usotsuki@buric.co              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.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca