Re: Hacking on Integer Basic, and ProDOS

["mspangler" <mspangler@gemsi.com>]

Basic system makes external calls to Applesoft for some functions.
Specifically, D43F, D61A, D665, D7D2,D820, D865, ED24, and F273.
Although you could certainly recycle some useful sections of code from
Basic.system to reuse for  Integer.System, I think it would work better
and end up smaller to do the Integer.system as a combined
language/system file. You might be able to put the language in the aux
memory language card area, and use the main Ram portion of the
interpreter to bankswitch between the language and the MLI, similarly
to the way Basic.system switches between Rom and the MLI. It would
depend on how much you needed the main Ram space. How big an integer
basic program  do you need to support?

By the way,, according to my IIe tech manual, Integer and Prodos would
collide only on zero page locations $4A through $4D, which are
supposedly used by Dos 3.3 as well. It looks like DOS 3.3 actually has
more potential conflicts with Integer Basic than Prodos would have.

Your project is way beyond my skill level, but sounds like fun. Given
that both Applesoft and Integer were built for the cassette
environment, they could both have benefited from an overhaul that
assumed DOS as standard. A lot less furious swapping of the input
/output hooks would have been needed.

Mike S.


Moll wrote:
>
> Having BASIC.SYSTEM already in RAM would deal with a lot of this, I
think.
>
> The disk image I linked to has a 22-sector (so, about 6K) B file
called
> INT.  It doesn't need the language card, it sits right in the 48K
area.
>   So it's prolly relocated. That solves one problem.  I've mentioned
the
> other problem, INTBASIC stepping on ProDOS ZP globals.  A little
hacking
> should fix that.
>
> Then, there's the question of interfacing it to the running
> BASIC.SYSTEM.  That would be the biggest challenge, I think.
> 
> Moll.