HDTenEightyP/NetNews huggingface dataset:
From: breese@monet.imada.ou.dk (Bjorn Reese)
Subject: How many math coprocessors?
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Tue, 26 Jan 1993 12:38:13 GMT

In the January 90 issue of Byte there was an article on math
coprocessors. It stated that 68020/030 was capable of having
7 math coprocessors (68881/2) at the same time.

As far as I know this statement is false. I think that
68020/030/040 are capable of having 8 different types of
coprocessors; one type being math coprocessor, another
MMU, etc. Am I right?

Thanks in advance.
--

Bjorn Reese                    |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)
Newsgroups: comp.sys.m68k
From: chaplin@keinstr.uucp (Roger Chaplin)
Subject: Re: A few Questions on the 68000 and 68008...
Organization: Keithley Instruments, Cleveland, Ohio
X-Newsreader: TIN [version 1.1 PL8]
Date: Fri, 22 Jan 1993 13:57:17 GMT

Steve Howell (steveh@tasman.cc.utas.edu.au) wrote:

: ok.. its been somewhat confirmed that a 6809 is not avail in a SMD package, so
: i guess the time has come to go 68k at long last.

: just a few questions before i dive in...
: can i do the following with a mc68008?

: 1) can i use the upper address lines thru say a 74ls138 (3-to-8) decoder
: to create the enable signal for each pheripherial?.. or do i need some
: complex PAL or something (like everone elses uses that ive seen!)

A '138 decoder will work very nicely.  We sell a MC68008-based product
which uses '138 decoders to create chip selects.  Take a look at the
`complex PAL or something' you see used by `everyone else', and see if
there are some connections to DTACK, BERR and maybe HALT.  If so, the
`complex PAL or something' is probably also performing the timing
required by the 68k's asynchronous bus.

: 2) the E timming signal on the 68000. is it on the 68008?

Yes, but the VMA signal is not.  If you need VMA (which you will if you
want to connect Motorola 68xx peripherals) you will have to create it
from E and AS.

: 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?)

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

I'll answer 3 and 4 together.  At reset, both the 68000 and the 68008
load the stack pointer from memory locations $000000-000003 and the
program counter from $000004-000007.  Therefore the simplest memory
configuration has ROM starting at address $000000, RAM and peripherals
somewhere else.

BTW, in a 6809 system RAM does NOT have to be at address $0000.  In any
system, the primary consideration is placing ROM (or some other
non-volatile memory) where the CPU expects to find its startup
vectors.  This means that there had better be some kind of non-volatile
memory at $FFFE-FFFF in a 6809 system, and at $000000-000007 in a 68k
system.

One additional comment: since the 68k family has an asynchronous bus,
you will need quite a bit more logic to connect memory and peripherals.
See if you can get a copy of Motorola's AR226, a reprint of an article
from March 1984 _Wireless World_ entitled "Designing with the 68008
microprocessor."

-- 
Roger Chaplin / chaplin@keinstr.uucp / CI$: 76307,3506
"For the lines are long and the fighting is strong and they're breakin'
down the distance between right and wrong."
                        - Bob Dylan, "Ring Them Bells"
Newsgroups: comp.sys.m68k
From: gregh@cserver.plexus.com (Greg Hawley)
Subject: Re: 68010
Organization: Plexus Corp. -- Neenah Wisconsin
Date: Mon, 25 Jan 1993 23:06:23 GMT

jackb@mdd.comm.mot.com (Jack Brindle) writes:

>In article <6741@pdxgate.UUCP> idr@rigel.cs.pdx.edu (Ian D Romanick) writes:
>>In article <A5471@ST.maus.de> Ralf_Czekalla@st.maus.de (Ralf Czekalla) writes:
>>>Hello Griff,
>>>
>>>there has been a posting here in our MausNet, that a 68010-16 was offered
>>>in the MicroTimes from 28.9.92 with a price of 60 US$. And it was definitely
>>>said, that it was a 16MHz-one!
>>>
>>>The poster couldn't affirm, if it was a joke but try it ...!
>>
>>	I hope it's a joke!  That is a serious rip off.  I have seen the 8Mhz
>>version sold for (in bulk, i.e. 10+ ordered) for $5.  Going on that, the 16Mhz
>>shouldn't cost 12 times as much!  At least, I would hope it wouldn't...

>Take another look at your sources. 68000's are going in the $5 range. If
>you call up a Motorola distributor I'll bet you will find the $60.00
>price is somewhat current. My guess is that the 010 just hasn't achieved
>the volume level that the 68k has, and thus commands a higher price.
>Any Semi reps around that might comment on this?


The Motorola Semiconductor Price List effective January 9, 1993
lists the following prices for Motorola microprocessors.  This
information appears to be in the public domain.  I am not a
rep., but I do have access to a price list.  No price is given
for the '040.

	MC68000P12 (Plastic DIP 12 MHz '000)............. $6.55
	MC68010P12 (Plastic DIP 12 MHz '010)............. 36.80
	MC68020RP25E (Pin Grid Array 25 MHz '020)........ 57.90
	MC68030RP33B (Pin Grid Array 33 MHz '030)....... 139.62

This would seem to back-up the argument that '010 volume has not pulled
'010 prices down.  It is interesting to note that next to the '010
price, Motorola calls out "No New Designs".  This seems to imply that
Motorola is suggesting that this part (as well as the rest of the '010s)
should not be used for new products.

I would also note that the 16 MHz part that is supposedly available
from MausNet is NOT a Motorola part.  I would guess that this part is
just a 12 MHz part test to run at 16 MHz.  Mind you, there is nothing
wrong with doing this.  Most semiconductor manufacturers do this
all the time.  If a part won't run at the highest speed it is tested
for a lower speed.  If it passes at the lower speed, it is labelled as
such.  No big deal.  


--Greg
+---------------------------+----------------------------+-----------------+
|  __     __          ___   |  Greg Hawley               |  Expressed      |
| /  \|  /   \ / |  | \     |  Technology Group Inc.     |  Opinions are   |
| +--/|  +--  X  |  |  \    |  55 Jewelers Park Drive    |  mine and not   |
| |   \__\__ / \ \__/ __\   |  Neenah WI 54956           |  of Technology  |
|                           |  gregh@cserver.plexus.com  |  Group Inc. or  |
|  Technology Group Inc.    |  414-722-8748              |  Plexus Corp.   |
+---------------------------+----------------------------+-----------------+
From: jlewis@indyvax.iupui.edu
Newsgroups: comp.sys.m68k
Subject: 68HCxx Group?  Where?
Date: 26 Jan 93 15:26:25 -0500

Is there a 68HCxx microcontroller group around?  I see a few messages here
but there's bound to be a list more geared for this microcontroller area?

Thanks...
Jeff
Newsgroups: comp.sys.m68k
From: lhummel@urbana.mcd.mot.com (Lionel Hummel)
Subject: Re: The end of the MC680X0 UNIX era?
Organization: Motorola MCD, Urbana Design Center
	<1993Jan18.160809.7109@elegant.com> <C15o3C.IoE@root.co.uk>
Date: Mon, 25 Jan 1993 03:15:05 GMT

In article <C15o3C.IoE@root.co.uk> pls@root.co.uk (Peter Skan) writes:

> In <1993Jan18.160809.7109@elegant.com> woods@elegant.com (Greg A. Woods) writes:
>> Rhetorically speaking, why wouldn't they drop SVR3 completely, since I
>> assume it wouldn't take much to include a working version of coff2elf,
>> and then they'd only have to support one O/S (on multiple platforms).
>
> Unfortunately, life is not so simple.  The whole system call interface in
> SVR4 is different, its not just a matter of COFF vs. ELF.  (I believe that
> coff2elf is only designed to work on .o files, BTW).
> Binary compatibility with SVR3 was given up a long time ago - there was
> no single binary standard for SVR3 on 68k anyway.

Yes and no.  Thanks to the 88k BCS/OCS, SVR3 binaries and sources have
little difficulty on SVR4.  Things start becoming muddy only when you
start pushing outside the ground covered by the standards or when you
get into DDI/DKI issues.

As you noted, the lack of applicable standards creates a problem
doing the same with the 68k.
                                      < Lionel
-----------
Lionel D. Hummel, Software Engineer
Motorola Computer Group, Urbana Design Center
lhummel@urbana.mcd.mot.com      uiucuxc!udc!lhummel

Disclaimer:  I'm no spokesperson.  I'm just me.
From: provo_b@kosmos.wcc.govt.nz (Bart)
Newsgroups: comp.sys.m68k
Subject: Re: 68HCxx Group?  Where?
Date: 27 Jan 1993 20:36:56 GMT
Organization: Wellington City Council (Public Access), Wgtn, Nz
Reply-To: provo_b@kosmos.wcc.govt.nz
NNTP-Posting-Host: kosmos.wcc.govt.nz

 , keithley@apple.com (Craig Keithley) writes:
>I'd kind of like to see a comp.sys.microcontrollers (or
>comp.microcontrollers).
>
>While I'm particularly interested in the 683xx and 68HC11 microcontrollers,
>it'd be worthwhile to have a general group so people could talk about the
>8031/8051, etc. microcontrollers.  comp.robotics gets a lot of HC11
>traffic, but thats mostly about the 6.270 and miniboard robotic
>controllers.
>
>Anyone else interested?  Should it be proposed to the net.gurus?
>
I think that such a move might simply increase the number of groups that you
would have to follow to catch anything of interest.  I have noticed a
tendancy for people to post microcontroller stuff in a number of groups, 
without considering which group would be most suitable.

I am interested in the Motorola range of 8 & 16 bit microcontrollers and 
find that I need to subscribe to the following groups to have a reasonable
chance of picking up net-traffic on these:
	sci.electronics   high traffic but needs heavy filtering, 68xx(x)
			  stuff tends to be initial enquiries.
	comp.sys.m6809    low traffic, occasional HC11 stuff
	comp.sys.m68k	  some 6833x/HC16 traffic 
	comp.robotics	  HC11/miniboard implementation basics lately, some
			  HC16 & 6833x posts.
	HC11 mailing list This covered HC11 and HC16 and 6833x, but I have not
			  seen anything from this list since June 1992.  Has it
			  disappeared???

What do others think?
What is the situation in foreign (non-Motorola) lands :-).
regards, Bart.


Bart Provo    |provo_b@kosmos.wcc.govt.nz |School of Electronic Engineering
PO Box 47-105 |access via: PC/AT+modem on |Central Institute of Technology
TRENTHAM      |home phone, (answer phone) |Private Bag 39-807
Wellington    |     in NZ: (04)-5277-054  |Wellington Mail Centre,  NZ.
NEW ZEALAND.  |     to NZ:+64-4-5277-054  |Phn:(04)5277-089 Fax:(04)5276-374
From: hanscom@atlantis.eid.anl.gov (roger hanscom)
Newsgroups: comp.sys.m68k
Subject: 68010 assembler wanted
Date: 21 Jan 93 02:47:56 GMT
Organization: Advanced Computer Application Center, Argonne National Laboratory

Does anybody have a pointer to an old version of the GNU assembler?  One
that supports the 68010?  I was disappointed to discover that the newer
versions of "gas" are for the 68020 only.  OR, does anybody know of a PD
assembler that could be used to generate code for a 68010?  I guess I'm
looking at a "which-came-first-chicken-or-egg" problem here too.  I've
got nothing to compile/assemble the assembler with, unless something like
"cc -target 68010 assembler.c" works on a Sun 3.  Any info much
appreciated.

          roger            hanscom@athens.eid.anl.gov
From: heller@cs.umass.edu (Robert Heller)
Newsgroups: comp.sys.m68k
Subject: Re: is there anyone who has compared m68k and ix86 ?
Date: 22 Jan 93 13:57:41 GMT
Organization: COINS, UMass, Amherst

In article <1993Jan21.154340.23424@murdoch.acc.Virginia.EDU>, jvn@fermi.clas.Virginia.EDU (Julian V. Noble) writes...
>> I have a 68020/68881 Definicon board (16 MHz) in my AST premium computer
>> (80286@10Mhz, 80287@8Mhz). The Savage benchmark, in optimized Forth, takes
>> 2.5 sec on the 80286/80287 pair, about 5x less on the 68020/68881 pair.
>> Clearly, a factor 2x from clock speed. Since the numbers are always on the
>> fpu there is no effect from 32-bit vs. 16 bit bus. So we are measuring
>> the raw speed difference of 68020/68881 pair vs. 80286/80287 to be 2.5 or
>> so. Does this help?  The Savage program follows:
>>  
>>         TASK SAVAGE
>>         : (SAVAGE)  F=1 F=0  0 DO  FOVER F+ F**2  FSQRT  FLN  FEXP
>>                 FATAN  FTAN   LOOP  ;
>>         : SAV  FINIT  ( TIMER )  2500 (SAVAGE)  ( ETIME )  
>>                 CR  F.  FDROP ;
>>  
>> Cheers! --J.V. Noble

When BYTE published its first IBM-specific special issue (early '80s sometime), I tried another benchmark in the article on the '286/287.  This was a benchmark where the value 1.0 (a float) was added to every element of a FORTRAN array of floats.  On my Stride 440 (10MHZ 68000, *no FPU* -- that is *software* floating point), the runtime for a C coded version was just as fast as a stock IBM-PC AT w/80278 (I think 8MHZ).  The 80287 is probably great IF you don't have to fetch or store floating point numbers 

in memory.   

More recently, BYTE did some benchmarks of MACs and 80386 boxes (late '80s) and found that for some things the '386s were faster and for some things ther MACs (68020s and 68030s) were faster.   Overall they were about the same (more or less).   The question is not which is "faster", but what it is you are trying to do, exactly, and which processor features will help you do what you want to do better.  The m68k chips have more registers and don't mess you up with a segmented address space.  The ix86 chips a

re more popular (for whatever that is worth).

		Robert Heller
InterNet:	Heller@CS.UMass.EDU
BIX:		locks.hill.bbs
FidoNet:	1:321/153 (Locks Hill BBS, Wendell, MA)
CompuServe	71450,3432
Newsgroups: comp.sys.m68k
From: lhummel@urbana.mcd.mot.com (Lionel Hummel)
Subject: Re: The end of the MC680X0 UNIX era?
Organization: Motorola MCD, Urbana Design Center
	<1993Jan18.160809.7109@elegant.com>
Date: Mon, 25 Jan 1993 02:52:28 GMT

In article <1993Jan18.160809.7109@elegant.com> woods@elegant.com (Greg A. Woods) writes:
> In article <1993Jan12.183816.16619@phx.mcd.mot.com> fredch@phx.mcd.mot.com (Fred Christiansen) writes:
>> (disclaimer:  I'm no spokeperson.  I just have opinions which Marketing
>> usually does not inquire about.) is that it's a resource issue; fully
>> supporting 68k and 88k hosts for both R3 and R4 Unix would require a certain
>> amount of resources which the higher-ups may not feel we have.
>
> Rhetorically speaking, why wouldn't they drop SVR3 completely, since I
> assume it wouldn't take much to include a working version of coff2elf,
> and then they'd only have to support one O/S (on multiple platforms).

SVR3 couldn't possibly go away that easily.  Even with the BCS/OCS
compatibilty available on SVR4, there are still device drivers and
other forms of SVR3 system support that take time to move to SVR4.

                                      < Lionel
-----------
Lionel D. Hummel, Software Engineer
Motorola Computer Group, Urbana Design Center
lhummel@urbana.mcd.mot.com      uiucuxc!udc!lhummel

Disclaimer:  I'm no spokesperson for my employer; I'm just me.
From: bleck@mobot.ai.mit.edu (Olaf Bleck)
Newsgroups: comp.sys.m68k
Subject: Re: MC68332 TCR1/TCR2 Problem
Date: 21 Jan 1993 05:45:53 GMT
Organization: MIT Artificial Intelligence Laboratory
Distribution: world
Reply-To: bleck@ai.mit.edu
NNTP-Posting-Host: mobot.ai.mit.edu

In article <1993Jan19.220045.28984@newsgate.sps.mot.com>, Jeff Loeliger <jeffl@darth.sps.mot.com> writes:
|> This is not a stupid feature. It provides the best possible real time
|> response.
|> With the greater than or equal comparator, if an event gets scheduled in
|> the "past"
|> it will happen immediately. This is useful if the TPU misses an event do
|> to heavy
|> loading. If the event was scheduled for $9000, but the TCR was $9002 by
|> the
|> time the TPU serviced the request the match will happen immediatly. If
|> the TPU
|> had only a equal comparator the match would happen $FFFD counts late!

Well, there is some merit to this claim, but if you're scheduling things so
close to the time when they're supposed to happen, then I'd want to rethink
the code.  Additionally, if you count on this to execute late scheduled
events, and you're depending on knowing when the event actually happened so
that you can schedule the next even relative to that time, then it's
important to realize that the TPU channel in fact saved the *actual time*,
i.e. the $9002, instead of the $9000.  Thus this little error in time will
propagate through and grow until and can resync everything at some other known
time.



|> Events can be scheduled $8000 from the current time without a problem. If
|> you
|> want to scheule a event $8001 from the current TCR, you should shedule an 
|> event $1  and then $8000. The event scheduled $1 from the current time
|> will
|> be serviced late, but the $8000 will be service at the correct time.
|> Using this
|> method you should always schedule the >$8000 part of a event first, and
|> then
|> schedule events $8000 away or repeatedly schedule events $8000 away. This
|> will provide the mininal amount of loading on the TPU.


That's an interesting twist--wish I'd thought of it!  I will consider it 
(especially given that mod $8000 is pretty easy...)



|> >"draft" copy, but who knows what that means.  Basically it was a manual
|> for
|> >the TPU assembler, which is *not* on the BBS.  Then, you'll have to get a
|> >copy of all the stuff on the BBS, including the TPU assembler, and take
|> it
|> >from there.  One of these days I will be tackling this task too...
|> >     -stuff deleted-
|> 
|> The TPU assembler is on the BBS, I checked today (Jan. 19). The assembler
|> on the BBS
|> was meant to be used to assemble new "mixes" of functions on the BBS.



Ah, what I meant was that the TPU Assembler *Manual* is NOT on the BBS.  It's
the only place where I've actually found all the syntax of the TPU assembler
described.

-- 
Tear Here:
-----------------------------------------------------------------
_________________________________________________________________
Olaf Bleck					bleck@ai.mit.edu

Newsgroups: comp.sys.m68k
From: manoj@i88.isc.com (Manoj Dalmia (STG))
Subject: need help with MVME167 SCSI sw pkg
Organization: INTERACTIVE Systems Corporation, Naperville, IL
Date: Tue, 26 Jan 1993 17:16:14 GMT



I'm trying to use, without much success, the SCSI software package
on a MVME167. I would appreciate any pointers to get it to work
from people who have been successful with it, or are familiar with
this pkg.

Basically, this pkg serves as a layer of code above the NCR SCSI
SCRIPTS processor on the board. According to the documentation, 
it is possible to send out SCSI CDBs to the SCRIPTS processor via
this layer of code.

I am making a trap #15 call to the .SIOPEPS function in M167Bug
to retrieve the SCSI pointers from M167Bug.
Then I initialize the above-mentioned layer of code via a call
to one of these ptrs.

When I try to send out a SCSI Inquiry cmd, the SCSI sw pkg comes back
with an error from the SIOP saying that "a bus error occurs when
the SIOP is attempting to access the local bus while it is physically
threaded to a SCSI device in any phase other than a SCSI bus 
DATA PHASE (i.e, BERR while sending a CDB out to target). ... 
The err_addr field of the siop_struc points to the fault address."

The fault address I get in the err_addr field of the siop_struc
is 0xBA7A200C. I get this fault address consistently.
The address has nothing to do with reality, it seems.
My program is operating out of SRAM on the board,
between 0xffe10000 and 0xffe20000.
There is only 32 Mb of RAM on the board (0x2000000).

I seem to get this error no matter what I try.

I would appreciate any pointers from you if you've been successuful
with this package, or are familiar with it.


Regards,

Manoj


Newsgroups: comp.sys.m68k
From: mteinone@snakemail.hut.fi (Matti Teinonen)
Subject: Olivetti LSX 3010, C anyone?
Organization: Helsinki University of Technology, Finland
Distribution: comp
Date: 21 Jan 93 08:56:03 GMT


The idea was to get a small post machine of an old Olivetti
LSX machine. It is Motorola 68020-based and it has its own
variate of sysVr3. Because they called it a mini back in the
end of 80's, there was never a C-compiler with the operating
system. It was naturally sold separately. Most of these 
machines were used for accounting and the sorts, so most
programming was done with Cobol - or so they say.

Nowadays the then sold C is no longer available and I have
no means to compile a gcc or anything else for the machine.
Does anybody of you know how to get some C or any other
workable compiler other than Cobol?

Help appreciated

And please point a better forum, if this is not the one.

Matti Teinonen

---
Matti.Teinonen@hut.fi
Newsgroups: comp.sys.m68k
From: gregh@cserver.plexus.com (Greg Hawley)
Subject: FAQ Progress (was Re: convert to hex)
Organization: Plexus Corp. -- Neenah Wisconsin
Date: Fri, 22 Jan 1993 14:59:40 GMT

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

>>btw we realy should have a FAQ for this group

>There are folks including myself and especially Greg Hawley that are working 
>on A FAQ. Unfortunately it takes lots of time and energy to do it right. 
>Would you like to help?

>BAJ
>---
>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

Because of the holidays, a nasty cold, a new project at work, and the
ongoing work building my own 68010 machine, progress on the FAQ for
comp.sys.m68k has been slow.  As traffic has begun to pick up, I'll
try to get some work done on the darn thing this weekend and release
something to the net next week (Jan 25-29).  I am quick to point out this
is NOT a promise, just a hope.  That is to say, don't insert the 
perennial "read my lips" here. :-).

As always, you suggestions are welcome at gregh@cserver.plexus.com

--- Greg
+---------------------------+----------------------------+-----------------+
|  __     __          ___   |  Greg Hawley               |  Expressed      |
| /  \|  /   \ / |  | \     |  Technology Group Inc.     |  Opinions are   |
| +--/|  +--  X  |  |  \    |  55 Jewelers Park Drive    |  mine and not   |
| |   \__\__ / \ \__/ __\   |  Neenah WI 54956           |  of Technology  |
|                           |  gregh@cserver.plexus.com  |  Group Inc. or  |
|  Technology Group Inc.    |  414-722-8748              |  Plexus Corp.   |
+---------------------------+----------------------------+-----------------+
Newsgroups: comp.sys.m68k
From: jtr@oakhill.sps.mot.com (Jim Reinhart)
Subject: Re: Info on 68060 wanted...
Organization: Motorola Inc., Austin Tx.
Date: Fri, 22 Jan 1993 15:25:05 GMT

In article <1993Jan21.224945.3148@csd.uwe.ac.uk> j_wilson@csd.uwe.ac.uk (Hi how are you) writes:
>Hi, just a quick one.
>Iv'e seen a lot of talk about the MC68060 recently. What is the primary
>differences between this and previos moto processors ?
>Thanks,
>Jamie.

The 68060 is the next-generation of architectural evolution of the 68000
family.  It's major enhancements (relative to the 68040) include:
  - Superscalar operation (int|int or int|float) w/ superpipelining
  - Branch Caching & Prediction (zero delay for predicted taken branches)
  - Larger Caches (8k icache & 8k dcache)
  - Full Hardware Instruction Execution (no microcode)
  - Fully static, 3.3v operation
  - Faster Floating Point
  - Configurable Bus Operation (full speed, half speed, ...)
  - Extended write buffering (4x 32bit fifo)

It's major similarities include:
  - 100% User object code compatible (may need some simple OS hacks)
  - Compatible w/ existing support ASICs (superset of 040 package)

That's the nickel tour.
-- 
Regards, 
Jim Reinhart
Motorola Microprocessor & Memory Technologies Group
Austin, Texas
Newsgroups: comp.sys.m68k