HDTenEightyP/NetNews huggingface dataset:
From: orchard@wiener.ece.wisc.edu (Bruce Orchard)
Subject: Surplus DN320's and DN460's available
Organization: Univ. of Wisconsin-Madison; Electrical & Computer Engineering
Date: 7 Jan 93 14:37:24 CST


The following surplus equipment is available.  The University's
surplus property office says it is junk, so I assume it would
be free, hauling it is your responsibility.  It has not been
used for at least 2 years and its operability is unknown.

2 Apollo DN320
2 Apollo DN460 (only one monitor)
1 Apollo DSP80A


Bruce Orchard
Department of Electrical and Computer Engineering
University of Wisconsin-Madison
1415 Johnson Drive
Madison, Wisconsin  53706
608-262-0974
orchard@ece.wisc.edu
From: sam@cs.stir.ac.uk (Sam Nelson (CO))
Newsgroups: comp.sys.m68k
Subject: Internet access to `Motorola Freeware BBS', Austin, Texas, sought...
Date: 8 Jan 93 11:25:00 GMT
Organization: Comp Sci Dept, University of Stirling, Scotland

Apologies if I'm in the wrong group---this looked like the best one to try.
I also looked for a Motorola-oriented FAQ and failed.

Technician from downstairs wandered into the office with a user's manual
for the above, written by one John Dumas, dated April 1991.  He's looking
for dialup access, and, while there is a number for a `mirror' BBS in
Munich as well as for the BBS in Austin, if I could find an Internet way
in I could give him `free' access rather than pay large phone bills.

Any suggestions gratefully received, by email preferably.

Sam.
-- 
Sam Nelson, Computer Officer, Comp Sci Dept, Stirling Univ, FK9 4LA, Scotland
Tel: +44 786 467443      G3 Fax: +44 786 464551      Email: sam@cs.stir.ac.uk
          $\Delta p\Delta {\bf r}\stackrel{\textstyle >}{\sim}\hbar$
Member of the League for Programming Freedom   (lpf@uunet.uu.net for details)
Newsgroups: comp.sys.m68k
From: iikoch@techfak.uni-bielefeld.de (Ingolf Koch)
Subject: state of data bus during write of byte
Date: Thu, 7 Jan 1993 14:19:13 GMT
Organization: Universitaet Bielefeld, Technische Fakultaet.

Hello,
can anyone of you out there tell me what happens to the unused wires
of the data bus coming out of the 68000 if a byte (8bit) value is
written to RAM.

Could it be that both halves (bits 0-7 and bits 8-15) contain the byte
value to be written and that the RAM then selects the correct bits by
looking at LDS and UDS?

What about other 680x0 (especially the 68040)?

Bye,
-- 

Ingolf Koch				Wellenkampstrasse 38
					W-4937 Lage, Lippe
					Germany
iikoch@techfak.uni-bielefeld.de		Phone: 05232 / 2700
From: jonathan@vinnie.cuc.ab.ca (Jonathan Levine)
Newsgroups: comp.sys.m68k
Subject: Motorola Memory (was: What is this thing???)
Date: 10 Jan 93 21:13:16 GMT


Thomas J. Trebisky (tom@afthree.as.arizona.edu) wrote:

: At an auction recently, I purchased an interesting piece of equipment
: that some Motorola expert may be able to identify for me.  It is a big
: card cage (takes two men to move) with about 20 slots holding cards roughly
: 2 by 2 feet in size.  Manufactured by Motorola as a "memory subsystem"
: Slots are labeled (left to right):

:  F E D C B A 9 8 7 6 5 4 3 2 1 0 ACC -- ECC USER+IO USER+IO USER

:  Slots 9 thru 2 are occupied with RAM boards:	MMS4311
: 	each has 1Meg of RAM in 64k by 1 dynamics
: 	each is 1/2 populated (could hold 2Meg)
: 	(or maybe it is 2Meg and could be 1Meg)

:  ACC slot has a board with a 68A01 with RAM, ROM, and interface logic.
:  ECC slot has a MMS4330 board
:  USER+IO has a MMS3354 prototyping board

: It also has a front panel with a hex keypad, Moto part number MMS3823.

: Again, the crate and the MMSxxxx cards were made by Motorola.

: Surely, all this RAM was not bank switched for the poor little 68A01.
: What is this thing, anyone know?
: It is definitely not a VME or Versabus crate.

This is a Motorola System 4000 "Semiconductor Mass Memory for Mobile
Environments".  A successor to the System 3000, Motorola sold this
"Ruggedized Mass Memory" for "Geophysical Data Acquisition, Radar Data
Analysis, Communications "Mailbox" Buffers, Medical X-Ray Body Scanners"
and as "Main Memory Add-on, Intelligent Memory, Disk Replacement, and
Disk Cache".  All this information courtesy Motorola document NP-364-R1
dated 1983.  With the 64K rams you have, the box will hold 32Meg.  Using
256K devices, the box maxes out at 128Meg, and will move data @80Meg/sec.

If you wish a copy of this four-page "Product Preview", e-mail me your
fax number.

Good Luck


--
Jonathan Levine: voice 403-686-0473 | Digital Alternatives      (Calgary AB)
                 fax   403-686-1254 | Virtual Universe Corp.    (Calgary AB)
      uucp: jonathan@vort.cuc.ab.ca | Survival Research Laboratories (SF CA)	
            ^^^^^^^^^^^^^^^^^^^^^^^
Please reply to this address.  Return address @vinnie is giving us some trouble.
Newsgroups: comp.sys.m68k
From: ncherry@cbnewsg.cb.att.com (neil j.cherry)
Subject: Source for circuit?
Organization: AT&T
Distribution: usa
Date: Mon, 11 Jan 1993 16:11:29 GMT

Does anybody know of a source for the circuit used to toggle the 68K Rom from
upper to $0000 during initial boot? (Such as  Moto AP or EDN articles).

NJC
Newsgroups: comp.sys.m68k
From: gerard@tscs.com (Stephen M. Gerard)
Subject: The end of the MC680X0 UNIX era?
Organization: Total Support Computer Systems, Tampa, Florida
Date: Tue, 12 Jan 93 05:32:18 GMT

There once was a time when if you wanted UNIX, you typically purchased
a machine based upon a member of the Motorola MC680X0 family.  Our
first machine was a 68010, followed by a 68030, then with a 68040 which
we still presently have.  I have found all to be excellent processors
and was looking forward to a 68060.  I now have reason to believe that
there will be no such beast.  This certainly would be a great pity to
see Intel survive and Motorola fail.  A great pity indeed!

The reason for my dismal expectations is that I hear that Motorola will
not be releasing System V Release 4 for the 680X0 family.  The only
reasonable conclusion that this leaves is that there will be *NO* future
processors in the 680X0 family and that Motorola has, at least internally,
admitted defeat to Intel (yuch!), at least in CISC processors.

Can anyone shed any light on this?  Like I said earlier, I was looking
forward to SVR4 and a 68060.  I might consider switching to a 88K based
platform if I felt assured that Motorola was not going to call it quits
on these as well.

Thanks, Steve

-- 
------------------------------------------------------------------------------
Stephen Gerard  -  Total Support Computer Systems  -  Tampa  -  (813) 876-5990
E-Mail: gerard@tscs.tscs.com				   FAX: (813) 871-2783
US-MAIL: Post Office Box 15395 - Tampa, Florida  33684-5395
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Newsgroups: comp.sys.m68k
Subject: Re: Can VME147 issue Sequential Access Bus Request to the VMEBus?
Date: 11 Jan 93 00:39:07
Organization: TH-Darmstadt
NNTP-Posting-Host: pdv2.fmr.maschinenbau.th-darmstadt.de
In-reply-to: cmhui@cs.cuhk.hk's message of Sun, 10 Jan 1993 04:05:33 GMT


In article <1993Jan10.040533.29908@cucs5.cs.cuhk.hk> cmhui@cs.cuhk.hk (Hui Chau Man) writes:

>   Dear netters,

>   I am using a VME147 system. Recently, I bought a graphics board which can 
>   handle Sequential Memory Access from the VMEBus. Can anyone tell me if the 
>   VME147 can issue Sequential Memory Access requests to the VMEBus slaves?
>   If it can, how to do it?

MVME147 implements at best Revision C of VMEBus.  Term "Sequential 
Memory Access" is not known for Revision C, at least according
to my manual. Perhaps you mean "Block Transfer".
(Motorola, The VMEBus Specification, Revision C.1, 
	Table 2-3, Address Modifier Codes,
	Table 2-17, Timing Diagrams ......)

On MVME147 VMEmodule, Monoboard Microcomputer ...., page 3-42, a table
lists all address modifier codes MVME147 is able to generate (master).
 
No address modifier for block transfers is listed ($xF or $xB), so it
is save to assume, that MVME147 is not able to issue block transfers.
(The MVME147 is even not able to respond to block tranfers ....,
	page 3-47, slave address modifier register:
	" BIT 0-2 ..... Note BLOCK should never be set ... ")

best adams
Newsgroups: comp.sys.m68k
From: archamba@ERE.UMontreal.CA (Archambault Benoit)
Subject: Re: MC68020 cross-assembler ...
Organization: Universite de Montreal
Date: Tue, 12 Jan 1993 16:59:35 GMT

	There's a public domain cross-assembler (MS-DOS env.) available
	from 'The C users journal' for $7.50 US. The distribution
	disk includes complete C source code, makefile, documentation
	assembler executable and assembly source files for testing.

	Here's the address:

	The C users journal
	1601 W. 23rd St., suite 200
	Lawrence, Kansas 66046

	Tel: (913) 841-1631
	Fax: (913) 841-2624

	Ask: for the CUG363 disk.


-- 
"Ribbit!"         Benoit Archambault                    Universite de Montreal 
  ` /\/@\/@\/\          archamba@ERE.UMontreal.CA       C.P. 6128, Succ. A 
   _\ \ -  / /_                                         Montreal, Quebec 
                                                        H3C 3J6
From: john@gu.uwa.edu.au (John West)
Newsgroups: comp.sys.m68k
Subject: 68000 exception vectors (was Re: A few Questions...)
Date: 12 Jan 1993 08:37:13 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: mackerel.gu.uwa.edu.au

byron@cc.gatech.edu (Byron A Jeff) writes:

>1) Have the whole IVT in EPROM. In this case a decoder is fine, the RAM is
>   not at $0000 because the EPROM is.

>2) Boot from the EPROM then relocate it. This is where the PAL is handy
>   because you can program the states into it. Basically a reset causes
>   a state where the EPROM is mapped to $0000. After the reset vector and
>   initial stack is read (first 8 reads for a 68008, first 4 for a 68000)
>   the state changes mapping RAM to $0000 (so it now contains the IVT) and
>   the EPROM somewhere else.

3) Keep the EPROM at $0000 and put the vectors in RAM. How? Its easy - the
   vectors in ROM point to short routines (single instructions, in fact) that
   jump through the table in RAM. You lose a few cycles on each one, but who
   really cares?
   The first thing the code must do on reset is set up this table in RAM. This
   must be done before any exception generating devices are enabled.

John West
--
For the humour impaired: Insert a :-) after every third word
Newsgroups: comp.sys.m68k
From: dfields@hydra.urbana.mcd.mot.com (David Fields)
Subject: Re: The end of the MC680X0 UNIX era?
Reply-To: dfields@urbana.mcd.mot.com
Organization: Motorola, Inc.  Computer Group
Date: Wed, 13 Jan 1993 01:50:54 GMT

I do NOT speak for Motorola!

In article <1993Jan12.053218.12579@tscs.com>, gerard@tscs.com (Stephen M. Gerard) writes:
|> There once was a time when if you wanted UNIX, you typically purchased
|> a machine based upon a member of the Motorola MC680X0 family.  Our
|> first machine was a 68010, followed by a 68030, then with a 68040 which
|> we still presently have.  I have found all to be excellent processors
|> and was looking forward to a 68060.  I now have reason to believe that
|> there will be no such beast.  This certainly would be a great pity to
|> see Intel survive and Motorola fail.  A great pity indeed!
|> 
|> The reason for my dismal expectations is that I hear that Motorola will
|> not be releasing System V Release 4 for the 680X0 family.  The only
|> reasonable conclusion that this leaves is that there will be *NO* future
|> processors in the 680X0 family and that Motorola has, at least internally,
|> admitted defeat to Intel (yuch!), at least in CISC processors.
|> 
|> Can anyone shed any light on this?  Like I said earlier, I was looking
|> forward to SVR4 and a 68060.  I might consider switching to a 88K based
|> platform if I felt assured that Motorola was not going to call it quits
|> on these as well.

Just because you hear that Motorola (and I assume you mean the Motorola
Computer Group) isn't going to release SVR4 for the '060 doesn't mean
that there won't be an '060 nor does it mean that there won't be SVR4
ports which support the '060.

Motorola is a very large corporation.  Take a look at a quarterly report.
The organization that productize the UNIX ports is the Computer Group (MCG)
which is part of the General Systems Sector which includes the cellular phone
business.  The Memory and Microprocessor Techmology Group (MMTG) which
produces the '060 is part of the Semicondoctor Product Sector.
--
Dave Fields	Motorola Computer Group		dfields@urbana.mcd.mot.com
SVR4: The Winchester Mystery Kernel		uiucuxc!udc!dfields
From: nau@struppi.medizin.uni-ulm.de (Thomas Nau)
Subject: Re: CPU/FPU wiring
Organization: University of Ulm, Departement of Anaesthesia
Date: Thu, 7 Jan 1993 06:59:04 GMT

In article <1993Jan6.165832.18756@schbbs.mot.com>, TMKT76@waccvm.corp.mot.com (Daniel Fusils) writes:
|> >I'm interested to wire a system, which will be put to
|> >68000 socket. It should contain a 68882 at 24mzh and
|> >a 68010 with half that speed (My memory is 16bit thats
|> >why 68010). System should have a 68851 MMU too.
|> 
|> I don't think putting a 68851 with a 68010 is a good idea, since the
|> protocole exchanged between a 68020 and the '851 is microcoded.
|> Same comments for 68882. Even if you want to stick with a 16 bit memory,
|> why don't you put together an '020 + '881 (or '882) + '851 (connected
|> in 32 bit mode) and your 16 bit mem using the dynamic bus sizing
|> mechanism?
|> This stuff is pretty well described in the appnote AN944/D (consult
|> your closest Mot rep).
|> 
|> >The problem is to find out enough technical info, so
|> >I can make approiate logic to split that FPU on a
|> >16bit bus and make it work with 7mzh mother board
|> >asynchronously
|> 
|> This is pretty well described in the appnote AN947/D (consult
|> your closest Mot rep).

Why use a 68020 + MMU +FPU if you can simplify your design by using a
68030 + FPU ? We did it for an Atari accelerator board (68030-25 with 68882-33)
and it works fine.

Thomas
-- 
**********************************************************************
                 Thomas Nau (nau@medizin.uni-ulm.de)
       Departement of Anaesthesia, University of Ulm, Germany

                    think about 42 and DONT PANIC
**********************************************************************
From: tom@afthree.as.arizona.edu (Thomas J. Trebisky)
Newsgroups: comp.sys.m68k
Subject: Re: 68010
Date: 12 Jan 93 20:24:24 GMT
Distribution: usa
Organization: University of Arizona, Tucson, AZ

miller@hmsp04.wg3.waii.com (Griff Miller X7114) writes:
>Hi. I have an Amiga 500 in which I have installed a 68010. It's the long,
>skinny one (I understand some 68000/68010's are squarish). It's also
>gray, not black (ceramic). Anyway, when I bought it I was looking for a
>16mHz version but could only find 10mHz (I think - something < 16 mHz,
>at any rate). Is there just not a 16 mHz 68010 available?

It is my understanding that the fastest 68010 ever in regular production
is(was) the 12 Mhz chip.  It is possible that selected parts might have
tested for 16 Mhz use -- hard to say.

>Also, 68010's are supposed to be able to work with a math coprocessor.
>Which one, and how is it done?

The 68010 does not have a coprocessor interface.  You could set up a
coprocessor chip as a peripheral (decoding it somewhere in the address
space).  Then you could code routines to essentially emulate the coprocessor
access via software.  You could even install these routines as handlers
for the F-line emulator traps that would result on an 010 from instructions
intended for the 68881 say.  However this buys you largely compatibility
and is not a big performance win (as you might guess).  The moral of the
story if you want performance is to go with a 68020 and 68881/2, that is
the "right way" to build an accelerator board.
--
	Tom Trebisky	ttrebisky@as.arizona.edu
"Did you know that 500,000 trees are consumed in America each week
to produce our Sunday newspapers.  Never mind recycling, why even
take the paper?"
Newsgroups: comp.sys.m68k
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Subject: byte swap
Organization: Jet Propulsion Laboratory
Date: Fri, 8 Jan 1993 17:58:20 GMT

	A while ago someone posted an algorithm that used the stack in
someway to invert bytes. Said it originally appeared in Byte magazine
and was faster on a 68000 than an LSR #8. I didn't keep a copy of this
post and I should have. Would some kind sole please repost it? 

thanks, jeff
From: lee@deneb.sw.stratus.com (Lee Cooprider)
Newsgroups: comp.sys.m68k
Subject: Need a 68030 instruction set simulator
Date: 7 Jan 1993 16:43:21 GMT
Organization: Stratus Computer, Software Engineering
Distribution: world
NNTP-Posting-Host: deneb.sw.stratus.com

I'm looking for source for a 68030 instruction set simulator to incorporate
into large simulation project.  The environment is C/C++ on a SparcStation.
Any pointers would be appreciated.

-- 
Lee W. Cooprider				PP-ASEL/IA
Lee_Cooprider@vos.stratus.com			Skylane N2908F "Wiley"
Newsgroups: comp.sys.m68k
From: apelled@cix.compulink.co.uk (Adam Pelled)
Subject: Re: CPU/FPU wiring
Reply-To: apelled@cix.compulink.co.uk
Date: Sun, 10 Jan 1993 01:40:00 +0000


In article <1993Jan7.065904.29670@wega.rz.uni-ulm.de>, nau@struppi.medizin.uni-ulm.de (Thomas Nau) writes:
>Why use a 68020 + MMU +FPU if you can simplify your design by using a
>68030 + FPU ? We did it for an Atari accelerator board (68030-25 with 68882-33)
>and it works fine.
>
>Thomas
>-- 
>**********************************************************************
>                 Thomas Nau (nau@medizin.uni-ulm.de)
>       Departement of Anaesthesia, University of Ulm, Germany
>
>                    think about 42 and DONT PANIC
>**********************************************************************

Thomas,
    Which Atari accelerator board is that ? i have 50Mhz 030 + fpu and no
board to put them in. Dave Small seems to have disappeared. i'd like to hear
about your design.

Regads
    Adam.
From: tatulund@polaris.utu.fi (Tatu J. Lund)
Newsgroups: comp.sys.m68k
Subject: CPU/FPU wiring
Date: 6 Jan 93 11:27:30 GMT
Organization: University of Turku
X-Newsreader: Tin 1.1 PL5


	I'm interested to wire a system, which will be put to
	68000 socket. It should contain a 68882 at 24mzh and
	a 68010 with half that speed (My memory is 16bit thats
	why 68010). System should have a 68851 MMU too.

	The problem is to find out enough technical info, so
	I can make approiate logic to split that FPU on a
	16bit bus and make it work with 7mzh mother board
	asynchronously
Newsgroups: comp.sys.m68k
From: gcall@systemname.uucp (Glen Call)
Subject: Re: A few Questions on the 68000 and 68008...
Originator: gcall@
Organization: Motorola Computer Group Marketing
Date: Mon, 11 Jan 1993 16:22:36 GMT


In article <steveh.726716248@tasman>, steveh@tasman.cc.utas.edu.au (Steve Howell) writes:
|> 
[stuff deleted]
|> 3) what is the base adress for RAM ($0000 is what a 6809 is at, but i hear its
|> not this simple with 68k devices?.. is this right?)

You can put RAM just about anywhere.  Since the 68k processors vector fetch from
$000000 upon power-up or reset, you will want either ROM or some kind of
pre-initialized memory (spells ROM to me :-) at 0 following power-up.  Many 
systems just shadow the ROM to $000000 for the first 4 word reads.  Why not put
ROM at $000000?  Reason: the 680000 and 68008 have the vector table fixed at
$000000-$0003FF.  Many people prefer to have their vector table RAM resident.

|> 4) Can i put ROM anywhere i like in the address map? (as long as its big enough)

Yes.

Good luck,
Glen

------------------------------------------------------------------------------
Glen Call                          Technical Marketing Systems Engineer
Motorola Computer Systems, Inc.    gcall@phx.mcd.mot.com or mcdapps!gcall
M/S DW212                          phone: (602) 438-3408
2900 S. Diablo Way                 pager: 1-602-244-3252 Pager#2818 (digital)
Tempe, AZ 85282                    FAX:   (602) 438-3534

Newsgroups: comp.sys.m68k
From: lemieux@spezko.enet.dec.com ()
Subject: Info wanted on Fortune systems 32:16 system
Reply-To: lemieux@spezko.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Mon, 11 Jan 1993 20:15:51 GMT



	I'm looking for any and all info on a system that I recently aquired.
	Its from Fortune systems, it's labeled 23:16 and it runs a version
	of UNIX that is called FOS1 by the manufacturer. Its a 68000 based
	unit and I believe it was sold as a word processing system. Seems
	to work fine and I'd like to put a more complete version of UNIX
	on it. Any info appreciated. I couldn't find the manufacturer listed
	anywhere... possibly out of business.
Newsgroups: comp.sys.m68k
From: tgl+@cs.cmu.edu (Tom Lane)
Subject: Re: A few Questions on the 68000 and 68008...
Organization: School of Computer Science, Carnegie Mellon
Date: Mon, 11 Jan 1993 18:04:27 GMT

gcall@systemname.uucp (Glen Call) writes:
> You can put RAM just about anywhere.  Since the 68k processors vector fetch from
> $000000 upon power-up or reset, you will want either ROM or some kind of
> pre-initialized memory (spells ROM to me :-) at 0 following power-up.  Many 
> systems just shadow the ROM to $000000 for the first 4 word reads.  Why not put
> ROM at $000000?  Reason: the 680000 and 68008 have the vector table fixed at
> $000000-$0003FF.  Many people prefer to have their vector table RAM resident.

HP's 68000-based machines use a different method.  The ROM always lives at
locations 0 and up; the reset vector at location 0 points to startup code,
also in the ROM.  RAM in these systems starts at location $FFFFFFFF and
grows down for however much RAM you have.  The interrupt vectors in (ROM)
locations 8,12,etc point to RAM locations $FFFFFFFA, $FFFFFFF4, etc, which
are initialized to contain JMP-abs-long instructions (6 bytes each) to the
real interrupt handlers.  This gives you changeable interrupt vectors
without any extra hardware to diddle the ROM into and out of location 0.
It does cost you an extra JMP instruction per interrupt service, though.

If you are using 68010 or newer, a much better solution is to change the VBR
(interrupt vector base register) to point to RAM after powerup.

				regards, tom lane
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.sys.m68k
Subject: Re: Need Help with "MAI Basic-Four"
Date: 12 Jan 93 11:40:33 EST

hanscom@atlantis.eid.anl.gov (roger hanscom) writes:
>I've just been given an MAI Basic-Four system.  It is 68010 based and
>runs what appears to be a UNIX derivative called "UNOS".  It may have
>been developed by Charles River Data Systems.

Ayup.  UNOS[*] is not a UNIX[**] derivative, it was developed quite
independantly.  The MAI systems are probably old enough that they predate
the UNIX compatability effort, but UNOS had a fairly strong UNIX feel to it
even before passing the SVVS, at least in comparison to (say) VMS.  The
system administration was quite different, but in some ways vastly easier
(or so I'd like to think).

I'll send mail with more specific answers, since my Universe system is at
home...

[*] UNOS is a trademark (registered or not, I don't know) of Charles River
Data Systems.
[**] UNIX is a registered trademark, but I don't remember offhand whether
AT&T, Bell Laboratories, USL, or my dog currently actually owns the trademark.