Re: ProDOS Plus

Michael J. Mahon wrote:

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

I could imagine a 128k OS. Much of the kernel code could run from the aux 64k utilizing it's own stack and page 0 as well. However, since it's already limiting the user base one might also want to require an accelerated CPU as well.

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.

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.

Not to make light of your incredible projects, intelligence and talent but realistically, how practical are your recent projects outside of the II environment? Now, how practical are they in the II environment other than to yourself and what would you estimate the user base to be? They are useful to you for the purposes you made them for but they are constrained to a limited user base of a classic computer environment. Practicality really isn't the issue whether you concede the point or not.

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

Hmmm and I thought I had problems. :)

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.

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.

But that is the whole point of the exercise. It's been said it couldn't be done but with the right developers and intelligent, well thought out design, the II is capable of some incredible things.

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.

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.

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.

Now you're thinking in the right direction. If a few more 8 bit guru's chip in there's no telling how much could be done on such a project.

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.

Agreed but ideas must be bandied about to kick loose the bits and pieces required to decide on which features are really important for the project.

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.

Considering the number of II users, wide usage isn't a consideration in most instances. IMHO, one great application could make the efforts worthwhile be it gaming, porting newer development systems or an Internet capable environment. I can think of a great number of things which were considered impractical when first created yet someone still made them.

Given that I hope to use my II systems longer than any PC I own plus the shorter lifetimes for most PC software, the useful lifetime I expect for II software is longer than it would be for other computers. This offers some possibilities that other II enthusiasts might consider when deciding about creating applications and extensions as well.

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.

And you play your part well. Quite often you get folks thinking about things being too difficult or even impossible and later on give ideas on how things might actually be possible. Take the issue of adapting for modern monitors. I recall you originally said it would not be worth the difficulty involved (not an exact quote) yet more recently you have mentioned several possibilities for developing just such an item.

Your intelligence and pragmatic insight are well used and well appreciated.

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.

Yet another purpose for discussions. Knowledge and development of skills are always a worthy goal.

If nothing else comes out of this discussion, I have enjoyed it immensely.

Cheers,
Mike T
.

Relevant Pages

  • Re: ProDOS Plus
    ... operating system was not considered worth the problems when it was just as easy to make the applications support 128k or more ram. ... 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. ... the OS could fit in *only* the space that ProDOS now occupies. ... if practicality were a concern we probably wouldn't be using old hardware. ...
    (comp.sys.apple2)
  • Re: File extensions and application associations ?
    ... that describes possible applications for each file extension/type? ... combination of extension, filetype and creator. ... text editor when I double click on a .PS file for instance. ... A possible solution is the use of aliases, dock icons or third party ...
    (comp.sys.mac.apps)
  • Re: A theorem cant be wrong
    ... > Is that all that matters then, practicality? ... *because* it is true and pure math and it has no applications. ... The pure mathematician doesn't care about applications. ... Esthetics, you may say, is subjective. ...
    (sci.math)
  • Modifying the "Open with..." list
    ... Clicking with the "ctrl" key offers a list of applications to open a given file type, presumably according to its extension. ... With picture files, you get an incredibly long list including totally useless options courtesy Adobe, such as "constrain to 64 pixels.exe" or "makebutton.exe" whilst I would like to get only the main options, i.e. GraphicConverter, Photoshop and few others. ...
    (comp.sys.mac.system)
  • Re: Proposal for a new PKI model (At least I hope its new)
    ... Bryan Olson writes: ... >extension. ... See RFC 3280. ... applications. ...
    (sci.crypt)
Loading