Re: You guys are NUTS !

[Rubywand <rubywand@swbell.net>]

Phoenyx writes ...
> 
> Well, it's a given that if this were to become a reality, the system
> would have to diverge. So eventually compatibility would not be as
> important as it would in the beginning.

     GS System is something of a patched together kludge. One reason for
starting with 'just' a very good monitor is to allow development and thorough
documentation of System software which gets the most from a relatively
straight-forward hardware design.

 
> Primary concern here is the ability to grow and expand in both the
> hardware and software. I like GS/OS. It is a very simple design which
> other GUI systems should take a lesson from.

     You can see the very raw beginnings of GS/OS in the Commodore 64. The
basic design philosophy shows up everywhere today. It is one which tends to
look a lot better that it works.

     Modern speed and memory allow a less weighty approach. That is, you have
a reasonably simple System and require that applications bring in most of the
smarts for whatever they do. The result would be easier, more efficient,
software design, better execution speed, easier debugging, and a system much
easier to protect from viruses and hackers.

     None of which means that GS/OS will not re-emerge in the new machine. If
users want it, someone will offer it.


> Yet I would like to see
> some improvements, for instance, a little more leniency with filenames.
> I would like them to be longer and accept a broader range of characters.
> I think 'virtual memory' should be used also, and maybe multi-tasking
> interrupt signal.

     Multi-tasking is an interesting issue. For one thing, "tasks" differ
greatly in terms of system resources required and whether or not they
actually need to run when in the "background". One approach is to just give
each always-running task its own processor and chunk of memory. The more Alt
Processor modules you plug in, the more full-speed multi-tasking you can do.


> Someone mentioned the programmable CPU which was what I had on my
> mind at the time. I would also like to see PCI slots.

     There have been a couple of interesting posts about programmable logic
array and other kinds of programmable IC's for possibly implementing a fast
CPU.

     Having PCI-compatible Slots is a good idea. I don't know exactly how we
would interface with current video, sound, and disk controller cards; but,
for sure, the first step is being able to plug them in.

 
> With the FST method which GS/OS uses, GB drives are already a fact.
> Unfortunately, it is still limited.  But I suppose you meant P8. In
> which case it would have to be completely re-written, too much trouble
> IMHO.
 ....

     Seems like I recall reading that GS/OS is limited to 4GB volumes-- much
better than 32MB but still too small for the long term.

     ProDOS itself would be reasonably easy to rewrite for larger block
sizes, more blocks, larger files, and very large volumes. The major snag on
the IIgs is that GS/OS wants to use a File System Translator. The FST for
ProDOS seems to be complicated by including calls to ProDOS-16.



Rubywand