Re: ProDOS Plus

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

mdj wrote:
> On Jul 1, 7:13 am, BluPhoenyx <bluphoe...@earthlink.net> wrote:
>
> > > Indeed, and I've already suggested a way of possibly satisfying the
> > > extermemly important memory constraint without too much compromise on
> > > the necessarily limited performance:
> >
> > Is interpretation of the OS practical on a 1 mhz cpu? I'm sure an
> > accelerated system would run fine but if acceleration is required to
> > ensure usability then hardware compatibility is lost.
> >
> > It is an interesting idea considering how much of the OS is actually
> > used in any given application. I would love to hear more of your ideas
> > in this regard.
>
>
> It's most certainly practical. Indeed, Apple Pascal is an
> implementation of such an idea, albeit without the optimisation phase.
>
> It should be noted however that Apple Pascal manages to use the entire
> language card and then some to provide a pseudo-machine plus an
> operating system that is considerably less sophisticated that ProDOS.

But the P-code interpreter is fully general-purpose, and relatively
low in semantic level.  Perhaps one could do much better for the
primitive operations of an OS, which need not be general purpose
at all.  For example, a single page could hold all the parameters,
variables, and pointers needed by the system.  A single operation
could gather all the parameters of a system call into the data area,
etc.

As a result, only a few bits would be needed to specify most operands,
and the operations could be quite semantically rich.  The question is
how much of the "test a bit/clear a field" code could be dealt with
in this way.

> > > > Now see, you're already coming up with ideas on workable
> > > > possibilities. This sounds like a rather likely possibility for a 8
> > > > bit P8 replacement or possible patch based update. If the interpreter
> > > > code were tight enough there might be enough reclaimable space in the
> > > > current P8 memory usage. That unused space in the aux 16k $d000 area
> > > > and perhaps removing the built in /ram driver if necessary. Well you
> > > > get the idea.
> >
> > > Are you sure that space is free?  How many applications have had the
> > > same thought?  The only thing we know "for sure" is that the currently
> > > occupied space is available.  (And not even all of that, since the
> > > _de jure_ space for a clock driver is actually smaller than the _de
> > > facto_ space--I know, because I have an outsize clock driver that
> > > has worked well for many years!)
> >
> > Probably not. At least not in a 100% compatible environment. However,
> > 100% compatibility may not be attainable in any case. This might depend
> > on how many application developers actually followed Apple's guidelines
> > regarding ProDOS.
>
>
> There's an established protocol for Auxiliary memory usage. Some
> limited testing that I did recently revealed that there really aren't
> any "128k" Applications that don't use some of the aux language card.
>
> The established protocol is this: If at application initialisation
> time /RAM is connected, you are free to use the whole Aux memory area,
> sans a small block in Aux. Language card bank 2 which is used by third
> party drivers. Fortunately, I found that applications tend to respect
> this barrier, so there's a whole 4K of useable RAM there.

Cool.  So there were never any third-party drivers?

> If /RAM is disconnected, you are theoretically not allowed to use the
> Language card at all. Anecdotal testing reveals most of the
> 'interesting' applications will either refuse to start, ask for
> permission to start, or ignore this recommendation.
>
> It really *is* a no-go zone. At a minimum, depending on this area will
> make it impossible to run AppleWorks or Merlin 8. Since these are holy
> applications to either the Apple II user community, developer
> community or both, it's a non-starter.
>
> I really feel it's a non sequitur to imagine a "turbo ProDOS 8" that
> really only power users are going to be interested in, and then set
> the hardware requirements to that of a stock Apple II. I would think
> that anyone interested in this project is going to have a RamWorks or
> similar card, or at the least, be prepared to source one in order to
> be involved.
>
> ProDOS 8 does a pretty good job of exploiting the 128k Apple II
> platform, and there's little functionality you can practically add to
> it within those constraints, with the exception of a couple of small
> behavioral mods to remove some limitations.

It might be good to deal with those mods first.  ;-)

And ProDOS is really a 64K OS--128K is optional.

> <<snip>>
>
> > > I agree, but note that there is not even a "steady trickle" of new
> > > software for our platforms that is intended for general use.
> >
> > Perhaps just as bad is the inability to extend existing application
> > functionality. Maintenance is an often overlooked process in software
> > development. I'm guilty of this myself as I often get occupied with yet
> > another project or some other task. Perhaps that is the difference in a
> > 'hack' like myself and real programmers.
>
>
> Overlooking maintenance has caused a lot of bad ideas to be
> implemented, then depended on, only to become financial/productivity/
> growth issues. This is *the* biggest recurring nasty surprise in the
> software development industry.

The chain of temporal dependencies between levels of developers and
users almost *guarantees* that problems found will be worked around,
often in regrettable ways.  Most developers are unwilling to hold up
their money-making application until the OS or library guys fix a
problem properly.

At some point, one must acknowledge an unchangeable property of the
meta-system, and find ways to live with what will not change.  Kludges
are forever.  So it goes.

Once in a great while, it used to be possible to start over, "knowing
what we know now", and correct (many) system design problems.  I know
that is still the case, but the time constant may be much longer.

I once heard the British software engineer Brian Randell say of such
a situation, "The theory of evolution, not revolution, is actually a
theory of fewer and bloodier revolutions."

Eventually, we will be running systems that will not run any of the
code we are running today, but the capabilities of that system may
still be shaped by the limitations we forged today.

"New axe head, new axe handle--same axe."

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

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