Re: ProDOS Plus

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.

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.

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.

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.

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.

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.

The problem is that it might take a long time with the community
at its current population and level of adventurousness to get
reasonable coverage of the application space.

One can only hope that others would consider this type of project worthwhile and participate but I tend to be an optimist. However, as you say, the size of the II community is the larger problem.

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.

Overcoming the implementation obstacle is just one input the the
"and gate"--a major remaining obstacle for any code that must handle
as many cases as an OS is ensuring that it is sufficiently reliable.

The combinatorics of an OS are such that testing is a very weak
strategy. Widespread use in many applications over a period of time
is the way that virtually all complex systems are brought to an
acceptable state of reliability. I'm concerned that the level of
acceptance and activity in the current Apple II community is marginal
for getting there.

One way to mitigate this would be to build a test scaffold to compare
intermediate states (as signatures) of the "new" ProDOS with the same
state signatures for the existing ProDOS. This would improve the
efficiency of "certification" testing of existing functionality by many
orders of magnitude.

Any new functionality would still be subject to less efficient testing
(and this is a good reason to limit the new functionality).

One step at a time. :)

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.

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.

Unless we (miraculously) get proactive in programming, and introduce
others to the joys of programming on the Apple II platform, I see no
reason to hope for the situation to change.

Maybe when more Boomers start to retire... ;-)

Now there's a thought. :)

Yes, I have a very strong aesthetic issue with using a cannon to kill
a mouse, and am always looking for simple solutions to simple problems,
or, even better, simple solutions to complex problems!

It has always set off alarms for me when complex solutions to simple
problems are proposed.

More of us could use such a trait.

Cheers,
Mike T
.

Relevant Pages

  • Re: [PATCH] adding two new options to cp
    ... Linux, I can download and install a copy. ... I detest Windows because the developers treat the ... This is a really funny reason not to. ... already created shell code to make this functionality easily available ...
    (freebsd-hackers)
  • Re: jQuery vs. My Library
    ... Web developers are copying bad ideas and practices and doing what they're told by managers who do not have any business to do the telling. ... most sites nowadays don't require javascript, but are authored in such a way that if the user has javascript turned off, then the site does function. ... No matter what project, if the project involves writing rich functionality in the browser, then there is going to be a need to write javascript functionality and that functionality will be best organized into abstractions. ...
    (comp.lang.javascript)
  • Re: Is there a "Large Scale Python Software Design" ?
    ... perspective - what functionality the application provides & its scope. ... million lines of code (all C++ & about 60-70 developers), ... different custom servers, a full web-based administrative interface, an end-user ... I've found that competitors in our same space tend to have ...
    (comp.lang.python)
  • Re: Lennart Poettering: BSD Isnt Relevant Anymore
    ... see accessing standards for SCSI ... products implementing them, prohibit developers using them, ... Giving that functionality to the ... FreeBSD users. ...
    (freebsd-questions)
  • Re: Existing forms to PDF or Excel
    ... It's a valid opinion. ... developers that have the same opinion. ... but basically, shoddiness comes to mind often, as well as the fact ... things offered for which "public accpetance" was far from the reason ...
    (comp.databases.pick)