From: Will Nerini <wnerini@WW1.ww-web.com>

Subject: OS, GUI and why Adam shouldn't be a doorstop.

Warning: This message is a first draft compilation of my thoughts
about Adam over the last couple of months. It's quite a tome.

   Let me state first off that I'm coming to this a a relative
neophyte.  Adam was my first computer, taught me a lot about 
assembly and it led me to a varied career writing bbses, games 
and the first "multi-media" apps. Now I write a lot of (trivial,
actually) perl and Visual Basic code. The upside is this has
allowed me to purchase Rich Lefko's entire Adam collection. This 
is a LARGE collection of hardware, software and documentation, 
over 500 pieces and over 200 pounds of stuff.  Now we know that 
I actually have a monentary investment in my words. You'll have 
to take my word for it that I have the intellectual interest. 
Just to clear up any questions about the sincerity and serious-
ness of my words. (LOONNGG WIND!)

   At this point I feel, difficulties (well understood) aside,
that the Adam can be made a platform useful to those that wish 
to use it (me for one). It would certainly be a trivial effort 
compared to the MAME project. MAME, for those who haven't seen 
it is an emulator that, with it's next release will emulate
over 240 classic arcade games. This with about 80 programmers 
working on 5 CPU emulators,  3 or 4 Sound chip emulators, and 
a myriad of video and memory hardware. 

  Certainly with the (2-4?) programmers that can be rounded up
here, we can create a new, open architecture?  Let me give a
vague outline of my ideas. Much of this will echo comments made 
by Richard and others on this list.  Suffice to say I will 
gladly incorporate any good suggestion into my (personal)
Adam-schaung. These thoughts are nebulous at best and somewhat 
un-organized but I believe complete.

  A brief overview: Disk/Tape loadable. No ROM dependancy.
Maximum compatibility with legacy OSes. Extensible. If I want 
to go out and create an IDE hard drive interface card, I should 
be able to write a driver that works seamlessly with the new
OS and provides maximum backwards compatibility to those legacy
OSes. An integrated, high-level language that allows full OS & 
assembly access. A GUI.


   Compatability: People want to run their special widget and we
just need to lump it. How can we overcome the problems? Well, if 
the problem is truly with *ONLY* a very few apps/games, we can 
modify them. But what about CMP apps, TDOS?  What we need is for 
a new OS to branch, as transparently as possible to legacy
OSes.  Making use of whatever "autorun" facilities are available.
Where we can't get a quick solution, I'm content to let there 
remain a ragged adge. Negative Stimulous will do a lot to get 
people to upgrade their apps.  The OS should _NEEDS_ to be load-
able from any media. Disk, tape, ?!?    90% of users won't up-
grade their ROM chips.  It should be based on a core which fits 
within the code 8k EOS RAM, but extensible though disk-loadable
libraries and devices. 
    
   Media Compatibility: The OS should provide low to mid level
routines for CPM, EOS and any other formats that can be squeezed
in. 

   Programmability.  Also provided should be a high-level
language, It should allow inline assembly, and provide easy, 
high-level access to all layers of the OS. it should, ideally, 
be a compiled language with an IDE.  

   GUI: WE don't need to write a GUI that's a lame imitation of
Windows.  That defeats the  purpose of providind a new _Adam_ OS.
But while exploiting the Adam's strengths, most noteably Smart-
Keys and users' familiarity with them, a GUI should provide
'modern' enhancements, like Cut, Copy and Paste for Programs 
working "Within" the OS/GUI.

How? I think, and I'm open to being proven wrong, that this whole
structure can be supported on very small headers, 2-6 bytes. say,
roughly in psuedo code:


Library {
   name : BYTE  ; 255 libraries
   Size : WORD  ; Libraries up to 65k
   Functions : Array of LibraryFunction
}

LibraryFunction {
   UniqueID : BYTE
   NextFunction : BYTE ; (as an offset)  
   FunctionCode: BYTE[254] 
}

   Problems here are obvious. All libs would require routines to
be limited to 256 bytes, and there are library management prob-
lems, but these can be worked out. 

   Code Maintenance: If any one comes after us to maintain this
platform, Code maint can be made trivial. Good documentation for
the OS and associated apps, and a distributed repository 
of mirrored nformation. Also, I think the "GNU" approach of
source code availability can be encouraged through the copyright
license and the above repository. 

   Build the OS in a layered way, maybe:

     USER APP           <- Top level
-------------------
       GUI
-------------------
   Extended OS 
-------------------
Libraries & Devices
-------------------
 Disk Loaded "EOS"
-------------------
     ROM EOS            <- Bottom Level


I've got the programming skill to significantly contribute to
such a project, but not the Hard knowledge. I'll get a great 
deal of that from the docs coming with my system. But not 
enough.  While Richard Certainly doesn't want hurrahs (he 
deserves them from what I've seen), He plays currently a very 
important role as the guru of the Adam community.  I'd like to 
ask him to try and write a ground up tutorial on the Adam Hard-
ware for the mailing list . I'm willing to provide all the Web 
space needed, and all the web apps, such as a Message forum, 
and code-repository for the project, and LOTS of my own time 
and effort.

Again, feel free to criticize and question. This kind of project
will require everone's input. Also I apologize in advance for 
mis-spellings and grammatical errors. This was typed WAY too 
late at night.


