Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!umb!ram
From: ram@umb.umb.edu (Robert Morris)
Newsgroups: comp.sys.att
Subject: pc 7300
Message-ID: <562@umb.umb.edu>
Date: Sun, 21-Jun-87 15:51:58 EDT
Article-I.D.: umb.562
Posted: Sun Jun 21 15:51:58 1987
Date-Received: Mon, 22-Jun-87 07:02:04 EDT
Expires: Wed, 15-Jul-87 00:00:00 EDT
Reply-To: ram@umb.edu (Robert Morris)
Distribution: world
Organization: UMASS-Boston, Boston, MA
Lines: 57
Keywords: unix pc

A few things I haven't seen pass here about the PC 7300:

About the only serious criticism I haven't seen pass in this 
discussion is that the keyboard has the most bizarrely placed CTRL key 
imaginable, down to the left of the space bar. I find it literally impossible 
to hold this key down while keeping the rest of my hands on the typing home 
position, and the machine is therefore almost useless with emacs (micro-emacs 
runs pretty well in a 1mB machine and I have seen claims that gnu-emacs
will run, though I doubt in 1 mB).

The slow 85 ms disk is a nuisance for C development. Since the screen
ain't all that fast either with emacs or vi, I still find it preferable to 
dial up my standalone Sun 3 and work by telephone even at 1200 baud,
let alone 2400. But, if you had no such access, the system is pretty
respectable, provided you have release 3.5 of the OS and related utilities.
The release 3.0 C compiler enforced 8 (?) character names on identifiers.
What was most amazing to me is that the C >>preprocessor<< understood this 
limit and there was no way to take your existing code and fix the brain 
damaged compiler with #defines.

My only other complaint is that there does not seem to be a way to directly
access the screen, so that if you want to do any raster graphics of your own
you need to make a system call per blt (an ioctl provides this), which induces
you to keep a shadow frame buffer in memory and do raster ops out of it with
the ioctl. Does someone know how to write in the frame buffer without
calling unix?

Part of what was distributed to universities given these machines is
GSS's GKS implementation, which I assume is similar to what is available 
on IBM PC's. This is so-so, except for its narrow-minded mouse handler
which implements a strict "pick" device. In particular, the application can
not tell where the mouse is until the user pushes a mouse button. If
it is the same as for the PC, these boxes might be a rational graphics
development environment for code headed for a PC.

If you snoop around a little in the diskette formatting scripts you will 
find that you can format at 10 sectors/track instead of the default 8. This
gives you about 20% more per disk, but >>substantially<< worse i/o speed
at the default interleaving factor. I can not remember whether you can't
change it with the formatter, or whether experiments revealed nothing 
better (I think the former), and AT&T's software support staff could not
help. As I recall, the 3.5 distribution is thus formatted. I
use it for stuff I don't read often, e.g. backups.  Anyone have any knowledge
about interleaving? The disk controller and driver understand both formats
automatically, and for all I know could support even higher density.

I taught an undergraduate graphics course on this machine and for either
GKS style graphics or rudimentary raster graphics its pretty much ok.
Certainly the unix tools make it a more productive software development
environment than a similarly priced PC.

Albeit somewhat primitive compared to X, the window/menu system makes it 
pretty easy to wrap your applications up in warm blankets which keep the
user from having to understand unix. The vendor's scheme for distributing
software is fully documented and you can use it to keep multiple machines
current with one another [ essentially you write formalized scripts 
describing what installing and removing each comprise].