[net.micro] why buy an apple

augsec@ecsvax.UUCP (09/23/83)

Reading the comments under the heading of 'RE: WHY BUY AN APPLE?' has
been a bit disappointing especially when you consider that at least
some of the other users reading these exchanges are probably new to the
world of microcomputing.

About three years ago I knew next to nothing about micros or which one
to buy. However, a friend of mine gave me some advice that helped me a
great deal and I think still applies today; i.e. buy the machine that
meets your needs today and don't spend too much time trying to second
guess what microcomputers will be like tomorrow. Following that line
of reasoning lead me to purchase an Apple II+ because it could do what
I wanted and needed to do. It has also had the extra benefit of allow-
ing me to learn more about micros than I probably could have on any
other machine around at that time.

Today things are not so simple and the first question that a person
needs to ask is whether an 8-bit or a 16-bit micro is what they need?
(Obviously a sub-set of this question is what operating system will
function best in your environment?) I work in a building where people
use Radio Shack Model 12s, Cromenco S-100 systems and Apples. The
Cromenco and Radio Shack users generally work with CP/M while the
Apples use DOS. Between public domain software and their own talents,
the CP/M group has developed programs that meet their needs. The same
can be said of the Apple users, primarily because Apple has let us
know what makes the II+/e tick. The point is that we are all using
8-bit systems and really don't see where a 16-bit system would make
that much difference to our work. We could be wrong and probably are;
but we are not sure where we can go to find out from fellow users just
what are the benefits of switching to the 16-bit world. By benefits I
mean more than just a few more characters on the keyboard or a 12 Mhz
clock vs. a 4 Mhz clock. Clock speed is a factor but so is instruction
set efficiency. Like it or not, a 1 Mhz 6502 matches a Cromenco 4 Mhz
Z-80 in interpreted BASIC (no disk I/O), at least for the programs we
have tested.

'RE: WHY BUY AN APPLE?' has generated the sort of exchange that could be
of value to most micro users. Perhaps we could keep the exchange going
but with a somewhat more constructive format. As a non-IBM-PC user I
would like to ask the following questions:
    1) How does the 8088 in the IBM-PC address 1Megabytes of RAM?
    (Does it use a MMU to transfer to fast RAM, or does it address
    all of its 1 Megabytes directly?)
    2) What is I/O redirection? What are path searches? Are these
    functions really necessary in a single user environment?
    3) Does word processing really need a 16-bit CPU?
    4) Why does IBM market its PC  with an 8088 when it also (and for
not that much more money) sells the IBM 9000 lab computer with a
68000? Somehow the logic of that move escapes me.

In return I would be willing to recount some of the capabilities of the
Apple. As someone pointed out, the Apple is hardware oriented and I use
it as a multi-channel analyzer (2048 channels) for a gamma-ray
spectrometer and to run an X-ray spectrometer. The same machine can
function as a word processor, and routinely crunches data using a
nonlinear least squares optimization program (the later is done in
Applesoft with machine language patches). Yes the Apple can us pseudo-
disks and you soon should be able to put 1 Megabytes in it on one card.
A friend of mine has one of the new 68000 boards with 128K in his
Apple and has been keeping our local users group informed on life with
the 68000. I also have a DOS for the Apple that lets me use SSSD and
DSSD disk drives(Elite II ) at the same time (NO that one is not
available from APPLE).

                                 Wayne Robarge
                              North Carolina State University
                               (919) 737 2636
                                decvax!mcnc!ecsvax!augsec

romkey@mit-borax@sri-unix.UUCP (09/27/83)

From:  John L. Romkey <romkey@mit-borax>

Hi, since I've already flamed about it, I thought maybe I should try to
answer your questions in a level-headed manner.

1) The 8088 addressing 1Mb of RAM.

The 8088 is a 16 bit processor which doesn't have pretenses to being a 32
bit processor, unlike the 68000 and 16032. A problem is that it's really
nice if your processor registers are wide enough to hold memory pointers. In
the 8088, this is a problem because people really do like to use more than
64K of memory, but that's all that 16 bits can address. So Intel made the
memory segmented. The idea is that there are also 16 bit segment addresses,
one for code, one for data, one for stack, and one extra one (which really
is called the "extra segment"). What you do to make a 20 bit address out of
a 16 bit data address is to take the 16 bit data segment address, shift it
left by 4 (multiplying it by 16), and add it to the data address. This
produces a new 20 bit address. Thus if you're looking at address 234B (hex)
and your data segment is 0800 (hex), then the physical address will be
0A34B, a 20 bit number.

There are some advantages and disadvantages to this scheme. Although you can
access more than 64K of address space (total), it's often inconvenient and
rather clumsy. The 8088 isn't a 32 bit processor, and you really feel it
when you're doing extensive work with pointers. Also, taking two random
pairs of segments and offsets and comparing them is a bit more work than
you'd really hope for.

2) I/O redirection, path searches, and the single user machine.

I/O redirection is sort of based on the idea that a program has a "standard
input" and a "standard output". These are usually associated with your
terminal, but it's sometimes useful to associate them with other things,
like files. Then you can do something like
                    dir > files
which will run the directory command and put everything it sends to standard
output into the file "files" instead. Then you can edit it, or print it, or
mail it to your best friend if you want. Or, you can do something called
piping. The unix way of writing it is with a |. You can say
                    dir | sort
and what this does is to take the standard output of dir and use it as the
standard input of sort. The above command line would give you a sorted
directory listing. If a system is multitasking, piping can be done by
buffering data in the operating system and awakening or putting to sleep
processes when necessary. If it's not, then you have to put all the output
of one program in a file and then have the other program read from that file
when it reads from standard input.

You might notice that this scheme forces terminal I/O to look a lot like
file I/O. In fact, it forces a move towards the position where you just
basically have streams which you read characters from and write characters
too.

Search paths are (I think) really only useful when you have a file system
which can have multiple directories (or perhaps when you have a whole lot of
disk drives on your machine). If you can have multiple directories, a search
path tells the command interpreter where to look for programs when you type
a command. Suppose your search path is /bin;/local;/etc. Then, when you type
the command "foo", the command processor will probably see if it has a built
in command of that name (thought it would be nicer if it waited till it had
checked elsewhere) and if it doesn't, it will look for a program named
"/bin/foo" or "/local/foo" or "/etc/foo" and try to execute it if it finds
it.

I think that I/O redirection and search pathes can be really useful, even in
a single user system. Just because a system can't have multiple processes
doesn't mean that you shouldn't have a decent working environment. Of
course, I worked for years without knowing about these things and would have
thought them useless if anybody had told me about them.

This message becomes to long. To be continued.
                                                            - John Romkey
                                                              romkey@mit-borax

MCMANIS@usc-eclc@sri-unix.UUCP (09/27/83)

From:  Chuck McManis <MCMANIS@usc-eclc>


As was mentioned earlier the discussion of the "best" computer is like
discussing the "best" tool. (Is a hammer better than a screwdriver ?)
And the point here is that computers are TOOLS. They perform a function
and/or increase productivity. Unfortunately they have been classified 
into the one big generic category of "computer". Note that many manufacturers
have tried to capture a bigger share of the market by making their 
computers very flexible, much like a swiss army knife, but they all end
up doing one thing great and several things so-so. 

When you decide to buy a computer it should be because you have a problem
or situation that a computer can fix or satisfy. If this is simply a 
problem of learning about computers in general go out and buy the cheapest
computer you cna find that runs at least 1 high level language (BASIC is
fine) and you can program in machine code if you want to. Then you can 
learn 80% of what a computer is like with respect to software, and certainly
a lot about architecture and how it does what it does. If the your problem
is controlling realtime processes or scientific applications get a computer
that runs as fast as you can find and has a flexible interrupt capability.
If you need one for business get one with the fastest printer you can find
(if you generate a lot of paper now wait till you see what a computer can
do!) and a large amount but not necessarily fast mass storage. Finally
if you are a Hobbiest/Hacker/Metaphysical Programmer and are interested
in writing new languages or operating systems then you have a problem.
Because you will want a fast processor, fast printer, lots of fast mass
storage and compatibility with as many people you can find because 
otherwise who else could appreciate your current masterpiece.

I hope this gives some new users at least a point to start in asking
questions. The bottom line is don't buy a computer because someone else
says it is what you need, buy one because it meets your requirements.

				--Chuck
-------

ron@brl-vgr@sri-unix.UUCP (10/03/83)

From:      Ron Natalie <ron@brl-vgr>

Please explain what unix style command sequences (I/O redirection and
search paths) has to do with comparing 8088's to 68000's or IBM PC's to
Apples?  Item 2 in your letter has nothing to do with the processor
hardware nor even the operating system running on it.  The whole software
tools aproach provides these "unix-like" command features on any operating
system.  There are even C tools available for the Apple that provide this.
Of course, UNIX (and it's derivatives) are available for most of the
16 bit micros (8088, 68000 and up).  And their are watered down implementations
for many micros (including the plain ol' 8080).

-Ron

seaburg@uiucdcs.UUCP (10/13/83)

#R:ecsvax:-125000:uiucdcs:10400082:000:182
uiucdcs!seaburg    Oct 12 23:59:00 1983

Apparently Apple DOS doesn't have such capabilities.  PC's do.  Some 
people like the flexibilty these capabilities give.  (That's how it
can pertain to the subject at hand, silly.)