[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ProDOS Plus

BluPhoenyx wrote:

Michael J. Mahon wrote:
However, I understand your advocation of a reworked and/or patched version of the existing system. For one thing, it would be easier to actually accomplish something useful. New OS development could take quite a while to develop properly. Also, your suggested P-code system could do something similar by running in the aux 64k memory range $D000...FFFF or perhaps the aux ram used by the P8 /ram driver code space. Another option would be an overlay type system where seldom used code could be loaded as required. Possibilities abound. 


The idea was to use interpretation to shrink the code so that *all* of
the OS could fit in *only* the space that ProDOS now occupies.  Anything
else fails the application compatibility test.
Wouldn't some of the OS such as low-level driver code require machine language coding? But yes, I understand the implication regarding memory footprint. One of a number of possible contentions that must be considered. 

Much of the ProDOS "RWTS" would certainly have to be machine code, since
it is timing critical.  But virtually everything else can run at almost
any speed, and most of ProDOS is never used by any one application.


I meant "practicality" in the context of an Apple enthusiast, not in
the context of "real-world" computing.
Well that certainly limits things but I think it would be a subjective matter based on the enthusiast's enthusiasm level. 

My test is quite simple--can it be reduced to practice?
I wouldn't call it fantasy. A lot of great inventions started out in a similar fashion. Just because we are focusing on a resource-constrained environment for a limited user base doesn't detract from the possibilities. It simply adds more challenge for the developers. 


I don't disagree as much as you think, as my next quoted paragraph makes
clear.  But I'm also quite aware of the need to calibrate the difficulty
of a task within the range that constitutes an "interesting challenge",
as opposed to either "too easy" or "too hard".  (And I do appreciate
that different people have different thresholds.)

Put another way, many years of experience have caused me to develop a
sense of when a project is in danger of becoming overblown, which is
a sure sign that it will never happen.



Another reason your input is so valuable to the II community.


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. 

Properly applied, interpretation only slows down infrequent paths,
so the actual user-perceived performance impact can be quite low--
particularly since interpretation "gives back" RAM that can be used
to speed up overall functioning (or to add more functionality).
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. 

Some profiling of ProDOS while running typical apps would be very
helpful in assessing what needs to be fast and what doesn't.  Of course,
that profile will differ from application to application, but if there
is a substantial commonality, it can be statically exploited.

The ultimate way of tuning this approach to a *variable* profile
(a result of running different loads) is an adaptive approach in
which an interpretive routine counts its executions and at some
threshold, it swaps in a less-interpretive version of itself.

To complete the picture, the less-interpretive routines also count
their frequencies, and if they drop below a threshold, they swap
in the more-interpretive version of themselves.

Taken to the limit, this is profile-driven dynamic optimization with
code caching, but that approach seems impractical for an Apple II OS.
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. 

Certainly lots more than followed them for DOS!  ;-)

There's a real advantage to providing an "official" way to do things
that applications frequently want to do.


A reasonable way to proceed would be to create a slightly modified
ProDOS that doesn't do much extra, but writes (and verifies that
it remains unclobbered) all the RAM that you might want to use.

You then distribute this to interested parties to use as another
"version" of ProDOS, and, after enough exercising, you will know
with reasonable probabliity just what is used and what isn't.
Incremental release is definitely the way to go. I suspect however that this type of project would be tested more by the developers than the user base. Then again, II users tend to be more system oriented so may be more willing to use the OS. 

Developers are always out in front, and are the "gatekeepers" for
the user community.  My concern is that the community of both developers
and users is no longer large enough to support a significant OS rollout.

This problem does not arise if a few incremental enhancements are made
while retaining full compatibility.  Then *anyone* can adopt it without
trouble or risk for *existing* applications.

<snip>


One step at a time. :)


Usually, but there are important exceptions when it comes to systems.

It's just as hard to regression test one change as it is to regression
test ten changes (though it's harder to localize a problem if more than
one change was made ;-).

I advocate "one change at a time" for developers, but several changes
that make a logical package for users.

The pain of updates should be minimized, and spread out months apart.
(Fixes for show-stopping bugs are another matter.)


It's true--but I must admit to lifelong impatience with "brainstorming"
as opposed to a focused design process.  Although it can be useful
in the "green field" phase, I've *almost* always found it to have too
low a signal to noise ratio (of course, that depends on the group ;-).
I would think that any reasonably complex project, hardware or software, requires some brainstorming. 

Surprisingly, in my experience they have not.  Usually a major project
arises as an "opportunity" presented by one or a few visionary designers
who have already scoped out the major issues and can demonstrate at
least plausible feasibility.  Sometimes, they even have a prototype
of the major subsystems!

This is the phase where the shape of the project is defined, and after
that, with a few exceptions, it's just "bells and whistles".

Though there is always a role for input, design is best done by a small
team of designers, not by committees involving non-designers.

Senior designers will always have internalized the needs of users (in
fact, that's what distinguishes them from junior designers), and can
fully appreciate the challenges to implementors.  Often, a new system
design will require a new implementation framework, and that will have
been foreseen by the designers, too.

In my experience, the best designers are both top-down and bottom-up,
playing off the "vision" against the "metal".  Being comfortable with
spanning all those levels of abstraction is what makes a good designer.
It's necessary to keep one's eye on the ball at every level of detail,
from years to nanoseconds.


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. 

Discipline is always scarce, at all levels.

Often we know what we *should* do, but just don't *want* to.  ;-)
(Documentation is a common casualty, which makes maintenance a
consequent casualty.)

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