Re: ProDOS Plus

[mdj <mdj.mdj@gmail.com>]

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.

> >> 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.

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.

<<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.

Matt