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.)