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

Re: ProDOS Plus

BluPhoenyx wrote:

Michael J. Mahon wrote:
Yes but... The 2gs supports HFS so it would likely be required for access to such devices. As a separate OS, it would need to access common usable media. 


My feeling is that anyone who chooses to routinely use a IIgs file
system should have a IIgs.  The IIgs has fine "links" to the 8-bit
Apple II's and ProDOS.
But what if said person wanted to run the OS on a GS as an alternative to GSOS? I've been know to run a variety of operating systems on practically every computer I've owned or maintained. A 128k OS would be limited but there are still possibilities.
Probably one of the most important issues. I'm sure 64k P8 programs could be executed if the system were designed for it. Likewise a number of binary programs could probably be run as well. There would be a lot of problems trying to use many current P8 system applications. 


Which would doom it to being a curiosity.
It was a doomed idea from the beginning. Even back in the day, a 128k operating system was not considered worth the problems when it was just as easy to make the applications support 128k or more ram. 

I don't think it should be a "128K" system...
One reason why I posted a new thread. We II users, at least some of us, still like to dream about the possibilities even if they never come true.
Back in the day, when I got the Zram for my 2c I often wondered how feasible it would be to make an OS which used it. Not that I had the skills to actually do so. 


I have no problem with dreaming, but it does seem to bring out the
kind of "free association" that never results in anything practical.
...Like the approximately annual "Apple II+++++" discussion.  ;-(
Yeah, I recall a few what if dreams discussions. Still this one now has it's own thread now. Besides, if practicality were a concern we probably wouldn't be using old hardware. For me this is a hobby or more precisely a diversion. 

Not at all.  Practicality is an absolute requirement for me.

The Apple II is a wonderful resource-constrained programming platform,
and I take no joy in fantasy that cannot be reduced to practice.

One of the greatest joys is imagining something that *seems* impossible,
then finding a way to *do* it.  But constraints are real, and there
are proveably impossible things, given those constraints.

Perhaps ProDOS and several filesystems could be coded and run
interpretively, like P-code, to get more code into the current
memory profile.  If this could be done, it would probably come
at the cost of speed, but it would be interesting.

Compatiblitiy is possible using this approach, since, unlike
DOS 3.3, there was little motivation, and even less facilitation,
for writing code dependent on internal entry points in ProDOS.

In the 1960s, a small company called Digitek wrote compilers for
small machines that were incredibly tiny and fast.  They used an
interpretive platform together with an implementation technique that
allowed any code path to be 1) fully interpretive, 2) fast procedure
call to "execute" routine, or 3) in-line macro expansion.

Using 2) was 2x-3x times faster than 1), and 3) was 10x faster than
1), but the space required for the various strategies was roughly
similar to the speed ratios.  The vast majority of the compiler had
to be run in mode 1) if it was to have any chance of fitting in
memory--which it had to do to remain fast, since overlays would
kill the speed.

They never wrote a compiler that wouldn't fit in half the memory
of the targer machine, because a critical phase in development was
to use the top half of memory to hold the execution profile of
the compiler.  This frequency data was used to select which of the
three code strategies was most appropriate for each "instruction".

The resulting tuned compilers were marvels that blew the doors off
of the competition until a few figured out how it was done.

IBM contracted with them to write the FORTRAN compiler for the
"F-level" (64KB) System 360's, but when they delivered it, it ran so
much faster than the "G-level" (128KB) compiler written by IBM that
it replaced it!  The IBM compiler team was briefly humbled, and
part of their revenge was to force Digitek to emit the specially
designed 360 DO loop closing instruction, BXLE, even though their
more conventional code generation was actually more efficient!

In any case, it always seemed to me that the technique should be
nicely applicable to an OS, since 90%+ of the time spent in an OS
is in 10% or less of the code, and so much OS code is error recovery
code with a frequency of essentially zero.

It shouldn't be hard to put the error recovery and reporting, exception
handling, initialization, and other low-frequency code into a very
compact, highly interpretive form, leaving only the frequently executed
parts as in-line executable code.

I've wanted to try this experiment for many years, but could never
convince the "powers that be", and have never seen a system that used
this approach.

Properly done, it would call for designing a "virtual machine" that
is particularly adept at doing the things that OS code does, just as
the Digitek interpreter was specialized to recursive-descent compiling.
In reality, P8 got it pretty accurate as the OS kernel. I think of the system as a group of compatible OS's where each system application is actually the rest of the OS.
Of course I also like the old adage, I can boot my Apple II into whatever I want it to be. 


Absolutely--but it would be nice not to be alone.  ;-)
Aww, I'm generally alone anyhow. I seem to be a bit anti-social. :) Probably a personality disorder.
However, my point was I still like being able to boot into Dos 3.x, Apple Pascal or P8 floppies and tend to use the large media devices for storage and maintenance of said floppies. 

Sure--so do I.  But I doubt that such a multi-filesystem OS can be
produced for 8-bit Apples while maintaining backward compatibility
unless some radical approach (see above) is taken.  The memory map
of the Apple II, including AUX mem, is too open to "squatting" to be
able to evict everyone at this late date.

Any practical extension will have to fit within the memory envelope
of the current ProDOS.  That's one reason that multi-filesystems
implemented in conventional ways don't compute for me.  And if they
require a large amount of buffer space, then I don't see any practical
way to implement them.


We are too late in the "life cycle" to roll out an OS that isn't
100% backward-compatible with the previous OS.
I don't think any OS has ever maintained 100% compatibility with previous versions. In my experience this has never been the case. Of course said experience is limited to the Apple2 and the PC and compatibles over the past 23 years. 

It's not necessary to maintain full compatibility while a system is
still on the upswing--new applications are being written, new systems
are being sold, and the motivation is there to achieve critical mass
on a new OS that offers functional advantages.

But I think you will agree that we are no longer in that situation
with the Apple II.  Now, compatibility is a must if there is to be
any hope of sufficient applications for (relatively) wide use.
It is still an interesting discussion of ideas and whether these things bear fruit or not they usually spark an idea in someones mind. Occasionally, these ideas are pretty good too. 

I play both top-down and bottom-up:  grand visions and incremental
extension.  But given the constraints outlined above, I think that
the incremental extension route is currently the most viable one for
ProDOS.

More concretely, small changes to compact the existing code enough
to allow extensions like "parent" in pathnames would be a very good,
100% compatible, and relatively doable extension.

If people liked it, it would provide both the learning and the
encouragement to proceed with other incremental extensions.

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