HDTenEightyP/NetNews huggingface dataset:
From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.sys.intel,comp.arch
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 20 Dec 1992 14:31:12 GMT
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
	<1992Dec8.000357.26577@newsroom.utas.edu.au>
	<PCG.92Dec9154602@aberdb.aber.ac.uk>
	<1992Dec12.152224.168173@zeus.calpoly.edu>
	<PCG.92Dec19165907@decb.aber.ac.uk>
Reply-To: stephen@acm.org
NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
In-reply-to: pcg@aber.ac.uk's message of 19 Dec 92 16:59:07 GMT

No; actually the real issue is whether PCs and workstations in fact run
batch mode. They don't. Contrary to what the market was mysteriously
made to swallow with the IBM PC and the Macintosh, what I do on my
workstation is in no way single threaded - at very *least* I have I/O
running in parallel with my application kernel (and in fact I usually
have a newsreader, a mailer, an editor (that's three copies of epoch
[emacs], actually), some language implementation, and half a dozen
monitor programmes (xloads, clocks, biffs, faces...) running. And that's
on a mere sparc....

If we start doing intelligent things like parallel garbage collection,
self-reorganising filesystems, code-generation-as-caching, we can
probably get a dozen processes running that have no desire to sleep.

The general-purpose world just isn't single-threaded. Nor, for that
matter, is it fp-intesive. But marketting determines reality, of course,
and people *will* keep insisting on engineering PCs for flops rather
than editable filesize, network transparency and user interface
responsiveness!

But no, the real reason is that the hardware and the software are never
optimised for each other; they merely co-evolve. So we are left with
hardware Unix engines and hardware DOS engines and C the best language
to programme them in. Probably, there is nothing we can do to change
that, so probably any idea related to micro-task-switching is doomed to
failure in the marketplace.
----------------------------------------------------------------------
stephen p spackman    +49 681 302 5288(o) 5282(sec)    stephen@acm.org
      dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany
----------------------------------------------------------------------
Newsgroups: comp.sys.intel
From: imbri_m@oswald.cs.odu.edu (I want my OREOS!)
Subject: 486/66 .. Into a 486/50 motherboard?
Organization: Old Dominion University, Norfolk, Va
Date: Wed, 16 Dec 1992 15:55:10 GMT


Is it possible to replace the 50MHz 486DX chip on a 486/50 mommyboard with a
66 MHz DX/2??  I am thinking of replacing my CPU, but I don't want to replace 
my entire motherboard if I don't have to.  Thanks.

imbri_m@cs.odu.edu

Mark Imbriaco
Xref: sparky comp.sys.intel:2733 comp.arch:11704
From: ntaib@silver.ucs.indiana.edu (Iskandar Taib)
Newsgroups: comp.sys.intel,comp.sys.mac.hardware,comp.sys.ibm.pc.hardware
Subject: Re: 486 vs. Mac Benchmarks
Date: 17 Dec 92 19:47:03 GMT
Organization: Indiana University

In article <1gdipoINN749@rave.larc.nasa.gov> w.l.vaughn@LaRC.NASA.GOV (Wallace L. Vaughn) writes:

>>(I write)

>>>Results:  Under Windows recalc took 3.3 seconds. 
>>>On the Mac, 7.5 seconds.

>>  4.1 seconds on my IIci.  
>I tried it using excel 3 on a IIci, cache card, two screens run in 8 
>bit(640x480) and 4 bit (15" stardard number of pixels) modes with video cards 
>(non-accelerated), system 7.01+, 20 meg ram, 3meg excel partition.

>recalc took 2.5 secs (hand held, so, say give or take 0.2 seconds), looks 
>like Evan may be correct 4.0 may be a little slower than 3.0. Looks like 
>Iskandar Taib is suffering from the onboard video slow down on the IIci or 
>maby the lack of a cache card.

Actually Excel 4 is faster than 3. The time shrank to 4.1 seconds with
4. 

I'm sure the cache card helps a lot.

>Mac II, 16mHz, system 7.01+, 8bit 640 x 480 video, 8 meg ram
>Mac IIci, 25mHz, see above
>386dx, 33mhz system, windows, 3.0, 640x480 svga screen, no cache. 8meg RAM
>                     calc.(sec)       scroll(min:sec)
>Mac II                    35.3            2:16.2 
>Mac IIci                  15.3            1:31.2
>Mac IIci/cache off        19.2            1:44.7
>386dx                     22.5            2:25.3

Hmmmm.

Most 386 motherboards above 25 MHz have a built-in SRAM cache 
these days. Even the bargain basement jobs.



-- 
-------------------------------------------------------------------------------
Iskandar Taib                          | The only thing worse than Peach ala
Internet: NTAIB@SILVER.UCS.INDIANA.EDU |    Frog is Frog ala Peach
Bitnet:   NTAIB@IUBACS                 !
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.sys.intel
Subject: Re: id in parts
Date: 16 Dec 92 14:05:13 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <BzBtuu.6t0@inews.Intel.COM> dmccart@gomez.intel.com (D. J. McCarthy) writes:
>	Even putting it in some sort of ROM section later (to be
>burned in at encasing time or something) would seem to me to be
>extremely cost-ineffective.  But like I said, I really have no idea.

D.J.,

Dallas Semi did something like this with a serially encoded id chip.  
The chip was dirt cheap, so it must have been fairly simple to program.
Obviously they could have used PROM or EERAM, but those do have a life
span... maybe it was just simple fused logic.  Regardless, it was probably
serialized during the testing.  True, it would add a few cents to the 
tester time, but as processors get more and more expensive it wouldn't
be such a bad idea to have them forever marked and traceable...

You heard it hear first :)

Tom

-- 
| Tom Barrett (TDBear), Sr. Engineer | tom.barrett@amd.com
| AMD PCD / Austin, TX  78741        | v:512-462-6856 / f:512-462-5155
| "No is Yes, and We are All FREE!"  | CO made a #2 no-no... PU!
| My views may not be shared by the organization of origin
Newsgroups: comp.sys.intel,comp.arch
From: norm@netcom.com (Norman Hardy)
Subject: Re: Superscalar vs. multiple CPUs ?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sun, 13 Dec 1992 06:39:30 GMT

In article <PRENER.92Dec12010123@prener.watson.ibm.com> prener@watson.ibm.com (Dan Prener) writes:
>In article <1992Dec11.060038.27494@netcom.com> norm@netcom.com (Norman Hardy) writes:
>
>> How about sharing expensive functional units (multiply, divide, 
>> DES) between processors on the same chip. This gives the economic 
>> advantages of heterogeneous processors (division of labor) without 
>> the software pain. The processors would appear to the operating 
>> system as CPUs sharing memory. Indeed this approach makes special 
>> purpose hardware more attractive as functional units.
>
>Doesn't that make saving the state of a processor somewhat complicated?
>--
>                                   Dan Prener (prener@watson.ibm.com)

I see no need to change the programmer's model in order to share 
functional units. Functional units have no state if you interrupt 
between instructions as in most architectures. On processors such 
as the 88K the floating point units are frozen upon interrupt so 
that interrupt latency may be less than the divide latency. At 
worst this can be handled by providing a register per processor 
per functional unit to capture the results of operations issued 
by the interrupted processor. The interrupt hardware might even 
be cagey and favor for interruption a processor with no 
outstanding instructions in shared units.

The 88K has a systolic multiplier and I imagine that few programs 
issue multiples more than 10% of the cycles. I imagine that 
sharing such a multiplier between four instruction streams would 
produce little interference. Perhaps the 88K has too much 
multiply hardware. I don't know the tradeoffs.
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.sys.intel
Subject: Re: Overdrive for the 486/50??
Date: 15 Dec 92 14:19:53 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <8f9__KS00WB5Qu_ogq@andrew.cmu.edu> fj05+@andrew.cmu.edu (Faisal Nameer Jawdat) writes:
>
>Well for one thing, the dx50 and the dx2/66 are different chips
>needing different motherboards, so it's quite possible that to switch

These two devices may or may not be the same... the OverDrive(tm) version
is of slightly different pinout and is plugged into the OverDrive(tm)
compatible socket.  There is also an OEM version which has identical 
pinout to the DX, but may be hard to find on the open market.

As for other issues... the DX2/66 uses a 33MHz clock and the DX50 uses
a 50MHz clock.  These frequencies are so far apart that it is unwise to 
replace crystals since the chipset and clock filtering components (for 
FCC/VDE) may not be able to take the change well.


-- 
| Tom Barrett (TDBear), Sr. Engineer | tom.barrett@amd.com
| AMD PCD / Austin, TX  78741        | v:512-462-6856 / f:512-462-5155
| "No is Yes, and We are All FREE!"  | CO made a #2 no-no... PU!
| My views may not be shared by the organization of origin
From: chbl@sbustd.rz.uni-sb.de (Christian Blum)
Newsgroups: comp.sys.intel
Subject: X assembler/compiler for the i960?
Date: 18 Dec 1992 08:49:22 GMT
Organization: Studenten-Mail, Rechenzentrum Universitaet des Saarlandes
NNTP-Posting-Host: sbustd.stud.uni-sb.de

Hi there!

Does anyone know a good cross compiler/assembler for the i960, running on
an IBM PC?
Any hint appreciated.
Please email, I don't check this group regularly.

Chris
--
          "Think for yourself, and always carry a light bulb."
                                           - Bob Dylan 1965
---------------------------------------------------------------------
Christian Blum                   Universitaet des Saarlandes, Germany
Friedrich-Ebert-Str. 50          chbl@stud.uni-sb.de
W-6685 Heiligenwald              chbl@sbustd.rz.uni-sb.de
Germany                          Tel (+49) (0) 6821 67476
Xref: sparky comp.sys.intel:2747 comp.arch:11728
From: psu@cs.duke.edu (Peter Su)
Newsgroups: comp.sys.intel,comp.arch
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 17 Dec 92 14:42:21 GMT
	<PCG.92Dec9154602@aberdb.aber.ac.uk>
	<1992Dec10.002951.23336@athena.mit.edu>
	<PCG.92Dec13170504@aberdb.aber.ac.uk>
Followup-To: comp.sys.intel
Organization: Duke University CS Dept., Durham, NC
In-reply-to: pcg@aber.ac.uk's message of 13 Dec 92 17:05:04 GMT

In article <PCG.92Dec13170504@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
   Precisely my point: single threaded *general purpose* codes have a
   limited intrinsic degree of exploitable parallelism .

	...

   So far the evidence seems (to me at least) that exploitable degrees of
   micro (multiple instruction issue in a cycle) and macro (multiple
   instruction streams in a program) parallelism for most codes don't go
   above 2-4; only codes with highly regular data reference patterns can be
   micro/macro parallelized with success/ease.

This sort of begs the question: if current code can't use these
architectures well because it wasn't designed to be parallel, why not
start the slow move towards code that *was* designed with these
architectures in mind?

It is possible to make irregular code (say, unstructured sparse matrix
ops) perform well, even on vector machines.  It is unlikely that a
compiler will do it for you.

It seems to me that the industry spends a huge amount of time trying
to mash old code until it runs fast when it could instead try to
figure out better algorithms and make sure that the systems needed to
get that software up fast and perform well is available.

Everyone who moves to a  new class of architectures has to expect to
rewrite their code, don't they?

Flame suit on,
Pete
--
Department of Computer Science, Duke University, Durham, NC 27706
Internet:	psu@cs.duke.edu
UUCP:		mcnc!duke!psu
Xref: sparky comp.sys.intel:2785 comp.arch:11788
From: tim@apple.com (Tim Olson)
Newsgroups: comp.sys.intel
Subject: Re: 486 vs. Mac Benchmarks
Date: 18 Dec 92 15:03:50 GMT
Followup-To: comp.sys.intel,comp.sys.mac.hardware,comp.sys.ibm.pc.hardware
Organization: Apple Computer Inc. / Somerset

In article <BzFoLA.LB1@news.cso.uiuc.edu>, rvenkate@ux4.cso.uiuc.edu
(Ravikuma Venkateswar) wrote:

> But wasn't the 68040-33 clock doubled?  (i.e. didn't it run internally
> at 66 MHz) Which would mean that the 68040-33 should be compared to the
> 80486DX2-66 . Which means that the Intel processor is still faster at the
> same clock speed.

No, the 68040 is not "clock doubled", at least in the way that is meant
with the 486DX2.  In going from the 68030 to the 68040, the input clock
changed from a 2x clock to a 1x clock, but the bus still runs at the same
speed as the processor.

     -- Tim Olson
        Apple Computer Inc. / Somerset
        (tim@apple.com)
Newsgroups: comp.sys.intel,comp.sys.mac.hardware,comp.sys.ibm.pc.hardware
From: ntaib@silver.ucs.indiana.edu (Iskandar Taib)
Subject: Re: 486 vs. Mac Benchmarks
Organization: Indiana University
Date: Thu, 17 Dec 1992 20:02:18 GMT

In article <1gl4bjINNh73@menudo.uh.edu> cosc184z@menudo.uh.edu (David Alten) writes:

>Did the ci and/or PC have an FPU??  If I remember correctly, Excel checks to
>see if you have an FPU, and uses FPU math instead of integer math if you have
>an FPU installed.

>I'm not too familiar with PC's, so if I missed something, please correct me.

Neither 386 box has an FPU as far as I know. The mac doesn't 
either. 


I'm going to try this on a couple 486 boxes upstairs.



-- 
-------------------------------------------------------------------------------
Iskandar Taib                          | The only thing worse than Peach ala
Internet: NTAIB@SILVER.UCS.INDIANA.EDU |    Frog is Frog ala Peach
Bitnet:   NTAIB@IUBACS                 !
From: hsmith@world.std.com (heath smith)
Subject: Looking for 8051/8044/Bitbus users group.
Keywords: 8051/8044/Bitbus/DCX51/DCM44
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 11 Dec 1992 18:32:11 GMT

Please return e-mail here. I am very interested in contributing to the PD
software collection as it pertains to the 8044 and Bitbus. I am also
interested in helping others with 8051 programming.

I have discovered many things about Bitbus and the 8044 over that past few
years, and I have finally found ways to configure and maintain Bitbus
networks painlessly. Also, now that the DCX51 and DCM44 source code has
been released, I am sure that many of the problems people have experienced
can now be corrected.

I would also like to say thanks to the people at Intel that were
responible for the release of the source.

You can also contact me at my FAX 313-229-9072, (which also has an
answering machine on it.)

Organization: Sophomore, Physics, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.intel,comp.sys.ibm.pc.hardware
Date: Fri, 18 Dec 1992 08:47:35 -0500 
From: Faisal Nameer Jawdat <fj05+@andrew.cmu.edu>
Subject: Re: 486SLC chip..NextStep on Cyrix
	<BzD3yJ.4pF@hfglobe.intel.com>

sting@hfglobe.intel.com (Joe Bennett) writes:
> possibly tested much that was written for the 486 with its changes to
> the supervisor mode/exception handling/etc. because *there* *was* *not*
> *much* *out* *there* that a general PC user would use.

One somewhat related question:  Did they test NT on it?  Doesn't NT
require a 486?  ( I could be wrong on this...)


-- faisal jawdat                  | "Certainly the game is rigged.
email: fj05+@andrew.cmu.edu       | Don't let that stop you;
if mail handler barfs             | if you don't bet, you can't win." 
fj05@andrew.cmu.edu               |        -Lazarus Long
Newsgroups: comp.sys.intel
From: Mark Kovarski <kovarski@zooid.guild.org>
Subject: Q: What's wrong with this?
Organization: ZOOiD BBS
Date: Tue, 15 Dec 1992 16:13:20 GMT


I have the following it of code which was given to me. Aside from the "few"
errors, the person claims that this will cause a message:

ON BOARD PARITY ERROR
ADDR (HEX) = (xxxx:xxxx)
SYSTEM HALTED.

This apparently appears when the following is run:

mov al,74
out 43,al
mov al,ff
out 41,al
mov al,ff
out 41,al
ret

----------

I can not check this since I am running OS/2 and traps the error before it
appears on the screen. The person claims that he interfers with the DMA
refresh rate and this is the reason a parity error appears.

Could someone check if this is the case and if so, why the error appears. From
my understanding, a parity error can only be caused by DRAM and I/O parity
errors. Furthermore, on the PC AT, 2BH and 29H are the post addresses for the
Interrupt controller (8259A). THe Programmer's PC Sourcebook mentiones that
ports 20 and 21 are only used. There seems to be something very strange going
on with this program. Thanks...

Mark K.
E-Mail: kovarski@zooid.guild.org
From: christos@kuhub.cc.ukans.edu
Newsgroups: comp.sys.intel
Subject: # of MIPS for all the '86 family
Date: 19 Dec 92 15:09:35 CST
Organization: University of Kansas Academic Computing Services

Hello there,

	I am looking for # of MIPS for the Intel '86 family, 286, 386SX, 386, 486SX
486 and 586(Pentium).

	I would appreciate any relevant response.
From: matthias@nsr.hp.com (Matthias Kamm)
Newsgroups: comp.sys.intel
Subject: Re: 486/66 .. Into a 486/50 motherboard?
Date: 17 Dec 1992 16:43:51 GMT
Organization: Hewlett Packard Santa Clara Site
NNTP-Posting-Host: hpmvd069.nsr.hp.com
X-Newsreader: TIN [version 1.1.2 PL7]

: >Is it possible to replace the 50MHz 486DX chip on a 486/50 mommyboard with a
: >66 MHz DX/2??  I am thinking of replacing my CPU, but I don't want to replace
: >my entire motherboard if I don't have to.  Thanks.
:
Nope.  I wouldn't do it.  A 50Mhz "system" is preferrable to a 33Mhz "system"
with a clock-doubled chip.  If there is a difference, it definitely 
wouldn't be worth the cost.  Save your money and buy a Pentium based system
(or a Cyrix 586... or a NextGen 586...???)

Newsgroups: comp.graphics
From: olsen_jo@cc.uvcc.edu
Subject: Re: Request for info on Video Toaster
Organization: Utah Valley Community College
Date: Thu, 17 Dec 1992 16:52:31 GMT

In article <7485@dove.nist.gov>, glenn@sloth.ncsl.nist.gov writes:
> Can someone please tell me what the term Video Toaster means.

The toaster is a hardware add-on for the Amiga which does real-time
video effects such as wipes, fades, color effects, chroma keying and
genlocking.  You can get a stand-alone toaster for the Mac, but it is 
really an Amiga being used as a peripheral to the other computer.

I don't know if they've done a PC interface yet.

olsen_jo@uvadm.uvcc.edu
From: 00rbspelman@leo.bsuvc.bsu.edu
Newsgroups: comp.graphics
Subject: GIF editor wanted
Date: 18 Dec 92 03:02:18 GMT
Organization: Ball State University, Muncie, In - Univ. Computing Svc's

I am looking for a program like PhotoMagic for the Ibm, which will
allow me to load GIF files, edit them - colorize, add/remove pixels,
and otherwise manipulate them - then save them again.  Is there a 
good shareware program out there that does the same thing?  Does
anyone know of a good retail program under $60.00 that does this?

Robert B. Spelman
Ball State University
Muncie, IN

00rbspelman@virgo.bsuvc.bsu.edu
	or
rspelman@bsu-cs.bsu.edu
From: udptech@uniwa.uwa.edu.au (Denis Brown)
Newsgroups: comp.graphics
Subject: Re: AXUM Graphics Package
Date: 17 Dec 1992 07:47:06 +0800
Organization: The University of Western Australia
NNTP-Posting-Host: uniwa.uwa.edu.au
X-Newsreader: Tin 1.1 PL5

Thanks to John Beale at Stanford and Jeff Bangert at Kansas Uni. who
were able to tell me that TriMetrix, Seattle WASHINGTON are publishers
of AXUM.
Cheers,
Denis.

Newsgroups: comp.graphics
From: yh3w@brain.med.virginia.edu (Yuan-Chuen Hwang)
Subject: information about BRLCAD
Organization: Neuroclinical Trials Center, University of Virginia
Date: Tue, 15 Dec 1992 19:02:39 GMT

Hi everyone:

I have received the information about BRLCAD from Ron Natalie and Alan Magnuson.

Thank you very much.


Hwang
Xref: sparky comp.graphics:12978 sci.image.processing:1417
From: saeed@a.cs.okstate.edu (SAEED FAISEL)
Newsgroups: comp.graphics,sci.image.processing,comp.archives.d
Subject: gif 89a
Date: 16 Dec 92 21:49:30 GMT
Article-I.D.: a.1992Dec16.214930.15256
Organization: Oklahoma State University

What is the latest gif standard ? Iassume gif89a, right ?

Now, I use gwks 6.1m for gif processing.
But it goofs up on gif89a pictures.
What should I use ?

Also, is there a utility to scale jpeg pictures ?

Any help will be appreciated.
-- 

-----------------------------------------------------------------------
| Faisel Saeed                        e-mail: saeed@a.cs.okstate.edu  |
| Department of Computer Science                                      |
Newsgroups: comp.graphics
From: bdickens@el_padre.mitre.org (Brian Dickens)
Subject: Reading LANSAT format images.
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Sat, 12 Dec 1992 19:56:04 GMT

I need to write a program capable of reading in LANSAT images.

Would anyone happen to know the data storage format?

Any help or suggestions appreciated.  (i.e., ways of converting LANSAT to more
conventional formats...)

-bdickens
Newsgroups: comp.graphics
Subject: Looking for help on VESA programing.
From: djlewis@ualr.edu
Date: 14 Dec 92 16:13:16 GMT
Organization: University of Arkansas at Little Rock

In article <37900@uflorida.cis.ufl.edu>, HANS@PINE.CIRCA.UFL.EDU (VAN_OOSTROM) writes:
> In <1992Dec7.091748.3093@mfltd.co.uk> sts@mfltd.co.uk writes:
> 
>> 
>> In article <1ftgdqINN711@gap.caltech.edu>, mikec@ugcs.caltech.edu (Michael Hamilton Coward) writes:
>> |> Hi, subject line says it all - I need a copy of the VESA standard in order
>> |> to program my graphics card.    
>> |> 
>> |> Thanks,
>> |> Mike     
> 
> Just call this number (408) 435-0333, and they will send you a free package
> with the whole specification and a disk.
> Ask for the VESA Super VGA standard documentation
> 
> Hans van Oostrom                    KD4MUJ
> PO Box J-254, JHMHC                 hans@ufpine                (BITNET)
> Gainesville, FL  32601, USA         hans@pine.circa.ufl.edu    (INTERNET)
>>>>          Hoe ver je ook gaat, overal zie je landgenoten           <<<

Hello all, 
	I have the above mentioned VESA kit. Be prepared to know PASCAL. I
found a public domain pas to c convertor that helps but does'nt do it all. I
asked for a "C" kit when I ordered it. The kit comes with old VESA drivers
from some vendors (early91) and some early demo programs.
	I have a technical question. I have the STB Evolution VESA compliant
card and am having a VERY difficult time getting the modes 0x101h, 0x103h,
0x104h, 0x105h or in other words, any 256colour mode. It appears to be a
problem with VESA function 0x4F05 (SetVesaBank()). Anyone programming VESA
modes want to share their experiance?
Don Lewis
djlewis@ualr.edu
djlewis@spider.ualr.edu
From: jsrobin@umiacs.umd.edu (John S. Robinson)
Newsgroups: comp.graphics
Subject: Spectral Intensity Meters
Date: 13 Dec 92 16:10:16 GMT
Distribution: usa
Organization: UMIACS, University of Maryland, College Park, MD 20742


Newsgroups: comp.graphics
From: coy@plato.ds.boeing.com (Stephen B Coy)
Subject: Re: Faster ray intersector for POV
Organization: Boeing Defense & Space Group
Date: Sat, 19 Dec 1992 00:10:30 GMT

In article <724717837snx@osea.demon.co.uk> andy@osea.demon.co.uk (Andrew Haveland-Robinson) writes:

>I haven't come across raw2pov before though.

You should be able to find it on CIS and The Graphics Alternative
BBS.

>Are raw files of the format:

The raw files are just the vertex data for the triangles.

x1 y1 z1
x2 y2 z2
x3 y3 z3

You end up with 9 numbers per triangle.  Most of the POV utilities
that read these don't require any special formatting.

Stephen Coy
coy@plato.ds.boeing.com



Xref: sparky comp.graphics:12888 comp.multimedia:3835 comp.sys.sun.wanted:2002