RonsWeek'n'ADAM

October 5, 1997

by Ron Mitchell

A somewhat schizophrenic article follows. There is gut reaction 
and there is, I think, more mellow and considered comment. 

Hopefully you'll be able to tell the difference, and hopefully 
you'll accept it in the spirt in which it is offered, 
constructive comment. It is not my intent to poke jabs at anyone.

I've been reading Richard Drushel's (drushel@apk.net) late August
and September contributions. He has invited public comment on a 
number of issues.

I have to confess that an understanding of Richard's material 
requires me to reach to a fair depth into my bag of hobbyist 
computer experience. Even then, I have more questions than 
answers about what he describes.

In the comment which follows, I'm going to spend some time asking
those questions. Some of the answers I may already know, but some
I want to hear again. In some cases I'm having trouble with 
verbiage, technical jargon, and programmer concepts that I'm only
vaguely familiar with. My perspective has always been and remains
that of a user. Perhaps I'm a slightly more experienced user than
most, but having read what Richard has written over the past 
month, I certainly know that I'm not a programmer.

The history on various ADAM operating systems, presented in 
outline, was most informative, but in one place infuriating. 
Every time I hear an adverse comment about TDOS, I get mad, not 
just mildly annoyed, but eye-flashing, neck-straining, lip 
trembling, fist-shaking angry.  (Just ask Ron Collins.)

The part about TDOS in Rich's work may indeed be accurate, but 
the manner in which it is presented leaves the impression that 
TDOS co-authors Tony Morehen and Guy Cousineau somehow produced a
product that was less than satisfactory. Having known these two 
talented men as friends for several years, I do not believe they 
wrote any 'spaghetti' code whatever. I believe that they wrote 
code that made sense to them, and I know that code continues to 
perform yeoman service on several ADAM computers here. In fact, 
had it not been for TDOS, I would have dumped ADAM long ago.

All of which leads to my first three questions:

1) What is spaghetti code, and by what standard is it judged?

2) What activities are included in the process of managing or 
   maintaining source code, and why are they important, given 
   that the product is out there and serving?

3) What is modular code, and why is having too many modular 
   source files a bad thing? After all, shouldn't we  be
   carrying only the baggage that we need for a given
   application?
      
In all fairness, it could be noted here that Guy Cousineau once 
remarked (mused, lamented, complained) that TDOS was approaching
the state where perhaps too many variations were 'out there' 
being used for one purpose and another. I think he realized that 
the 'monster' was growing. In my mind however, that in no way 
diminishes the immense utility of TDOS in this place here. Each 
of my ADAM systems has a different setup. I have boot disks for 
each variation. It is not a problem.

Backward Compatibility for the Backward:

Yup. From me a programmer gets user inertia of the finest grade. 
I don't care how 'nifty' a new version of 'anything' is if I have
a 'thing' that does the job I want done, a 'thing' that I'm 
familiar with and fits me like an old slipper.

Backward compatibility may be a problem for programmers, but 
programmers need to keep in mind that some users cling 
tenaciously to what they're familiar with unless there is a grand
and handsome payoff. Perhaps the payoff has not been adequately 
sold.

Question 4

Why would a program written in the early and mid-eighties do 
anything other than assume that it had the whole computer to 
itself? Was that not in fact true? Given the limited memory 
available, was there really any legitimate possibility of multi- 
tasking? I know that Radio Shack had OS9 which claimed to be 
almost UNIX-like in its multitasking capabilty, and that there 
was GEOS in the Commodore 64/128 world which could share data 
amongst its applications, but beyond that was there really a 
computer capable of doing more than one thing at a time? When I 
hear this talk about so-called 'badly behaved programs' I have to
wonder 'badly behaved' for whom?

Speedywrite has often been cited as a fine example of a 'badly 
behaved program' in the ADAM world. The fact that it provided 
superior wordprocessing capability to anything then available for
EOS seemed to be completely irrelevant. Speedywrite provides it's
own methods of dealing with the computer's resources and by doing
so provided an impressive example - in my estimation - of what a 
creative imagination can do with limited computing resources if 
left unfettered by conventions and rules. And that, in my opinion
was and is to author David White's credit. In my humble 
estimation, a program of Speedywrite's quality, under any 
operating system, would be difficult to replace.

The Ultimate Failure of SmartBASIC 1.x

Quote: "The ultimate failure of SmartBASIC 1.x was that it could 
not directly run existing SmartBASIC programs which were full of 
PEEK's, POKESs, and CALLS."

Comment: Seems to me that another reason it didn't catch on was 
         that users didn't understand the payoff that it offered.
         At the time it arrived here, it would not correctly 
         address my Hazeltine terminal, a problem which the
         author subsequently corrected, and it was competing for
         my time and attention with GODOS. Both required me to 
         learn new commands, and it seemed to me at the time 
         that GODOS offered 'sexier' possibilities such as mixed
         font sizes on the screen, dialogue boxes and pulldown 
         menus. As things eventually played out, I had difficul-
         ty remembering anything other than accepted SmartBASIC 
         commands and the DBASEII programming language. Nothing 
         else would stick for some unfathomable reason. Hence,
         little got done here with either SmartBASIC 1.x or
         GODOS.     One user hangup clarified for the record.

...................I'm wandering.

Moving along to the real point of all this.... which is , I hope,
to be helpful.

I would not have known about any of EOS's shortcomings unless I 
had become a CP/M and TDOS user, and an owner of all sorts of 
other computers designed at roughly the same time as ADAM. So 
following is my 'spaghetti user' perception of what's troubling 
EOS. Bear in mind that I'm talking about what you can do under 
EOS without any other program loaded. In ADAM's case, such a 
state is hypothetical because you've never seen the bare bones
EOS, unadorned without Smartwriter, SmartBASIC, CP/M, TDOS, or 
an application of some sort. Presumably it's there, but we have 
to accept that on faith, in much the same manner as a Commodore 
64 user accepts his or her bootup state. At any rate, I will 
mark EOS down because:

1)  It cannot format a blank disk without the aid of an
appropriate  program;

    I can do that with my Apple II and IIe. I can do it with the
    C64 and C128, albeit from BASIC which is included on 
    startup and therefore counts as available. I can do it with
    any CP/M machine such as the Osborne, albeit with a
    transient.

2)  As Rich Drushel has already pointed out, there is non-
    standard use of certain resources such as the memory 
    expander. Having said that, if I were asked to prepare
    a user specification on the use of the memory expander,
    I have absolutely no idea what I would recommend. There 
    are times when I want a RAM DISK. There are times when
    I want additional I/O buffer space. There are times when
    I want contiguous transient program area. At no time, do
    I ever want a print spooler, that much I'm sure of, but 
    then, who knows!.

    Suffice it to note that there is non-standard use. 

3)  There is no inline-assembler or debug utility. Even 
    the simplest of boot monitor programs such as that for the 
    Xerox 820-II provided at least an elementary capability in 
    this regard.

4)  Machine language is required to access some of the
    computers functions, such as sound and VRAM operations.

5)  EOS performs no memory management. As I understand it
    one of the duties of any good operating system is to
    fulfill the role of 'traffic cop' so that if more 
    than one application is in memory, each receives 
    its fair shair of CPU attention.

6)  EOS provides no file maintenance capability, such as copying,
    renaming, or deleting files.

7)  EOS provides no visible file organization capability such as
    that available under TDOS with named directories.

8)  EOS provides no command-line-history buffer. In fact there is
    no place for command-lines at all.

9)  There is no capability to generate a report on memory status
    stating what memory is used, and what is clear and 
    available. In other words, where can I load just one
    more "Terminate and Stay Resident" program without crucifying
    something important already in memory?

10) Under EOS files of operating system commands such as .BAT
    or .SUB files are not supported.


Leaving the list at that, it's probably fairly safe to say that 
there's plenty wrong with EOS about which plenty could be done. 
Whether or not it is worth doing except as an academic exercise 
remains debatable.

I for one would like to see the effort proceed, because I think 
that it will result in some interesting possibilities. I like the
concept of a user shell that Rich Drushel refers to in his August
31 article. I like the concept of having high level commands 
to access system resources, provided that the commands are short 
and to the point. (Things like "WriteWindowAT x,y" don't cut it.)

Insofar as providing additional memory is concerned, I can see no
problem with setting aside a 64k memory expander as a hardware 
requirement for the new operating system. Seems like a small 
price to pay. 

But perhaps we need something more. Perhaps we need not just a 
standard, or specification covering EOS and how it will work. 
Perhaps we also need a standard for programmers proposing to 
develop new software. (I'm assuming there will be some; perhaps 
that's a leap of faith). At the very least we need some sort of 
common understanding as to how ADAM's resources are to be 
accessed. For example, if it's a 'no-no' for me to make direct 
BIOS calls, then perhaps someone had better tell me why. Perhaps 
we also need a common understanding about how programs are to be 
judged or reviewed. And perhaps we need a way of defining user 
specifications describing in layman's terms the job that any 
given piece of software is to do.

In plain fact, we need standards and procedures that even the 
good people at Microsoft, Corel, Digital and Lotus have had 
difficulty in establishing. The possibility of competitive 
advantage shouldn't be a problem with us, but it has been 
elsewhere, and it certainly was in the days when new ADAM 
software was being written. 

'Nuff said. I do hope this discussion continues. I think it's 
marvelous that Dr. Drushel has initiated some thinking about 
these things. I hope we can all follow along, contribute to the 
best of our ability,  and learn in the process.
