home bbs files messages ]

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