HDTenEightyP/NetNews huggingface dataset:
From: gblock@csd4.csd.uwm.edu (Gregory R Block)
Subject: Re: Zorro III Stuff (Was: Guesses, et al.)
Organization: University of Wisconsin - Milwaukee
Date: Fri, 17 Apr 1992 00:01:41 GMT

daveh@cbmvax.commodore.com (Dave Haynie) writes:
: Well, basically, CPU to Zorro III transactions are governed by 32MHz timing
: grain on the 16MHz system and 50MHz timing grain on the 25MHz system.  Which
: reflects the fact that while the Zorro III protocol is asynchronous, neither
: the 68030 bus nor the Fat Buster chip can (or should) be fully asynchronous.

Ahh.  Okay.  I had thought that would be the case, I didn't think
Zorro III ran off of the BCLK...  Does it base itself off of PCLK, or
does it double the BCLK?  (Kind of a needless, stupid question, but
I'm interested...).

: Pretty much so.  I could extend Zorro III to be more efficient at 
: multiprocessing, but I think you could easily go that one better.  For exampl
: the free 68040 bus you get with any 68040 solves one of the two big homogenou
: multiprocessing problems, that of cache coherency.

(I see a Zorro III+ in our future.)  Seriously, wouldn't that require
a total overhaul on the way Zorro III does things?  Or would it be as
simple as being an "extension"?

: Basically, when two devices require pure or near pure determinism from a 
: memory system, there's nothing you can do.  Obviously, a CPU would like to ge
: stuff to and from memory as fast as possible, but it doesn't generally fail
: if things just slow down, it just slows down.  The CPU doesn't require any
: purely deterministic access.  However, video devices like the 34010 and Agnus
: do -- if they can't get at memory just when they need it, the display fails,
: and you see this as a picture that breaks up.

Yup.  However, couldn't one set up the hardware so that, just as the
current agnes/denise/copper gets deterministic access, the A2410 could
get deterministic access to chip over the ZorroII/ZorroIII bus (center
on the latter...)?  Or doesn't current design allow something like
that to happen?  An interesting thing to see would be multiprocessing
boards that "grabbed" certain parts of memory for deterministic
access...

But I digress.

Greg
-- 
"Walking in London, and you are watching me walk,      gblock@csd4.csd.uwm.edu
 Talking Italian, and you are watching me talk,            Gregory R Block
 Singing in Sydney, and you are sitting right there,
 Feeling you with me, everywhere, everywhere."  -Concrete Blonde
From: Lee_Robert_Willis@cup.portal.com
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: AppleEvents, how to they work?
Date: 6 Apr 92 02:22:12 GMT
  <jbickers.05mj@templar.actrix.gen.nz>
  <kdarling.702469592@garfield.catt.ncsu.edu>
Organization: The Portal System (TM)

>I have an ARexx (or any Rexx, I guess) question:  what if you're running
>two incarnations of an application?  How do you specify which one's port
>you're wanting to talk to?   Or does one simply avoid this situation?
>
>thx - kevin <kdarling@catt.ncsu.edu>

From the Amiga User Interface Style Guide:

   "Each ARexx port must have a unique name and must be in
   upper-case.  In AREexx, a port name is derived from:

      <basename>.<slot #>
   ...

   Unique port names should be given to each project stared within
   your application.  For example, a fictional word processing package
   named GonzoWord with a basename of GWord should have an ARexx port
   of GWORD.1 when the first document is opened.  A second document
   running concurrently should be given the port name of GWORD.2."


On startup, one of the first thing an AREXX-supporting application
is supposed to do is look to see if its AREXX port already exists.
If it does, the application should pass the new project on to
the existing application, and exit..  (i.e. there's really only one
copy of the Application running, just multiple projects.)

--
Lee      Lee_Robert_Willis@cup.portal.com
Newsgroups: comp.sys.amiga.advocacy
From: torrie@cs.stanford.edu (Evan Torrie)
Subject: Re: Mac OS just sucks -- "ease of use" = "lack of freedom" ?
Originator: torrie@Xenon.Stanford.EDU
Organization: CS Department, Stanford University, California, USA
Date: 10 Apr 92 05:31:53 GMT

justin@graphlab.cc.uky.edu  (Justin Sullivan) writes:

>Evan Torrie writes
> 
>>   It's getting especially silly because A/UX 3.0 is NOT SVR4.  Apple is

>You are quite.. WRONG! A/UX 3.0 is a VERY revamoed A/UX 2.0.. It is an  
>SVR4-based UNIX.

  Strange then that the A/UX 3.0 data sheet I picked up at MacWorld says

  Standards Compliance
  ====================

  * AT&T UNIX System V, Release 2, Version 2

  Of course, I guess they could have totally redone their design, changed
to SVR4, done all the testing, and got it out to beta and ready to ship
this month in the four months since MacWorld....  ENN, OH, TEE.

-- 
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu 
Blasphemy is a victimless crime.                     NZ for the America's Cup!
Newsgroups: comp.sys.amiga.advocacy
From: nap42487@uxa.cso.uiuc.edu (Nishith A. Patel)
Subject: Re: 040 and 486_ (bunch O' Kaka anyway)
Organization: University of Illinois at Urbana
Date: Wed, 15 Apr 1992 22:41:49 GMT

Why do we even bother talking about this? It is obvious we are not going
get exact equal comparisons, so we should do this the easy way. Get 
a magazine that has already tried comparing the two and read their results
(like I said before, something like a UNIX magazine that tested a common
operating system, etc.)

Another reason why we should do this, instead of talk about testing, is,
that the benchmarks have to be comprehensive to some point. They should 
actually DO something,
From: lindblad@cc.helsinki.fi
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: 040 and 486 and nap42487 knows nothing about CPUs.
Date: 12 Apr 92 16:48:25 GMT
Organization: University of Helsinki

In article <1992Apr11.195629.9933@ux1.cso.uiuc.edu>, nap42487@uxa.cso.uiuc.edu (Nishith A. Patel) writes:
> The following are a series of benchmarks performed on a 25 MHz 040 with
> 128K external cache and a 25 MHz 486 with 128K external cache.

And you still don't get it. Benchmarks do not tell you anything you think they
tell you.

> Benchmark	040 128K cache		486 128K cache
> 
> Integer:
> gcc		13.8			13.8
> espresso	13.4			12.2
> li		15.5			16.8
> eqntott		9.8			11.0
> 
> FP:
> spice2g6	13.1			8.8
> doduc		8.1			5.8
> nasa7		12.1			5.8
> matrix 300	11.5			9.5
> fpppp		13.4			7.0
> tomcatv		9.1			4.3

And did the compiler make 040 specific code? I didn't think so. Did 040 have
copyback on? No? How much did the compilers optimize code in each case? Are you
stupid?

Why have you yet not answered the question I've asked you several times:

If 68040 has 50% faster instructions, copyback mode, less register shuffle and
the instruction sets in general do quite similar amount of work per
instruction, why on earth would 486 system beat 040?

> These tests show what I have said before, that the 486 is marginally faster
> than the 040 at the same speed on integer, and that the 040 a little more
> than 1.5 times the speed of the 486 on FP, which means that the 50 MHz 486
> will be faster. 040's without caches, common on the Amiga, will do a little
> worse than the results shown here.

And you believe in benchmarks? Okay, here's some more:

	HP 9000/425e (68040 @ 25)            486 Clone (@ 25 MHz)

Dhrystone 1s:	58139				25906
Dhrystone 2s:   39185				24606      
Whetstones:	10858				5580	    
SPECmarks:	10.3				7.9
Graphstones:	26118				7120
Khornerstones:	42753				11933

(Dhrystones are integer ones, Whetstones are floating point ones, SPECmarks
have both, Graphstones are what the name tells, Khorners have cpu, fpu, disk,
etc. benchmarks.)


Gee - these give us totally different picture.... anyhow I do not claim that
these benchmarks are the absolute truth as they are not: it all depends on
compilers, systems, how the system's set up, how much one has memory etc.
	Please, also answer me why those _your_ benchmarks do tell us the whole
truth and these ones don't? Could it be that benchmarks do not tell _you_ one
fucking thing.


--
Jarkko Lindblad
lindblad@cc.helsinki.fi
Xref: sparky comp.sys.amiga.advocacy:12532 comp.sys.amiga.games:6893 comp.sys.amiga.misc:8497 comp.sys.amiga.multimedia:821 comp.sys.amiga.graphics:3692 comp.sys.amiga.hardware:8812
From: chucks@pnet51.orb.mn.org (Erik Funkenbusch)
Newsgroups: comp.sys.amiga.advocacy,comp.sys.amiga.games,comp.sys.amiga.misc,comp.sys.amiga.multimedia,comp.sys.amiga.graphics,comp.sys.amiga.hardware
Subject: Re: Considering switching to IBM
Date: 14 Apr 92 05:25:02 GMT
Article-I.D.: orbit.7472
Organization: People-Net [pnet51], Minneapolis, MN.

tron1@tronsbox.UUCP (Kenneth Jamieson) writes:
>>ProVideo Post (requires 1 meg chip ram)
>
>	Ok. 
>
>>Duluxe Paint (uses extra halfbrite)
>
>	I have that.

You have extra halfbrite?  or you have DPaint?  If you have EHB then you don't
have an 85 Amiga (or at least not a 100% 85 amiga), that would date it at late
86..

>>Prowrite 3.2 (has 256 color modes)
>
>	Show me an amiga without an add on that has a 256 color mode.

Show me a non-developer A1000 that has 2.0 without an ad on (legally). 
Whether there is an amiga without an add on that can display these  is moot,
since your article said that there was hardly any software that had modes your
1000 could not support.  Perhaps you should have worded it more carefully.

>>Art Department Pro (has 256 color, Ham8, and other modes)
>
>	Ditto.
>
>>Scala (uses 1280x200/400 modes and productivity modes i believe)
>
>	Ok.
>
>>Deluxe Paint IV (has 256 color, Ham8 and other modes)
>
>	Ditto.
>
>>The countless number of PD, Shareware and Commercial programs that are either
>>2.0 ONLY or have extended features under 2.0 such as
>
>	Many of that is software stuff. And I can run 2.0

Without a hardware add on?  sure.. if you don't mind breaking the law, you
could also run mac software without a hardware add on, if you don't mind
breaking the law.  Same difference.  Your 1000 cannot run any 2.0 only
programs unless you physically modify the motherboard by using a Kwickstart
board or something like that...

.--------------------------------------------------------------------------.
| UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back |
| ARPA: crash!orbit!pnet51!chucks@nosc.mil        | from the dead, but do  |
| INET: chucks@pnet51.orb.mn.org                  | you really think he's  |
|-------------------------------------------------| moved back in?"        |
| Amiga programmer at large, employment options   | Lou Diamond Philips in |
| welcome, inquire within.                        | "The First Power".     |
`--------------------------------------------------------------------------'
From: kontos@clipper.ingr.com (Thorne Kontos)
Newsgroups: comp.sys.amiga.advocacy
Subject: Powerbook problems?
Keywords: Battery packs can cause fires!
Date: 6 Apr 92 14:32:30 GMT
Distribution: na
Organization: Intergraph Advanced Processor Division - Palo Alto, CA


     Apple announced Friday that they are giving away a free plastic
battery case to all Powerbook owners who ask for it. Apparently
the battery pack can cause a fire if left out, and a piece of
conductive material happens to fall across its terminals. There was no 
mention in the San Jose Mecury News article about whether this
problem has happened to a customer, or if Apple discovered this
themselves. (My own personal opinion - Can you think of a better
way to avoid a lawsuit? Scenario follows:

Customer: My powerbook battery pack started my home on fire!
Apple: Did you get our free plastic case?
Customer: No
Apple: Judge, this obviously is negligence on the part of the customer. 
Judge: Case dismissed )

Engineering students: Classify this as a design problem
Law students: What laws were broken by releasing a product with
              a potential fire hazard?
From: Paula_Lieberman@amicol.UUCP (Paula Lieberman)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: EISA vs. ZorroIII
Date: 8 Apr 92 14:50:18 GMT
Organization: Amiga Colony BBS

There's another way to get an EISA or MicroChannel machine with high speed
32 bit bus -- use a third party product which has its own bus, like Data
Translations' DT-Connect.......


-- Via DLG Pro v0.991
Newsgroups: comp.sys.amiga.advocacy
From: gblock@csd4.csd.uwm.edu (Gregory R Block)
Subject: Re: CDTV
Organization: University of Wisconsin - Milwaukee
Date: Tue, 7 Apr 1992 13:16:48 GMT

philip@utstat.uucp (Philip McDunnough) writes:
: In article <314@cbmger.de.so.commodore.com> peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany) writes:
: 
: [CDTV's use of nonstandard PCMIA...]
: >
: >It's bad luck, not intention.
: >CDTV followed the *then* current PCMCIA specs, but these
: >were not the final ones. And for bad luck, these specs were changed
: >for the final release. They had no prophets to look in the future.
: 
: That's what management is paid to do. If they can't forsee the trends with
: fair probability then they shouldn't be there. What else do they do?

I may not love the fact that it DID happen, but that's overdoing it a
bit, don't you think?  I mean, even Apple, the supermarketing giant
(grr), screwed up with the Mac II and 4mb simms the first time
around...

Am I the only one that remembers that?  When 4mb simms came out, they
didn't work, because Apple had used prelim. specs that were current at
the time?

Peoples' memories are so short.  Better spend some of those paperclips
Mike Mellinger talks about and buy another 4mb.  ;)

Greg
-- 
 __________________________________________________________________________
|				     The Chesterfield Electronic Towel (TM)|
|gblock@csd4.csd.uwm.edu                    Don't leave Krikkit without it!|
|__________________________________________________________________________|
Newsgroups: comp.sys.amiga.advocacy
From: gerald@seas.gwu.edu (Gerald G. Washington)
Subject: Re: Mac & IBM advocates read this!
Organization: George Washington University
Date: Fri, 10 Apr 1992 00:57:58 GMT

justin@mik.uky.edu (Justin Sullivan) writes:
>Insecure may be the word to describe Amiga users.

Perhaps.  Those who must defend their systems against the words of insecure
Amiga users must really be pathetic.

>The degree of hostility in Amiga users is equally astounding.. :)
>Just a friendly post.. No flames intended, none expected. E-mail welcome.

You have got to be kidding.

-- Gerald
From: slvj6@cc.usu.edu
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: 040 and 486_ (bunch O' Kaka anyway)
Date: 15 Apr 92 09:17:47 GMT
Article-I.D.: cc.1992Apr15.031747.54486
Organization: Utah State University

In article <mykes.2757@amiga0.SF-Bay.ORG>, mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
> In article <1992Apr13.231232.12366@ra.msstate.edu> skip@tacky.cs.olemiss.edu (Skip 'AdaX' Sauls) writes:
>>In article <1992Apr13.190041.16557@ctr.columbia.edu> jerry@connection.prospect.com (Jerry Shekhel) writes:
>>
>><compiler bashing  deleted>
>>
>>>I think the best thing to do would be to use UNIX SVR4 and Gnu C on both
>>>machines (with similar RAM) to see which produces faster results.  This would
>>>give a reasonable overall CPU performance estimate.
>>
>>Sounds fair enough.  Why don't we ask Rob H. (frequent comp.unix.amiga poster)
>>to perform the tests?  He has an A3000UX, uses a 386 with SVR4 and would
>>probably run them if we asked nicely.  What sort of tests should be run?
> 
> The way to do the benchmarks is to code them in hand crafted assembly.  That
> way, the quality of the 'C' compiler does NOT come into play.  The same coder
> should do both programs.

Do people write in assembly under Unix though?  ;-)
Possibly several people should review the assembly code for both processors to
make sure both make the most use of the processor.

> The above test will show how the shuffling of registers makes a difference.

Something I strongly agree with...
But then that would only tell the machines potential.  In all fairness,
C benchmarks should also be done.  Potential is great... but if you can't use
it, it's not much good.

Since the 80x86 processor's registers aren't as general purpose as the 680x0's,
the Motorola machine will have the advantage on the assembly benchmarks.

Since the current 680x0 C compilers make rotten use of those registers, the 
C benchmarks won't show the true capabilities of the hardware.
The benchmarks *will* give you a comparison of speed you can expect from that
compiler at this point in time.

This would give a good indication of either machines un-used potential.

Gee, anyone wanna guess which processor fits that description?

> Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)

James
From: etxansk@garbo.ericsson.se
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: The Gail-chip and its uses
Keywords: chip, piracy, AFD, Gail
Date: 9 Apr 92 14:25:24 GMT
Organization: Ericsson

boberg@lysator.liu.se (Stefan Boberg) writes:

>>One use of the Gail-chip I have not heared someone on the net mention yet, is
>>that it incorperates the AFD-technique.
>> ...
>>You could try to copy the disks before the code is transfered, but Gail will
>>sense it and erase the disks.
>>CBM have been installing the Gail-chip in all amigas since the first of April.
> ...
>
>  Man, this is most definitely an April fools joke!!! And besides, that mag
>is usually full of bogus information anyway. It's better considered a comic
>than computer mag (The Q&A section is hilarious - but that's unintentional).

 Yes, it has to be a joke. On the other hand, I suspect there _is_ a new
chip in the A600 called GAIL (or GAYLE?). They (the magazine) mentioned
it twice, in two different articles. One article about the illegal copy
detection and one about the A600.

 On the other hand, it's a clever idea - except that I wouldn't want
a computer that can rewrite write-protected disks.

 Anders Skelander # # #
                  # # #
                 #  #  #
                #   #   #
From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: 040 and 486_ (bunch O' Kaka anyway)
Distribution: world
X-NewsSoftware: Amiga GRn V1.29 4/10/92 (Beta) by Mike Schwartz
Date: 15 Apr 92 12:09:05 PST
Organization: Amiga makes it possible

In article <1992Apr15.112639.29149@nic.unh.edu> pss1@kepler.unh.edu (Paul S Secinaro) writes:
>In article <1992Apr15.003149.29648@ux1.cso.uiuc.edu> nap42487@uxa.cso.uiuc.edu (Nishith A. Patel) writes:
>
>>>The way to do the benchmarks is to code them in hand crafted assembly.  That
>>>way, the quality of the 'C' compiler does NOT come into play.  The same coder
>>>should do both programs.
>>
>>>The above test will show how the shuffling of registers makes a difference.
>>
>>If they are in assembly language, we have to use two programmers. One who
>>specializes in the 68k line, and one who specializes in the 486 line. If
>>we used one programmer, which one would he develop better code for, the
>>one he is better at or the one he is worse at? 
>
>Also, you'd probably need an impartial judge or panel of judges to
>examine the code and make sure nobody uses any cute "tricks" to make
>the benchmark run faster.  What constitutes a "trick" would, of
>course, be a matter for debate.  For starters, you might say a "trick"
>would be anything that a typical, good quality compiler _wouldn't_
>normally generate.
>

Bullshit.  A "trick" is just something that the compiler writers haven't
figured out how to generate yet.  Hand crafted assembly (especially in
this case) can't be beat by a compiler.  You can get the 100% best optimized
program for doing the benchmark, leaving nothing to chance.


--
Author of Amiga GRn, MailMinder, Budokan, Beyond Dark Castle, Dark Castle,
and Genesis Dick Tracy and Marble Madness.
Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)
1124 Fremont Ave.
Los Altos, CA 94024

Newsgroups: comp.sys.amiga.advocacy
From: philip@utstat.uucp (Philip McDunnough)
Subject: Re: Considering switching to IBM
Organization: University of Toronto, Dept. of Statistics
Date: Fri, 10 Apr 1992 06:01:26 GMT

In article <FZGRq*nW0@laosinh.stgt.sub.org> Gerrit@laosinh.stgt.sub.org (Gerrit_Heitsch) writes:
>In article <1992Apr5.224121.13332@ctr.columbia.edu>, Jerry Shekhel writes:
>
>> It could be, but IBM will supposedly attempt to change that view by bundling
>> OS/2 with its home systems (PS/1's) and doing heavy advertising.
>I thought OS/2 2.0 will only work on a 386/486 ?
>The PS/1 is a 80286-10 with 1 waitstate. Do you want to run OS/2 on
>such a slow processor ?

That's the original PS/1. The current line includes a 20MHz sx and IBM
intends on expanding the line all the way to the 486(). I used OS/2
version 2.0 on a 16MHz PS/1 for a week. Worked fine with 4 megs. Of course
it wouldn't satify all the power users here who want home Crays.

Philip McDunnough
philip@utstat.toronto.edu

Newsgroups: comp.sys.amiga.advocacy
From: jerry@connection.prospect.com (Jerry Shekhel)
Subject: Re: 040 and 486 and nap42487 knows nothing about CPUs.
Organization: Molecular Simulations, Inc.
Date: Thu, 16 Apr 1992 21:44:16 GMT

har@ux.acs.umn.edu (--SeebS--) writes:
>
>>Wow.  For a man of your education, a PhD, your attitude sure is arrogant.
>
>Wow. For a man without a PhD, your attitude sure is arrogant.
>

Gosh, Peter, aren't you clever.  Look, Dr. Kittel said, "If you don't
share my opinion, you must be from another planet."  Do you deny that that
is an arrogant attitude?  The Dr. himself admitted it was impolite.

Now please explain what I said to warrant your calling *me* arrogant.

>
>Face it - no one has yet spoken up who has programmed both chips in
>assembly and who does not feel that Intel is a total kludge. I know
>that the computer science department at my old school was full of people
>who all "grew up" programming the 80x86's. According to your theory, they
>would like the one they started on better, explaining why none of them
>are willing to touch the 80x86 series except as a mention of "this is
>one of the stupid backwards chips."
>

Yeah right.  And I'm sure those people are resting easy knowing that
they've got you to speak for them all.

>
>He *was* right, y'know. It's only arrogant if you're wrong.
>

Nope, he was wrong, just as you are.

>
>Peter Seebach, using my fiancee's acount. (Please use "SEEBS" in the subject
>
--
+-------------------+-----------------------+--------------------------------+
| Jerry J. Shekhel  | Molecular Simulations | Time just fades the pages      |
| Drummers do it... | Inc.  Waltham, MA USA | in my book of memories.        |
|    ... In rhythm! |     (617) 890-2888    |              -- Guns N' Roses  |
+-------------------+-----------------------+--------------------------------+
|           ...! [ princeton mit-eddie bu sunne ] !polygen!jerry             |
|                            jerry@polygen.com                               |
+----------------------------------------------------------------------------+
Newsgroups: comp.sys.amiga.advocacy