HDTenEightyP/NetNews huggingface dataset:
From: tom@afthree.as.arizona.edu (Thomas J. Trebisky)
Newsgroups: comp.sys.m68k
Subject: Re: GCC cross compiler MSDOS --> 68k question
Keywords: GCC MSDOS 68000 cross compiler help
Date: 16 Nov 92 22:32:51 GMT
Organization: University of Arizona, Tucson, AZ

4bclass@bode.uwaterloo.ca (Elec/CompEng '92  Alumni) writes:
>Hello everyone,

>I am certain that someone out there has built a full GCC-based cross
>compiling environment hosted on an MSDOS machine and with a 68k target.

Good for you, you are a man of great faith and astounding confidence.

>I am looking for a fully compiled and built system to save me some time
>in doing this myself.

You and my aunt Frannie. :-)

>Would you please email me info on where such a beast can be obtained.  I
>appologize if this question has been asked before, but I just started
>reading this newsgroup.

OK, all kidding aside, I am not too optimistic about this.  I embarked
on an attempt to do this some time ago with gcc 1.39 and hit the following
barriers:

	The version of the Microsoft compiler I had then (4.0) was
	(to be polite) sadly lacking.  The gnu folks love to use run-on
	variable and function names like "expression_in_progress_now()"
	and such.  Microsoft cc chopped these to 6 or 8 characters which
	led to lots of nasty clashes.  Some other compiler gagging problems
	popped up that I forget the details of.  Some really gigantic
	.h files were choking the compiler as I remember.

	640K just won't cut it for gcc.  Running gcc 1.40 on my virtual
	memory 3b1 machine (a 68010 based machine running unix) will
	routinely use over 1M of address space, in fact on rare occasions
	it runs out of VM with a 3.5M address space.  One of my machines
	actually has 3.5M physical, so don't tell me I don't have `nuff
	swap space.

If you are determined, it could probably be done with one of the new
compilers (like Zortech C for the 386) that generate native mode code.
I agree it would be a nice thing. Another possibility is that this post
will bring someone out of the bushes to prove me wrong.

>
>Thank you for your time,
>	Alex Leyn

Best of luck -- my problems were solved by setting up a cross compiler
on a sun sparcstation, and then later by acquiring my 3b1 and using it
for cross development -- I have a spare, wanna buy a cheap 3b1?
--
	Tom Trebisky	ttrebisky@as.arizona.edu
...."There's no sense in being precise when you don't even
.... know what you're talking about." 
                       - John von Neumann
From: mwr@eng.tridom.com (Mark Reardon)
Newsgroups: comp.sys.m68k
Subject: Re: 68020 MOVEA vs LEA
Date: 20 Nov 92 17:48:21 GMT
Reply-To: mwr@eng.tridom.com (Mark Reardon)
Distribution: na
Organization: AT&T Tridom; Marietta, Georgia

In article <1992Nov17.190823.1347@brtph560.bnr.ca>, scottb@brtph690.bnr.ca (Scott Brasington P870) writes:
|> The instruction timing section of the motorola 68020
|> user's manual seems to indicate that a MOVEA immediate
|> is faster than an LEA, and that in one case the LEA.W is
|> slower than an LEA.L.  Can anybody verify this?
|>                                 -best-    -cache-    -worst-
|> MOVEA.W       #<data>.w,An     0(0/0/0)   4(0/0/0)   3(0/1/0)
|> LEA           #<data>.w,An     4(0/0/0)   4(0/0/0)   6(0/2/0)
|> 
|> MOVEA.L       #<data>.l,An     0(0/0/0)   6(0/0/0)   5(0/1/0)
|> LEA           #<data>.l,An     3(0/0/0)   6(0/0/0)   7(0/2/0)
|> 
Note that the # signs on the LEA instructions are in error.

Verify, no.  Accept, yes.  LEA instructions are able to do address
computation.  Even if that is not required is not unacceptable 
that it would possibly take longer to perform than a MOVEA.
I have noticed that the compiler writers have noticed this and
use the MOVEA instruction whenever possible.

As for the difference between the best LEA.W and LEA.L.  This
is probably because the LEA.W instruction requires an extend of
the word to be done.  After all, address registers can't load
just a word.  This means that the LEA.L in the best case has
the data ready to go and just slaps it into the register.
The LEA,W on the other hand must sign extend it first, ALWAYS.

|> Scott Brasington          scottb@bnr.ca
|> BNR INC                   Phone: 919-991-8217
|> RTP, NC 27709             Fax:   919-991-8369

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 
Newsgroups: comp.sys.m68k
From: hhc@athena.mit.edu (Hong-Hsiang Chen)
Subject: Re: GCC cross compiler MSDOS --> 68k question
Keywords: GCC MSDOS 68000 cross compiler help
Organization: Massachusetts Institute of Technology
Date: Tue, 17 Nov 1992 15:50:05 GMT

In article <1992Nov16.223251.1337@organpipe.uug.arizona.edu> tom@afthree.as.arizona.edu (Thomas J. Trebisky) writes:
>4bclass@bode.uwaterloo.ca (Elec/CompEng '92  Alumni) writes:
>>Hello everyone,
>
>>I am certain that someone out there has built a full GCC-based cross
>>compiling environment hosted on an MSDOS machine and with a 68k target.
[some stuff..]
>OK, all kidding aside, I am not too optimistic about this.  I embarked
>on an attempt to do this some time ago with gcc 1.39 and hit the following
>barriers:
[stuff about inadequacies of existing C compilers for MSDOS]

The obvious solution is to use gcc, of course!
DJ Delorie has had a port of gcc using a DOS extender for MSDOS for quite
some time now.  Since it seems that no-one has done this successfully yet,
that would be the place to start.
You'd probably want to set up Delorie's gcc on MSDOS then modify his sources
to spit 68k code...

You'd need more than 640k, though...
BTW, the 3b1 has a VM of only 2 megs for user space...blecch! ran up hard
against it using gcc 2.3.1, alas...

>If you are determined, it could probably be done with one of the new
>compilers (like Zortech C for the 386) that generate native mode code.
>I agree it would be a nice thing. Another possibility is that this post
>will bring someone out of the bushes to prove me wrong.
                                                         heh heh...
You'd probably be better off using gcc to bootstrap itself...but I don't
know how hacked Delorie's port is so I couln't tell ya...
>>
>>Thank you for your time,
>>	Alex Leyn
>--
>	Tom Trebisky	ttrebisky@as.arizona.edu
>...."There's no sense in being precise when you don't even
>.... know what you're talking about." 
>                       - John von Neumann  
Well, have fun!


--
-----
Sean Chen.  hhc@athena.mit.edu
"Nunc in scutella iaceo,/et volitare nequeo,/dentes fredentes video./Miser!"
  Olim lacus colueram, _Carmina Burana_
Newsgroups: comp.sys.m68k
From: rflukes@ccu.umanitoba.ca (Richard F. Lukes)
Subject: 68010 -> 68332 adapter?
Organization: University of Manitoba, Winnipeg, Canada
Distribution: na
Date: Tue, 17 Nov 1992 19:26:30 GMT

I am interested in building an adapter which replaces a 68010
with a 68332 (operating at the same clock speed).  This should
result in an almost two-fold increase in performance for many
existing 68010 designs.  First of all,  has anyone had any
experience with such an adapter?  Does Motorola provide an
application note describing a 68010->68020 adapter?  Does anyone
see any incompatibility problems I may encounter?

Any suggestions or comments would be appreciated.  The adapter
board would include a small boot EPROM, a PAL or two to convert
the few incompatible signals...

Thanks in advance,
--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.xerox
From: welch@news.cis.ohio-state.edu (Arun Welch)
Subject: Decoupling info-1100 and comp.sys.xerox
Organization: Info-1100 Mailing List
Date: Fri, 20 Nov 1992 12:09:22 GMT

Reviving the discussion we had a month or so ago on the contents of this
newsgroup...

Would anyone object if we decouple info-1100 and comp.sys.xerox?

...arun
From: sy9@cadmus.co.uk (Richard Fisker,x2355)
Newsgroups: comp.sys.misc
Subject: Re: Writing amiga disks on suns.
Date: 17 Nov 92 12:18:44 GMT
Reply-To: sy9@cadmus.co.uk
Organization: Sun Microsystems

In article 9027@newsgate.sps.mot.com, nahaym@soleil.tmc.edu (Michael Nahay) writes:
>Does anyone know if it is possible to read and write
>amiga disks on a Sun or HP workstation?
>
This is not possible. The way I transfer files between AMIGA and SUN is
by using MS-DOS format disks, which can be read/written on both systems
 Use Cross Dos or Messy-DOS (on FISH disks) on the AMIGA, /pcfs or
MTOOLS on the Sun. Works fine (and AMIGA-DOS text files are the same
format as UNIX, which also makes things easier). I always format my
MS-DOS disks on the AMIGA, since it ensures that they are formatted as
720K.

 
Richard Fisker (European Centre for Medium-Range Weather Forecasts)
-- Internet: RFisker@ecmwf.co.uk
-- Post:     ECMWF, Shinfield Park, Reading RG2 9AX, England
-- Phone:    - (44) 734 499355  -- Fax:      - (44) 734 869450
-----------------------------------------------
Newsgroups: comp.sys.misc
From: cobrin@rx.xerox.com (Steve Cobrin)
Subject: Re: Burroughs B20
Keywords: BTOS, CTOS, Unisys
Reply-To: cobrin@rx.xerox.com
Organization: Rank Xerox, Welwyn Garden City, UK
Date: Mon, 16 Nov 1992 14:47:06 GMT

Gosh, blast from the past time :-)

I worked on B20's just when Sperry and Burroughs merged about 7 years
ago. They were OEM'd by Burroughs from Convergent Technology who called
them NGen's. They were Intel based, and by the time I left B38 had '386
chips fitted in them.

The really neat thing about them, was that the modules (extras disks,
floppy's, etc) were added by just addding another "slice". The main
processor box was just slightly smaller than a Sun IPC/IPX box on its
side, to add another one just plugged in the another box, via some clip
mechanism, I never ever had to open a box. Power supplies were
separate, and consisted of "power-bricks" which one just plugged in to
the slices as one needed to.

The Operating System CTOS/BTOS version 2 (when I left), was probably
one of the best documented OS's I had seen since Unix Version 7, the
documentation was all based on the Systems Programming Language, which
was a superset of Pascal. It was a pleasure to use. We actually used C
on it, which wasn't quite as well integrated as the Pascal, but still
more than adequate. We ported Sperry's DCA architecture to run on it,
to allow a B20 to appear like a real Sperry host.

When we had the '286 and above versions, CTOS supported memory
management and multitasking long before DOS and its successors managed
to provide it. The main problem, I guess was the price, and lack of
marketting, lack of support of fancy graphics and screens. They were
and still are quite popular in Local Government and Banking markets.

Convergent also used to make minis running CTOS, and at one point sold
Unix Servers to Unisys which had CTOS underlying them. Nowadays I
believe Convergent/CTOS (or whatever it now called) is POSIX
compliant.


	-- Steve

Arpa Email address:	cobrin.sbd-e@RX.Xerox.COM
+------------------------------------------+---------------------------------+
| Rank Xerox, Systems Centre,              | Overseas +44 707   38 2276      |
| IMS Dept,                                | UK        (0707)   38 2276      |
|                                          | Fax      +44 707   38 2418      |
|   Bridgefields, Tewin Road,              +---------------------------------+
|   Welwyn Garden City, Herts,             | Xerox Intelnet: 8*668 2276      |
|   AL7 1BD, England, GB                   | Xerox address:  Cobrin:SBD-E:RX |
+------------------------------------------+---------------------------------+
From: dave@frackit.UUCP (Dave Ratcliffe)
Newsgroups: comp.sys.misc
Subject: Re: Murph's VAPORWARE Column for November 1992
Date: 14 Nov 92 18:50:58 GMT
Organization: Data Factory Services, Harrisburg, Pa.

In article <id.I0PU.WHE@ferranti.com>, peter@ferranti.com (peter da silva) writes:
> In article <9210271021.aa12345@WHARF.BRL.MIL> Sewall@UCONNVM.UCONN.EDU (Murph Sewall) writes:
> > Another venerable Apple 2 organization, Beagle Brothers, went
> > quietly out of business in October.
> 
> Aw man, that's like the Beatles breaking up...

You read it wrong Peter...

It was the BeaGles
              ^
:)

-- 
 ...uunet!wa3wbu!frackit!dave -or-                       |  Dave Ratcliffe  |
 frackit!dave@uunet.UU.NET -or- dave@frackit.uucp -or-   |  Sys. <*> Admin. |
 vogon1!compnect!frackit!dave@psuvax1.psu.edu            | Harrisburg,  Pa. |
From: suhler@pollux.usc.edu (Paul Suhler)
Newsgroups: comp.sys.misc
Subject: Any Experience With "Pre-Owned Electronics"?
Date: 17 Nov 1992 12:12:38 -0800
Organization: USC Advanced Computer Architecture Laboratory
Distribution: usa
NNTP-Posting-Host: pollux.usc.edu

I'm considering buying a $329 reconditioned Syquest 44MB drive from
Pre-Owned Electronics, in Masschusetts.  They give a 90-day warranty,
but I'm not sure that the risk is worth saving $70.

Does anyone have any experience, good or bad, with them?

Thanks.  Please e-mail me and I'll summarize to the net if there's
interest.

Paul Suhler
Xref: sparky comp.sys.misc:969 alt.folklore.computers:16331
From: Walter.Harms@arbi.informatik.uni-oldenburg.de (Walter Harms)
Subject: Re: Writing amiga disks on suns.
Organization: University of Oldenburg, Germany
Date: Mon, 23 Nov 1992 13:42:00 GMT



there was a prg called berkley, with that device you can read the disk.
i didnt test it, yust read the readme.

A1000 forever           walter
Newsgroups: comp.sys.emulations,comp.sys.misc
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: Writing amiga disks on suns.
Organization: MetaPro Systems, Perth, Western Australia
Date: Wed, 18 Nov 92 02:02:13 GMT

In <1992Nov14.044314.9027@newsgate.sps.mot.com>
   nahaym@soleil.tmc.edu (Michael Nahay) writes:

>Does anyone know if it is possible to read and write
>amiga disks on a Sun or HP workstation?

Try writing DOS format (720K) and then read them on the
Amiga using one of the available DOS filesystem handler
(commercial or otherwise). CrossDOS, MultiDos, Msh and a
couple of others on the Amiga seem to do OK.
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
From: rtstoney@memstvx1.memst.edu
Newsgroups: comp.sys.misc
Subject: HELP!
Date: 23 Nov 92 20:30:30 -0600
Organization: Memphis State University

I AM SEEKING SOME TECHNICAL INFORMATION ON WESTERN DIGITAL, SEAGATE, 
AND CONNER HARD DRIVES.  I NEED THE FOLLOWING INFORMATION FOR THE
FOLLOWING DRIVES:

TRACKS PER CYLINDER, TRACK CAPACITY IN BYTES, AND DEVICE OVERHEAD IN BYTES.

WESTERN DIGITAL, AC2200 200MB HD
SEAGATE ST1239A 200MB HD

THANKS IN ADVANCE FOR ANY ASSISTANCE.
NO NEED TO POST TO THE NET.
From: cmac@cup.portal.com (Chris R MacAskill)
Newsgroups: comp.sys.pen
Subject: Re: GRiD Convertible Announcement
Date: Sat, 21 Nov 92 20:25:54 PST
Organization: The Portal System (TM)
Distribution: world

The idea GRiD has sounds pretty good.  I got about 8 PenPoint demos at Comdex
and all of them came off poorly because handwriting recognition is so
difficult.  Their entire interface depends on not just recognizing characters
but also gestures and it's just too complicated.  No one I saw could use one
with any speed, not even Go employees.

With the GRiD system you can use the pen for what it's good at -- pointing.
And you can use the keyboard for what it does well -- data entry.  Seems
sensible to me.
Newsgroups: comp.sys.pen
From: nagle@netcom.com (John Nagle)
Subject: Re: PERSONAL DIGITAL ASSISTANTS ON HOLD
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 17 Nov 1992 19:21:14 GMT

      The fundamental problem is that the so-called "PDA"s include all
the parts of a good laptop, plus the communications gear.  So a PDA
and a laptop will tend to be in the same price range.  This is not
a product-killing problem, but will delay things a few years.

      The user interface will remain a problem, although PenPoint is a
step in the right direction.  

      And besides, to take off in the consumer market, it will probably
have to receive TV, too.

					John Nagle
Newsgroups: comp.sys.pen
From: rparker@world.std.com (Randy Parker)
Subject: Boston pen meeting
Organization: NoteSystems, Brookline, MA
Distribution: comp.sys.pen
Date: Mon, 23 Nov 1992 04:35:44 GMT

            BOSTON COMPUTER SOCIETY PEN COMPUTING SIG (BCS*PEN)
                             DECEMBER MEETING
                       (Free and open to the public)

              Brainstorming about the Industry and the Market
                           (plus COMDEX Roundup)

              Wednesday, December 2nd, 7pm -- MIT, Room 4-163

        It has been a big year for the pen computing industry,
        and despite some "growing pains," the signs of
        maturation are clear.  1993 looks to be a promising
        year for the industry, and tonight subgroup members
        gather for an audience-participation discussion on
        what approaches to the market will be most successful
        for developers and other early adopters.  
        
        Also, we brainstorm regarding the group's focus for
        1993, as well as meeting topics, speakers, and
        projects.  Please join us and help make this subgroup
        meet your needs more effectively!!  (Plus all the
        usual giveaways, rumors, and a roundup of new pen
        products demonstrated at Fall COMDEX.)
  
        For more information, contact Randy Parker (75300.2654@compuserve.com)
        Location:          MIT, Building 4, room 163, Cambridge, MA.
        Directions:        Kendall Square/MIT stop on the Red Line.  
                           Parking along Memorial Dr. 
Newsgroups: comp.sys.pen
From: dale@manet.wustl.edu (Dale Frye)
Subject: Re: Newton Technology
Reply-To: dale@manet.wustl.edu
Organization: Washington University, School of Engineering, St. Louis MO
Date: Tue, 17 Nov 1992 16:04:04 GMT

In article <1992Nov16.193216.5158@ulrik.uio.no> rivero@cc.unizar.es  
(rivero) writes:
> In article <1992Nov14.095726.13059@nntp.hut.fi> Juri Munkki,
> jmunkki@vipunen.hut.fi writes:
> >The enthusiasm that people have for Newton technology will be one of
> >its possible keys to success. Would you rather have a situation where
> >no one ever gets exited about anything: "Oh yeah, I've seen that kind
> >of thing before, so what's new?".
> 
> For me, the new thing is ARM610, even thought before Apple other
> manufacturers had similar proposals with this chip; actually I
> dont know of any other pen-system using this or a similar chip. 
> In fact, almost all the proposals 486 bases. I expect the garbage
> collection will be better here.

Have you heard of the Hobbit processor that EO is using in their machine?  
Its a stack-based RISC design that sounds impressive. I called AT&T (maker  
of the Hobbit) yesterday and ordered tech data. I have some white papers  
written several years ago about AT&T's CRISP technology (on which the  
Hobbit is based). In a nutshell CRISP is designed to run C code. It has no  
registers. Instead it caches the stack so that stack references are as  
fast as registers. They get 13.5 MIPS at 3.3V (using 250mW!) and 20 MIPS  
at 5V (using 900mW). IMHO this will become the processor of choice for  
running PenPoint.

Dale Frye
Washington University in St. Louis
Newsgroups: comp.sys.pen
From: rivero <rivero@cc.unizar.es>
Subject: Re: Newton Technology
X-Xxdate: Mon, 16 Nov 92 14:23:06 GMT
Organization: fisica teorica UZ
X-Useragent: Nuntius v1.1.1d12
Date: Wed, 18 Nov 1992 13:25:30 GMT

In article <1992Nov17.160404.4456@wuecl.wustl.edu> Dale Frye,
dale@manet.wustl.edu writes:
>Have you heard of the Hobbit processor that EO is using in their machine?  
>Its a stack-based RISC design that sounds impressive. I called AT&T (maker  
>of the Hobbit) yesterday and ordered tech data. I have some white papers  
>written several years ago about AT&T's CRISP technology (on which the  
>Hobbit is based). In a nutshell CRISP is designed to run C code. It has no  
>registers. Instead it caches the stack so that stack references are as  
>fast as registers. They get 13.5 MIPS at 3.3V (using 250mW!) and 20 MIPS  
>at 5V (using 900mW). IMHO this will become the processor of choice for  
>running PenPoint.

I ack I have not tech data about the Hobbit. When you get it, could you
tell us how good is the memory management? For me that was a 
interesting point in the last ARM, that was inviting to put a object
oriented OS into (allthought the older ARM have always run with
Unix as preferred OS).

Alejandro Rivero
Theoretical Physica, Zaragoza Univ, Spain
From: ggolden@msen.com (Glenn Golden)
Newsgroups: comp.sys.pen
Subject: Re: GRiD Convertible Announcement
Date: 21 Nov 1992 12:28:27 GMT
Organization: Msen, Inc. -- Ann Arbor, MI
NNTP-Posting-Host: heifetz.msen.com
X-Newsreader: TIN [version 1.1 PL6]

I agree that the GRID machine sounds interesting, but it seems
like a continuation of the trend to shrink a desktop machine
(with it's 386 and Windows).

What I find *really* interesting is the new breed of machine;
ARM processor of some sort and PenPoint.

- Glenn R. Golden  |  Global Architect @ Comshare, Inc. |  Ann Arbor, MI, USA.
  (home) ggolden@msen.com   (work) ggolden@comshare.com


Newsgroups: comp.sys.pen
From: dale@manet.wustl.edu (Dale Frye)
Subject: Re: Newton Technology
Reply-To: dale@manet.wustl.edu
Organization: Washington University, School of Engineering, St. Louis MO
Date: Wed, 18 Nov 1992 19:55:07 GMT

In article <1992Nov18.132530.8651@ulrik.uio.no> rivero  
<rivero@cc.unizar.es> writes:
> In article <1992Nov17.160404.4456@wuecl.wustl.edu> Dale Frye,
> dale@manet.wustl.edu writes:
> >Have you heard of the Hobbit processor that EO is using in their  
machine?  
> >Its a stack-based RISC design that sounds impressive. I called AT&T  
(maker  
> >of the Hobbit) yesterday and ordered tech data. I have some white  
papers  
> >written several years ago about AT&T's CRISP technology (on which the  
> >Hobbit is based). In a nutshell CRISP is designed to run C code. It has  
no  
> >registers. Instead it caches the stack so that stack references are as  
> >fast as registers. They get 13.5 MIPS at 3.3V (using 250mW!) and 20  
MIPS  
> >at 5V (using 900mW). IMHO this will become the processor of choice for  
> >running PenPoint.
> 
> I ack I have not tech data about the Hobbit. When you get it, could you
> tell us how good is the memory management? For me that was a 
> interesting point in the last ARM, that was inviting to put a object
> oriented OS into (allthought the older ARM have always run with
> Unix as preferred OS).

So far I only have glossies on both processors. I've ordered tech data but  
it has arrived. The Hobbit does have a MMU (the glossy labels it as 2 x 32  
Page TLB, 2 x 1 Seg TLB). I'd love to see a head-to-head comparision of  
these two chips (and families).

For info on Hobbit call:
US 800-372-2447
Europe (44)732 742 999
or call local AT&T office

Dale Frye
Washington University in St. Louis
Xref: sparky comp.sys.pen:705 comp.sys.palmtops:3670