Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 200
=========================================================================
INFO-ATARI16 Digest Wed, 14 Feb 90 Volume 90 : Issue 200
Today's Topics:
DEC keyboard as ST replacement
drawings -< pic, laserjet, postscript??
GNU emacs (numbers 17 thru 20 missing)
Key virus NOT harmless
STE and multisyncs
----------------------------------------------------------------------
Date: 13 Feb 90 10:02:15 GMT
From: hp-sdd!ncr-sd!ncrlnk!ncrwic!wsucsa!mwjester@hplabs.hp.com
Subject: DEC keyboard as ST replacement
Message-ID: <13203@wsucsa.uucp>
Has anyone tried out the package that supposedly allows one to connect a
DEC LK201 keyboard to the ST? (I think the package is at Terminator.) I
have been using DEC keyboards for some time now, and an LK201 would be my
choice if I was looking for a 'better' keyboard for the ST.
Max J
------------------------------
Date: 13 Feb 90 18:16:12 GMT
From: uw-entropy!dataio!pilchuck!ssc!fyl@beaver.cs.washington.edu (Phil Hughes)
Subject: drawings -< pic, laserjet, postscript??
Message-ID: <478@ssc.UUCP>
In article <3831@cbnewsj.ATT.COM>, rcd@cbnewsj.ATT.COM (rana.c.dutt) writes:
> The drawing tools in Pagestream 1.8 are very good. After you're done,
> you simply load the printer driver you want from Pagestream's wide
> selection of output modules, which includes the HP Laserjet and Postscript.
> I have both the HP Deskjet and the Paintjet, and the output quality on both
> is excellent.
> If you want to merge these drawings into troff documents, I suggest you
> convert your troff output to postscript first, with a postscript
> post-processor. Then merge the postscript generated from Pagestream into it.
Actually, you can just include the postscript into troff input.
By adding a \! prefix, troff will just pass it thru to the typesetter.
I use this feature all the time to produce overheads for my
UNIX classes. I produce postscript with Publishing Partner and
then use a make file on the UNIX system to handle the preprocessing
of the postscript to add the prefixes (and strip out garbage generated by
PP. I use a macro in my troff source to include the postscript file and
tell troff how much space the figure will take. I am using devps to drive
the postscript printer or typesetter from troff.
--
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX
uunet!pilchuck!ssc!fyl or attmail!ssc!fyl (206)527-3385
------------------------------
Date: 12 Feb 90 16:23:00 GMT
From: hp-sdd!ncr-sd!ncrlnk!ncrcam!system!mike@hplabs.hp.com (mike reiss)
Subject: GNU emacs (numbers 17 thru 20 missing)
Message-ID: <564@system.Cambridge.NCR.COM>
I have been waiting patiently for GNU emacs for the Atari ST since I heard
it was going to be posted (before Christmas I think). Well it finally
came and wouldn't you know it, I didn't get it all. Why does this always
happen with something that you are looking forward too? Well, I'm looking
for a volunteer to send these to me. Any takers?
Many thanks to anyone who would be willing,
mike
------------------------------
Date: 14 Feb 90 09:12:09 GMT
From:
zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caesar.cs.montana.edu!icsu805
3@tut.cis.ohio-state.edu (Craig Pratt)
Subject: Key virus NOT harmless
Message-ID: <3117@caesar.cs.montana.edu>
In article <9906@ttidca.TTI.COM> you write:
>In article <28923@brunix.UUCP> rjd@cs.brown.edu (Rob Demillo) writes:
>...[edited]...
>>This is directly from the horse's mouth, as it were...the statement
>>was issued by SoftLogik, Inc. to the ST Report. It the statement it
>>is refered to as the "key virus." (Anyone hear of this?) Any of the
>>anti-virus programs should take care of it, but Soft Logik is,
>>of course, exchanging disks if you are nervous.
>
>The "KEY" virus is the most widespread virus in the USA. That is
>because it displays no symptoms, it only spreads. It represents
>two dangers:
>1) It spreads to every disk that passes through the ST while the
>virus is active, thus wiping out existing executable boot sectors
>on disks which must have them. This can render a disk which must
>be self-booting useless.
>
>2) It is called the "KEY" virus because, once installed in a
>system, it checks every passing disk for a "KEY" value in the
>boot sector. If it locates one, it will cause the execution of
>whatever code is on that disk, even if the machine is not being
>powered up or reset at the time the "KEY" disk is located. There
>have been no episodes of a "KEY" disk being located reported, to
>date. That doesn't mean they don't exist. That only means that
>I haven't heard of them, or the victim of whatever the "KEY" did
>was not aware of the cause (which is quite likely, if such an event
>has occurred).
>
>Every virus killer I've seen (or written, of course) will eradicate
>this virus.
>
>--
>* George R. Woodside - Citicorp/TTI - Santa Monica, CA *
>* Path: woodside@ttidca *
>* or: ..!?philabs|csun|psivax?!ttidca!woodside *
I just ran into this virus yesterday and it is not even in the general sense
harmless! It ate two of my disks last night before I could isolate it and
kill it. I figured the first disk, my WordPerfect document disk, had gone
bad but the second disk made me suspicious so I ran the *excellent* vkiller
program on it and discovered that I had the key virus on both the dead disks
and some "undead" disks as well. I tried to recover these disks with Norton
utilities, which always has recovered all but a few of the files on a toasted
disk; it would have nothing to do with it. It created some files but they
were bits and pieces of multiple files. I've devoted this evening attempting
to figure out what happened. I took one disk which still had the "harmless"
key virus on it and copied just the files off. I also installed the hospital
utilities just to see if they worked - it did very well. Anyway, I then made
this the test disk and formatted a new blank disk. I discovered that when I
booted off the "undead" disk, it suddenly became dead and gave a read error
on the disk. When I inserted the control disk, which had tested safe, and
pressed retry, it didn't do anything. When I displayed information on the
control disk, it read and probably wrote to the disk. I ran vkiller. It
couldn't read the test virus disk and said the control disk now had a virus.
By determination and disk switching, I finally got the test disk to read. It
said it was virused, had eight sides and 119538576 bytes total of disk space.
By examinig the sectors, I discovered that Key had written over the directory
sectors of the disk. It was very dead. So, it would seem that the key virus
is *NOT* *HARMLESS*. All I can say is install the hospital programs and hope
and pray that the bozo/moron/idiot scumball/50 caret moron(s) who wrote this
virus doesn't make one that messes with my hard drive. It would be time to play
"Hunt down & destroy the pesky little virus hacker" (New...from Nintendo!).
A tremendous Thank You to George Woodside for his excellent vkiller program!
Craig Pratt
BitNet: Craig.Pratt@msu3.oscs.montana.edu
GEnie: C.PRATT4 (not here often)
"The ships hung in the air in exactly the same way that bricks don't"
Douglas Adams, _The_Hitchhiker's_Guide_to_the_Galaxy_
------------------------------
Date: 14 Feb 90 02:01:28 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: STE and multisyncs
Message-ID: <2042@atari.UUCP>
01659@AECLCR.BITNET (Greg Csullog) writes:
>I ask ONCE AGAIN. If the STE supports large screen monitors, like the
>MONITERMs, can I get the full rez (1024x768) on an OMNIMON Rainbow
>multisync. If so, HOW!!!!!
Taking this tone does not help you get an answer. This is the first
time I have seen this question come up, and I'm answering you in spite
of your tone mainly as an excuse to ask people to be more considerate
in the future.
No, the STe can not drive a Moniterm or similar monitor directly. The
video signal for that kind of monitor is totally different from the
normal ST/STe video, and requires extra hardware. There is an add-in
board available for the Mega which has this hardware. Since the STe is
in a 1040 case, without the room or stakes for this kind of board,
it's not available for STe. We do have plans for a future STe with
enough expansion capability to make this possible, but the details
are not public yet (and I don't know them).
The TT does support Moniterm-style monitors directly. It has that
extra hardware built in, in addition to other new video modes, plus the
three ST video modes for compatibility. All the modes except the
1024x768 Moniterm-style mode are usable with the same type of monitor.
That monitor is *like* VGA, but the timing is a little different, so an
off-the-shelf VGA monitor will look funny (i.e. picture too small and
not centered, or something like that). If you buy the monitor from us,
it will work (of course). If you buy a multisync monitor, it will come
with enough adjustments that you can make it look good. Your ST
monitors will not work with a TT.
>Can someone from Atari also post the specs on the SIMMs the STE and STACY
>are supposed to use?
I don't know them. The SIMMs are there mainly for the cost and space
savings on the PC board, not so you can add memory to your machine.
In some machines the memory is not even socketed: it's SIPs, not SIMMs.
If the cost of SIPs is lower than SIMMs plus sockets at the time we
buy, we use SIPs.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
End of INFO-ATARI16 Digest V90 Issue #200
*****************************************
