HDTenEightyP/NetNews huggingface dataset:
From: cpg@cs.utexas.edu (Carlos M. Puchol)
Newsgroups: comp.sys.m68k
Subject: S-records
Date: 12 Aug 1992 14:25:45 -0500
Organization: Department of Computer Sciences, UT Austin
Distribution: world
NNTP-Posting-Host: atacama.cs.utexas.edu

Hi, I have a request for sources for translation programs
for S-Records. Let's see:

1) I have a file that looks like this:

S30500000000FA
S320000800C01B454D3638303030204D6F6E69746F722056554255472056342E30B3
S320000800DB472037204665622C20313939310D0A0A003A2042616420436F6D6DE3
S30B000800F6616E640D0A00AC
S320000801000000000000000000000000000000000000000000000807B2200027CE
S30A0008011B000D0A210099
S3200008040046F90008011A13FC0000000C041B13FC0080000C041D323C00FF22EC
S3200008041B7C00000000247C0008000022DA5BC9FFFC323C000A43F90000055070
S32000080436429951C9FFFC13FC0020000C040513FC0030000C040513FC002000E6
S72000080436429951C9FFFC13FC0020000C040513FC0030000C040513FC002000E6
-- deleted --
S3200008432D58484022094A00670000180280000000FF488048C0D280200161006E
S31900084348C4186000000E301948C0D28020016100C4084E7555
S70500000000FA

What are these called? [Let's call them S3/S7-records or Motorola Records]

2) I have an eprom programmer that will accept files like this:

:10000000F6260E2029204DC6031D1F01C6021D170E
:1000100026092040C6021D1F01C6021D1725FC200F
:1000200033C6011D1F01C6021D1725EF2026C12E54
:1000300027D5C13D27D1C18027DAC18127D6C1820A
:1000400027D2C18327CEC1A027CAC1AE27B7C1AF6F
-- deleted --
:103FD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1
:103FE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE1
:103FF000FFFFE7CCDBA4DBA4D740DBA4F183DBA489
:00000001FF

What are these called? [Let's call them Intel records]

Now the problem is:

I need to program two eproms, each of which has to be programmed in even
and odd bytes. Now I would need a program to split the S3 file into two
S3s and then a translator to Intel for the programmer. Apparently, I found
a program that claimed to do all that, but the program says

	"error, file mon.s3 has not an 'S' in column 1"

when fed with the S3-record file. I seem to remember that there exist
another format called S1 or similar. Is there such a thing?

I figure that there must be plenty of programs out there in some
ftp site that have these translating and splitting utilities.
Can someone help me out, please? Any pointer is appreciated.
If there is a document that specifies these formats, I would also
like to know. It can be figured out quite easily, but I'd rather
know "officially".

Thanks in advance!!

-- Carlos Puchol
-- cpg@cs.utexas.edu		CS Department, UT Austin
-- 
-- Carlos Puchol
-- cpg@cs.utexas.edu		CS Department, UT Austin
From: shome@eeserv.ee.umanitoba.ca (Tapas Shome)
Newsgroups: comp.sys.m68k
Subject: MC68020 simulator
Summary: Need Info regarding MC68020 Simulator on Sparc.
Keywords: Simulator.
Date: 21 Aug 92 21:51:54 GMT
Organization: University of Manitoba, Winnipeg, Canada

Need info reagrding Mc68020 simulator running on sparc.

I will summerize.
Tapas shome
--
Parallel Systems are easier to built than to use them---- MIT. 
E_mail: (Tapas Shome )shome@eeserv.ee.umanitoba.ca, tshome@ccu.umanitoba.ca
Aim:  Ordnung ist halve laben. Arbeit macht ordnung.
From: nabil@qiclab.scn.rain.com (Aaron Nabil)
Newsgroups: comp.sys.m68k
Subject: 68k dissassembler wanted
Date: 21 Aug 92 09:51:51 GMT
Article-I.D.: qiclab.1992Aug21.095151.15655
Distribution: usa
Organization: Explosive Space Modulators - R - Us

I'm sorry this is probably a FAQ.

I have a 68020 ROM image I need to dissasemble, and I've looked at 
the comp.sources.misc 68kdisassem and 68kdisasm and found them 
wanting.  Is there anything better out there?
-- 
Aaron
nabil@cse.ogi.edu
Newsgroups: comp.sys.m68k
From: manoj@i88.isc.com (Manoj Dalmia (STG))
Subject: Re: S-records
Followup-To: comp.sys.m68k
Summary: EPROM programmer
Keywords: EPROM programmer
Organization: INTERACTIVE Systems Corporation, Naperville, IL
Distribution: usa
Date: Tue, 18 Aug 1992 14:17:56 GMT


In article <l8l271INNo2q@trurl.cs.utexas.edu> cpg@cs.utexas.edu (Carlos M. Puchol) writes:
>Thanks to all that responded. We have decided to get a new 
> EPROM programmer that works with S-Records. We would need to plug it to a SPARCstation
>serial line, so we would need the software to run in it. Would you please
>give me any pointers to US companies that sell this kind of programmer?
>All of the programmers we have found are for PCs. With an internal card
>attached.
>Thanks again!!
>
>-- Carlos Puchol


We recently bought the EPROM-1 programmer from Intl Microsystems Inc.
We are very satisfied with both the product and the service provided
by their technical support dept.
It handles both Motorola S-records and Intel format as well as a few 
others. We use it on a serial port on a Sparc-station, as you propose to.

International Microsystems, Inc 
521 Valley Way
Milpitas, CA 95035

Phone: (800) 237-4734

We have no affiliation with this company. We are just satisfied customers.

Regards,

Manoj
From: cpg@cs.utexas.edu (Carlos M. Puchol)
Newsgroups: comp.sys.m68k
Subject: Re: S-records
Date: 13 Aug 1992 11:08:01 -0500
Organization: Department of Computer Sciences, UT Austin
Distribution: world
NNTP-Posting-Host: trurl.cs.utexas.edu

Thanks to all that responded. We have decided to get a new EPROM programmer
that works with S-Records. We would need to plug it to a SPARCstation
serial line, so we would need the software to run in it. Would you please
give me any pointers to US companies that sell this kind of programmer?
All of the programmers we have found are for PCs. With an internal card
attached.

Thanks again!!

-- Carlos Puchol
-- cpg@cs.utexas.edu		CS Department, UT Austin
-- 
-- Carlos Puchol
-- cpg@cs.utexas.edu		CS Department, UT Austin
Newsgroups: comp.sys.m68k
From: sapp@falcon.ssc.gov (Kevin Sapp)
Subject: 040 FPU SW
Originator: sapp@sawdust.ssc.gov
Keywords: 68040
Organization: Superconducting Super Collider Laboratory, Dallas
Date: Fri, 21 Aug 1992 21:34:39 GMT


Greetings,

I am working on a port from a 030 to an 040 card.  The compiler has 
the 040 software libraries, but they are  SSSSSSSLLLLLLLLOOOOOOOOWWWWWWW.

Does anyone have a source for some GOOD FPU code (interested in the
trig functions)? 

Thanks for any help.
Kevin
sapp@falcon.ssc.gov



-- 
----------------------------------------------------------------------------
Kevin A. Sapp                         "A civilization depends upon the
Superconducting Super Colider          quality of individual it 
2550 Beckleymeade Ave. MS 4004         creates"
From: wilker@hopf.math.purdue.edu (Clarence Wilkerson)
Newsgroups: comp.sys.m68k
Subject: Re: Looking for a 68000 C cross compiler on PC
Date: 20 Aug 92 19:40:15 GMT

Check out some of the source groups for Atari and Amigas.
There's available in source form
"North C"
Sozaabon C
C68k vIII in minix collection at plains.nodak.edu.
All these are much smaller in source form than GCC.
They may not be ANSI, but they're usable.

You can check out the FISH disk collection for Amiga sources.
-- 
Clarence Wilkerson      \ Bitnet:       wilker%math.purdue.edu@purccvm
Prof. of Math. (topology)\ Internet:    wilker@math.purdue.edu
Dept. of Mathematics      \ messages:   (317) 494-1903, FAX 494-0548
Purdue University,         \ office:    (317) 494-1955 (voice/modem)
W. Lafayette, Indiana 47907 \ 
Newsgroups: comp.sys.m68k
From: jjsmith@nyx.cs.du.edu (Jonathan J. Smith)
Subject: Re: 020 vs 030
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Thu, 13 Aug 92 01:22:27 GMT

In article <1992Aug12.234441.11526@oakhill.sps.mot.com> floydg@oakhill.sps.mot.com (Floyd Goodrich) writes:
>ahansfor@hongkong.wpi.edu (Andrew L. Hansford) writes:
>>
>>Another group is having a discussion on whether the 020 or 030 should
>>be the minimum processor used in new systems.  So I have a few
>>questions that I would like to post to a place of finding a more
>>accurate answer.
>>
>>First assume that MU is not needed by the OS so an EC030 could
>>probably be used. (Several accelerators do this)
>>
>>Given the same clock speed, the EC030 would be faster than the 020 due
>>to the data cache, and burst cycles (if the memory supports burst). Correct?
>
>Correct.  The 68030 supports burst mode (for 32-bit accesses) and has a
>256kbyte data cache.  The cache really boosts performance on loops of <256kb.
^^^^^^^^^^
it has a 256Kbyte data cache????? woah, hold on, unless Im way out in the blue yonder I was under the impression it was a great deal smaller!
(just checking, don't have a data book handy)... 256Kbytes, seems a tad on the large side though.

>Don't forget that the STERM pin on the 68030/EC030 bus interface allows you
>to terminate a bus cycle from a 32-bit memory bank in 2 clocks instead of 3
>as the 68020 requires. At the same frequency, based on dhrystones, you get:
>    020/EC030 = 0.75 in terms of performance.
>
>>Does the EC030 have any other advantaged over the 020?
>
>It's offered in clock speeds up to 50MHz instead of just up to 33MHz.  The
>package types are different, too.  Some of the bus specs are better on the 030.
>
>>IS the EC030 pin compatible with the 030 so if you needed a PMMU later
>>you could just pop a 030 in place of the EC030.  Does the EC030 have a
>>the coprocessor interface for an 882?
>
>It's pin compatible with the 030.  The EC030 retains the coprocessor interface.
>
>>What is the current $$/chip in lots of 10,000 for the 030,EC030, and 020?
>
>Call your local Motorola Sales Office.  The number in Boston is 617 932-9700
>or in Berlin, MA is 508 481-8100.  They can help you get data books, too.
>
>---
>Floyd Goodrich
>floydg@oakhill.sps.mot.com
>
Newsgroups: comp.sys.m68k
Subject: Re: S-records
From: bill@mri.com (Bill Weinberg)
Date: 21 Aug 92 01:05:23 GMT
Organization: Microtec Research Inc., Santa Clara, CA

In article <9722@kralizec.zeta.org.au> craig@kralizec.zeta.org.au (Craig Dewick) writes:
> 
>One thing that has perplexed me for a long time is why both manufacturers
>use different code storage methods? I think they must stem from early
>microcoding days when these formats were how the microcode images were
>set out be each company.
>
The origins of Intel HEX and Motorola S records have nothing to do with
"microcode" - no one uses ASCII hex formats for work with on-chip pro-
cessor internals.

To understand the origins of competing file formats, you must realize that
both Motorola S and Intel HEX formats were both originally developed to 
support the programming of 8-bit micros (6800 and 8008 respectively) with
(E)PROM programmers developed in-house by the two companies. Motorola used
to offer a programming board that went into the EXORciser* while Intel did
the same for its development tools (I forget their names). There were almost
no commercially available device programmers at the time (maybe Data I/O)
and so multiple standards were free to develop in-house.

Other competing ASCII/HEX formats include TEKHEX, Hitachi S records, and
others beyond my ken.


Bill Weinberg
Prod Marketing Mgr
Microtec Research Inc.

*now that I think about it, Motorola supported S records with its earliest eval
 boards, like the ones with MICbug too, before the EXORcisor.
Newsgroups: comp.sys.m68k
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: Pointer needed for gcc-2.2.2- cross library generationgk~[;z+
Date: Tue, 18 Aug 1992 13:22:42 GMT
Organization: TH-Darmstadt


>Also There seems to be some problem with COFF format genaration with
>gas1.38. The patches mentioned in gas1.36 do not work properly.

Yes, there were some bugs concerning structures and arrays. We did fix
as much as we could, for us gas-1.38 works reliable.

Have a look at 
	"ftp.th-darmstadt.de:/pub/incoming/local_ports/sysV68/"

Please send all complaints to :	
	"gnu@pdv2.fmr.maschinenbau.th-darmstadt.de",
as above mentioned port is _NOT_ approved by FSF and RMS.

best adams
From: cmhui@cucs18.cs.cuhk.hk (Hui Chau Man)
Newsgroups: comp.sys.m68k
Subject: C++ compiler for VME147, UNIX System V/68
Date: 19 Aug 92 02:56:37 GMT
Organization: Faculty of Engineering, The Chinese U. of Hong Kong

Dear Netters,

I am now using a VME147. The O/S UNIX Sysetm V/68 by Motorola. I would
like to know if there are any C++ compilers which can run on this
machine.

Thanks in advance.


C.M. Hui
Dept. of Computer Science
The Chinese University of Hongkong
Shatin, N.T.
Hongkong

Internet: cmhui@cucs18.cs.cuhk.hk
FAX: (852) 6035024
Newsgroups: comp.sys.m68k
From: jackb@mdd.comm.mot.com (Jack Brindle)
Subject: Re: S-records
Organization: Motorola, Mobile Data Division - Seattle, WA
Date: Fri, 21 Aug 1992 17:58:44 GMT

In article <1992Aug21.010523.17300@mri.com> bill@mri.com (Bill Weinberg) writes:
>
>The origins of Intel HEX and Motorola S records have nothing to do with
>"microcode" - no one uses ASCII hex formats for work with on-chip pro-
>cessor internals.
>
>To understand the origins of competing file formats, you must realize that
>both Motorola S and Intel HEX formats were both originally developed to 
>support the programming of 8-bit micros (6800 and 8008 respectively) with
>(E)PROM programmers developed in-house by the two companies. Motorola used
>to offer a programming board that went into the EXORciser* while Intel did
>the same for its development tools (I forget their names). There were almost
>no commercially available device programmers at the time (maybe Data I/O)
>and so multiple standards were free to develop in-house.

Actually, if I remember correctly, Intel Hex and Motorola S-Record formats
predate EPROM technology. Both were originally developed to enable the
"easy" transfer of data to be used in Masked ROMs. So, if you wanted a
mask ROM from either company, you would cut a paper tape (or punch cards)
with the image you desired (in the RIGHT format :-), and send it to the
company with your order. When the 1702 EPROM (256 bytes...) came out, it
was simply natural to use the same format to download the data into the
eprom programmer. Each format was developed by the manufacturer to go
with their own in-house mask ROM setup equipment.

>Other competing ASCII/HEX formats include TEKHEX, Hitachi S records, and
>others beyond my ken.

My favorite ('cause I used it so much) is MOS Technology hex format. There
_are_ a lot of them, aren't there...

>*now that I think about it, Motorola supported S records with its earliest eval
> boards, like the ones with MICbug too, before the EXORcisor.

The dump formatter was a staple in every manufacturer's debugger. So, MIKBUG
did indeed have S-Record support, as did MOS's TIM and KIM ROMs. Sorry, I
don't remember the debugger in Intel's 8080 EVK.

Ahhh. Thanks for the trip down memory lane. Maybe I'll dig out the old
Dr Dobbs Journal's this weekend...  Gee, I _really_ don't miss all the
paper tape problems any more ;-).

-- 
==========================================================
Jack Brindle
ham radio: wa4fib
internet: jackb@mdd.comm.mot.com
Newsgroups: comp.sys.m68k
From: shome@eeserv.ee.umanitoba.ca (Tapas Shome)
Subject: MC68020 Simulator wanted.
Summary: Sparc mc68020 simulator wanted.
Organization: University of Manitoba, Winnipeg, Canada
Date: Fri, 21 Aug 1992 16:03:02 GMT

 Need some mc68020 simulator for aprc for developing runtime libraries for the above target system.
All pointers will be appreciated.
I will summarize.

Tapas Shome

--
Parallel Systems are easier to built than to use them---- MIT. 
E_mail: (Tapas Shome )shome@eeserv.ee.umanitoba.ca, tshome@ccu.umanitoba.ca
Aim:  Ordnung ist halve laben. Arbeit macht ordnung.
Newsgroups: comp.sys.m68k
From: craig@kralizec.zeta.org.au (Craig Dewick)
Newsgroups: comp.sys.m68k
Subject: Re: S-records
Date: 19 Aug 92 00:50:46 GMT
Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32

cpg@cs.utexas.edu (Carlos M. Puchol) writes:

>Hi, I have a request for sources for translation programs
>for S-Records. Let's see:

It appears that what you want to do is convert a binary file stored
as Motorola S-Records into Intel hex format so it can be thrown at an
EPROM programmer??
 
>I need to program two eproms, each of which has to be programmed in even
>and odd bytes. Now I would need a program to split the S3 file into two
>S3s and then a translator to Intel for the programmer. Apparently, I found

As you said, you will need utilities to split the S-record file into
even- and odd-byte S-record files, then run these two through Intel
hex translators before feeding them to the EPROM programmer.
 
One thing that has perplexed me for a long time is why both manufacturers
use different code storage methods? I think they must stem from early
microcoding days when these formats were how the microcode images were
set out be each company.

-- 
                                   ___  ________  ________
 Craig Dewick                |    /  / /  _____/ /  _____/   --   INTEGRATED
 Send email to:              |   /  / /  /____  /  _____/   --   CONTROL
 craig@kralizec.zeta.org.au  |  /__/ /_______/ /_______/   --   ELECTRONICS
Newsgroups: comp.sys.m68k
From: shome@eeserv.ee.umanitoba.ca (Tapas Shome)
Subject: Info Needed for MC68020 Cross Assembler and Simulator For Sparc.
Summary: Need simulator/assembler package on sparc for gcclib1.c generation.
Organization: University of Manitoba, Winnipeg, Canada
Date: Tue, 18 Aug 1992 19:31:39 GMT

 I have just receiev NCSU's MC68000 simulator assembler package.
I need simuilar package for MC68020 processor.
I am planning to use these packages for libcc1.c development for
gnu-2.2.2 cross compiler.

Any pointers and or documents will be appreciated.
I also promise to post the summary back in this group.


Tapas Shome
--
Parallel Systems are easier to built than to use them---- MIT. 
E_mail: (Tapas Shome )shome@eeserv.ee.umanitoba.ca, tshome@ccu.umanitoba.ca
Aim:  Ordnung ist halve laben. Arbeit mucht ordnung.
Newsgroups: comp.sys.m68k
From: mef@ehsl.mitre.org (Marc E. Fiucznski)
Subject: Re: Looking for a 68000 C cross compiler on PC
Organization: Electronic Hardware Standards Laboratory, MITRE Corporation,
	Reston, VA.
Date: Thu, 20 Aug 1992 18:58:39 GMT

Look for the GNU compiler.  I think that it is possible to get the GNU
C compiler working on a PC.

Marc

Newsgroups: comp.sys.m68k
From: floydg@oakhill.sps.mot.com (Floyd Goodrich)
Subject: Re: 020 vs 030
Organization: Motorola Inc., Austin Tx.
Date: Wed, 12 Aug 1992 23:44:41 GMT

ahansfor@hongkong.wpi.edu (Andrew L. Hansford) writes:
>
>Another group is having a discussion on whether the 020 or 030 should
>be the minimum processor used in new systems.  So I have a few
>questions that I would like to post to a place of finding a more
>accurate answer.
>
>First assume that MU is not needed by the OS so an EC030 could
>probably be used. (Several accelerators do this)
>
>Given the same clock speed, the EC030 would be faster than the 020 due
>to the data cache, and burst cycles (if the memory supports burst). Correct?

Correct.  The 68030 supports burst mode (for 32-bit accesses) and has a
256kbyte data cache.  The cache really boosts performance on loops of <256kb.
Don't forget that the STERM pin on the 68030/EC030 bus interface allows you
to terminate a bus cycle from a 32-bit memory bank in 2 clocks instead of 3
as the 68020 requires. At the same frequency, based on dhrystones, you get:
    020/EC030 = 0.75 in terms of performance.

>Does the EC030 have any other advantaged over the 020?

It's offered in clock speeds up to 50MHz instead of just up to 33MHz.  The
package types are different, too.  Some of the bus specs are better on the 030.

>IS the EC030 pin compatible with the 030 so if you needed a PMMU later
>you could just pop a 030 in place of the EC030.  Does the EC030 have a
>the coprocessor interface for an 882?

It's pin compatible with the 030.  The EC030 retains the coprocessor interface.

>What is the current $$/chip in lots of 10,000 for the 030,EC030, and 020?

Call your local Motorola Sales Office.  The number in Boston is 617 932-9700
or in Berlin, MA is 508 481-8100.  They can help you get data books, too.

---
Floyd Goodrich
floydg@oakhill.sps.mot.com

Xref: sparky comp.sys.m68k:1043 gnu.gcc.help:1937 comp.sys.misc:630
From: michael@vk2bea.UUCP (Michael G. Katzmann)
Newsgroups: comp.sys.m68k,gnu.gcc.help,comp.sys.misc
Subject: gcc and gas for 68332 ?
Keywords: gcc gas 68332
Date: 18 Aug 92 19:09:38 GMT
Followup-To: comp.sys.misc
Organization: Broadcast Sports Technology., Crofton, MD

Is the latest gcc (2.2) and gas useable on the 68332?  It has a 
few extra instructions than the 68020.
I'd like to hear from anyone who has and experience with it on this
micro-controller.

Please email to the address below..

-- 
Michael Katzmann	  >	Broadcast Sports Technology Inc.
~~~~~~~~~~~~~~~~	 <	Crofton, Maryland. U.S.A
Amateur Radio Stations:   >
NV3Z / VK2BEA / G4NYV	 <	opel!vk2bea!michael@uunet.uu.net
Newsgroups: comp.sys.m68k
From: floydg@oakhill.sps.mot.com (Floyd Goodrich)
Subject: Re: 020 vs 030
Organization: Motorola Inc., Austin Tx.
Date: Thu, 13 Aug 1992 14:39:07 GMT

In article <1992Aug13.012227.29329@mnemosyne.cs.du.edu> jjsmith@nyx.cs.du.edu (Jonathan J. Smith) writes:
>In article <1992Aug12.234441.11526@oakhill.sps.mot.com> floydg@oakhill.sps.mot.com (Floyd Goodrich) writes:
>>
>>Correct.  The 68030 supports burst mode (for 32-bit accesses) and has a
>>256kbyte data cache.  The cache really boosts performance on loops of <256kb.
>^^^^^^^^^^
>it has a 256Kbyte data cache????? woah, hold on, unless Im way out in the blue yonder I was under the impression it was a great deal smaller!
>(just checking, don't have a data book handy)... 256Kbytes, seems a tad on the large side though.
>

You are right.  I caught that after sending it.  Both the data and instruction
caches on the 68030 and EC030 are 256 byte not 256K byte.  What's a few orders
of magnitude among friends?  ;-)


---
Floyd Goodrich
floydg@oakhill.sps.mot.com
Newsgroups: comp.sys.m68k
From: rflukes@ccu.umanitoba.ca (Richard F. Lukes)
Subject: S-records
Organization: University of Manitoba, Winnipeg, Canada
Date: Tue, 18 Aug 1992 22:43:29 GMT

With all the recent discussions about S-records I thought I should
mention this.

I have recently written a C program to convert S-records (S0..S9)
to binary data or Intel Hex records.  The program can also print hex
dumps which are useful for debugging.  I wrote the program to burn
some EPROMs with software produced by the AS32 (68332) assembler.
Currently,  I have it working under Turbo C and SunOS (Sun Unix).
I still have not decided if I want to distribute the source program (i.e.
public domain) but I may decide to make DOS executables available
either by mail or anonymouse FTP.  If there is sufficient demand I
could make improvements etc...  The current version accepts a 32-bit offset
and can be used to produce 64KB ROMs.  S1,S2 and S3 formats are supported.

Please e-mail me directly.  All suggestions are appreciated.
--Rich
-- 
Richard F. Lukes                    rflukes@ccu.UManitoba.CA
Computer Science Department         (or rflukes@ccm.UManitoba.CA)
University of Manitoba
WORK: (204)-474-8696                HOME: (204)-257-6701
Newsgroups: comp.sys.m68k
From: gstovall@crchh67.bnr.ca (Greg Stovall)
Subject: 683XX series with on-chip FPU???
Reply-To: gstovall@crchh67.bnr.ca (Greg Stovall)
Organization: Bell-Northern Research, Richardson, Tx
Date: Mon, 17 Aug 1992 23:01:32 GMT

Does anyone know whether Motorola is planning on building
a version of the 683xx family (particularly the 68340)
with a built-in FPU?  I know the CPU32 core currently does
not support the coprocessor instructions...

Such a beast would work extremely well in a number of niche
embedded processor applications...

-- 
Gregory T. Stovall                gstovall@bnr.ca
Bell-Northern Research            ESN   444-7009
Richardson, Texas, USA            (214) 684-7009