HDTenEightyP/NetNews huggingface dataset:
From: ifaq570@ccwf.cc.utexas.edu (Allen Kitchen)
Newsgroups: comp.sys.intel
Subject: Re: AMD and INTEL
Date: 22 Jul 92 19:01:01 GMT
Organization: The University of Texas at Austin


	For those of you out there who want to know,

	The actual ruling ruling of the jury was that intel did not prove
that AMD did not have the rights to the 287 microcode, and that AMD did not
prove that it did have the rights to the 287 microcode.  No other products
are implicated, and it does not cover any (ANY) other chips than the 80287
math coproccessor.
	Also it is interesting to note that when the jury returned this 
"we don't know" ruling, the judge in the case, dismissed them from hearing
further parts of the case. 
	The jury said that neither side proved their side of the argument.
The argument stems from a technology sharing agreement AMD had with Intel.
When the deal went sour, AMD went it's own way, and continued to use those
things that were shared by contract.  Intel then sued, claiming that the 
agreement was for internal use only (which is not in the document) and that
Intel never intended for AMD to sell anything.
	Intel has lost every other suit it has had with AMD.  AMD has been 
granted full rights without restriction to the 386 family of chips. In
addition, Intel has been ordered to stop their legal harrasment of AMD.

Summary:
Intel did not win, and AMD did not win the latest module.  The jury said
that they were not convinced by either side.  The jury was then dismissed
by District Judge William Ingram, who will now hear everything by himself.
AMD is asking the judge to overturn the jury's decision, and Intel is 
asking for the decision to be final.  

Sources:
	Electronic Engineering Times, June 22 1992, page 1
	Electronic Engineering Times, July 20 1992, page 2
	
Allen
ifaq570@ccwf.cc.utexas.edu


Newsgroups: comp.sys.intel
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: AMD and INTEL 
Organization: Keith's Computer, Hope Mills, NC
Date: Thu, 23 Jul 92 02:48:49 GMT

In article <1992Jul20.181728.3039@nic.unh.edu> pss1@kepler.unh.edu (Paul S Secinaro) writes:
>In article <1992Jul20.155024.11256@clpd.kodak.com> fischer@li.serum.kodak.com (Chris Fischer (x39613)) writes:
>>Speaking of AMD and Intel, I was perusing the AMD literature
>>for their 386 line and found this tidbit:
>>
>>"Only the Am386DX architecture can run UNIX, OS/2 and MS-DOS."
>>
>>I think AMD should inform my PC at home about this.  It 
>>disagrees.
>
>Well, it didn't say only the Am386DX could run UNIX, OS/2, and MS-DOS,
>it said only the Am386DX *architecture* could run those things.  Since
>the chip is a clone of the Intel 386, I guess it's technically true,
>though a tad misleading.
>

No,  Not at all.  This was quoted out of context (can YOU say ELBIL
YLOH?) ...

AMD Sells a wide variety of different  CPU's but for the widest software
support ..

>>"Only the Am386DX architecture can run UNIX, OS/2 and MS-DOS."

It is a bit amusing though.

I mean if the subject of the literature is AMD Microprocessors, I think
the statement is perfectly valid.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
From: mkahn@hopi.sedona.intel.com (Mitch Kahn)
Newsgroups: comp.sys.intel
Subject: Re: Successor to i860?
Date: 30 Jul 92 16:26:18 GMT
	<1992Jul24.153842.27205@uwm.edu>
Organization: /eng/eng3/mkahn/.organization
In-reply-to: markh@csd4.csd.uwm.edu's message of 24 Jul 92 15:38:42 GMT

markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:


] In article <1992Jul24.051517.177756@zeus.calpoly.edu> mneideng@thidwick.acs.calpoly.edu (Mark Neidengard) writes:
]
] The entire embedded controller series: 8051/8096/80960.  The last two are
] highly orthogonalized and have plenty of RISC design features in them, the
] first had many RISC features designed in it before RISC was even a word.
]

Semantic police here: The 80960 is an *embedded microprocessor*.
Embedded controllers are typically used for electromechanical 
control and/or have a slew of peripherals on board. The 80960 is
a RISC processor (less the MMU which seems to denote full
microprocessor these days).

IMHO of course.

--
|  Mitch Kahn              | "I hope you know that this will go down on |
|  mkahn@sedona.intel.com  |  your permanent record..."                 |
*************************MY OWN OPINIONS*********************************
Newsgroups: comp.sys.intel
From: hays@ssd.intel.com (Kirk Hays)
Subject: Re: Ada compiler for Intel 520
Organization: Intel Supercomputer Systems Division
Date: Thu, 30 Jul 1992 18:20:45 GMT

In article <25069@dog.ee.lbl.gov>, G_Jin@lbl.gov (Jin Guojun[ITG]) writes:
|> Can anyone provide information about the Intel/520 computer?
|> What is this machine, and who distributes the Ada compiler for
|> the Intel/520 computer?

I could be wrong, but it seems that the 520 was a Multibus II based box.

The Ada compiler was a Telesoft Ada derivitive, enhanced and distributed by
Intel, and probably still is - contact your local Intel sales office.

If I remember right, the 520 ran a SYSVR3.2 (or was it XENIX 386?) OS on one of
the 386 CPU boards, and Ada applications linked with the RMK-386 real time kernel
on the <n> other cpu boards in the backplane.

If this doesn't correspond with the hardware sitting in front of you, please
disregard.

Obviously, I don't speak for Intel, not being an officer of the company.

-- 
Kirk Hays - NRA Life.
Start your day with a little civil disobedience.  Call BATF at 1-800-ATF-GUNS or
1-800-RUN-GUNS, tell them what you think of gun grabbers and government employees
that encourage people to narc on their neighbors.  Good for the soul.
Newsgroups: comp.sys.intel
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: Successor to i860?
Date: Sat, 25 Jul 1992 16:08:29 GMT
Organization: The Portland Group, Portland, OR

In article <1992Jul25.143208.129539@zeus.calpoly.edu> mneideng@thidwick.acs.calpoly.edu (Mark Neidengard) writes:

>Yeah, those are the "current" i860's.  Mark Hopkins also mentions the
>imbedded controller line, of which I am also cognizant.  I am interested in
>heretofor unreleased (unannounced?) chips.  Thanks for the info though..=)

As you know, Intel is very unlikely to give any information on unannounced
chips without non-disclosure, and those under non-disclosure would not be
allowed to answer in such a forum.  The rumors might be interesting, though
(look at all the P5 speculation that's come out).
-- 
Larry Meadows		The Portland Group
lfm@pgroup.com
Organization: University of Maine System
Date: Monday, 27 Jul 1992 14:01:36 EDT
From: <REE700A@MAINE.MAINE.EDU>
Newsgroups: comp.sys.intel
Subject: Re: 386/486 clock (1x or 2x)?
 <TMH.92Jul22194404@keks.first.gmd.de> <scott.711851090@labtam>

Scott Colwell states (correctly) that quartz crystal oscillators (TTL-crystal o
scillators) run out of steam (read: price-performance benefits) around 80 MHz.
 On the other hand, clock division is very cheap, even if a little ECL is neede
d, and SAW-based quartz oscillators start around 300 MHz (i.e. garage door open
er xmitter oscillators.  So, the availability of oscillators doesn't limit the
CPU speed.  Furthermore, having a 100MHz oscillator and 2x divider in a sheilde
d box will not cause RFI any more than the inherent harmonics of a square wave
at most of the popular CPU speeds.
   What really limits CPU speed is heat dissapation and the 5V standard.  Curre
nt research in the microwave generation of diamond thin films from methane will
 be a big factor in future high speed cpu's.  Since crystalline diamond is the
best thermal conductor/ electrical insulator (OK ultra-wide bandgap semiconduct
or), such a film would be a big help.  also, the drive to low voltage logic (se
e the IEEE spectrum article "High on Low Voltage" recently) will allow faster c
lock speeds at the same power dissapation and also allow smaller transistors.

   So, my question is:   Just because your board manufacturer uses a 2X clock s
cheme and divider to provide the 486 with its 1X clock, why do you insist on th
inking that that clock (oscillator) is directly fed to your chip?  The 486 is a
 1X chip, which is neither an innovation nor a big advance.  It probably has li
ttle or no impact on RF interference and only a slight psychological ecffect on
 the dope at the FCC that licences it (Hey, this is a computer, not an FM trans
mitter!) since many mainframes and workstations have CPU clocks of 100 - 200 MH
z. (covers most of the TV VHF, UHF and cable TV bands, better stop that trend,
too).
    The only technical reason for the 486 being 1X that I can arrive at is that
 a fiberglass, multilevel circuit board is one hell of a capacitive load for a
100 MHz TTL signal to drive.  The vendors knew it and Intel knew it.  So, Intel
 made the 486 a 1X clocked chip so they wouldn't need to use low-dielectric cir
cuit board like teflon at 5X the price.  My only shock at this is that they did
n't rate the previous 2X chips at the input clock rate (Hey, its a 20 MHz 8088!
  Try AMD's 80 MHz 386!   got a 32 MHz 386SX.. Real cheap!) rather than the eff
ective clock rate...

   So, can we end this useless bickering over whether Intel's data book is corr
ect (wrt the input clock speed at least) & get on to the important things in li
fe)
Newsgroups: comp.sys.intel
From: jmclaugh@gandalf.ca (Jim Mclaughlin)
Subject: Re: 386/486 clock (1x or 2x)?
Organization: Gandalf Data Ltd., Nepean, Ontario
Date: Wed, 22 Jul 1992 21:00:53 GMT

In article <TMH.92Jul22194404@keks.first.gmd.de> tmh@keks.first.gmd.de (Thomas Hoberg) writes:
>In article <3713@svin02.info.win.tue.nl> debra@wsinis07.info.win.tue.nl (Paul De Bra) writes:
>   In article <RFowler.288@kelvin.jpl.nasa.gov> RFowler@kelvin.jpl.nasa.gov (Robert A. Fowler) writes:
>   >In comp.ibm.pc.hardware there is a thread about weather the 486DX uses a 1x 
>   >or a 2x clock.  I (perhaps mistakenly) said it used a 2x clock, (all of the 
>   >motherbords I've seen had a 2x occilator) could some one with a real data 
>   >book clarify?
>
>   The 386 uses a 2x clock, whereas the 486 uses a 1x clock.
>   A 2x clock has the advantage of delivering a perfectly symmetrical
>   1x clock after halving. A 1x clock needs better clock circuitry to
>   make sure it is symmetrical.
>
>Hmm, I was always under the impression that even the 486 used a 2x
>clock up until the 486DX[2]50, which uses a 1x clock. Anyway I have a
>66MHz oscillator on my 486/33 motherboard.
>---
I'm looking at page 2-177 of the 1992 Intel Microprocessor data book

For the 50 MHz 486 part the minimum input frequency is 16MHz, and the
maximum input frequency is 50MHz.  There is a note for this saying that
it is a 1x CLK to Intel 486.  The spec also calls for the clock symetry
to be no worse than 56-44, with .1% stability.

For those out there with a 2x oscillator on the motherboard, it is likely
that the support chip set needs the 2x, cause the CPU don't.....



Newsgroups: comp.sys.intel
From: RFowler@kelvin.jpl.nasa.gov (Robert A. Fowler)
Subject: Re: 386/486 clock (1x or 2x)?
Organization: Jet Propulsion Laboratory
Date: Mon, 27 Jul 1992 21:09:28 GMT

In article <92209.140137REE700A@MAINE.MAINE.EDU> <REE700A@MAINE.MAINE.EDU> writes:

>It probably has little or no impact on RF interference and only a slight 
>psychological ecffect on the dope at the FCC that licences it (Hey, this is 
>a computer, not an FM transmitter!) since many mainframes and workstations 
>have CPU clocks of 100 - 200 MHz. (covers most of the TV VHF, UHF and cable 
>TV bands, better stop that trend,too).

BUT most mainframes are class C (industrial) FCC rating, while pc's are 
class B (residental) which is much more stringent, remeber the FCC reps (
with radio DF equipment) at COMDEX the first year there were 386-33s?  
First day 10-20 vendors had motherboards in "FCC Aproved" boxes, second day 
only Everex(?) had a machine running.
    _________________________________________________________________
                        
                        HONDA -- The only way to fly
    o          
  _/\_>   -A proud owner (just wish they were made in the USA)
 O,> / O   [with all respects to Ohio MINE were made in Japan]
           
                           CM400T/XL500R/VF500F
                             '79   '82    '84
                           
     Slower trafic keep right (SUCKzukies, HDs, etc.) ->->->->->->->
    _________________________________________________________________
From: mkahn@pima.sedona.intel.com (Mitch Kahn)
Newsgroups: comp.sys.intel
Subject: Re: Are 50 MHz 486 DX's actually DX2's?
Date: 21 Jul 92 18:06:44 GMT
	<1992Jul15.094706.5095@ntuix.ntu.ac.sg>
	<1992Jul17.182842.273@visus.com>
Organization: /eng/eng3/mkahn/.organization
In-reply-to: br@cognos.visus.com's message of 17 Jul 92 18:28:42 GMT

br@cognos.visus.com (Brian Rosen) writes:

 Nntp-Posting-Host: brian.cognos.visus.com
]
]
]  In CMOS processes, switching edges uses power.  The
]  internal gates use much less power that the external
]  pins.  The very biggest use of power in a chip like a 486
]  is to switch the external pins fast.  A real 486DX-50
]  switches its pins using the 50Mhz clock.  The -DX2
]  switches its pins with a 25Mhz clock.  There is a substantial
]  difference in power usage.
]

] | Brian Rosen                   |  Cognos*centi Corp.                     |

From the 486DX50 datasheet: Ic(max) = 1000ma; Icc(typ) = 800ma
From the 486DX250 datasheet: Icc(max) = 1600ma!! (no typical spec'd)

Bear in mind that the DX2 numbers are preliminary. I have better info
direct from the engineer who says the Icc numbers only differ by 50mA
(in the DX2's favor). The data sheets do not specify bus load which would
have a significant impact on Icc. Due to the small difference between
parts, I would think that they are tested unloaded.
--
|  Mitch Kahn              | "I hope you know that this will go down on |
|  mkahn@sedona.intel.com  |  your permanent record..."                 |
*************************MY OWN OPINIONS*********************************
From: muriana@aclcb.purdue.edu (Peter M. Muriana)
Newsgroups: comp.graphics
Subject: Scientific Documentation: Captured Video Images
Date: 23 Jul 92 17:08:10 GMT
Reply-To: muriana@aclcb.purdue.edu
Organization: Purdue University AIDS Center

Hi,
I would appreciate if anyone can give me info on what is minimally
needed to capture video images on the PC?

Here's our application.  We have recently purchased a Polaroid slide maker
which can make nice slides of graphs, graphics, text slides at 4,000 lines
per inch from something like Freelance, etc, which grad students/faculty 
use for seminars, symposia, talks, etc.

What would be even better, or complement this, is if we could obtain 
graphic images on computer from a video source (VCR camera?) that could be
brought up in, again say Freelance, then overlayed with text to point out
what we want to illustrate, and then shuttled over to the slide maker.

I know this could be done with scanned images, but that would again require 
playing with flat images (photographs?).  We would prefer the video 
capability so that 3-dimensional images (engineering equipment, etc) can be
captured directly without the need to first obtain photographs.

What would we need? A frame grabber card, video hookup, software?  What is 
the available software for this on PC (commercial and/or public domain)?

Thanks in advance for any help.
*********************************************************************
*  Peter M. Muriana, Ph.D.		Phone	= (317)-494-8284    *
*  Dept. of Food Science		FAX	= (317)-494-7953    *
*  Purdue University		E-mail	= muriana@aclcb.purdue.edu  *
*  W. Lafayette, IN  47907                                          *
*********************************************************************
Newsgroups: comp.graphics
From: tomj@monster.saic.com (Tom Johnson)
Subject: TIFF rotate filter needed
Reply-To: tomj@monster.saic.com.UUCP (Tom Johnson)
Organization: SAIC, McLean, VA
Date: Wed, 22 Jul 92 11:38:34 GMT

We're developing a system to automatically scan reels of microfilm and
digitize the images.  Unfortunately, our customer has reels that have
been filmed sideways, so that the images are rotated 90 degrees CCW.
The scanner could rotate the image, but the scan time slows dramatically;
we'd like to rotate on some other (cheaper) platform so that the (expensive)
scanning resources aren't wasted.

All we need is a filter that rotates TIFF images 90 degrees.
I've been prowling around anonymous FTP sites all day and have had
no luck.

Does anyone out there have such a filter written in C,
that runs under DOS, OS/2, or UNIX (OS/2 preferred)????

Thanks!!
tom

Newsgroups: comp.graphics,alt.graphics.pixutils
From: jef@netcom.com (Jef Poskanzer)
Subject: Re: PBMPLUS
Date: Mon, 27 Jul 92 01:27:05 GMT
Organization: Paratheo-Anametamystikhood Of Eris Esoteric
Reply-To: Jef Poskanzer <jef@netcom.com>

johns@mcs213c.cs.umr.edu (John Stone):
}    If anyone out there is using OS/2 2.0, I've got a fair portion of 
}pbmplus ported now... I'm about halfway done... All that had to be done
}to port each program is build a .lib file out of the libp?m*.c files,
}and then to edit all of the file I/O stuff so that it uses binary
}I/O instead of text (OS/2 and Dos both default to text mode on the
}stdin and stdout)  
}The hardest part about the OS/2 port is that IBM C Set/2 won't let you
}use setmode() on a stream (which is how a friend of mine did a port of it
}to dos...)  So I had to use fdopen(); to do it.
}Using fdopen, means that I have to edit every call to a file I/O function
}and make sure it calls my binary file handle, and not the regular stdout 
}handle etc.

I've seen other people doing DOS ports do the same thing, and I still
can't figure out why.  How about just *replacing* stdout and stdin
with binary-mode handles?  Seems like doing that and then fixing
any bugs it introduces would be a lot less editing, and more
importantly would not, if done right, need #ifdefs all over the
place.
---
Jef

           Jef Poskanzer  jef@netcom.com  jef@well.sf.ca.us
"If you don't use Saber to develop your next C program, you're a dork."
                             -- Brian Reid
From: bce@sactoh0.sac.ca.us (Byron C. Ellis)
Newsgroups: comp.graphics
Subject: Rayshade 4 troubles
Keywords: Problems with MS-DOS Rayshade
Date: 27 Jul 92 21:17:50 GMT
Organization: Sacramento Public Access Unix

I just got Rayshade 4.0 via FTP for MS-DOS, and whenever I try to run the
program this keeps turning up, what am I doing wrong?:
Unexpected interrupt 0E (code 00000000) at 0148:0044B25A
And a whole bunch of other stuff.. Thanx in Advance
-- 
Flying (v) : The art or knack of throwing : Byron C. Ellis
yourself at the ground and missing        : Internet: bce@sactoh0.SAC.CA.US
-The more than complete Hitchikers Guide  :
 to the Galaxy trilogy                    :
From: mdf+@cs.cmu.edu (Mike Fox)
Newsgroups: comp.graphics
Subject: Re: Foley, Van Dam... errata file
Date: 21 Jul 92 16:03:32 GMT
Article-I.D.: cs.1992Jul21.160332.212271
Distribution: comp.graphics
Organization: School of Computer Science, Carnegie Mellon


Someone just answered my question.

Use: ftp 128.148.31.66

Thanks, that was fast!

-mike
From: stevanc@castle.ed.ac.uk (Stevan Clee)
Newsgroups: comp.graphics
Subject: Q's on 1280x1024 monitor
Date: 24 Jul 92 21:46:23 GMT
Distribution: comp
Organization: Edinburgh University

Does anyone have the tech. specs. of the Mag Innovision MX15F monitor?

Also, Does anyone know of a cheap card which will drive this (at
1280x1024).

Thanks,

Stevan
(stevanc@uk.ac.ed.castle)
From: sysmgt007@spacm1.spac.spc.com (Dean Nedelman)
Newsgroups: comp.graphics
Subject: Re: POV-Ray 1.0 Released
Date: 24 Jul 92 08:15:13 PDT
Followup-To: comp.graphics
Organization: Security Pacific Automation Co., LA, CA

In article <1992Jul24.054152.2535@cunews.carleton.ca>, dbuck@alfred.carleton.ca (Dave Buck) writes:
> 
>    The POV-Ray (Persistance of Vision) raytracing program version 1.0
>    is now available for anonymous FTP.  POV-Ray is based on my
>    DKBTrace program and has been developed with my permission by the
>    POV-Team.
> 
>    You can get POV-Ray from:
> 
>       alfred.ccs.carleton.ca (134.117.1.1)
>         directory: pub/pov-ray/POV-Ray1.0
> 
>    from overseas, please use (allowing a few days to make the files visible):
> 
>       ftp.informatik.uni-oldenburg.de (134.106.1.9)
> 
>    This distribution contains the source code, sample scene files,
>    documentation, and executables for the IBMPC and the Amiga.
>    Macintosh executables will be posted as they become available.
>    Executables for UNIX platforms and VAX/VMS are not supplied, but
>    instructions are provided for compiling the source on those platforms.
> 

Expect to see the VAX/VMS sources and executables to show up in the 
VMSNET.SOURCES newsgroup late next week.  The posting to VMSNET.SOURCES
will be a MFTU encoded Backup saveset, rather than the TAR and ZIP formats
prefered by Drew Wells.

For those VAX/VMS sites with FTP access, {BLACK|WHITE}.cerritos.edu is the 
officical VMSNET.SOURCES archive site.

Dean (The Shadow)
+---------------------------------------------------------------------------+
| Dean I. Nedelman                            sysmgt007@spacm1.spac.spc.com |
| Systems Consultant               sysmgt007%spacm1.uucp@elroy.jpl.nasa.gov |
| Security Pacific Automation Co.       spacm1!sysmgt007@elroy.jpl.nasa.gov |
| 333 South Beaudry Ave.       {...,decwrl,ames,usc}!elroy!spacm1!sysmgt007 |
| Los Angeles, CA  90017                                                    |
|                                                                           |
| Systems programmers are the high priests of a low cult.                   |
+---------------------------------------------------------------------------+
From: verdier@aar.alcatel-alsthom.fr (Franck Verdier)
Newsgroups: comp.graphics
Subject: Looking for geometric algorithms on polygons
Date: 28 Jul 92 13:21:38 GMT
Reply-To: verdier@aar.alcatel-alsthom.fr ()
Organization: Alcatel Alsthom Recherche (Marcoussis)


Does anybody know where I can find C source code (on a ftp site) about
geometric algorithms on polygons ?

The polygons may be non convex, may have holes, may be only lines or
points and even may be non connected (may consist of several disjoint
polygons).

The algorithms must perform the following geometric manipulations:
	- symetric
	- complementary
	- union
	- intersection
	- geometric sum (Minkowski sum)

Thank you in advance for any information.

===================================================================
Franck du Verdier
ALCATEL ALSTHOM RECHERCHE, Route de Nozay, 91460 Marcoussis, FRANCE
Tel: 33 (1) 64 49 15 73  Fax: 33 (1) 64 49 06 95
Email: verdier@aar.alcatel-alsthom.fr
===================================================================
Newsgroups: comp.graphics
From: bogstad@blaze.cs.jhu.edu (Bill Bogstad)
Subject: Need info on "IDL" a product of Research Systems Inc.
Organization: Johns Hopkins Computer Science Department, Baltimore, MD
Date: Wed, 22 Jul 1992 22:42:18 GMT

	I've been told to investigate a product called "IDL" which is a
graphical user interface tool for scientific/engineering users.  At this
point I don't know anything else about it.  (Even how to contact the
vendor.)  Contact information and candid reviews would be appreciated.

				Thanks,
				Bill Bogstad
Newsgroups: comp.graphics
From: xepo@csd4.csd.uwm.edu (Scott R Violet)
Subject: Polygon Graphics Books sought
Originator: xepo@csd4.csd.uwm.edu
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Distribution: usa
Date: Fri, 24 Jul 1992 16:09:10 GMT


HI all,
	I am interested in finding books on polygon ray tracing
methods.  I would like one that goes into detail on how they work, and
possibly how I might implement it by some coding examples.
-- 

		-Scott Violet (xepo@csd4.csd.uwm.edu)
From: davei@comp.lancs.ac.uk (Mr D Ingles)
Newsgroups: comp.graphics
Subject: half toning
Date: 28 Jul 92 09:49:44 GMT
Organization: Department of Computing at Lancaster University, UK.

Has anyone got any half-toning code that is written in C lying around ?

Davei
Newsgroups: comp.graphics