HDTenEightyP/NetNews huggingface dataset:
From: roeber@vxcrna.cern.ch
Newsgroups: comp.sys.apollo
Subject: re: timezone()
Date: 2 Oct 92 15:04:36 GMT
Reply-To: roeber@cern.ch
Organization: CERN -- European Organization for Nuclear Research

In article <1992Oct2.140503.3655@email.tuwien.ac.at>, mjl@newton.auto.tuwien.ac.at (Martin J. Laubach) writes:
> | Your edit is still there; nothing's changed.  I suspect the original
> | dude was using BSD semantics but compiling under SysV.
> 
>   Not quite. I'm using BSD semantings and compiling under BSD.

Yes, I was wrong.  It seems that HP has left the initialization file
/usr/include/apollo_$std.h intact, but the new compilers don't
include it!  Go figure...

-- 
Frederick G. M. Roeber | CERN -- European Center for Nuclear Research
e-mail: roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80
From: thompson@PAN.SSEC.HONEYWELL.COM (jt -- John Thompson)
Newsgroups: comp.sys.apollo
Subject: re: Problem with extended acl objects
Date: 30 Sep 92 21:52:32 GMT
Article-I.D.: pan.199209302152.AA11656
Distribution: world
Organization: The Internet



> In the past few months, of and on, we're losing some files with
> the error "extended acl object not found for object". ls shows
> that the file is there but we cannot read/copy it. ld -a shows
> that the rights are "rts??". Salvol, sald, salacl don't help in
> any way. Does anyone have any idea as to what causes this
> problem? Is there any way to fix it?

The problem is that somewhere, you're losing the ACL object that holds extended
entries (the ones beyond Person/Group/Org/World).  The why is beyond me.

The workaround for this is to have root or locksmith do a
    /com/acl file_with_missing_acls   file_with_good_acls
on the object(s).  If dirs are getting hosed, then use a directory for each of
the above, and tack a '-all' onto the end of the command.  This will throw out 
the current (bad/missing) ACLs, and replace them with the known good ones.

-- jt --
John Thompson
Design Services Engineer / Sys-Admin
Honeywell, SSEC
Plymouth, MN  55441
thompson@pan.ssec.honeywell.com

If you're not part of the solution, you're part of the precipitate.
*************************************************************************
* This e-mail correspondence is a work of fiction.  Any similarity      *
* between the views presented and actual views, personal or corporate,  *
* living, dead, or still to be conceived, is pure coincidence.          *
*************************************************************************
Newsgroups: comp.sys.apollo
From: pato@apollo.HP.COM (Joe Pato)
Subject: Re: Registry Woes -- Registry is full !?
Date: Tue, 29 Sep 1992 21:40:21 GMT
Organization: Hewlett-Packard Company, Chelmsford, MA
Keywords: Registry Full, database store failed

In article <1aahgaINN58g@agate.berkeley.edu>, kmorgan@ocf.berkeley.edu (Keir Morgan) writes:
|> Hi all!
|> 
|>    The OCF has seem to run into an interesting problem -- our registry won't
|> accept any more person or account entries! Currently we are at 4742 account
|> entries and if I try to add any person or account entries I get the following
|> error:
|> 
  . . .

|>    Also, as you might expect, after the store fails all the glb registry
|> objects disappear (checked by /etc/ncs/lb_admin and /etc/ncs/drm_admin).
|> This problem happens regardless of whether on not I run a slave registry.
|> I've tried reinitializing the glbd data base (/etc/ncs/glbd -create -first)
|> , but this still results in the same problem when I try to add an entry. I
|> even tried changing the family to dds to see if that might do something, but
|> no dice. I've also recreated the registry from a backup, but again this was
|> no help. Is this a known problem? Oh, BTW typhoon is a DN4500 with 24MB ram,
|> so I'm fairly sure this is not the source of my problems. 
|> 
|> Oh, a few other things:
|> 
|>    1) Why does renice say that rgyd is niced -10, while ps says it is niced
|>       +11 ? What does ps know that renice does not or vice versa?
|> 
|>    2) What does the "-init_buf" option on rgyd do?
|> 
|> Cheers All!
|> 
|> Keir Morgan                 |  U.C. Berkeley's Open Computing Facility
|> kmorgan@ocf.berkeley.edu    | Unix accounts for UCB students -- if the
|> kmorgan@UCBOCF.BITNET       |  registry would add accounts, that is!
|> 
|>       

No, the registry is not full.  There exist registries with more than
10,000 entries (and there is no hard upper bound on the number of entries
in the database).

It appears that the registry server is failing in a subsequent or 
simultaneous invocation of getpwent().  Do all of your registry servers
die (or is the master the only instance?)  When you talk about replication
you mention the glbd - but that is the location broker not the registry.
Are you running other instances of the registry?

I would suspect a data corruption problem in the master registry site.  It
would be very useful to know if a slave registry suffers from the same problem.
Of course if the replica were created from an already damaged master it too
would have the same data corruption.

The -init_buf option to the registry is not documented, but it controls
the buffer size used for initializing slave replicas.

You should contact customer service with your problem.  You may need to
run a salvager over your database to fix the problem (to date we have only
needed to salvage databases at two sites - where the databases had been
damaged by faulty hardware)

-- 
                    -- Joe Pato
                       Distributed Object Computing Program / East
                       Hewlett-Packard Company
                       pato@apollo.hp.com
Newsgroups: comp.sys.apollo
From: bri@pegasus.mit.edu (Brian D. Carlstrom)
Subject: Imake Config Files for SR10.4
Organization: mit
Date: Mon, 28 Sep 1992 02:45:55 GMT

I am trying to install some software that heavily depends on imakefiles
for the installation, build, etc. i was wondering if any people have 
whatever imakefiles are necessary for SR10.4 (or 10.x) in a BSD environment.
I'd appreciate it if you could email them to me so i can figure out whats 
going on.

-bri

Newsgroups: comp.sys.apollo
From: vlcek@mtl.mit.edu (Jim Vlcek)
Subject: Problems with XON/XOFF handshaking
Organization: EPI Software Systems, Chorus Corp, St. Paul MN
Date: Fri, 2 Oct 1992 06:23:02 GMT

We've got a couple of Apollo DN3000s that we use for print and plot
spooling for some Autocad users.  Lately (sometime after I upgraded
the plot spooler to SR10.4), we've been having problems with
/dev/sio1.  It's set up for XON/XOFF handshaking, and does do the
handshaking OK for a while, but then after a certain period of time
(somewhere in the range of 75-100K bytes transmitted), the sytem will
receive an XOFF but still keep on trucking.  This causes our plotter
to suffer a buffer overflow.

ANyone got any ideas on what might be causing this?  It's definitely
something on the Apollo side; we have an analyzer on the serial line
at one point, and we could clearly see the handshaking progressing
well until suddenly the DN3000 didn't recognize an XOFF.

Here's a tctl output for that line:

% /com/tctl -line 1
Status of Line 1: 
Erase (character delete) character: 08 (hex)
Kill (line delete) character: 15 (hex)
End of file character: 04 (hex)
Quit character: 03 (hex)
Fault character: 1C (hex)
Suspend character: 1A (hex)
New line delay: 0 
Speed: 9600
Raw: TRUE,          Echo: FALSE,        Cvt_NL: FALSE
CvtRaw_NL: FALSE,   Host_Sync: FALSE,   Input_Sync: TRUE
RTS: TRUE,          DTR: TRUE,          DCD: TRUE
CTS: TRUE,          Quit_Enable: FALSE, Fault_Enable: FALSE
Susp_Enable: FALSE, DCD_Enable: FALSE,  CTS_enable: FALSE
BP_Enable: FALSE,   RTS_Enable: FALSE
Seven bits per character, Parity: Even, One stop bit
Errors enabled: FRAMING OVERRUN CTS_CHANGE 
Polite: FALSE      
%

Please email me if you have any suggestions; I'm vlcek@epimbe.com

Jim Vlcek
Newsgroups: comp.sys.m68k
From: byron@cc.gatech.edu (Byron A Jeff)
Subject: Re: WANTED: Shareware 68000 assembler
Reply-To: byron@cc.gatech.edu (Byron A Jeff)
Organization: Georgia Institute of Technology
Date: Tue, 29 Sep 1992 11:57:17 GMT

In article <1992Sep28.192319.22674@galileo.cc.rochester.edu> mdsp_ltd@uhura.cc.rochester.edu (Pooch) writes:
>I'm looking for a 68000 assembler for either mac or PC based machines. I'm 
>working on a small project, and have zero money to invest in a real one.
>
>Any halp would be appreciated.
>
>E-Mail to mdsp_ltd@uhura.cc.rochester.edu
>

This is definitely the Frequently Asked Question of this group. Fred Fish
of Amiga fame has several different versions of C compilers and assemblers
on is public domain Fish Disks. They include source and are fairly easily
portable to other environments (I've ported them to DOS and UNIX with no
real problems). Now however they are not highly optimized or anything
like that but can get you from C source code down to Motorola S records.

Also the Motorola BBS (512-891-FREE) has always had 68K software available
just for the cost of the telephone call. I pulled down the 683XX Background
Debugger that run on the PC, put together the $3 interface directly on
my 68340 board, and had everything up and running in 1 evening (except
that the RESET pin from the interface doesn't work properly.)

Does anyone else think that it might be time to start a collection of this
type software and advertise it here?

And one last questions: Does anyone know if gcc and gas has been ported to
a DOS environment with a 68K backend? I'd like to use a highly optimized
compiler when I start development of the 68EC040 part of my project.

Hope this helps.

BAJ

>Thanks
>
>-- 
>+-------------------------------------------------------------------------+
>|    Marc D. Spencer, C.E. WRUR-FM   | Technology is a way of organizing  |
>|   mdsp_ltd@uhura.cc.rochester.edu  |  the universe so that man doesn't  |
>|                                    |  have to experience it    -Frisch  |


---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu
Newsgroups: comp.sys.m68k
From: eero@field.fi (Eero Sarlin)
Subject: Re: 68HC16
Organization: Field Oy, Helsinki, Finland, Europe
Date: Fri, 2 Oct 1992 18:00:37 GMT

In article <BvG07B.Isv@dei.unipd.it> red@emma.dei.unipd.it (Piergiorgio Sartor 274199/IL) writes:
>Does exist a version of the 68HC16 other then SMD?
	I Assume, Yoy mean Surface Mounted Device as a reference to the
Plastic Quad Flat Pack (PQFP), as used in MC68HC16Z1CFC

The answer is simple NO.
according to moto MC68HC16Z1 Technical summary rev. 3 (MC68HC16Z1TD&D)
the device is available in the following packages:

FC	132pin PQFP
FD	132pin MCR (Molded carrier ring)
FV	144pin	Plastic surface mount
FM	144pin	MCR(Molded carrier ring)

same document refers to 16.78, 20 and 25MHz versions (16,20 and 25 suffixes),
-40 to 85c ,-40 to 105c and -40 to 125c tempranges (c as centigrade celcius)
with C V and M prefixes before package letter

as to Your original qestion, if all you want is a way to solder the device to
traditional thru-hole PCB, at least 3 manufacturers make sockets for this
JEDEC PQFP/CQFP standard package (132pin)

AMP 3M/Textool and Yamaichi
at least these are available in Finland, the AMP socket costs about the same 
as the device, but that may be still insignificant compared to the saved burden
when and if you go to faster chip versions
take note, that AMP has a modular approach, with same socket and 2 alternative
lids, one for Ceramic and other for the 'mickey eared' plastic package.
when requesting information on sockets, it might be advisable to refer to
other Moto processors,that have same package: DSP56001CFC33, DSP56156CFC60
MC68331CFC and MC68332CFC, just in case, their crossref is older, than HC16


Mentioned trademarks etc. are some sort of properity of their owners and the
use of those is purely for informative purposes to clarify the matter.

>-- 
>					red@paola.dei.unipd.it
>					red@sabrina.dei.unipd.it


-- 
Disclaimer: opinions are and will stay mine, my employer just pays my salary
Eero "HC11F1" A. Sarlin                   E-Mail : eero@gandalf.field.fi
Motorola FAE  HC11/HC16/DSP56K /Field Oy. Telex  : 122022 field sf
sysop of Field OTP (in Finland 9700-8560) Phone  : +358 0 757 1011
Newsgroups: comp.sys.m68k
From: Harley Myler <hrm@engr.ucf.edu>
Subject: Tutor Simulator
Organization: Univ. of Central Florida
X-Useragent: Nuntius v1.1b3
Date: Mon, 5 Oct 1992 20:09:55 GMT

Anyone seen a Tutor simulator out there? (preferably one that runs
on an MSDOS platform)
Newsgroups: comp.sys.m68k
From: kestes@nswc-wo.nswc.navy.mil (Kent Estes)
Subject: MVME167 multiprocessing...
Summary: info request 
Organization: Naval Surface Warfare Center
Date: Thu, 1 Oct 1992 12:00:20 GMT

We currently have a VME cage with 3 MVME167 boards (68040).  Does
anyone know of an easy way to communicate with the other processors ?

               thanks,
                          KL

Newsgroups: comp.sys.m68k
From: breese@monet.imada.ou.dk (Bjoern Reese)
Subject: How to determine 68030 versions?
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Mon, 28 Sep 1992 12:50:39 GMT

Recently there has been a discussion on how to find the different versions of
the 68040 (normal, EC). I was wondering if the method using FNOP also would
apply to the 68030s.

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)

     "Keinem Gedanken Glauben schenken, der nicht im Freien geboren ist."
                       - Friedrich Nietzsche, Ecce Homo
Newsgroups: comp.sys.m68k,comp.sys.mac.hardware
From: aslakson@pico.cs.umn.edu (Brian Excarnate)
Subject: Re: 68050
Organization: :noitazinagrO
Date: Sat, 26 Sep 1992 23:52:30 GMT

halpin@vsg1.dsg.dec.com (Stephen E. Halpin) writes:
>longer.  A properly designed 33MHz 68040 system is no match
>for a properly designed 66MHz 80486DX2.  Expect the P5 to
A rag fairly recently tested a Mac running a Radius Rocket (33MHz) against an
80486 (50MHz) (using applications for testing).  The Mac beat the 486.
MacWorld, I think.

Anyway, depending on what you do, an 80486 can't beat anything.  Same for a
68040.  Your bias is showing.


Brian
Or shouldn't I talk real-world here?
--
Donny IS Joseph
Newsgroups: comp.sys.m68k
From: Harley Myler <hrm@engr.ucf.edu>
Subject: Tutor Simulator
Organization: Univ. of Central Florida
X-Useragent: Nuntius v1.1b3
Date: Mon, 5 Oct 1992 20:08:19 GMT

Anyone seen a Tutor simulator out there? (preferably one that runs
on an MSDOS platform)
From: drchip@cup.portal.com (MYRON A LIEBERMAN)
Newsgroups: comp.sys.m68k
Subject: Re: Re: MCM6810
Date: Mon, 28 Sep 92 23:54:38 PDT
Organization: The Portal System (TM)
  <1992Sep27.115255.2251@reks.uia.ac.be>



>the MCM6810 is a very old 128 x 8 (bytes) static RAM chip
>
>(popular in the early days of microprocessors (mid 1970) ).
>
>willy
>
>wittesa@reks.uia.ac.be

Actually the MCM6810 is 128 x 8 (1K) BITs, not BYTEs. The x 8 makes this
1Kbit SRAM 128 words, each 1 Byte (8 bits) wide. Please do not confuse
this, by the way, with a 628128 or any of the other 128K x 8 SRAMs
popular today. They have 1024 times more capacity.
From: aek@Apple.COM (Al Kossow)
Newsgroups: apple.general,comp.sys.m68k
Subject: number for motorola BBS
Date: 6 Oct 92 20:55:17 GMT
Distribution: usa
Organization: RISC Products Group, Apple Computer, Inc.

The number I have for Motorola's freeware bbs is 512-440-2725
Is this still current? 

-- 

Al Kossow @ Apple Computer, Inc., Cupertino, CA
Internet: aek@apple.com
Phone: (408) 974-5136
Newsgroups: comp.sys.m68k
From: wittesa@reks.uia.ac.be (Willy Wittesaele)
Subject: Re: MCM6810
Organization: U.I.A.
X-Newsreader: Tin 1.1 PL5
Date: Sun, 27 Sep 1992 11:52:55 GMT

hello ,

the MCM6810 is a very old 128 x 8 (bytes) static RAM chip

(popular in the early days of microprocessors (mid 1970) ).

willy

wittesa@reks.uia.ac.be
From: jackb@mdd.comm.mot.com (Jack Brindle)
Newsgroups: comp.sys.m68k
Subject: Re: What is an MC68302?
Date: 4 Oct 92 03:25:50 GMT
Organization: Motorola, Mobile Data Division - Seattle, WA

In article <1992Oct2.125812.2590@keinstr.uucp> chaplin@keinstr.uucp (Roger Chaplin) writes:
>Sakari Aaltonen (sakaria@vipunen.hut.fi) wrote:
>: The 68302 has a 68000 core. Parts 68330/68331/68332/68333/68340 do have the
>: CPU32 core. Apparently, the 68302 was the first out, at a time when the
>: CPU32 core was not ready.
>
>I remember the '332 being the first one out, followed by the '302.  Our
>local Motorola salesman tells us that the '302 is actually a custom
>design for one of their customers, and all they wanted was the 68000
>core - they didn't need or want the CPU32.  (And the rest of the world
>loses in a BIG way :-(

Actually, it was the other way around. The 68302 was designed by the 68K
group, and is a pretty big enhancement of the Hitachi 68301. It was designed
for several applications, most notably ISDN.

The 68332 was designed by the microcontrollers group, and was originally a
response to a specific customer. You might notice that the TPU microcode
is highly biased towards automotive applications, with code for things
like a tachometer, dwell, etc. The '332 came out at least a year after the
302.

I would reasonably expect that there will be additional members to the
683XX family, and hope there will be a 68302 replacement using the CPU32
core. I do not, of course, have any knowledge of any future devices,
especially since I am not a member of the Semiconductor group. Just a
satisfied customer...



-- 
==========================================================
Jack Brindle
ham radio: wa4fib
internet: jackb@mdd.comm.mot.com
Xref: sparky comp.sys.m68k:1163 comp.sys.mac.hardware:17974
From: israel@risky.Convergent.COM (Paul Israel)
Newsgroups: comp.sys.m68k,comp.sys.mac.hardware
Subject: Re: 68050
Date: 28 Sep 92 16:14:54 GMT
Followup-To: comp.sys.m68k
Organization: Unisys Unix Systems Group, San Jose, CA

From article <1992Sep25.222309.8471@nntpd.lkg.dec.com>, by halpin@vsg1.dsg.dec.com (Stephen E. Halpin):
> Personally I wouldnt be worried about 680x0 systems much
> longer.  A properly designed 33MHz 68040 system is no match
> for a properly designed 66MHz 80486DX2.  Expect the P5 to

Well, if we're waiting for Intel to supply a 'properly designed'
component, I'd say Motorola has nothing to worry about. From
a hardware perspective, IMHO, the 680x0 family was and is the
best designed CISC microprocessor series on the market. As for Intel,
if IBM hadn't selected them for the original PC, they would
have gone out of business long ago.
-- 
Paul Israel -----------------  israel@risky.convergent.com
Senior Smartypants ----------- Unisys Corporation, San Jose, California
Disclaimer: "Who, me? I wasn't even there!"
Newsgroups: comp.sys.m68k
From: htoppman@cip.informatik.uni-erlangen.de (Herbert Oppmann)
Subject: Motorola BBS mirror (was: WANTED: Shareware 68000 assembler)
Organization: CSD., University of Erlangen
Date: Wed, 30 Sep 1992 11:16:19 GMT

pmiach@mullian.ee.mu.OZ.AU (Paul Miach) writes:

>	I have seen listing form Motorola's BBS, but I have not been able to
>find an ftp site that carries the stuff. Is there a mirror about? (archie
>shows nothing)

I needed some files from Motorola's BBS for my project.
The Munich office of Motorola told me, that the only way to get
something from their BBS is to dial up.

But we were able to persuade them to send us a diskette with the
files I needed. They gave us permission to put these files in our
ftp directory, so here it is:

site: ftp.uni-erlangen.de [131.188.1.43]
path: pub/motorola
file: 68020-test.tar.Z (54058 byte)
      Confidence test for the MC68020

Just a tiny bit, but maybe it helps ...
-- 
| Herbert Oppmann | email: htoppman@cip.informatik.uni-erlangen.de |
| irc: mtx        |  mail: Drausnickstrasse 29, D-8520 Erlangen    |
Newsgroups: comp.sys.m68k
From: chaplin@keinstr.uucp (Roger Chaplin)
Subject: Re: What is an MC68302?
Organization: Keithley Instruments, Cleveland, Ohio
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 2 Oct 1992 12:58:12 GMT

Sakari Aaltonen (sakaria@vipunen.hut.fi) wrote:
: The 68302 has a 68000 core. Parts 68330/68331/68332/68333/68340 do have the
: CPU32 core. Apparently, the 68302 was the first out, at a time when the
: CPU32 core was not ready.

I remember the '332 being the first one out, followed by the '302.  Our
local Motorola salesman tells us that the '302 is actually a custom
design for one of their customers, and all they wanted was the 68000
core - they didn't need or want the CPU32.  (And the rest of the world
loses in a BIG way :-(

-- 
Roger Chaplin / Instruments Division Engineering / "Worry does not empty
chaplin@keinstr.uucp / CI$: 76307,3506          / tomorrow of sorrow -
#include <disclaimer.h>                        / it empties today of strength."
#include "disclaimer.h" /* cover all bases */ /               - Corrie ten Boom
Newsgroups: comp.sys.m68k,comp.sys.mac.hardware
From: hsu@eng.umd.edu (Dagwood splits the Atom)
Subject: Re: 68050
Date: Tue, 29 Sep 92 18:26:39 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <1992Sep28.235522.29116@grebyn.com> richk@grebyn.com (Richard Krehbiel) writes:
>In article <1992Sep25.222309.8471@nntpd.lkg.dec.com> halpin@vsg1.dsg.dec.com (Stephen E. Halpin) writes:
>>Personally I wouldnt be worried about 680x0 systems much
>>longer.  A properly designed 33MHz 68040 system is no match
>>for a properly designed 66MHz 80486DX2.
>
>Only thing, you can't get a "properly designed 486 system."  Only PCs.

Well, you *almost* can, and it pains me to say that, as a longtime anti-
PC partisan.  The 486DX50 and DX2/66 are frighteningly usable, in spite
of their insipid register usage.  486 instruction timings are finally down
to something reasonable, one clock for most of the common moves and
whatnot.  And they're cheap, very cheap.  With VL-bus starting to hit the
shelves, we should finally see the death of segmented 8MHz access to the
video subsystem.  Now, if only they'd stop concentrating on building faster
Windows video accelerators and spend a few bucks on RAMDACs that don't look
like shit, you could build a pretty decent color workstation for about
$3 1/2k by next spring.

>Maybe in a few years, once OS/2 and Windows NT have finally isolated
>PC hardware from the domain of the applications, PCs can really be
>designed with high performance system architectures.

386BSD does it today.  Free.  With source.  NFS.  Full Berkeley networking.
X11R5.  And it runs xtank damn well.

With a little bit of luck, PowerPC should put Apple back near the price/
performance curve in another year or two.

-dave

-- 
David Hsu    hsu@eng.umd.edu                 "No animals were harmed in
U of Md Systems Research Center               the making of this film.
College Park, Md  20742-3311                  Some, however, were well fed."
+1 301 405 3689
Newsgroups: comp.sys.m68k
From: kurmas@ttd.teradyne.com (Paul Kurmas)
Subject: Re: What is an MC68302?
Keywords: MC68000 MC68302 peripherals
Organization: Teradyne Inc., Telecommunications Div.
Date: Thu, 01 Oct 92 14:00:18 GMT

In article <1992Sep29.195214.90232@vaxc.cc.monash.edu.au> bull@vaxc.cc.monash.edu.au writes:
>
>
>                                                  What *is* a 68302?
>I'm assuming it's a variation of the 68030, but some more info
>would be appreciated.

Although I'm sure this question will have been answers many times over, 
the MC68302 is an "integrated multiprotocol processor" (Mot's lingo). 
It has an MC68000, not CPU32 (like the 6833? and 68340), core, plus
three high-speed serial controllers, plus on-chip RAM, DMA, parallel I/O,
chip select generation, ... It is quite useful for communications applications
such as ISDN terminals and X.25 PSN interfaces. I don't think it would be
a stretch to use it for MIDI. 

>
>
>           Bull@vaxc.cc.monash.edu.au  OR  bull@monu1.cc.monash.oz
>                    DOD# 251  '84 VF 750   Closet Ducatisto
>             Disclaimer. If you love your llama, let it lambada.

Paul Kurmas
Teradyne Telecommunications
Deerfield IL

voice: (708)940-9000
Email: kurmas@ttd.teradyne.com
Newsgroups: comp.sys.m68k