Re: ProDOS Plus

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

On Jul 1, 5:03 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

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

I agree. I'm just having a bit of trouble finding the 'seed thought'
of what these operations would be that provided enough compaction to
justify it. In the general p-Machine case, you've got the entire
semantic model of a high level language to work with. Were ProDOS
written in a high level language and compiled I'd agree, there's a lot
of room for shrinkage. However, it's hand coded, so a lot of the
redundancy and indirection caused by higher level languages just isn't
going to be there.

I fear that there's few enough cases that hand tuned machine code that
uses subroutines intelligently will probably end up being smaller. As
we all know, hand-crafted low level code can produce glorious cut
gems, and given the number of revisions ProDOS has had, it seems
unlikely there's a rich field of rough diamond to work with.

I would *love* to be proven wrong on this ...

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

Only third-party Ramdisk drivers, for example the ones provided for
the RamWorks. I also expect that the caching utility that comes with
ProSEL also hides in there, but I've not done the investigation to
confirm this.

Not the whole of bank 2 is 'reserved' for such use, but it is reserved
in *all* cases, and isn't used by any other part of ProDOS.

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

Agreed!

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

Yes. I think the decision to leave it as such and just establish
simple conventions for the other bank probably resulted in a lot more
available memory to programs than if they'd decided to make memory
management an OS level function.

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

This is why systems built from simpler layers have greater longevity
than those that don't - the layered approach permits many limitations
to be engineered out without a codebase revolution.

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

:-) very true.

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

Unix (in the broad sense of the term) is a great example of this. Code
written for a 1990-era box likely won't run on todays boxes without a
few modifications here and there to the source but are usually minor.
But great revolutions that sacrificed majority source level
compatibility have never been required since the whole system is a
taxonomy of KISS solutions.

Matt