Re: Working, slowly, on a BASIC.SYSTEM clone of sorts

["Michael J. Mahon" <mjmahon@aol.com>]

Lyrical Nanoha wrote:
> On Sun, 4 Dec 2005, Michael J. Mahon wrote:
>
> > Lyrical Nanoha wrote:
> >
> > > I've thought of trying to cruft together a BASIC.SYSTEM replacement, 
> > > but I'm not very familiar with any of what I'm doing.  Oh well.  
> > > Well, here's what I'm trying to do.
> > >
> > > 1. Interface more like DOS 3.3, with chr$(4) recognized even in 
> > > direct mode and ASM programs, and MAXFILES working like DOS 3.3.  
> > > Attempt to limit code size to comparable with DOS 3.3 (since most of 
> > > the OS is above $D000 anyway).  This should make DOS 3.3 programs 
> > > more compatible with it.
> >
> >
> > Do you have any examples of programs that run under DOS 3.3 that don't
> > run under ProDOS because ProDOS has more "lower 48" memory available?
>
>
> I do have programs that do not work on ProDOS.  Mainly chargens...

Actually, I meant programs that *would* have run if only ProDOS
didn't provide more available memory under $C000.  I would be
very surprised if there were any.

I rereading your post, about "limit[ing] code size to comparable with
DOS 3.3", I now realize that you mean whatever BASIC.SYSTEM replacement
you make would have to use no more low-48 memory than DOS 3.3, which
should not be difficult, since there is plenty of space available.

> > Just ignoring MAXFILES should work fine, since ProDOS allocates file
> > buffers dynamically.  Any DOS program that relies on static buffer
> > allocation will almost certainly have other OS dependencies that will
> > conflict with ProDOS.
>
>
> Maybe the programs are using DOS 3.3 entry points.  Except for $BFxx, 
> most of that memory can be used here to emulate DOS 3.3's entry points, 
> or whatever.

Any program that calls DOS directly is going to pose some serious
difficulties in any case.

> > Recognizing CHR$(4) in direct mode seems redundant, since most DOS or
> > ProDOS commands can already be typed in direct mode.
>
>
> Believe this, I tended to use that method to exec multiple commands at 
> once, though, that's only a side-effect.  Really, another effect is that 
> you can use the same DOS commands from ASM.

If you mean that you want to intercept COUT to trap DOS commands,
I understand.  That shouldn't be to difficult, since, after getting
the command in the input buffer, you can just invoke DOSCMD in ProDOS
to perform the command (assuming that it is also a ProDOS command).

> > There would also be the need to support PEEKs for file length and load
> > addresses which are different for ProDOS than for DOS.
>
>
> Can both be supported?

In principle, but the DOS addresses may be in relatively inconvenient
places for BASIC.SYSTEM.  If you're willing to reassemble it, that
could be accommodated.

> > > 2. Commands BYE, CREATE, PREFIX like BASIC.SYSTEM (replacing INIT, 
> > > INT and MON).  Also, line and filetype semantics implemented in 
> > > BASIC.SYSTEM may also need to be implemented here.  Also, add - 
> > > command.  CATALOG is CAT in BASIC.SYSTEM.
> >
> >
> > I guess I'm losing track of the objective.  Why would any extensions to
> > the DOS command set make an environment more compatible with DOS 3.3?
>
>
> These are only necessary commands to handle the extensions.  BYE isn't 
> strictly necessary nor - but they really help.
>
> > > I figure this might make some DOS 3.3 stuff easier to run on ProDOS 
> > > as PDOS.SYSTEM did RDOS.
> >
> >
> > So, would this be a kind of "hybrid" ProDOS with support for some DOS-
> > specific commands, or am I misunderstanding?
>
>
> Pretty much a BASIC.SYSTEM replacement that acts more like DOS 3.3 and 
> plays nicer with DOS 3.3-coded software.

Interesting--happy coding!

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."