Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Virus attack through printer chip?

22 views
Skip to first unread message

Charles Packer

unread,
Jan 13, 1992, 7:46:00 AM1/13/92
to
Is it possible to introduce a virus into a mainframe's
software via a printer; that is, by replacing a ROM chip
on the printer with one that will attack the mainframe?

It would seem to depend on the host reading the firmware
off the chip and executing it in it's own memory, right?
Is this a typical printer control strategy?

Steve McKinty - Sun ICNC

unread,
Jan 13, 1992, 8:49:04 AM1/13/92
to
In article <13JAN199...@amarna.gsfc.nasa.gov>, pac...@amarna.gsfc.nasa.gov (Charles Packer) writes:
> Is it possible to introduce a virus into a mainframe's
> software via a printer; that is, by replacing a ROM chip
> on the printer with one that will attack the mainframe?

Well, anything's possible, but I'd think that was extremely unlikely

>
> It would seem to depend on the host reading the firmware
> off the chip and executing it in it's own memory, right?
> Is this a typical printer control strategy?

Not one I've ever seen. It would mean that the printer would only work
on one specific computer (the one that could run the code). About the
only commonplace printers which talk back to the mainframe at all are
Postscript ones, and they usually confine themselves to sending back error
and status messages, certainly not code that is executed. Most printers
are strictly one-way devices, except possibly for a couple of stop/start
characters which are sent back to pause the data to the printer if
the mainframe is sending it too fast.

--
Steve McKinty
SUN Microsystems ICNC
38240 Meylan, France
email: smck...@france.sun.com BIX: smckinty

Chris J. Wein

unread,
Jan 13, 1992, 9:30:59 AM1/13/92
to

I assume that this article is in reply to a recent newspaper column which
states that the National Security Agency (NSA) planted a virus in the
Iraqi defense net using exactly this technique. Supposedly, they
located a French printer which was to be smuggled into Iraq and then
changed a `chip'. The article did not state if the chip was a ROM chip
but that was probably assumed...

Just FYI...


--
==============================================================================
Chris Wein | cjw...@watcgl.waterloo.edu
Computer Graphics Lab, CS Dept. | cjw...@watcgl.uwaterloo.ca
University of Waterloo | (519) 888-4548

David Feustel

unread,
Jan 13, 1992, 9:21:22 AM1/13/92
to
pac...@amarna.gsfc.nasa.gov (Charles Packer) writes:

I saw this explanation of why Iraq did so poorly against U.S. Air
Attack, but I don't buy it. I think this is an attempt by the U.S.
military to obfuscate the effectiveness of U.S. electronic warfare.
--
David Feustel N9MYI, 1930 Curdes Ave, Fort Wayne, IN 46805. (219)482-9631
feu...@netcom.com

francis deck

unread,
Jan 13, 1992, 11:57:15 AM1/13/92
to

Perhaps reading in firmware from a printer's ROM is standard
technique for mainframes. Then, sure. you could inject a
virus from that printer ROM.

Fortunately, this cannot happen on a PC. The PC's printer
port is unidirectional, and no code or data are read from
the printer!

F. Deck

Douglas A Taylor

unread,
Jan 13, 1992, 12:33:20 PM1/13/92
to
In article <1992Jan13.1...@watcgl.waterloo.edu> cjw...@watcgl.waterloo.edu (Chris J. Wein) writes:
%In article <13JAN199...@amarna.gsfc.nasa.gov> pac...@amarna.gsfc.nasa.gov (Charles Packer) writes:
%>Is it possible to introduce a virus into a mainframe's
%>software via a printer; that is, by replacing a ROM chip
%>on the printer with one that will attack the mainframe?
%
%I assume that this article is in reply to a recent newspaper column which
%states that the National Security Agency (NSA) planted a virus in the
%Iraqi defense net using exactly this technique. Supposedly, they
%located a French printer which was to be smuggled into Iraq and then
%changed a `chip'. The article did not state if the chip was a ROM chip
%but that was probably assumed...

I don't know which newpaper you read this in, but I first saw an
article about this in Infoworld in early April '91. The columnist
told this long story about how the NSA created a super-virus that
could hide in the printer chips, could adapt to either Intel- or
Motorola- based computers, and was palindromic, so that it could be
read either front-to-back or back-to-front.

He attributed Iraq's lack of offense in the Gulf war to this virus, at
least in part. Evidently, the virus got loose and is slowly wending
its way from the Middle East towards the West, while the NSA is
frantically trying to come up with a way to nuke the virus.

However, the last paragraph of the column made it pretty clear that
the whole story was just a April Fool's joke.

Sounds like we have an urban legend in the making, eh?

% Chris Wein | cjw...@watcgl.waterloo.edu
--
Doug Taylor | Nothing real can be threatened.
The Ohio State University | Nothing unreal exists.
doug_...@osu.edu | - A Course in Miracles

Dave Chu

unread,
Jan 13, 1992, 12:53:42 PM1/13/92
to
It seems very plausible that the United State government would do such a
thing. The article was not very specific about the type of printer
involved. If the printer in question was a network printer it would be
very easy for it to infect computers on the same network. Especially if
the computers used were most likly sold to Iraq by US computer sources.
These computers could already have a time bomb in them and was just
waiting for the right command to release them. Well atleast we know one
thing for sure, the government of the United States is actively involved
in the production of computer virus.

David B. Horvath, CDP

unread,
Jan 13, 1992, 1:14:12 PM1/13/92
to
In article <1992Jan13.1...@news.nd.edu>, fd...@bashful.helios.nd.edu
(francis deck) says:
>
> {stuff about virus through printer port deleted}
>

>
>Fortunately, this cannot happen on a PC. The PC's printer
>port is unidirectional, and no code or data are read from
>the printer!
>
>F. Deck

The parallel printer port on IBM-PC's and true clones is a bi-directional
port - data can be written *OR* read. I've seen articles that use that
ability to get high-speed data input to a PC without the use of the
serial port or a new interface board. The idea is to convert the data
into a byte, trigger the proper bits on the interface, and have a
program to read the byte from the port.

BTW: Could it have a network server printer? Printers like DEC's LPS
series are actually MicroVAX II's driving the print engine...

- David

Matthew J. Harper

unread,
Jan 13, 1992, 1:43:30 PM1/13/92
to
fd...@bashful.helios.nd.edu (francis deck) writes:

>F. Deck

To quote my younger brother: NOT!

A PC's printer port is NOT unidirectional. It is bidirectional. That's one
of the reasons programs like lap-link can work using the parallel port to
transfer files between two PC's.

Granted, reading data from a *printer* is not done too often, but it's not the
port that restricts it.

-Matth
--
Matthew J. Harper ! Progress Software Corp. ! Internet: ma...@progress.com
Disclaimer: I speak/write for myself. With more pay I might consider
speaking for Progress if they asked me *real* nice.

les...@naomi.b23b.ingr.com

unread,
Jan 13, 1992, 3:18:47 PM1/13/92
to
In article <kn366g...@grapevine.EBay.Sun.COM>, smck...@sunicnc.France.Sun.COM (Steve McKinty - Sun ICNC) writes:
|> In article <13JAN199...@amarna.gsfc.nasa.gov>, pac...@amarna.gsfc.nasa.gov (Charles Packer) writes:
|> > Is it possible to introduce a virus into a mainframe's
|> > software via a printer; that is, by replacing a ROM chip
|> > on the printer with one that will attack the mainframe?
|>

I don't know the details of this particular situation (The US managed
to place a printer with modified ROM code in a major computer center in
Iraq with the intent to disable the computers). On a unix system, a
printer is sometimes (always?) connected to a serial port that can also
act as a port for a terminal. Perhaps the printer ROM was able to "login"
to the computer and remove files or whatever. Note the wishy washy
language I used here! I do not claim that this is actually how the
events unfolded, but this is a possibility that I thought of. And very
simple at that.

- Les

--
Les Bartel les...@naomi.b23b.ingr.com
Dazix, An Intergraph Company uunet!ingr!b23b!naomi!lester

Tomi H Engdahl

unread,
Jan 13, 1992, 4:28:22 PM1/13/92
to
In article <1992Jan13.1...@news.nd.edu> fd...@bashful.helios.nd.edu (francis deck) writes:

> Fortunately, this cannot happen on a PC. The PC's printer
> port is unidirectional, and no code or data are read from
> the printer!

This is not whole truth. Some PCs have bidirectional parallel
port (IBM PS/2 series and some clones). There is also a way to
use the parallel port, which is usually considered unidirectional,
in normal PC as bidirectional port.
I have never heard that any code is downloaded from printer to PC.
That system is not used, but is not impossible with new hardware,
though DOS does dos support such feature.


--

Tomi.E...@hut.fi
th...@vipunen.hut.fi

John Whitmore

unread,
Jan 13, 1992, 4:20:52 PM1/13/92
to
In article <1992Jan13.1...@news.nd.edu> fd...@bashful.helios.nd.edu (francis deck) writes:

>Perhaps reading in firmware from a printer's ROM is standard
>technique

Not likely. For a disk drive (boot device) this sort of
behavior IS standard, however.

>Fortunately, this cannot happen on a PC. The PC's printer
>port is unidirectional, and no code or data are read from
>the printer!

This depends on how the printer attaches, and there are
LOTS of options here. My 'PC', for example, is a Macintosh,
and there are Mac printers that connect to the Localtalk LAN,
and others that connect to the SCSI bus. In both cases,
the printer has access to every block/packet on the bus.

And by appropriately writing the software, any printer
so connected can take control just like a CPU normally would.

It would be relatively simple to 'spoof' the startup
sequence on a Mac with an attached Laserwriter SC, so that a
nub of code was loaded from the printer before the main hard
disk got a chance to boot normally. On the LAN version
printers, any networked data transfer could be monitored
and (if some trigger pattern were noted) one could create
parity/checksum errors by violating LAN protocol, to slow down (or
block) transfer of some particular type of information. It
would also be possible to insert spurious information, but
that would require some finesse.

The bus packets are identified in software; change the
software, and no packet address information can be trusted.
It could take a LOT of work to find out why the networked system
isn't functioning.

John Whitmore

Mike Ardai

unread,
Jan 13, 1992, 4:20:43 PM1/13/92
to
In article <1992Jan13.1...@progress.com> ma...@progress.COM (Matthew J. Harper) writes:
-fd...@bashful.helios.nd.edu (francis deck) writes:
-
--Fortunately, this cannot happen on a PC. The PC's printer
--port is unidirectional, and no code or data are read from
--the printer!
- To quote my younger brother: NOT!
-
- A PC's printer port is NOT unidirectional. It is bidirectional. That's one
-of the reasons programs like lap-link can work using the parallel port to
-transfer files between two PC's.
-
- Granted, reading data from a *printer* is not done too often, but it's not the
-port that restricts it.
-

Actually, the correct answer is 'it depends'. All PC printer ports are
bidir to some extent. Unfortunately, in their infinite wisdom, IBM decided
to make the 8-bit data path unidirectional (While it can be read, there is no
way to turn off the drivers). This can be fixed with a 1-wire mod if the
printer port is made out of TTL chips. If it is in an ASIC, you have to hope
the designer has lready done it. There are 5 strictly input bits (error,
busy, no paper, etc.) and a bunch of bidirs with OC drivers and pullups.
There was a 'Design Ideas' entry in EDN a few months back that used a
clever muxing scheme to hook an 8255 to a printer port with full bidir
capabilities.

As for laplink, they may send the data 5 bits at a time, overdrive three of the
OD/pullup bits, or do things serially; I'm not sure which.

/mike
--
\|/ Michael L. Ardai N1IST Teradyne EDA East
--- -------------------------------------------------------------------------
/|\ ar...@teda.teradyne.com

Brian Powell

unread,
Jan 13, 1992, 7:41:23 PM1/13/92
to

In article <1992Jan13....@magnus.acs.ohio-state.edu>, dta...@magnus.acs.ohio-state.edu (Douglas A Taylor) writes:
>
> I don't know which newpaper you read this in, but I first saw an
> article about this in Infoworld in early April '91. The columnist
> told this long story about how the NSA created a super-virus that
> could hide in the printer chips, could adapt to either Intel- or
> Motorola- based computers, and was palindromic, so that it could be
> read either front-to-back or back-to-front.
>
> He attributed Iraq's lack of offense in the Gulf war to this virus, at
> least in part. Evidently, the virus got loose and is slowly wending
> its way from the Middle East towards the West, while the NSA is
> frantically trying to come up with a way to nuke the virus.
>
> However, the last paragraph of the column made it pretty clear that
> the whole story was just a April Fool's joke.
>
> Sounds like we have an urban legend in the making, eh?


Actually, this exact story (except the "slowly wending its way toward the West"
part) was told on an ABC Special Nightline report on the gulf war...


-- Brian

+--The Ohio Supercomputer Center----------------------------------------------+
| Brian S. Powell bpo...@osc.edu |
+--"My other computer is a CRAY" (YMP 8/864)----------------------------------+

C G Kolar

unread,
Jan 14, 1992, 4:29:02 AM1/14/92
to
bpo...@osc.edu (Brian Powell) writes:

>Actually, this exact story (except the "slowly wending its way toward the West"
>part) was told on an ABC Special Nightline report on the gulf war...

>-- Brian

thanks for bringing the discussion back to the story. on Nightline it was
reported that the virus was put into a printer that was to be installed
in the network controlling baghdad's air defences. i don't recall any
mention of PCs. supposedly the virus left the printer and, at just the
right moment, attacked the radar screens of the baghdad air defence batteries.
the stealth virus story was used to explain the low level of air losses
suffered by US planes flying missions over the capital, saying that the
AA batteries in baghdad were essentially "'firing blind"'.

it seems to me that a lot of really specialzed programming would have
been needed to pull this off, this isn't exactly another STONED virus.
does anyone in netland know about soviet hardware? i'm pretty skeptical.

chris

--
c-k...@uiuc.edu

Harald Ljoen FBA

unread,
Jan 14, 1992, 6:10:02 AM1/14/92
to
In article <92013.131...@ROHVM1.BITNET>, MBA...@ROHVM1.BITNET (David B. Horvath, CDP) writes:
|> In article <1992Jan13.1...@news.nd.edu>, fd...@bashful.helios.nd.edu
|> (francis deck) says:
|> >
|> > {stuff about virus through printer port deleted}
|> >
|>
|> >
|> >Fortunately, this cannot happen on a PC. The PC's printer
|> >port is unidirectional, and no code or data are read from
|> >the printer!
|> >
|> >F. Deck
|>
|> The parallel printer port on IBM-PC's and true clones is a bi-directional
|> port - data can be written *OR* read. I've seen articles that use that

My memory tells me that bidirectional printer ports was introduced with the AT in
1984. If my memory is coerrect, PC and PC/XT printer ports were unidirectional.

--
+----------------------------+----------------------------------------------+
| Harald Ljoen | X400: harald...@forskning.teledir.no |
| Norwegian Telecom Research | internet: h...@hal.nta.no |
| Box 83 | Phone: + 47 6 80 91 70 |
| N-2007 Kjeller, NORWAY | Fax: + 47 6 81 00 76 |
+----------------------------+--------- #include <StdDisclaimer.h> ---------+

Evil Engineer doin' it the Cowboy Way

unread,
Jan 14, 1992, 10:51:04 AM1/14/92
to
In article <THEN.92Ja...@vipunen.hut.fi> th...@vipunen.hut.fi (Tomi H Engdahl) writes:

In article <1992Jan13.1...@news.nd.edu> fd...@bashful.helios.nd.edu (francis deck) writes:

> Fortunately, this cannot happen on a PC. The PC's printer
> port is unidirectional, and no code or data are read from
> the printer!

This is not whole truth. Some PCs have bidirectional parallel
port (IBM PS/2 series and some clones). There is also a way to
use the parallel port, which is usually considered unidirectional,
in normal PC as bidirectional port.

Well, there IS a way, assuming you don't mind abusing TTL-compatible
circuitry. The standard 8-bit "bidirectional" data port on the parallel
interface has 27 ohm damping resistors in series with its outputs, which
are driven (classically) by a 74LS374 (latch with 3-state outputs). The
374 outputs are always enabled in the standard circuit, so the data lines
are always driven. You CAN overpower the outputs with a low-impedance external
driver, due to the 27-ohm damping resistors. Doing so is pretty mean to
an ordinary three-state output, although they probably can take it for
a long time. It's certainly not the COWBOY WAY of interfacing it.

I have never heard that any code is downloaded from printer to PC.
That system is not used, but is not impossible with new hardware,
though DOS does dos support such feature.

The only thing that makes sense for introducing a virus is a printer (or
other device) with a network interface. Such a device could easily be
altered to monitor and transmit data to introduce all sorts of things into
the system. All the required resources a probably in place, just add a
control program in the PROM..

--

Tomi.E...@hut.fi
th...@vipunen.hut.fi

"Yeh, Buddy.. | la...@psl.nmsu.edu (Larry Cunningham)| _~~_
I've got your COMPUTER! | % Physical Science Laboratory | (O)(-)
Right HERE!!" | New Mexico State University | /..\
(computer THIS!) | Las Cruces, New Mexico, USA 88003 | <>
--------------------------------------------------------------------------
Disclaimer: Opinions expressed here are CORRECT, mine, and not PSLs or NMSUs..
O Fair New Mexico! Landfill of Enchantment. And home of THEM (Atomic Ants)..

K. Khan

unread,
Jan 14, 1992, 12:39:29 PM1/14/92
to

In article <kn366g...@grapevine.EBay.Sun.COM> smck...@sunicnc.France.Sun.COM (Steve McKinty - Sun ICNC) writes:
>In article <13JAN199...@amarna.gsfc.nasa.gov>, pac...@amarna.gsfc.nasa.gov (Charles Packer) writes:
> > Is it possible to introduce a virus into a mainframe's
> > software via a printer; that is, by replacing a ROM chip
> > on the printer with one that will attack the mainframe?
>
>Well, anything's possible, but I'd think that was extremely unlikely

Coincidentally, over the weekend there were news reports that one reason
the Iraqui air defenses were so impotent during the war was because we
had sent them a computer virus lodged in a printer. Someone found out
that this printer was going to be smuggled across the border from
Jordan, so it was infected with a virus which caused the Iraqi radar
screens to go blank. On the surface, it sounds EXTREMELY unlikely, but
I'm suspending judgement for the moment.

I'm DYING to hear a logical explanation of how this could happen.
Otherwise, I'll have to chalk it up to just another technically ignorant
news reporter making severe technical blunders and the equally
technically ignorant news editor failing to catch them.

K. Khan

unread,
Jan 14, 1992, 12:40:32 PM1/14/92
to

In article <1992Jan13.1...@news.nd.edu> fd...@bashful.helios.nd.edu (francis deck) writes:
>
>Fortunately, this cannot happen on a PC. The PC's printer
>port is unidirectional, and no code or data are read from
>the printer!

Minor nit: the *IBM* PC's printer port is unidirectional, but many clone
printer ports are fully bidirectional. Also, PS/2s have bidirectional
printer ports.

Still, there's no way to infect a PC using a printer.

K. Khan

unread,
Jan 14, 1992, 12:40:54 PM1/14/92
to

In article <1992Jan14.0...@osc.edu> bpo...@osc.edu (Brian Powell) writes:
>
>In article <1992Jan13....@magnus.acs.ohio-state.edu>, dta...@magnus.acs.ohio-state.edu (Douglas A Taylor) writes:
>>
>> I don't know which newpaper you read this in, but I first saw an
>> article about this in Infoworld in early April '91.
>> [...]

>> However, the last paragraph of the column made it pretty clear that
>> the whole story was just a April Fool's joke.
>>
>> Sounds like we have an urban legend in the making, eh?
>
>
>Actually, this exact story (except the "slowly wending its way toward the West"
>part) was told on an ABC Special Nightline report on the gulf war...

Did Ted Koppel tell you that the name of this virus is "AF/91"? I'll bet
he didn't!! ;-)

I have just (re-)read the column from the April 1, 1991 issue of
InfoWorld (it's on page 39). It doesn't surprise me in the slightest
that the mainstream news media would take an April Fool's joke story and
regurgitate it as real news. Most of the reporters and editors don't
know squat about computers, and thus the problems which to us are
obvious (e.g. the computer doesn't execute code located in the printer's
ROM) completely escape their ability to detect, and they print the
story. Perhaps someone submitted the bogus story to them just to see if
they were dumb enough to report it? ;-)

Don't think this is impossible: in "Out of the Inner Circle," dark side
hacker Bill Landreth tells of the time he and his buddies discovered a
story submission system for a major newspaper. They could have easily
submitted a story and, if it wasn't obviously bogus, it could very well
have been printed. Perhaps someone submitted the AF/91 virus story from
InfoWorld (with minor modifications) to UPI or some other news service
and it was passed on without being checked out?

Things that make ya go "Hmm......" ;-) ;-)

jaap

unread,
Jan 14, 1992, 2:38:49 PM1/14/92
to
In article <1992Jan13.1...@news.nd.edu> fd...@bashful.helios.nd.edu (francis deck) writes:
>
> Fortunately, this cannot happen on a PC. The PC's printer
> port is unidirectional, and no code or data are read from
> the printer!
>

Depends on your defnition of a PC. The Lisa had a port which could
connect to a printer or a disk.

Also, PostScript printers do have a two-way communication channel, but
in general, the whole story sounds pretty weird to me.

jaap

John O'Beck

unread,
Jan 14, 1992, 2:35:19 PM1/14/92
to

>>bpo...@osc.edu (Brian Powell) writes:
>>Actually, this exact story (except the "slowly wending its way toward the
>> West" part) was told on an ABC Special Nightline report on the gulf war...
>>-- Brian

>cgk1...@uxa.cso.uiuc.edu (C G Kolar) writes:
>thanks for bringing the discussion back to the story. on Nightline it was
>reported that the virus was put into a printer that was to be installed

>in the network controlling baghdad's air defences...


Well, the first I saw the story was in an article in one of the trade
magazines, PCWeek, Unix Today, I forget which.
HINT - The date of the article was 1 APR 91

--
******************************************************************************
J. T. O'Beck Litwin Process Automation j...@dynsim1.litwin.com
1250 W. Sam Houston Pkwy S.
Houston TX, 77042 (713) 268-7356

Pete Hardie

unread,
Jan 14, 1992, 3:22:36 PM1/14/92
to

A friend of mine has told me someone he knew used their Postscript printer
as a coprocessor, back when such a printer usually had more horsepower than
the PC it was attached to. So if there was some really sharp software on the
printer, it might find a way to sneak something into the 'master' computer's
dataspace.


--
Pete Hardie: phardie@nastar (voice) (404) 497-0101
Digital Transmission Systems, Inc., Duluth GA
Member, DTS Dart Team |
Position: Goalie | cat * | fgrep -v "signature virus"

Mark Zenier

unread,
Jan 13, 1992, 6:36:01 PM1/13/92
to
In article <1992Jan13.1...@news.nd.edu>, fd...@bashful.helios.nd.edu (francis deck) writes:
> Fortunately, this cannot happen on a PC. The PC's printer
> port is unidirectional, and no code or data are read from
> the printer!

But if you substitute "adaptor card with a BIOS exetension" for
"printer", in the Messy-Dos/PC world, it's very possible.

Mark Zenier ma...@ssc.wa.com mzenier%polar...@sumax.seattleu.edu

John De Armond

unread,
Jan 14, 1992, 6:46:30 PM1/14/92
to
cgk1...@uxa.cso.uiuc.edu (C G Kolar) writes:

>thanks for bringing the discussion back to the story. on Nightline it was
> reported that the virus was put into a printer that was to be installed
> in the network controlling baghdad's air defences. i don't recall any
> mention of PCs. supposedly the virus left the printer and, at just the
> right moment, attacked the radar screens of the baghdad air defence batteries.
> the stealth virus story was used to explain the low level of air losses
> suffered by US planes flying missions over the capital, saying that the
> AA batteries in baghdad were essentially "'firing blind"'.

>it seems to me that a lot of really specialzed programming would have
> been needed to pull this off, this isn't exactly another STONED virus.
> does anyone in netland know about soviet hardware? i'm pretty skeptical.


The Nightline report said that the virus was installed in a French-made
network printer that was to be smuggled to Iraq. My impression was that
the system was French but I might be mistaken.

Another interesting point of interest. Last summer I ran into an old
classmate who is working for some defense contractor, Rockwell I believe.
I knew he had been working on some pretty nifty stuff so I brought up
the Gulf War. He asked me if I had noticed all the AAA fire in Baghdad
firing in random spirals. I noted that I had. His comment then was
"That was my work" and grinned real big. He would not tell me anything
more but now I'm putting 2 and 2 together. I'm definitely going to
have to look him up again. :-)

John

--
John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm)
Rapid Deployment System, Inc. | Home of the Nidgets (tm)
Marietta, Ga | "It's not a bald spot, its a solar panel for
j...@dixie.com | a sex machine."

j...@dstos3.dsto.oz.au

unread,
Jan 15, 1992, 1:20:13 PM1/15/92
to
In article <1992Jan13.1...@news.nd.edu>, fd...@bashful.helios.nd.edu (francis deck) writes:

One of my colleagues has just got through telling me that the IBM pc printer
port has 4 input bits, and some people tend to use them + 4 output bits as a
bidirectional link. Possible applications are for disc drives, ethernet
interfaces.

Regardless of that lot, it is unlikely that...
a) a printer would want to dump its ROM
b) a host would be interested in reading it.

I support the theory that this is urban myth in the making :-)

Regards,

John Bennett, E-mail : j...@dstos3.dsto.oz.au
Head, Networks Group Phone : +61 8 259 5292
Information Systems Branch FAX : +61 8 259 6726
DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION Postal : Bld 73 Labs Area
AUSTRALIA PO Box 1600 Salisbury
"Lord Warden of the Sync Ports" South Australia 5108
(DSTO Network Manager) AUSTRALIA

Ken Shirriff

unread,
Jan 15, 1992, 12:16:48 AM1/15/92
to
One thing that seems to be getting lost in this discussion is that the
Iraqi air defense systems most likely don't use networked IBM PCs with
PostScript printers. Thus, much of this speculation is irrelevant.
Someone with Jane's handy should look up the details of their air defense,
but I'd expect that it's barely digital.

Ken Shirriff shir...@sprite.Berkeley.EDU

Robert Garito

unread,
Jan 15, 1992, 12:19:41 AM1/15/92
to
I think I know what is being brought up about viruses and printers. A few
days ago, the news program Primetime reported in a special on the Gulf war
that the US crippled the Iraqi's defense systems via a computer virus
that was sent over in a printer (manufactured in the US if I remember right)
that was attached to their computers. They said it was programmed into
a computer chip. Hmmmm.... Having worked on computers for most
of my life and doing quite a bit of systems' programming on everything
from Trash-80's to mainframes, I find this a bit impossible. I have a
feeling that someone got their story screwed up. Anyone else hear of
this?

--
Robert Garito, President
MicroLAN Technologies
INTERNET: rga...@sol.cs.fau.edu
rga...@novavax.nova.edu
u311...@elm.circa.ufl.edu
UUCP: ..!uunet!gatech!uflorida!novavax!rgarito

Robert Garito

unread,
Jan 15, 1992, 12:26:38 AM1/15/92
to


>Perhaps reading in firmware from a printer's ROM is standard
>technique for mainframes. Then, sure. you could inject a
>virus from that printer ROM.

Mainframe printers work basically the same as those on PC's. BUT, one
idea that you gave me is the possibility that the printer MAY have been
a network-interface printer (like a 3270 printer for you mainframe guys)
and the changed chip may have actually been the ROM/CPU that controlls
communications between the printer and the network. (Kinda' like
those ROMLESS (Z8000?) chips found on PC network cards). I suppose
this firmware could be infected with code that could foul up the
network when activated (eg: sending a jabber/collision signal
constantly or intermittently to successfully bring throughput to NIL).
Just a possibility, I suppose...

--
Robert Garito, President
MicroLAN Technologies
INTERNET: rga...@sol.cs.fau.edu
rga...@novavax.nova.edu

rga...@elm.circa.ufl.edu
UUCP: ..!uunet!gatech!uflorida!novavax!rgarito

Larry Kessler

unread,
Jan 15, 1992, 1:24:51 AM1/15/92
to
In article <1992Jan14....@nntp.nta.no>, h...@hal.nta.no (Harald Ljoen FBA) writes:
> In article <92013.131...@ROHVM1.BITNET>, MBA...@ROHVM1.BITNET (David B. Horvath, CDP) writes:
> |> In article <1992Jan13.1...@news.nd.edu>, fd...@bashful.helios.nd.edu
> |> (francis deck) says:
> |> >
> |> > {stuff about virus through printer port deleted}
> |> >
> |>
> |> >
> |> >Fortunately, this cannot happen on a PC. The PC's printer
> |> >port is unidirectional, and no code or data are read from
> |> >the printer!
> |> >
> |> >F. Deck
> |>
> |> The parallel printer port on IBM-PC's and true clones is a bi-directional
> |> port - data can be written *OR* read. I've seen articles that use that
>
> My memory tells me that bidirectional printer ports was introduced with the AT in
> 1984. If my memory is coerrect, PC and PC/XT printer ports were unidirectional.

Nope. True clones, even lowly 8088-based ones, have bidirectional
parallel ports. If it were not true, how would Laplink work? (Laplink is
a program used to port files from one PC to another quickly. Developed
for laptops but works great with desktops too. Comes with a six-headed
cable: 9-pin and 25-pin serial and 25-pin parallel connectors on each
end. The fastest transfers happen parallel-to-parallel.)

==================================================================
Larry Kessler Voice: 713-973-9393
Nature's Way Diaper Service Usenet: la...@sugar.neosoft.com
1741 Campbell Rd. Compu$pend: 7007...@compuserve.com
Houston TX 77080
The environmentally safe alternative to "disposable" diapers.
I _am_ the company, I can say any damn thing I please.
==================================================================
--

Rob Slade

unread,
Jan 15, 1992, 1:01:46 AM1/15/92
to
If I may be permitted to be a bit pedantic here, I had, by chance, to give a
seminar on viri today, and, of course, had to address this article.

Both parallel/Centronics and serial RS-232 ports are bidirectional. (Cabling
is not always, and I well remember having to deal, in the early days of PCs,
with serial ports which had been used as printer ports, and could not be used
as modem ports because the "return" pin had been sheared off, a common
practice to "fix" balky printers.) However, the "information" which comes back
over the line is concerned strictly with whether or not the printer is ready
to accept more data. It is never accepted as a program by the "host".

The case of "network" printers, is somewhat more complex. Two cases have been
suggested today: VMS and Mac: and they are quite distinct. The print server
mentioned on DECnet is actually a networked computer acting as a print server;
accepting files from other network sources and spooling them to a printer.
True, this computer/printer combo is often referred to simply as a printer,
but it would not, in any case, be able to submit programs to other hosts on
the net. The Mac case is substantially different, since the Mac laser
printers are attached as "peers". Mac laserwriters, at least, do have the
ability to submit programs to other computers on the network, and one Mac virus
uses the laserwriter as a vector. However, it is unlikely that the Iraqui air
defence system was Mac based, and few other systems see printers as peers.

The Infoworld AF/91 prank article has been mentioned. There was, however,
another article, quite seriously presented in a French military aerospace
magazine in February (which possibly prompted the Infoworld joke.) This earlier
article stated that a virus had been developed which would prevent Exocet
missiles, which the French had sold to Iraq, from impacting on French ships in
the area. The author used a mix of technobabble and unrelated facts, somehow
inferring from the downloading of weather data at the last minute before
launch, the programmability of targets on certain missiles and the radio
destruct sequences used in testing that such a "virus" was possible.

It has also been rumoured, and by sources who should know, that the US military
has sent out an RFP on the use of computer viri as computer weapons. Although
I have not seen the request, I *do* believe it went out. I *don't* believe
in teh newspaper report.

==============
Vancouver p...@arkham.wimsey.bc.ca | "A ship in a harbour
Institute for Robert...@sfu.ca | is safe, but that is
Research into rsl...@cue.bc.ca | not what ships are
User CyberStore Dpac 85301030 | built for."
Security Canada V7K 2G6 | John Parks

Nick Haines

unread,
Jan 15, 1992, 9:13:08 AM1/15/92
to
In article <1992Jan15....@softwords.bc.ca>, rsl...@cue.bc.ca (Rob Slade) writes:
> another article, quite seriously presented in a French military aerospace
> magazine in February (which possibly prompted the Infoworld joke.) This earlier
> article stated that a virus had been developed which would prevent Exocet
> missiles, which the French had sold to Iraq, from impacting on French ships in
> the area. The author used a mix of technobabble and unrelated facts, somehow
> inferring from the downloading of weather data at the last minute before
> launch, the programmability of targets on certain missiles and the radio
> destruct sequences used in testing that such a "virus" was possible.

This is a modern myth. It came up during the Falklands Fiasco, when the
Argentinians used Exocets. when it was claimed in some of the British press
that the French had radio sequences that would cause Exocets to do all sorts
of things (explode before launch, target on any potential target _except_
ones selected, explode in the air, make a good cup of tea, fall into the
sea, etc.), but because they were villainous frogs, they weren't letting on.
(Of course, the `virus' aspect wasn't present then, only being added when
viruses became fashionable). It was denied (and seemed extremely unlikely)
then.

|> ==============
|> Vancouver p...@arkham.wimsey.bc.ca | "A ship in a harbour
|> Institute for Robert...@sfu.ca | is safe, but that is
|> Research into rsl...@cue.bc.ca | not what ships are
|> User CyberStore Dpac 85301030 | built for."
|> Security Canada V7K 2G6 | John Parks

Nick Haines
ni...@cs.cmu.edu

Jeremy Reimer

unread,
Jan 15, 1992, 5:02:11 AM1/15/92
to
cgk1...@uxa.cso.uiuc.edu (C G Kolar) writes:

> bpo...@osc.edu (Brian Powell) writes:
>
> >Actually, this exact story (except the "slowly wending its way toward the We

> >part) was told on an ABC Special Nightline report on the gulf war...
>
> >-- Brian
>
> thanks for bringing the discussion back to the story. on Nightline it was
> reported that the virus was put into a printer that was to be installed
> in the network controlling baghdad's air defences. i don't recall any
> mention of PCs. supposedly the virus left the printer and, at just the
> right moment, attacked the radar screens of the baghdad air defence batteri

> the stealth virus story was used to explain the low level of air losses
> suffered by US planes flying missions over the capital, saying that the
> AA batteries in baghdad were essentially "'firing blind"'.
>
> it seems to me that a lot of really specialzed programming would have
> been needed to pull this off, this isn't exactly another STONED virus.
> does anyone in netland know about soviet hardware? i'm pretty skeptical.
>
> chris
>
> --
> c-k...@uiuc.edu

I don't see a need for this "magic" virus. All the US had to do is take out
the main radar batteries, and then, because of the low-tech way the Soviet
MiG-29's are designed, the entire Iraqi air-force was completely blind. So
they could have sent a few, fast, stealthy planes in to get the ground-based
radar, and then just attacked at leisure.

Also, I'm surprised the Iraqi's had computers at all (considering how backward
computer technology is in the former Soviet Union), let alone a big network of
PC's specially set up to be vulnerable to "printer viruses".

/\ FUSCHAL: THE PROMISED LAND. Where those who have faith shall wear
>==/ \==> hats of great majesty, yea, though they be made of cardboard and
/____\ have humourous arrows through them. (Red Dwarf)
.----------------------------------. Sunny Vancouver BC
Jeremy Reimer, aka [ => jag...@arkham.wimsey.bc.ca <= ] CANADA, where it's
The Jaguar! The Car, `----------------------------------' fun, fun, fun...
the Cat, the Lunatic George: What time is it? ^^^ ^^^ ^^^
-------------------- Edmund: Three o'clock in the afternoon, Your Highness.
PININ FOR THE FJORDS George: Oh thank GOD for that I thought I'd overslept!

Mike Berger

unread,
Jan 15, 1992, 3:18:19 PM1/15/92
to
j...@dstos3.dsto.oz.au writes:

>In article <1992Jan13.1...@news.nd.edu>, fd...@bashful.helios.nd.edu (francis deck) writes:
>> Perhaps reading in firmware from a printer's ROM is standard
>> technique for mainframes. Then, sure. you could inject a
>> virus from that printer ROM.
>>
>> Fortunately, this cannot happen on a PC. The PC's printer
>> port is unidirectional, and no code or data are read from
>> the printer!

>One of my colleagues has just got through telling me that the IBM pc printer
>port has 4 input bits, and some people tend to use them + 4 output bits as a
>bidirectional link. Possible applications are for disc drives, ethernet
>interfaces.

*----
A standard PC serial port is bidirectional. In addition, there are
handshaking lines that COULD be used for input; but it's not
necessary. A properly-implemented parallel printer port on a
PC is 8-bit bidirectional. NEC even makes a SCSI adapter for
a PC type parallel printer port.
--
Mike Berger
Department of Statistics, University of Illinois
AT&TNET 217-244-6067
Internet ber...@atropa.stat.uiuc.edu

Norman Soley

unread,
Jan 15, 1992, 5:02:40 PM1/15/92
to

In article <22...@alice.att.com>, ja...@alice.att.com (jaap) writes...

>In article <1992Jan13.1...@news.nd.edu> fd...@bashful.helios.nd.edu (francis deck) writes:
> >
> > Fortunately, this cannot happen on a PC. The PC's printer
> > port is unidirectional, and no code or data are read from
> > the printer!
>
>Depends on your defnition of a PC. The Lisa had a port which could
>connect to a printer or a disk.
>
>Also, PostScript printers do have a two-way communication channel, but
>in general, the whole story sounds pretty weird to me.

Let's suspend reality for a moment and assume that this really happened
instead of just being lifted from the Infoworld joke article.

The US News article said that the virus was aimed at "a mainframe" not
at a PC. Since we're dealing with mainly Soviet supplied technology this
suggests a cloned VAX (there are other possibilites but a cloned VAX is the
most likely). Now if the printer in question was a DEC PrinterServer, which
contains an embedded Microvax processor, it would not be too difficult at all
to produce a modified ROM which would include some extra code to spoof
network packets a couple of people have suggested ways this could be done
that would produce the blank window behavior described.

Just because it's possible don't make it true though....

--
Norman Soley, Specialist, Professional Software Services, ITC District
Digital Equipment of Canada so...@trooa.enet.dec.com
Opinions expressed are mine alone and do not reflect those of Digital
Equipment Corporation or my cat Marge.

Norman Soley

unread,
Jan 15, 1992, 5:22:31 PM1/15/92
to

In article <1992Jan15....@softwords.bc.ca>, rsl...@cue.bc.ca (Rob Slade) writes...

>
>The case of "network" printers, is somewhat more complex. Two cases have been
>suggested today: VMS and Mac: and they are quite distinct. The print server
>mentioned on DECnet is actually a networked computer acting as a print server;
>accepting files from other network sources and spooling them to a printer.
>True, this computer/printer combo is often referred to simply as a printer,
>but it would not, in any case, be able to submit programs to other hosts on
>the net.

BZZZT, false. What you've got there is a fully functional VAX cpu running
VAXeln realtime software. There is nothing stopping a clever programmer
from modifying the ROM to add routines to make it spoof a "real" vax.
Wouldn't be easy but it's possible.

It's also false to assume that it is necessary to submit programs to hosts
on the net to produce the described behavior, as ethernet is a broadcast
medium simply injecting additional packets at strategic points would be
enough.

Bill Mitchell

unread,
Jan 15, 1992, 6:21:25 PM1/15/92
to
>>>
>>> Fortunately, this cannot happen on a PC. The PC's printer
>>> port is unidirectional, and no code or data are read from
>>> the printer!
>
>>One of my colleagues has just got through telling me that the IBM pc printer
>>port has 4 input bits, and some people tend to use them + 4 output bits as a
>>bidirectional link. Possible applications are for disc drives, ethernet
>>interfaces.
>*----
>A standard PC serial port is bidirectional. In addition, there are
>handshaking lines that COULD be used for input; but it's not
>necessary. A properly-implemented parallel printer port on a
>PC is 8-bit bidirectional. NEC even makes a SCSI adapter for
>a PC type parallel printer port.

I meant to check this when I got home tonite, but the following posting
in alt.folklore.computers beat me to it:

> Repeat after me : The IBM Printer port is _NOT_ Bidirectional.
> I have read the techref, looked at the boards, and :
> the data lines are driven by a 74LS374. The OE signal is grounded. There
> is no way to disable driving those lines. There is a way of reading back
> the status of the pins, which is used by iBM diiagnositics. The strobe
> line is controlled by a separate latch which also controls interupt
> enable. A hack was to use the unused bit 5 or that latch to control OE of
> the 74LS374. That would give bidirectionality. It was a hack though. NOT
> standard.
> There were also 5 inputs from the printer. They could be used as data
> inputs, which is how laplink etc does it. But, the BIOS doesn't support
> such use which means that a virus would require a program on the PC as
> well.
> What annoys me is that the 8211 parrallel port chip has an OE pin, but no
> way of controlling it without a lot of extra logic. Pity :-)
> (BTW, I accept that a printer virus could spread on an RS232 printer
> (assuming the software on the PC accepts dat from the printer (unlikely)),
> or on a networked (ethernet) printer. But not on a centronics port.)
> Tony 'PDP11 Hacker' Duell
> a...@siva.bris.ac.uk
>
>
--
mitc...@mdd.comm.mot.com (Bill Mitchell)

Stuart Lynne

unread,
Jan 15, 1992, 9:30:41 PM1/15/92
to
In article <1992Jan15.0...@NeoSoft.com> la...@NeoSoft.com (Larry Kessler) writes:
>> My memory tells me that bidirectional printer ports was introduced with the AT in
>> 1984. If my memory is coerrect, PC and PC/XT printer ports were unidirectional.
>
>Nope. True clones, even lowly 8088-based ones, have bidirectional
>parallel ports. If it were not true, how would Laplink work? (Laplink is

By using the four(?) control bits present. Even though the data bits are
uni-directional there are enough control bits that are bi-directional
to transfer a nibble at a time.

--
Stuart Lynne Computer Signal Corporation, Canada
...!van-bc!sl 604-937-7785 604-937-7718(fax) s...@wimsey.bc.ca

Robert Garito

unread,
Jan 15, 1992, 11:24:48 PM1/15/92
to
Damn - it's amazing how everyone here sees it as a PC printer.... Hmmmm...
WHY are all computers in this world PC's? It was quoted as being a NETWORK
printer - probably being something like 3270 or ethernet (such beasts DO
exist - I've used them). The mainframe world is quite different than that
of mini's. And, furthermore, SOME PC printer ports are biderectional.
The original PC port is not (as IBM designed it), but most of the new ones
are. Anyone ever seen a 'dongle' type copy-protection device? Well, they
attach to the port and the programmer can store information in them
eg: code, serial #'s, etc and read it later. I've used them befor (programmed
with them) and they work on MOST existing printer ports (some ARE unidirectional
). BUT, code must exist to force the computer to execute the information
received from the port. This is not standard in a PC. But, on a network,
packets can even be substituted with pieces ov virus code that WILL be
executed by computers (in addition to the jabber method that I mentioned
before). Provided that the processor in the printer that controls
communications is the one with the virus...

Javier Perez

unread,
Jan 16, 1992, 1:55:57 AM1/16/92
to
In article <cq6keB...@arkham.wimsey.bc.ca> jag...@arkham.wimsey.bc.ca (Jeremy Reimer) writes:
>cgk1...@uxa.cso.uiuc.edu (C G Kolar) writes:
>
>> thanks for bringing the discussion back to the story. on Nightline it was
>> reported that the virus was put into a printer that was to be installed
>> in the network controlling baghdad's air defences. i don't recall any
>> mention of PCs. supposedly the virus left the printer and, at just the

Please somebody correct me if I am wrong but I fail to see how you can
"spread" a virus from a printer. For all I know, a printer doesn't access,
nor should it, the processor's main memory. Also, the printer cannot make
accesses to the computer's main storage (disks, etc), so how can you
spread the virus through the network from a printer? A printer is
a "passive" device, in the same sense a computer monitor is. It receives data
and puts it on a form that us humans can understand. It only replies if it
could do it or not sending an appropriate acknowledgement.

Hank Nussbacher

unread,
Jan 16, 1992, 1:31:46 AM1/16/92
to
In article <1992Jan14.1...@ux1.cso.uiuc.edu>, tm...@uiuc.edu (K. Khan)
says:

>Don't think this is impossible: in "Out of the Inner Circle," dark side
>hacker Bill Landreth tells of the time he and his buddies discovered a
>story submission system for a major newspaper. They could have easily
>submitted a story and, if it wasn't obviously bogus, it could very well
>have been printed. Perhaps someone submitted the AF/91 virus story from
>InfoWorld (with minor modifications) to UPI or some other news service
>and it was passed on without being checked out?
>
>Things that make ya go "Hmm......" ;-) ;-)
>

About 5 years ago an Israeli hacker did exactly that to an Israeli
daily. He planted a front page article (circulation about 600,000)
about a high-school teacher who was caught in NYC trying to smuggle
videos into Israel containing cocaine. Needless to say, the teacher
was his teacher and he did it to get back at him. He typed up the
article in Israel, downloaded to a system in the USA, where he had
broken into an account of a reporter who was working on assignment
for the paper. The article looked like it came from the reporter
(it was typed in Hebrew) and the editor assumed it to be true without
double checking. They retracted the story the next day and the
high school kis was caught and tried and given "public" work to do
as punishment.

Hank Nussbacher
Israel

Madis Kaal

unread,
Jan 15, 1992, 12:52:24 PM1/15/92
to

> - A PC's printer port is NOT unidirectional. It is bidirectional.
> That's one
> -of the reasons programs like lap-link can work using the parallel
> port to
> -transfer files between two PC's.

> As for laplink, they may send the data 5 bits at a time, overdrive
> three of the
> OD/pullup bits, or do things serially; I'm not sure which.

LapLink, FastWire, Lantasic's PPORT and other programs use the 5 status
bits for incoming data, lower 5 data output bits are cross connected to
other sides status bits. This allows to transfer 4 bits at the time, while
the remaining bit is used for handshake.

PS/2 systems have their port specification changed, so that the parallel
port can be either like old PC port or 'enhanced'. In enhanced mode,
printer control register bit 5 will disable the output drivers and you can
read the 8-bit data bus freely. Theoretically it's possible detect the port
mode by software by the following code sequence ( I don't have any bi-
directional ports, so i'll be happy if anyone will test this and let me
know) assuming that there is nothing connected to printer port:

mov dx,PORTBASE ;port base address
mov al,0 ;pull all bits low
out dx,al ;in data port
add dx,2
in al,dx ;read control port
mov ah,al ;keep it
or al,20h ;set output drive disable bit
out dx,al ;try to disable output drive
sub dx,2
in al,dx ;TTL inputs should go high after that
xchg al,ah ;transfer the old status back to al
add dx,2
out dx,al ;restore control bits
or ah,ah ;test result
jz unidir ;if we got all zeroes, output drive didn't went
;off...

There is a possibility to use data pins of the normal PC/AT port for input,
but it's brute force approach. The trick is that the original printer port
was designed so, that the 8-bit latch was used for data register, output
of which could be read back using 8-bit buffer. TTL chips have more
strength to pull their outputs low than to hold them high, so you can
use your data output as input port if you first set all bits high in the
latch and then pull the needed bits low externally. It's called 'wired
OR' sometimes. However, this approach involves a small risk that your
printer port is based on ASIC chip which cannot tolerate it.

--

John Stracke

unread,
Jan 16, 1992, 9:29:26 AM1/16/92
to

In article <LARRY.92J...@rock.psl.nmsu> la...@rock.psl.nmsu (Evil Engineer doin' it the Cowboy Way) writes:

> I have never heard that any code is downloaded from printer to PC.
> That system is not used, but is not impossible with new hardware,
> though DOS does dos support such feature.

>The only thing that makes sense for introducing a virus is a printer (or
>other device) with a network interface. Such a device could easily be
>altered to monitor and transmit data to introduce all sorts of things into
>the system. All the required resources a probably in place, just add a
>control program in the PROM..

\begin{speculation}

PROM, nothing. If it's a programmable printer (e.g., PS), its
language may have primitives for network transmission.

Anybody know if PS or any of the other printer languages includes such
things? (Maybe not PS as specified by Adobe; maybe some company's
implementation.) This could be scary: somebody could post a PS file
with a virus in it; most people don't have all that much security on
their printers, and many printers are actually on the Internet. You
could have a virus spreading from site to site, using the printers as
intermediate hosts. Sort of like malaria. :-)

\end{speculation}

Anybody know if this is reasonable, or am I just pegging bogometers?

/===========================================================================\
|John (Francis) Stracke |My opinions are my own. | No matter how |
|Natl. Science Center Foundation|========================/ subtle the |
|Augusta, GA |wizard, a knife between the shoulderblades |
|fra...@dogwood.atl.ga.us | will seriously cramp his style. |
\===========================================================================/
(Formerly fra...@zaphod.uchicago.edu)

David Brooks

unread,
Jan 16, 1992, 12:17:53 PM1/16/92
to
rsl...@cue.bc.ca (Rob Slade) writes:
|> ...the "information" which comes back

|> over the line is concerned strictly with whether or not the printer is ready
|> to accept more data. It is never accepted as a program by the "host".

Be careful with this assertion. It's exactly how the Internet Worm abused
fingerd (by sending more data than expected, and running off the buffer and
onto the execution stack). Of course, we are postulating a knowable bug in
the host software here; I'm not implying this could have been the cause of
the Iraqi attack.
--
David Brooks dbr...@osf.org
Systems Engineering, OSF uunet!osf.org!dbrooks
Destroy the environment and public health systems: vote Libertarian in 1992.

Stuart Lynne

unread,
Jan 16, 1992, 5:25:25 PM1/16/92
to
In article <1992Jan15.2...@ux1.cso.uiuc.edu> berger@iboga (Mike Berger) writes:

>j...@dstos3.dsto.oz.au writes:
>
>A standard PC serial port is bidirectional. In addition, there are
>handshaking lines that COULD be used for input; but it's not
>necessary. A properly-implemented parallel printer port on a
>PC is 8-bit bidirectional. NEC even makes a SCSI adapter for
>a PC type parallel printer port.

A standard PC parallel port is NOT bi-directional because it
was not properly implemented. A properly implemented version
is bi-directional and even compatible, but is then no longer
a standard PC port - which by the original definition is not
bi-directional.

Mark Saum

unread,
Jan 16, 1992, 5:19:56 PM1/16/92
to
In another news group I read that the computer network the Iraqi Air Defenses
used were Unix based. They were hooked up over a dynamically configuring
ethernet configuration. One that would automatically know how to route
packets if a node was mysteriously downed (the subject in the other
newsgroup.)
If that were so, then we'd need to deal with it in relation to Unix rather
than IBM/3270 or Vax machines. In this case, the possibilites become more
unlikely if the printer were standard. If if were a network printer, it
could possibly do all sorts of nasty things as was previously stated.

Mark

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mark Saum | Texas A&M University
Senior BANA/MIS Major | College Station, Texas
mss...@tamsun.tamu.edu | Programmer, Department of Physics
Sysop: Aggieland BBS (409) 775-3018 | (409) 845-7017

Alton Harkcom

unread,
Jan 16, 1992, 5:52:06 PM1/16/92
to
In article <1992Jan16.0...@wimsey.bc.ca> s...@wimsey.bc.ca
(Stuart Lynne) writes:

=}In article <1992Jan15.0...@NeoSoft.com> la...@NeoSoft.com (Larry Kessler) writes:
=}>> My memory tells me that bidirectional printer ports was introduced with the AT in
=}>> 1984. If my memory is coerrect, PC and PC/XT printer ports were unidirectional.
=}>
=}>Nope. True clones, even lowly 8088-based ones, have bidirectional
=}>parallel ports. If it were not true, how would Laplink work? (Laplink is
=}
=}By using the four(?) control bits present. Even though the data bits are
=}uni-directional there are enough control bits that are bi-directional
=}to transfer a nibble at a time.

But even if the port allows for 2 way, I doubt that a device driver for
a printer would read/use the signal from the printer. Even for post script
printers, the only thing done with returning information is that it is
displayed as an error if it is in the proper format...

Is there any way for the port to 'take control' of the CPU?

Al

j...@cmkrnl.com

unread,
Jan 16, 1992, 10:13:56 AM1/16/92
to
In article <1992Jan15.2...@engage.pko.dec.com>,

so...@trooa.enet.dec.com (Norman Soley) writes:
> In article <1992Jan15....@softwords.bc.ca>, rsl...@cue.bc.ca (Rob Slade) writes...
>>
>>The case of "network" printers, is somewhat more complex. Two cases have been
>>suggested today: VMS and Mac: and they are quite distinct. The print server
>>mentioned on DECnet is actually a networked computer acting as a print server;
>>accepting files from other network sources and spooling them to a printer.
>>True, this computer/printer combo is often referred to simply as a printer,
>>but it would not, in any case, be able to submit programs to other hosts on
>>the net.
>
> BZZZT, false. What you've got there is a fully functional VAX cpu running
> VAXeln realtime software. There is nothing stopping a clever programmer
> from modifying the ROM to add routines to make it spoof a "real" vax.
> Wouldn't be easy but it's possible.

I'd say "extremely difficult". Hmm, the printer is on the Ethernet. I suppose
the printer could start speaking LAT or CTERM and so log on to a VAX. Assuming
the printer already knew a username and password for a privileged account... Or
it could start some DECnet file copies... assuming the printer knew what node
addresses to try, and (if default access to the FAL object is disabled)
usernames and passwords again... but without prior knowledge of something about
the hosts in question, and without "accomplice" code running on the hosts, it'd
be damned difficult. The fact that printer control programs ("print symbionts"
in VMS) may read responses from the printer does not mean that they are ready
to accept programs from the printer and create processes to run them in.

> It's also false to assume that it is necessary to submit programs to hosts
> on the net to produce the described behavior, as ethernet is a broadcast
> medium simply injecting additional packets at strategic points would be
> enough.

Well, perhaps. If the printer's software had access to its Ethernet controller
at a very low level, it could deliberately cause packet corruption. However,
"inserting additional packets" would be a real trick, since once a logical link
(session) is established between two network nodes, upper-level protocols tend
to sequence-number their packets (or bytes). But injecting additional packets
into a given session could cause lots of confusion at the session layer,
perhaps enough to disrupt the session entirely. Creating new sessions would
be harder, again requiring that username/password pairs be known or probed for,
or that default or proxy accesses be enabled on the target nodes.

I can also think of a way that a suitably "prepared" printer, even one on a
parallel port with no absolutely NO "data in" capability, could be used
to *trigger* virii that are already resident in the host.

However, wrt evaluating news reports of CIA/NSA activity:

1. We don't know everything, and

2. They're not telling us everything.

--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet: j...@cmkrnl.com, hanr...@eisner.decus.org, or j...@crash.cts.com
Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh

Mika R Iisakkila

unread,
Jan 15, 1992, 4:39:36 PM1/15/92
to
la...@NeoSoft.com (Larry Kessler) writes:

>Nope. True clones, even lowly 8088-based ones, have bidirectional
>parallel ports. If it were not true, how would Laplink work?

Laplink uses the handshake and status lines to transfer four bits at a
time. These lines can be configured to work either way by software.
The real data bits can be either written or read, but reading them
only returns the bits that were last written (bits from the output
latch - this is used by the BIOS to determine if the port is present and
working during boot state). The port hardware can be made
bidirectional with a single cut and a jumper wire, but, originally,
they are write only.

This is the way the original PC/AT printer port and most clones work.
Most portables have unidirectional ports, because they are implemented
with custom chips and not with separate LS-TTL logic. PS/2 has
bidirectional printer ports from the start.

Follow-ups go to alt.folklore.computers, because folklore is all the
printer port -induced PC-virii will ever be.

- Mika

greg dyess

unread,
Jan 17, 1992, 10:08:34 AM1/17/92
to
I'm not commenting on whether this did happen or not, I have no information.
I would like to point out that not having the username/password ahead of
time is not a major obstacle (sp). Since the LPSx0 s indeed a microVAX II,
it could simply run some network monitoring software until it picked up
enough login sequences to obtain the necessary passwords.

This should not be very difficult to do, since the LPSx0's are fully-functional
microVAXen. (I know that for a fact, playing around one time, we actually
booted an LPS40 as a full member of our cluster running VMS. This was
rather painful, since it had only 2 MB and no local page/swap disk.)


Madis Kaal

unread,
Jan 17, 1992, 8:38:42 AM1/17/92
to

> at a PC. Since we're dealing with mainly Soviet supplied technology
> this
> suggests a cloned VAX (there are other possibilites but a cloned VAX
> is the
> most likely). Now if the printer in question was a DEC PrinterServer,

Excuse me, but Soviet industry wasn't (read "isn,t") able to produce VAX
clone as much as I know. They have clones of PDP-11 series and IBM 370
mainframe line, yes, but no VAX. We have couple of PDP clones here, and
boy, are they royal pain in the a** - failure to failure time is worse than
it was on Eniac. The newer models are a bit better, but there's a lot of
imported technology involved - for example Seagates HDs, hard disk
controllers etc.

Now that Poland, Hungary and other 'friendly' countries aren't so friendly
any more, I seriosly doubt that they can produce _anything_ on their own.

--

Peter da Silva

unread,
Jan 17, 1992, 9:41:49 PM1/17/92
to
In article <1992Jan16....@cmkrnl.com> j...@cmkrnl.com writes:
>However,
>"inserting additional packets" would be a real trick, since once a logical link
>(session) is established between two network nodes, upper-level protocols tend
>to sequence-number their packets (or bytes).

You could probably selectively zap packets and piggyback stuff on the
retransmissions, but the timing is a little tricky. :->
--
-- Peter da Silva. Taronga Park BBS. +1 713 568 0480|1032 2400/n/8/1.
-- `-_-' "Have you hugged your wolf today?"
-- 'U`

Brett G Person

unread,
Jan 18, 1992, 5:22:06 PM1/18/92
to
Huh??? Sounds like a lot of crap to me... The virus would have to go
across different types of hadrdware and would need to deal with
completely different types of software. I.e. radar screens and their
sub-systems are a far cry from the associated parts of printers..


--
Brett G. Person
North Dakota State University
uunet!plains!person | per...@plains.bitnet | per...@plains.nodak.edu

Michael Moscovitch

unread,
Jan 18, 1992, 8:47:21 PM1/18/92
to
In article <kn7gu...@agate.berkeley.edu> shir...@sprite.berkeley.edu (Ken Shirriff) writes:
>One thing that seems to be getting lost in this discussion is that the
>Iraqi air defense systems most likely don't use networked IBM PCs with
>PostScript printers. Thus, much of this speculation is irrelevant.
>...

I don't know much about their air defence system, but I have seen news
programs that showed that they did have some workstation level computers.
These machines (looked like HP) were obtained for the purpose of designing
farm machinery. I do not know where they actually ended up.

--
<Mike>
mich...@pike.ee.mcgill.ca

Scott Coleman

unread,
Jan 19, 1992, 10:46:20 AM1/19/92
to
th...@vipunen.hut.fi (Tomi H Engdahl) writes:

>The only signal the port can send to CPU (without CPU asking it) is
>the interrupt request (IRQ) signal.

On the subject of getting the printer port to generate an interrupt request,
just how exactly is this done? I have a piece of external hardware that I
would like to interrupt the PC when it has data ready to be sent.

I know there is a bit in one of the printer port registers which is set to
enable IRQ generation. Is this all I need to do, or must I also monkey with
the interupt controller's masks? Once everything is enabled, what sort of
signal will trigger the interrupt? A positive going transition, a negative
going pulse of X uS duration? All the books I have mention that it is
possible to generate an interrupt, but none mention specifically how.

All pointers and info will be greatly appreciated.

--
Scott Coleman tm...@uiuc.edu

Free Advice: It is inadvisable to read Bush's lips at an official banquet.

Mejia Pablo

unread,
Jan 19, 1992, 7:24:26 PM1/19/92
to
In article <1992Jan19....@thunder.mcrcim.mcgill.edu> mich...@pike.ee.mcgill.ca (Michael Moscovitch) writes:
In article <kn7gu...@agate.berkeley.edu> shir...@sprite.berkeley.edu (Ken Shirriff) writes:
>One thing that seems to be getting lost in this discussion is that the
>Iraqi air defense systems most likely don't use networked IBM PCs with
>PostScript printers. Thus, much of this speculation is irrelevant.
>...

I think one thing that has gotten really lost in this whole silly thread
is the fact that a time-on-target strike by Air Force Special Operations
helicopters, Air Force F117A Stealth Fighters and Navy Tomahawk Cruise
Missiles took out the major portion of Iraqi radar within one minutes
of mission time. The AA guns over Baghdad (?) were old Russian
WWII surplus, hand-cranked flack guns. The radar controlled portion
of their defenses were the SAM's, not the guns.

--
*** Theory is when we know everything but nothing goes right. ***
*** Practice is when everything goes right but nobody knows why. ***
*** Here, we have an harmonious mix between theory and practice: ***
*** nothing goes right and nobody knows why. ***

Tomi H Engdahl

unread,
Jan 19, 1992, 4:56:01 PM1/19/92
to
In article <1992Jan19....@ux1.cso.uiuc.edu> kh...@mrcnext.cso.uiuc.edu (Scott Coleman) writes:

> I know there is a bit in one of the printer port registers which is set to
> enable IRQ generation. Is this all I need to do, or must I also monkey with
> the interupt controller's masks? Once everything is enabled, what sort of
> signal will trigger the interrupt? A positive going transition, a negative
> going pulse of X uS duration? All the books I have mention that it is
> possible to generate an interrupt, but none mention specifically how.

The interrupt in genrated with negative going ACK pulse. When the
interrupts are enabled the ACK input is connected to corresponding
IRQ line through inverting buffer. So when ACK=0 then the interrupt
request is active. I think that 1 microsecond pulse is enough, because
interrupt controller in PC is triggered by positive going IRQ edge.

--

Tomi.E...@hut.fi
th...@vipunen.hut.fi

Charles Hannum

unread,
Jan 20, 1992, 8:35:44 AM1/20/92
to

In article <FRANCIS.92...@Galois.dogwood.atl.ga.us>

francis@francis@dogwood.atl.ga.us (John Stracke) writes:
>
> PROM, nothing. If it's a programmable printer (e.g., PS), its
> language may have primitives for network transmission.
>
> [,,,]

>
> Anybody know if this is reasonable, or am I just pegging bogometers?

Why the hell would any printer language have primitives to talk over
the network?

Tauren N Mills

unread,
Jan 20, 1992, 4:37:06 PM1/20/92
to

I've been following the discussion on SVGA cards recently. Now that I am
ready to buy and think I know the features that I need, maybe the rest of
you in net.land could help me out.

***What I need:
SVGA card that does 1024x768x256, 800x600x32K, 640x480x32K (all Non-interlaced)
Good Windows 3.0 drivers (or hardware acceleration/coprocessor)
Not TOO expensive, but still fast. I'm willing to pay more for more speed,
features, etc.
VESA compatible (72Hz)
1MB RAM

***What I wouldn't mind having:
Built in Genlock/overlay
NTSC output
24-bit color

***So what cards would you recommend?
Should I go with a S3 or a TSENG4000, or a ???
Any thoughts on the:
Diamond Stealth VRAM
Diamond Speedstar 24
Diamond Speedstar Hicolor
Orchid 1280
Orchid Prodesigner II ?
ATI ?
Boca ?
Ultra Hicolor--(have you heard of this:
$145 or so
1280x1024x16 Interlaced
1024x768x256 N-I
800x600x32K
etc
TSENG 4000 chip set
1 MB memory
Sierra RAMDAC
Drivers
Lifetime warrenty
Good review in PC Mag???- haven't seen review.
TARGA boards ?

I've heard rumor of new cards that include Genlock/overlay capabilities. I
would definately be interested in this.

Can anyone direct me to some good reviews?

Thanks for the help. I can post a summary if there's a demand.

Tauren

P.S. By the way, is there anything or combination of things (hardware/software)for the PC that resembles the Amiga's Video Toaster? Is it outrageously
expensive? Thanks

Tauren Mills
tau...@rigel.cs.pdx.edu

Eric Lindsay

unread,
Jan 21, 1992, 11:16:13 AM1/21/92
to
If the only information on this `virus attack through printer chip' is from
a news magazine report, perhaps the term `virus' is being used badly. That
would not be unknown in news reports.

You could probably cause minor problems by setting the printer to respond
to characters sent it rather more slowly than average (just before the
acknowledge period times out, say). Or if a serial line, maybe blast the
port so that interrupts are forced at a 30kHz rate. Does anyone actually
have any solid information about what was really done?

--
er...@zen.maths.uts.edu.au Eric Lindsay, Sch of Maths, Uni of Tech
Don't take life too seriously.
It is only temporary.

Mike Fox

unread,
Jan 20, 1992, 6:49:53 PM1/20/92
to

I've been pretty impressed by the Diamond Stealth Hi-Color. This is an S3
card which is supposed to be second only to the ATI Ultra in Windows speed
(according to the 'review' in the latest Computer Shopper). It offers all
the resolutions which you ask for, in fact it even does 1024x768x32K
non-interlaced (70 MHz) and 1280x1024x32K interlaced (42MHz?). Apparently,
new drivers are being written for the card which should make it even faster
Windows operations. I've seen this card for $269 in Computer Shopper
(although I'm a bit skeptical as this sounds _too_ good -- I saw it for $350
on another page so the $269 _might_ be wrong). This is much cheaper than the
ATI Ultra ($819 suggested, maybe $650? street). The ATI Ultra supports
1280x1024 non-interlaced but with fewer (256) colors at all resolutions. I
only plan to get a display capable of 1024x768 anyway (the NEC 4FG) since I
don't want to pay the extra premium (pretty close to $1000) to go to
1280x1024 with least 32K colors and non-interlaced. The Stealth looks like
the best bet to meet these requirements. I figure I might go to 1280x1024
true (24-bit) color in the future but at current prices, this would cost me
$2000 more than what 1024x768x32K is going to cost me.

Hope this helps,

-mike

George Pell

unread,
Jan 20, 1992, 8:49:07 PM1/20/92
to
I have an STB Ergo- VGA card 1024 X 768 X 256 colors, which uses the Tseng
4000 chip set. One word of warning, the BIOS Int 10 calls are hosed up
in the 1024 X 768 mode. You cannot access any lines greater than 511
without writing your own driver. I got a Beta site upgrade to the BIOS,
but it has the same problem.


geo

Max Rochlin

unread,
Jan 20, 1992, 7:53:27 PM1/20/92
to
In article <44...@pdxgate.UUCP> tau...@rigel.cs.pdx.edu (Tauren N Mills) writes:
>
>I've been following the discussion on SVGA cards recently. Now that I am
>ready to buy and think I know the features that I need, maybe the rest of
>you in net.land could help me out.

Forget SVGA in alt.folklore.computers. Buy a DEC gigi system and write an
emulator that offers Word for Windows users an upgrade path for their TECO
macros.

(
roughly translated this means your request doens't belong in
alt.folklore.computers, please be more careful in newsgroup
selection or you'll be asked to port MUSIC from IBM-VM to
DEC-VMS ;-]
)

--

+------------------------------------------------------------------------+
| m...@gupta.com | Max J. Rochlin | m...@queernet.org |
+------------------------+------------------------+----------------------+

Michael L. Kaufman

unread,
Jan 20, 1992, 11:41:34 PM1/20/92
to
In <1992Jan20.2...@cs.cmu.edu> md...@cs.cmu.edu (Mike Fox) writes:
>I've been pretty impressed by the Diamond Stealth Hi-Color. ... it even does
>1024x768x32K non-interlaced (70 MHz) and 1280x1024x32K interlaced (42MHz?).

Considering that this would take 1.5 meg and the card only has 1 meg on it,
I am a bit skeptical. Maybe they use compression techniques. ;-) I did see
a very positive review of this card, but they didn't mention this.

I have an Orchid Prodesigner IIs, and I am very happy with it.

Michael


--
Michael Kaufman | I've seen things you people wouldn't believe. Attack ships on
kaufman | fire off the shoulder of Orion. I watched C-beams glitter in
@eecs.nwu.edu | the dark near the Tannhauser gate. All those moments will be
| lost in time - like tears in rain. Time to die. Roy Batty

|S| Norbert Juffa

unread,
Jan 21, 1992, 4:22:28 AM1/21/92
to
In <44...@pdxgate.UUCP> tau...@rigel.cs.pdx.edu writes:

>
> I've been following the discussion on SVGA cards recently. Now that I am

> ***So what cards would you recommend?


> Should I go with a S3 or a TSENG4000, or a ???
> Any thoughts on the:

> Diamond Speedstar Hicolor

Bought one of these in November '91. Very good price / performance ratio for
the hardware BUT the drivers for Windows are too buggy. Diamond has special
"Turbo" drivers for Windows that use some kind of software accelerator (don't
ask me how it works) from BINAR ..... (I forgot) company. They are the
fastest Windows drivers I have seen for an ET4000 chip. However, the HiColor
drivers doesn't work correctly in REAL mode. Splatters the text of your icons
and dialog boxes all over the screen, so that you can barely operate the
SWAPFILE program. The drivers with 256 colors as well as the HiColor drivers
have problems with BitBlt operation as you can easily notice by moving some
windows around on the desktop. The 256 color drivers randomly writes
pixels inside the window, so when you move it around often enough you can
barely recognize the contents. The HiColor drivers sometimes leave complete
screen lines behind if you moce a window horizontally. I got myself the
newest version Tseng's original drivers (including HiColor) now and they
work well, but they are a bit slower than Diamond's drivers. BTW, the
drivers diskette of my Diamond Speedstar says it's version 5.4 of the
software.

> Tauren Mills
> tau...@rigel.cs.pdx.edu

Norbert Juffa

-------------------------------------------------------------------------------
Norbert Juffa email: S_J...@IRAVCL.IRA.UKA.DE Live and let live!

Kevin Martin

unread,
Jan 21, 1992, 12:30:04 PM1/21/92
to
kau...@eecs.nwu.edu (Michael L. Kaufman) writes:
>In <1992Jan20.2...@cs.cmu.edu> md...@cs.cmu.edu (Mike Fox) writes:
>>I've been pretty impressed by the Diamond Stealth Hi-Color. ... it even does
>>1024x768x32K non-interlaced (70 MHz) and 1280x1024x32K interlaced (42MHz?).
>Considering that this would take 1.5 meg and the card only has 1 meg on it,
>I am a bit skeptical. Maybe they use compression techniques. ;-) I did see
>a very positive review of this card, but they didn't mention this.

Considering you'd have to push 2048 or 2560 bytes per scanline through the
RAMDAC, and those things barely work at 800x600 on some boards, I'm very
skeptical. There are bandwidth limits. I don't claim to understand them,
but I think they pretty much rule out 1280x1024x32K on a SVGA card.

--
Kevin Martin
si...@ipl.rpi.edu
BIFF, we miss you.

Mike Fox

unread,
Jan 21, 1992, 12:00:20 PM1/21/92
to
In article <1992Jan21....@eecs.nwu.edu> kau...@eecs.nwu.edu (Michael L. Kaufman) writes:
>In <1992Jan20.2...@cs.cmu.edu> md...@cs.cmu.edu (Mike Fox) writes:
>>I've been pretty impressed by the Diamond Stealth Hi-Color. ... it even does
>>1024x768x32K non-interlaced (70 MHz) and 1280x1024x32K interlaced (42MHz?).
>
>Considering that this would take 1.5 meg and the card only has 1 meg on it,
>I am a bit skeptical. Maybe they use compression techniques. ;-) I did see
>a very positive review of this card, but they didn't mention this.
>
>I have an Orchid Prodesigner IIs, and I am very happy with it.
>
>Michael


Hopefully, this will clear the above up. Sorry for any confusion but the
article which I read did not give many details.

1)
Yes, I was considering the Ultra too before I saw the Stealth. The Stealth
uses an S3 co-processed board and was the fastest of the S3 boards which
were tested by Computer Shopper in the latest issue. It is supposed to be
slower than the Ultra by a factor of only about 30%. If you get the Stealth
(Hi-Color) with the RAMDAC chip you get 15/16 bit 'deep' color in the
800x600 mode (sorry I thought this was at all modes yesterday). So you
basically get 1024x728x256 non-interlaced, 1280x1024x256 interlaced, and
800x600x32768 (don't know if this would be non-interlaced). These features
are pretty standard for the S3 boards but diamond is one of the few
companies using S3 technology that is custom-writing drivers for its board
which should make it even faster when these are available. I believe it does
all this with 1M VRAM + the RAMDAC. Another note about the Ultra, I
understand that in VGA mode (640x400x16), the Ultra's performance drops down
to that of any non-accelerated VGA board because in this mode, it
essentially by-passes the MACH-8 chip (not a big deal if you don't have
drivers for any software that has to use VGA mode anyway). Of course the
Ultra does come with a mouse and its anti-aliasing technology which lets you
read very small fonts but at $700 or so for the Ultra and about $350 for the
Stealth, is it worth it? I don't know about other drivers for the Stealth
but I would suggest giving them a call if you want to be sure.

2)
Hi Don, I found the review in Byte Jan. 92 last night. As you noted, they
did not review the Diamond Stealth. Then I reread this month's Computer
Shopper review which compared the Stealth, Ultra and the STB Wind/X. They
found the Stealth to be by far the fastest of the S3 boards and they found
the STB card to be near the bottom of the pack (but liked its mouse
support). The Stealth was only a bit slower (33%) than the Ultra, which they
attributed to the fact that Diamond was one of the few companies using S3
technology that wrote its own drivers. New Windows drivers are due which
should make Windows operations even faster. I am a bit confused because the
Byte review showed the S3 cards to be darn close to the Ultra so I don't see
how the Stealth could be "much faster than the STB" and yet "only about 33%
slower than the Ultra". The byte chart did not seem to leave that much room
in between the S3 and Ultra performances. However, I buy the fact that all
the S3 boards are about the same and that Diamond's custom drivers could
give them the edge. Unless the Computer Shopper people are totally
incompetent, they found the Stealth to be much faster.

I cleared up another thing last night as well (took me until 2am though).
All the S3 cards seem to support the same resolutions (1280x1024x256,
1280x960x256, 1024x728x256 and VGA) although I'm not positive the 1280x1024
mode is available (don't care since my monitor will only go up to 1024x728
anyway). The 1280 mode(s) are interlaced with a 45MHz or so refresh rate and
the others have a healthy 70 MHz non-interlaced rate. The S3 boards can use
the Sierra RAMDAC chip to give a 800x600x32768 mode (not sure if this would
be interlaced). This is known as 'deep' color and in many cases will look as
good as true 24-bit color. Sierra may come out with a 16 bit chip and
drivers to allow 65535 colors. My wish list would have 16 bits at all
resolutions, but that will have to wait for now. It is a jump of $1000-$2000
to get a board and monitor which will support these at present.

In answer to your question, yes, I do hope to get 53ns memory to support the
upgrade to 50MHz. I also found some systems last night which put the CPU and
crystal on a card which plugs into the motherboard to make the upgrade
easier, and another company has a plug-in crystal on the motherboard so you
can just change this when you change the CPU.

-mike

tra...@bnr.ca

unread,
Jan 21, 1992, 8:22:26 PM1/21/92
to
In article <1992Jan21.1...@cs.cmu.edu>, md...@cs.cmu.edu (Mike Fox) writes:
|> In article <1992Jan21....@eecs.nwu.edu> kau...@eecs.nwu.edu (Michael L. Kaufman) writes:
[Stuff...]

|> are pretty standard for the S3 boards but diamond is one of the few
|> companies using S3 technology that is custom-writing drivers for its board
|> which should make it even faster when these are available. I believe it does
|> all this with 1M VRAM + the RAMDAC. Another note about the Ultra, I
|> understand that in VGA mode (640x400x16), the Ultra's performance drops down
|> to that of any non-accelerated VGA board because in this mode, it
|> essentially by-passes the MACH-8 chip (not a big deal if you don't have
[More stuff...]

One thing to note here is that the S3 chip is simply another accelerator
supporting some 8514/a-type internal functions (e.g., bltbit transfers,
line-draw, etc.). IT IS NOT A REALLY FAST SVGA CARD. In fact, most
reviews I have read, while making it clear that the card(s) fly under
windows, also say that when doing normal (S)VGA mode operations the
card runs almost 10-15% SLOWER than a good fast SVGA card (e.g., Orchid
Prodesigner II). So the only time you'll get real speed is when you're
running a graphics program that has a driver for the S3.

One nice thing about the Ultra/Vantage is, being 8514/a (super)clones,
any graphics program that currently supports the 8514/a standard can
be used quite speedily on these cards (e.g., Windows, most CAD progs,
WP page preview, etc.).

Did you notice that the BYTE accelerated card review only talked
about text scrolling under various window applications? So what?!
I've read a few other reviews that puts the S3 board(s) in a
performance niche somewhere between the Ultra and Vantage, but closer
to the Vantage side.

I'm not downplaying the S3 cards, I think they sound great! I would
have bought one instead of the Vantage I have if they had been
available at the time, but you have to look at all aspects. They
essentially operate with the same principle as other accelerators,
calling upon their speedy built in functions only when a driver
requests it.

The S3 does have a really nice feature set though. Lots of modes, etc.

,------------.-----------------------.---------------------,
| Karl Tracy | e-mail: tra...@bnr.ca | Fax: 1-613-765-4018 |
| Blomquist | ENVOY: T.BLOMQUIST | Ph: 1-613-765-4886 |
`------------'-----------------------'---------------------'

Bailey Brown

unread,
Jan 21, 1992, 7:19:55 PM1/21/92
to
Does anybody know for sure what the maximum size, in megabytes,
you can have on a DOS5 C: drive?

------------
Bailey Brown "Above all else, confusion reigns."
Intergraph Corporation
bbr...@casca.b11.ingr.com Procol Harum

Harry Salvini

unread,
Jan 22, 1992, 9:22:32 AM1/22/92
to
In article <1992Jan22.0...@b11.ingr.com>, bbr...@b11.ingr.com (Bailey Brown) writes:
>
> Does anybody know for sure what the maximum size, in megabytes,
> you can have on a DOS5 C: drive?
>

If I remember correctly, the maximum hard disk size is 1.2 GBytes.

Anyone else?

------------------------------------------------------------------------------
The most awesome and excellent hardware and software procurement dude
If I don't have it, and can't get it, it just doesn't exist
hgs
AND Loral doesn't have anything to do with my opinions. I came up with them
all on my own.

Bruce Clement

unread,
Jan 22, 1992, 5:13:55 PM1/22/92
to
myc...@hal.gnu.ai.mit.edu (Charles Hannum) writes:

>
> In article <FRANCIS.92...@Galois.dogwood.atl.ga.us>
> francis@francis@dogwood.atl.ga.us (John Stracke) writes:
> >
> > PROM, nothing. If it's a programmable printer (e.g., PS), its
> > language may have primitives for network transmission.
> >
> > [,,,]
> >
> > Anybody know if this is reasonable, or am I just pegging bogometers?

Not reasonable, but accurate.

"All PostScript interpreters provide *standard input* and *standard output*
files, which usually represent a real-time communication channel to an from
another computer or user terminal. The standard input and output files
always exist; it is not necessary for a program to create of close them.

"...Also, a PostScript language program may execute the *print* operator
to send arbitrary data to the standard output file. Note that print is a
file operator; it has nothing to do with placing text on a page or causing
pages to emerge from the printer"

Quoted from PostScript(R) Language Reference Manual/2nd edition/
Adobe Systems Incorporated/1990/ISBN 0-210-18127-4. page 72.

This extract is of the nature of a review, or other fair dealing, within
the terms of the Copyright Act 1961. Review: Good book.


>
> Why the hell would any printer language have primitives to talk over
> the network?

Probably to report status back to the user/host computer. Why they are
as powerful as Adobe made their's is an interesting question. It may be
an attempt to avoid obsolesence, or perhaps an early customer requested
it?

J.W.

unread,
Jan 22, 1992, 3:07:13 AM1/22/92
to
In article <1992Jan22.0...@b11.ingr.com> bbr...@b11.ingr.com (Bailey Brown) writes:
>Does anybody know for sure what the maximum size, in megabytes,
>you can have on a DOS5 C: drive?
>

Up to 2 Gigabytes according to the dos 5.0 user's guide (p.xi).


+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Uhura: "There's Klingons of the starboard bow, starboard bow, starboard bow...
Jim."
Spock: "It's life Jim, but not as we know it, not as we know it, not as we
know it...Captain."
Bones: "It's worse than that, he's dead Jim, dead Jim, dead Jim...."
Kirk: "We come in peace, shoot to kill, shoot to kill, shoot to kill...men."
Scotty "Ye canna change the laws a physics, laws a physics, laws a physics...
Cap'n."
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(A deranged Ferengi made me do this.)

Nick Haines

unread,
Jan 22, 1992, 10:29:16 AM1/22/92
to
In article <w62XeB...@alfheim.cavebbs.gen.nz>, fr...@alfheim.cavebbs.gen.nz (Bruce Clement) writes:

|> myc...@hal.gnu.ai.mit.edu (Charles Hannum) writes:
|> >
|> > Why the hell would any printer language have primitives to talk over
|> > the network?
|>
|> Probably to report status back to the user/host computer. Why they are
|> as powerful as Adobe made their's is an interesting question. It may be
|> an attempt to avoid obsolesence, or perhaps an early customer requested
|> it?

Well, it could be because not _all_ PS interpreters run inside printers. In
fact, high-end PS interpreters commonly run on workstation hardware.

Nick Haines ni...@cs.cmu.edu

paul goffin

unread,
Jan 22, 1992, 10:29:05 AM1/22/92
to
In article <1992Jan21.1...@cs.cmu.edu> md...@cs.cmu.edu (Mike Fox) writes:
>I've been pretty impressed by the Diamond Stealth Hi-Color. ... it even does
>1024x768x32K non-interlaced (70 MHz) and 1280x1024x32K interlaced (42MHz?).

Can anyone please give me a phone number where I can contact a supplier
about this card (or even Diamond themselves). A UK number would be nice,
but I hav'n't seen it advertised over here. If not, then a US one would
do (as long as it's not an 800 number, we can't use them here).

>I cleared up another thing last night as well (took me until 2am though).
>All the S3 cards seem to support the same resolutions (1280x1024x256,
>1280x960x256, 1024x728x256 and VGA) although I'm not positive the 1280x1024

>-mike

Does this mean that it won't do CGA, EGA, VGA (640x480) etc.? Do I need
another VGA card for lower resolutions?

Thanks in advance for the info.

Paul.
--
+-------------+-------------------------------------------------------+
+ Paul Goffin + Crosfield Electronics Ltd. U.K. +44 442 230000x3357 +
+ + My opinions are my OWN. - no one would pay for this! +
+-------------+-------------------------------------------------------+

Peter D. Smith

unread,
Jan 22, 1992, 11:13:33 AM1/22/92
to

Don't think of it as "powerful" -- think of it as "obvious." Postscript is
a full programming language (similar to Forth), so any solution will be
general. Also, Postscript can be used to emulate other printers. Since
most printers have a printer-status responce, there has to be some way
to send data back.

As for how a printer could propagate a virus....all it has to do it look
at the Ethernet packets flowing by, looking for ones that says
"login: root", grab the password, then start shipping its own packets,
log in as that root, determine the system type, upload a suitably nasty
program (eg, rm /usr/bin/*), et voila!


Peter D. Smith

Mike Fox

unread,
Jan 22, 1992, 11:30:36 AM1/22/92
to
In article <73...@bnr-rsc.UUCP> tra...@bnr.ca writes:
>
>One thing to note here is that the S3 chip is simply another accelerator
>supporting some 8514/a-type internal functions (e.g., bltbit transfers,
>line-draw, etc.). IT IS NOT A REALLY FAST SVGA CARD. In fact, most
>reviews I have read, while making it clear that the card(s) fly under
>windows, also say that when doing normal (S)VGA mode operations the
>card runs almost 10-15% SLOWER than a good fast SVGA card (e.g., Orchid
>Prodesigner II). So the only time you'll get real speed is when you're
>running a graphics program that has a driver for the S3.
>
>One nice thing about the Ultra/Vantage is, being 8514/a (super)clones,
>any graphics program that currently supports the 8514/a standard can
>be used quite speedily on these cards (e.g., Windows, most CAD progs,
>WP page preview, etc.).
>

i.e. there are currently more drivers written for the Ultra than for most S3
cards. I think another important point is that when you use these cards in
normal VGA mode, or in some mode+software combination without a driver, the
Ultra wins because it does have a fast SVGA card built-in while, as you
mentioned (and I'm willing to buy this), the S3 cards are actually slower
than many fast SVGA cards (like the ATI Wonder). Does this make sense?

-mike

Mike Fox

unread,
Jan 22, 1992, 12:50:23 PM1/22/92
to
In article <12...@suns3.crosfield.co.uk> p...@crosfield.co.uk (paul goffin) writes:
>In article <1992Jan21.1...@cs.cmu.edu> md...@cs.cmu.edu (Mike Fox) writes:
>>I cleared up another thing last night as well (took me until 2am though).
>>All the S3 cards seem to support the same resolutions (1280x1024x256,
>>1280x960x256, 1024x728x256 and VGA) although I'm not positive the 1280x1024
>
>>-mike
>
>Does this mean that it won't do CGA, EGA, VGA (640x480) etc.? Do I need
>another VGA card for lower resolutions?
>

Someone can correct me if I'm wrong (and I'm sure someone will) but I
believe that a card which advertizes that it does VGA should do CGA and EGA
as well since these are supported by the VGA standard? I understood that the
VGA is register level compatible with the EGA and CGA. I hope so anyway
because I have a number of EGA (and even some CGA!) games and other software
which I would want to be able to run on an Ultra or S3 card (some of the
games, e.g. King's Quest IV, support VGA mode, and are in fact even better
on a VGA, but a lot of them will only work in EGA/CGA mode).

Note that if you are planning on doing a lot of VGA mode stuff, a card such
as the ATI Ultra might be a good choice since its VGA mode is pretty fast.
None of the S3 or Mach-8 co-processed cards use the co-processor for
standard VGA mode and the Ultra has an edge because it includes the fast VGA
Wonder for these modes. Some of the S3 cards might be slower than fast
Super-VGA cards in VGA mode. Also, anytime you don't have a driver for the
software which you are using, you will not be taking advantage of the
co-processor and the Ultra again has an edge here because a) there are more
drivers for it currently and b) it is pretty fast even without a driver.

Feel free to shoot down any and all of the above if this is incorrect.

-mike

Economics/Chess/Physics

unread,
Jan 22, 1992, 7:46:03 PM1/22/92
to
My SpeedStar Hi Color works fine, and I like the performance.
I'd be more worried about my monitor.

Scott Evernden

unread,
Jan 22, 1992, 9:35:47 PM1/22/92
to
In article <1992Jan22.1...@cs.cmu.edu> md...@cs.cmu.edu (Mike Fox) writes:
>Note that if you are planning on doing a lot of VGA mode stuff, a card such
>as the ATI Ultra might be a good choice since its VGA mode is pretty fast.
>... it includes the fast VGA

>Wonder for these modes. Some of the S3 cards might be slower than fast

I started with a 1M Diamond SpeedSTAR+ HiColor; when DELL started selling
the ATI Graphics Ultra w/o VGA (named ATI Ultra Accelerator) for under $400
with VGA passthru, I jumped for it. Now I have a 1Meg Mach8 for speed and
1M ET4000 for compatibility (2 slots lost, I will admit; and the HiColor
modes do *not* pass thru). The ET4000 is better supported than the Wonder
XL VGA. Also, remember that the Graphics Ultra VGA section is limited to
512K tops (i.e., 16, not 256, colors in hirez mode)

-scott

Bryce Newall

unread,
Jan 22, 1992, 11:32:16 PM1/22/92
to
bbr...@b11.ingr.com (Bailey Brown) writes:

> Does anybody know for sure what the maximum size, in megabytes,
> you can have on a DOS5 C: drive?
>

Quoting from the DOS 5.0 manual under the FDISK command: "The maximum
partition size is 2 gigabytes". That should hold ya for a while, eh: :)

-- Trekkie

--
Warp 5, engage...No, Mr. Data, more clutch!
%A@%n (%W) %o

Kevin Martin

unread,
Jan 23, 1992, 12:09:48 AM1/23/92
to
tre...@netlink.cts.com (Bryce Newall) writes:
>bbr...@b11.ingr.com (Bailey Brown) writes:
>> Does anybody know for sure what the maximum size, in megabytes,
>> you can have on a DOS5 C: drive?
>Quoting from the DOS 5.0 manual under the FDISK command: "The maximum
>partition size is 2 gigabytes". That should hold ya for a while, eh: :)

Yeah, and the clusters would only be 32,768 bytes each. Mm, tasty.

--
Kevin Martin
si...@ipl.rpi.edu
"So good with children..." "They never proved anything!"

Steven Hayes

unread,
Jan 22, 1992, 10:43:28 PM1/22/92
to
md...@cs.cmu.edu (Mike Fox) writes:

>Note that if you are planning on doing a lot of VGA mode stuff, a card such
>as the ATI Ultra might be a good choice since its VGA mode is pretty fast.
>None of the S3 or Mach-8 co-processed cards use the co-processor for
>standard VGA mode and the Ultra has an edge because it includes the fast VGA
>Wonder for these modes. Some of the S3 cards might be slower than fast
>Super-VGA cards in VGA mode. Also, anytime you don't have a driver for the
>software which you are using, you will not be taking advantage of the
>co-processor and the Ultra again has an edge here because a) there are more
>drivers for it currently and b) it is pretty fast even without a driver.

I really don't think thats its all that important that the co-processor based
cards are slower (than say an ET4000) in the standard VGA modes. The speed of
the cards in these modes is fast enough, no matter what your application is.
Its in Windows that you NOTICE that the graphics is slow. You DON'T notice
the slowness of the card during a game, do you? (Well, I don't ;-)

So I personally don't give a damn that my Wind/X is slower than an ET4000
in VGA modes. Its still fast enough. Its when I run windows that i really
see the benefit on the Wind/X. And thats why I got the card.
--

Steven Hayes | ste...@goanna.cs.rmit.oz.au
Royal Melbourne Institute of Technology (RMIT) | rcs...@minyos.xx.rmit.oz.au



The Master of Symbolic Links

unread,
Jan 23, 1992, 2:46:50 AM1/23/92
to
>slower than the Ultra by a factor of only about 30%. If you get the Stealth
>(Hi-Color) with the RAMDAC chip you get 15/16 bit 'deep' color in the
>800x600 mode (sorry I thought this was at all modes yesterday). So you
>basically get 1024x728x256 non-interlaced, 1280x1024x256 interlaced, and
>800x600x32768 (don't know if this would be non-interlaced). These features

Well, as far I know (and I'm writing drivers for the S3 chipset) does the
86C911 support all standard CGA/HGC/EGA/VGA/SVGA modes along with accelerated
modes (i.e. non-VGA):

640x480x32768 (800x600 may also work, but I never saw it)
1024x768x256
1280x1024x16

Note, that since the 86C911 allows only 1MB to be connected 1280x1024x256 is
pretty much impossible.

And just another thing for benchmarks: The 86C911 uses only a 16bit databus
to the VRAM (instead of a 32bit one like the Ultra; this has also NOTHING to
do with the CPU interface ...). Thus if a 86C911 driver is tested in 16 colors
it is almost as fast as a Ultra. But if you compare them in 256 colors the
performance of the 86C911 drops significantly, since twice as many VRAM
access cycles are necessary.

- Thomas
--
-------------------------------------------------------------------------------
e-mail: ro...@informatik.tu-muenchen.de

In the beginning was the plan, and then the specification;
And the plan was without form, and the specification was void.

Ted B. Drude

unread,
Jan 24, 1992, 11:52:57 AM1/24/92
to
In article <1992Jan21.1...@cs.cmu.edu> md...@cs.cmu.edu (Mike Fox) writes:

[RE: Two recently articles comparing S3 boards in Byte and Computer Shopper]

>Then I reread this month's Computer Shopper review which compared the
>Stealth, Ultra and the STB Wind/X.

I read the same two articles.

>I am a bit confused because the Byte review showed the S3 cards
>to be darn close to the Ultra so I don't see how the Stealth could be
>"much faster than the STB" and yet "only about 33% slower than the
>Ultra". The byte chart did not seem to leave that much room in between

^^^^ ^^^^^


>the S3 and Ultra performances.

...

It sure didn't. And if you noticed, the Computer Shopper article did
not have any benchmark numbers listed. Harvey didn't like the Orchid
Farenheit 1280 either. That was obvious.

>Unless the Computer Shopper people are totally incompetent, they found
the Stealth to be much faster.

...

I wouldn't say they are ALL incompetent (since I used to work there,
and still know a couple of their editors personally). However the author of
that particular article is NOT a regular Computer Shopper staffer, but
a free-lancer who contibutes to the mag. If he had published the hard
benchmark numbers that he vauguely refers to in his article, I think the
actual results might actually have been closer to what Byte reported. I
have done tests on a "generic" S3 board and know that they don't vary by
much.

Moral of the story: "Caveat Reader - Demand Reproducible Benchmarks!"

- Ted Drude (drudetb@ingr) [Former Technical and Associate Editor of
Computer Shopper]

Bailey Brown

unread,
Jan 24, 1992, 1:32:36 PM1/24/92
to
The S3 is a piece of junk. First of all, no S3 based board with only
1 Meg of display memory is going to go above 800x512 in hicolor mode.
This is because, in their infinite lack of wisdom, the S3 people
made the offset from one scanline to the next have to be a power of
two, and in the case of 513x??? or greater, this has to be 1024.
Two bytes per pixel means 800(really 1024)x512x2bytes is max, because
that is 1 megabyte. You can't have an S3 doing 800x600x32K.
There may be a way around this by having the board run in a dumb
frame buffer mode without using the S3 chip with 800x600x32K, but it
will be slow.

Also, you can't have 1280x960x256 with 1 meg of display memory. That would
require 1228800 bytes. A meg is 1048576 bytes. Whoever has been saying
tha the stealth vram 1mb does this mode is wrong. Also, needless to say,
it can't do 1280x1024x256 either. Of course, 1280x1024x16 is doable.

Will somebody make a decent board for less than $500?

640x480x24bit
800x600x16bit All of these can be done with 1MB display memory
1024x768x8bit
1280x960x4bit
1280x1024x4bit

All accelerated.

With 56, 60, 70, and 72 Hz NI modes, and an I mode for the higher
resolutions.

Orville R. Weyrich

unread,
Jan 26, 1992, 7:28:20 PM1/26/92
to
In article <1992Jan20.1...@mintaka.lcs.mit.edu> myc...@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>
>In article <FRANCIS.92...@Galois.dogwood.atl.ga.us>
>francis@francis@dogwood.atl.ga.us (John Stracke) writes:
>>
>> PROM, nothing. If it's a programmable printer (e.g., PS), its
>> language may have primitives for network transmission.
>>
>> [,,,]
>>
>> Anybody know if this is reasonable, or am I just pegging bogometers?
>
>Why the hell would any printer language have primitives to talk over
>the network?
>

Suppose for example:

(1) the language were Turing-complete. (I am pretty sure that
PostScript is).

(2) the language made some provision for handshaking (for example,
exchanging capabilities, etc.) I don't know of any printer
language that does this, but I could imagine that it might be
useful. If this capability were to be provided, the implementer
might decide to "keep things general".

(3) Or suppose that an implementation is built on top of, for example,
a FORTH engine? It might be possible to escape to the underlying
architecture (perhaps as an undocumented feature left over from
product development/debugging).

Just some thoughts...


orville

-------------------------------------- ******************************
Orville R. Weyrich, Jr. Weyrich Computer Consulting
Certified Data Processor POB 5782, Scottsdale, AZ 85261
Certified Systems Professional Voice: (602) 391-0821
Internet: orville%wey...@uunet.uu.net Fax: (602) 661-0660
-------------------------------------- ******************************

Jennifer Cross

unread,
Jan 28, 1992, 1:23:58 AM1/28/92
to
Well for my $.25 worth...

It really depends on the host system the printer was destined for...
In my experience (systems admin on unix/workstations and Comms Sys programmer
on IBM/MVS) many printers (esp for mainframe systems) carry on a
intensive dialog with the host, establishing operating parameters,
device capabilities, comms protocols, etc.

Now, given that they _knew_ the systems which the printer was
going to be attached into (both hardware and software)
there could be *lots* of ways to break the "normal" operating
procedures and introduce problems in the host. The first
(and most obvious is if the printer port is also configured as
a login device... just have the printer attempt logins on
generated/known users/passwords. Another method could be to use
the same trick as was used in the unix worm a few years ago, eg
tell the host that a 90 byte packet follows, then upload a *large*
data packet (overflowing the 90byte buffer, on into other data or
better yet code space!!). This could also be done closer to the
hardware (much harder to monitor). An example (from my IBM days)
would be to have the printer attack the:
a) Cluster Controller (device multiplexer). This could interfere
with all data in or out of the controller.
b) Attack the 3725 communications frontend. This thing has more
programmable bits inside than you could possibly believe. Problems
here could affect hundreds of screens and/or lan interfaces.
c) Attack the Channel Adaptor forgotten the number on the box, sorry).
Jackpot... A destructive program could have a field day here!!
This box controls all Comms frontends, Disk controllers, basically
ALL I/O must pass through here... including the control lines to
the power control module (heh heh) (it (and many others boxes) have
a "remote power control signal...) Maybe just adjust the signal
timeing on a few channels ... causes _heaps_ of re-trys, etc and
is a real hassle to diagnose (the data makes it through, just
the throughput is really low!!) if you interfered with the
disk i/o's only, the tech type would have to check...
i. Disk Mechanisms and accociated control circuits (all boxes!!)
ii. Cables
iii. Disk Controllers
iv. Cables
v. Channel Interface (!!)
vi. Cables
and she would be looking for a hardware type problem... not a
microcode bug!!

Basically the hassle with most of the discussion on the net has been
that everyone is considering the attack as an attack on a PC...
Being a relativly simple device (only one processor, single tasking),
it presents a much much harder target than a host with heaps of
external processors, all doing their own thing...


Hey, this was fun! Anyone need a military installation crippled?? :-)
-- ___
( > /) (voice) +61 9 362 6680
__/_/> ____ ____ o // _ __ (home) cjc...@DIALix.oz.au
/ / (__/ / <_/ / <_<_//__</_/ (_ @ Beautiful Perth, Western Australia
<_/ /> (work) jcr...@ecel.uwa.oz.au
</ (voice) +61 9 380 3879

Kimberly Churchwell

unread,
Jan 28, 1992, 8:58:07 AM1/28/92
to
Ported from BIX (BYTE Information eXchange). For more information on BIX,
call 800-227-2983 (in NH and outside the US, call 603-924-7681).
==========================
bbx.news/the.ticker #832, from brianock, 20352 chars, Mon Jan 27 16:10:31
1992
--------------------------
Magazine Spoofed by Virus Spoof: The Virus That Was Not

Microbytes Daily News Service
Copyright (c) 1992 McGraw-Hill Inc.
It was a flurry of activity that would make a computer cracker's
heart warm with pride. In an article labeled "Spy Wars," U.S.
News and World Report last week told the story of a U.S. effort
to shut down the Iraqi air defense during the Gulf War by
inserting a virus into the Iraqi air defense computers. The
tale of the super-secret National Security Agency inserting
ROMs containing a virus into a French-made printer bound for
Baghdad made for good reading as it explained how the printer
resident virus would make the contents of terminal screens
disappear when users attempted to open a window to perform a
function. Good reading, perhaps, except that it never happened.

Adding confusion was a series of reports by the Associated
Press telling of the U.S. News story and attempting to debunk
it. While the AP was correct in that the virus attack never
happened, they were just as wrong as U.S. News when it came to
the explanation. According to the AP, the story had to be wrong
because printers were incapable of transmitting information to
computers. The result was a crisis of consternation in
Washington, because the agencies alleged to be responsible knew
that they hadn't carried out a virus attack, but weren't sure
that some other agency had not.

Finally, the story ended when the AP revealed that U.S. News
had actually learned of the alleged Iraqi virus attack when the
publication mistakenly believed an April fool article in
InfoWorld. U.S. News responded with a denial, saying that they
hadn't read the InfoWorld item.

At this point, Microbytes Daily entered the fray and
investigated what really happened. As it turned out, both sides
were wrong. According to Defense Department officials familiar
with the incident, Pentagon personnel had read the initial
story and retold it to friends. In the retelling, the story
took on the aspects of an urban legend, which was eventually
picked up by U.S. News. U.S. News, not knowing whether Iraqi
air defense computers use windowing software (they don't)
believed the story. The AP, not having a clue whether printers
can transmit (they can) debunked it. Washington, not knowing if
either side was right, believed both accounts. Meanwhile, the
virus that ate Baghdad remains exactly what it always was - a
myth.
-- Wayne Rash

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

--
Kimberly B. Churchwell, Prog./Analyst, College of Osteo- | TANSTAAFL, but
pathic Medicine, Oklahoma State Univ. Inet: churchwell@ | even so, I never
vms.ocom.okstate.edu; BIX: kchurchwell; AOL: KChurchwel | quit hoping.

Joe Diederichs

unread,
Jan 27, 1992, 10:04:04 PM1/27/92
to
I know the S3 is supposed to accelerate Windows. How does it do for
games under DOS (e.g. Falcon 3, MS Flight Simulator)? Are these two
different problems, or will the games eventually be able to take
advantage of "Windows accelerators" if they can't already. I actually
read somewhere that an S3 card may be SLOWER than stock VGA under DOS.
Well....?

Thanks,
Joe Diederichs

Mike Fox

unread,
Jan 30, 1992, 12:09:00 AM1/30/92
to

The only boards which will be faster than S3 boards in regular VGA modes
will be _fast_ dedicated VGA or superVGA cards like the Orchid Prodesigner
series, for example. Not that this matters -- you really don't need more
than passable speed for these modes, and speed is a non-issue for text
modes. I gave some figures on this a few posts back but check out the Jan 14
PC-Magazine review of 40MHz 386s with various cards, including an S3 based
card, the Actix Quantum in one of them. The S3 card is slower than the
fastest cards in VGA mode by a factor of about 2.5 which still makes it
faster than a lot of cards, and of course it blows away the other cards for
Windows in 1024x768x8bits mode. In VGA mode, the VGA Wonder XL card was only
about 30% faster which means that the S3 would probably beat the original
DRAM version of the Wonder in VGA modes, for what its worth. I'd be
surprised if there are any games which rely on a fast video card -- most of
the processing needed for games has to be done by the main CPU and its with
a fast CPU that you will notice improvement. Forget about MS Flight
Simulator, this game involves very minor and infrequent changes to the
screen and requires a fast CPU above all . I can't think of any games that
need to move anywhere near as much video information as Windows in 1024x768
mode.

As I've said all along, if you use or plan to use GUIs a lot in the future,
get an accelerated card (I like the STB Wind/X S3 card since it comes with a
nice mouse -- but suit yourself), otherwise get a fast superVGA card but you
probably won't notice much 'speed' except for Windows anyway. The graphics
card/bus simply does not present bottleneck for regular VGA mode work.

-mike

Iskandar Taib

unread,
Jan 30, 1992, 9:26:28 PM1/30/92
to
In article <1992Jan30.0...@cs.cmu.edu> md...@cs.cmu.edu (Mike Fox) writes:

>The only boards which will be faster than S3 boards in regular VGA modes
>will be _fast_ dedicated VGA or superVGA cards like the Orchid Prodesigner
>series, for example. Not that this matters -- you really don't need more
>than passable speed for these modes, and speed is a non-issue for text
>modes.

This conjures up images of Lt. Cdr. Data on the Enterprise reading
the wildly scrolling screens on his console....


8-)

--
-------------------------------------------------------------------------------
Iskandar Taib | The only thing worse than Peach ala
Internet: NT...@SILVER.UCS.INDIANA.EDU | Frog is Frog ala Peach
Bitnet: NTAIB@IUBACS !
-------------------------------------------------------------------------------

Russ Poffenberger

unread,
Jan 30, 1992, 3:33:42 PM1/30/92
to
jk...@faraday.clas.Virginia.EDU (jk...@faraday.clas.Virginia.EDU) writes:

I agree. I have an Orchid 1280, and it screams under windows. It is a little
slower under DOS (no driver) than some standard SVGA cards, but all the
games I have played don't seem to mind, and the speed is more than adequate.

It seems like some of the S3 bashing may be from those people who have
recently bought plain vanilla SVGA cards, and are looking for an excuse
to justify not waiting for the S3 card. If you don't do windows, fine, but
if you do, once you try an S3 based system, you won't want to go back.

Russ Poffenberger DOMAIN: pof...@sj.ate.slb.com
Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen
1601 Technology Drive CIS: 72401,276
San Jose, Ca. 95110 Voice: (408)437-5254 FAX: (408)437-5246

Bailey Brown

unread,
Feb 2, 1992, 12:36:13 PM2/2/92
to
pof...@sj.ate.slb.com (Russ Poffenberger) writes:

>It seems like some of the S3 bashing may be from those people who have
>recently bought plain vanilla SVGA cards, and are looking for an excuse
>to justify not waiting for the S3 card. If you don't do windows, fine, but
>if you do, once you try an S3 based system, you won't want to go back.

Most of the recent S3 bashing has come from me. No, I didn't recently buy
a plain SVGA card. I got my Sigma Tseng 4K based board a year and a half
ago, and I am reasonably pleased with it. It was one of the first boards
to offer the 72Hz refresh rate, and with the Winspeed drivers, the performance
is adequate.

The reason I am bashing the S3 is that I am tired of seeing the accelerator
chip manufacturers setting their sights too low. It appears that Weitek
set their sights even lower than the S3. At this rate, we will never have
any low-cost low-res+truecolor & mid-res+hicolor & high-res+256color
options in the $500 range. If I were S3, I would have made the chip more
flexible, so that I could put it on a $250 board that does the traditional
SVGA modes faster or a $500 board that does those modes and true and
hicolor modes.

I am not doubting the usefulness of the S3 for windows or the adequacy of
it's performance when performing vga duties. I just hope that Tseng
has been thinking about truecolor while they've been designing their
windows accelerator. Anybody know when the Tseng accelerator is coming out?

>Russ Poffenberger DOMAIN: pof...@sj.ate.slb.com
>Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen
>1601 Technology Drive CIS: 72401,276
>San Jose, Ca. 95110 Voice: (408)437-5254 FAX: (408)437-5246

------------

Danny Low

unread,
Feb 3, 1992, 1:58:32 PM2/3/92
to
>(Bailey Brown)
>The S3 is a piece of junk. First of all, no S3 based board with only
>1 Meg of display memory is going to go above 800x512 in hicolor mode.
>This is because, in their infinite lack of wisdom, the S3 people
>made the offset from one scanline to the next have to be a power of
>two, and in the case of 513x??? or greater, this has to be 1024.
>Two bytes per pixel means 800(really 1024)x512x2bytes is max, because
>that is 1 megabyte. You can't have an S3 doing 800x600x32K.
>There may be a way around this by having the board run in a dumb
>frame buffer mode without using the S3 chip with 800x600x32K, but it
>will be slow.

This like complaining that a Porsche 911 is a piece of junk
because it cannot carry 5 adults with all their luggage in comfort.
If you want hicolor, there are several such cards for the PC
that provide this. The S3 chip is NOT intended for that market
any more than the Porsche 911 is intended for the family car
market. If you cannot afford a 24 bit card, bitch at the people who
make those cards for their high prices. The S3 chip is for
people who want a fast SVGA card and NOT a hicolor card.

Danny Low
"Question Authority and the Authorities will question You"
Valley of Hearts Delight, Silicon Valley
HP NPCD dl...@pollux.svale.hp.com

Bailey Brown

unread,
Feb 8, 1992, 4:05:45 PM2/8/92
to
dl...@pollux.svale.hp.com (Danny Low) writes:

>This like complaining that a Porsche 911 is a piece of junk
>because it cannot carry 5 adults with all their luggage in comfort.

No, this is like complaining that the Porsche can't be had with
a sunroof because some idiot designer made it such that a hole
could not be cut in the roof without severely weakening the chasis.

>If you want hicolor, there are several such cards for the PC
>that provide this. The S3 chip is NOT intended for that market
>any more than the Porsche 911 is intended for the family car
>market. If you cannot afford a 24 bit card, bitch at the people who
>make those cards for their high prices. The S3 chip is for
>people who want a fast SVGA card and NOT a hicolor card.

My point is that I don't think it would have been that much harder to
make the S3 have an 800x600 hicolor mode. Some of us want hicolor
and fast 8-bit in the same card.

> Danny Low
> "Question Authority and the Authorities will question You"
> Valley of Hearts Delight, Silicon Valley
> HP NPCD dl...@pollux.svale.hp.com

------------

Kevin Warne

unread,
Feb 8, 1992, 6:21:17 PM2/8/92
to
In article <1992Feb8.2...@b11.ingr.com> bbr...@b11.ingr.com (Bailey Brown) writes:
>My point is that I don't think it would have been that much harder to
>make the S3 have an 800x600 hicolor mode. Some of us want hicolor
>and fast 8-bit in the same card.

From what I understand, the S3 cards are excellent 256 color windows (or OS/2)
accelerators. So they don't have 800x600 hicolor. They're still a good
first step on the road towards fast, coprocessed, true color for PCs at an
affordable price. What we need now is a manufacturers to release a
coprocessed card with more than 1MB video memory supporting true color at
under $600. Now there would be card to have. Of course, with more than 1MB
of video memory, the card would have to be run by protected mode drivers.
Which probably means that we'll have to wait for OS/2 V2.0 to gain ground
before we'll see it happen.

Kevin
"I want 24 bit color, but I can't afford it"

Joel Upchurch

unread,
Feb 14, 1992, 3:35:42 AM2/14/92
to
In article <1992Feb8.2...@descartes.waterloo.edu>, krw...@descartes.waterloo.edu (Kevin Warne) writes:
>affordable price. What we need now is a manufacturers to release a
>coprocessed card with more than 1MB video memory supporting true color at
>under $600. Now there would be card to have. Of course, with more than 1MB
>of video memory, the card would have to be run by protected mode drivers.
>Which probably means that we'll have to wait for OS/2 V2.0 to gain ground
>before we'll see it happen.

Is that really true? I thought video cards only had a 64kb window
into the main memory of the machine and that the video drivers
bank-selected which part of the video RAM to look at, sort of
like EMS. Now maybe they only allocated 4 bits for the bank
select, but it doesn't seem to me that it would be too hard
to have a mode that would use a 8 bit bank select. Of course,
if you use a video co-processor, it should reduce the need
of the main processor to access the video RAM anyway.
--
Joel Upchurch/Upchurch Computer Consulting/718 Galsworthy/Orlando, FL 32809
jo...@peora.ccur.com {uiucuxc,hoptoad,petsd,ucf-cs}!peora!joel (407) 859-0982

0 new messages