COMSAT@MC.LCS.MIT.EDU (Communications Satellite) (03/20/88)
FAILED: TETHER at MITLNS.MIT.EDU; Funny reply from foreign host after sending message.
Last reply was: {554 Unable to deliver mail to given recipient(s)}
Failed message follows:
-------
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 20 MAR 88 04:38:45 EST
Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU with Chaos/SMTP; Sun 20 Mar 88 04:37:51-EST
Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Sun 20 Mar 88 04:38:24-EST
Date: Sat 19 Mar 88 23:46:13 PST
Subject: Info-Atari16 Digest V88 #127
From: Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU>
Sender: Info-Atari16-request@Score.Stanford.EDU
Errors-to: Info-Atari16-request@Score.Stanford.EDU
Maint-Path: Info-Atari16-request@Score.Stanford.EDU
To: Info-Atari16 Distribution List: ;
Reply-to: Info-Atari16@Score.Stanford.edu
Info-Atari16 Digest Saturday, March 19, 1988 Volume 88 : Issue 127
This weeks Editor: Bill Westfield
Today's Topics:
Re: A cure looking for a disease? (I hope)
Re: alcyon question
Atari TOS
Re: Video interrupts: using or disabling
Re: Mouse Addresses...
Re: WARNING ! Atari ST owners look away now....
Re: New version of Turtle?
Re: Re: Re: Copyright notices (was: Shareware? Hah!)
Re: Re: Problems w/uue files at ATARINET (UH-INFO@UHUPVM1.BITNET)
Re: Blitter and Assempro ?
----------------------------------------------------------------------
Date: 9 Mar 88 18:43:43 GMT
From: nunki.usc.edu!sal23.usc.edu!rjung@oberon.usc.edu (Robert Jung)
Subject: Re: A cure looking for a disease? (I hope)
To: info-atari16@score.stanford.edu
In article <8803081650.AA29358@ucbvax.Berkeley.EDU> 051332@UOTTAWA.BITNET (John Turnbull) writes:
>A program called VDU_2_0.PRG has been posted to the FILESERVers at
>CANADA01 and UHUPVM1. It is claimed that it will cure the 'Boot sector'
>virus and immunize the disk from future infection with this virus.
>
>Does anybody have any information about this virus, its mode of
>infection, mechanism, symptoms or how wide-spread it may have become?
>
>Please post replies to the net. Most people will be interested. /JT
Yes, this is interesting, especially since I find it hard for a virus to
proliferate on a microcomputer (since it gets coldstarted quite often,
relative to mainframes, where these things are easy).
I'm also interested in what this virus does. Rumor mill in the L.A.
area has it that there are at least two viruses running around, but I
can't confirm (supposedly one is from Germany, and ST-Express has a program
to "find" it). There is also a utility program and a desk accessory
that's supposed to "check" your disks for the virus. Whether or not they
really work is another matter.
A local ST programmer here says that he's dissected the code, and while
he doesn't know exactly what it does (either that, or he's not telling me),
it "modifieds the disk I/O buffers in some manner"...Sounds like bad news
to me.
Any virus information would be handy. Just what DOES this thing do, anyway?
--R.J.,
sharing information
B-)
P.S. Has anyone else heard the rumor that (one of) the Amiga virus programs
is designed to cause "a massive worldwide screw-up" on some prespecified date?
______________________________________________________________________________
Bitnet: rjung@castor.usc.edu "Who needs an Amiga?" = == =
= == =
Power WithOUT the Price = == =
===== == =====
Just because it's 8-bits doesn't make it obsolete. ==== == ====
------------------------------
Date: 11 Mar 88 18:32:05 GMT
From: portal!atari!apratt@uunet.uu.net (Allan Pratt)
Subject: Re: alcyon question
To: info-atari16@score.stanford.edu
From article <1374@alliant.Alliant.COM>,
by rosenkra@Alliant.COM (Bill Rosenkranz):
> does anyone know if it is possible to write inline assembler with
> alcyon? seems like i've tried all the ways i can think of but none
> seem to work. it's really not a big deal, just curious....
>
> -bill
Yes: say asm("foo") where foo is an as68-compatible line of assembly code.
For instance...
#include <osbind.h>
main()
{
long oldssp = Super(0L);
asm("move.l #$0,$420"); /* set _memvalid to 0 (invalid) */
asm("move.l $4f2,a0"); /* a0 -> system header */
asm("move.l 2(a0),a0"); /* 2(a0) is reset vector */
asm("jmp (a0)");
}
will cause a COLD system reset (as opposed to the normal warm one).
Equivalent C code is left as an exercise to the reader -- this is just
an example. (JMPing indirect through 4 would work, but JMPing directly
to FC0000 or FC0030 wouldn't be right because new STs might have ROM
starting at a different location.)
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 11 Mar 88 21:35:11 GMT
From: portal!atari!good@uunet.uu.net (Roy Good)
Subject: Atari TOS
To: info-atari16@score.stanford.edu
We are in the process of finalizing the next version of TOS for the ST and
Mega series. It already includes many significant improvements and bug
fixes, a list of which will be posted when the product is ready for Beta.
We have already solicited and received input for fixes and enhancements
from our international subsidiaries, and also via GEnie, Bix and Compuserve,
resulting in well over 200 items.
The readers of this category are invited to submit their own requests at this
time. Please keep them brief and sensible - we are not requesting flames,
just the fuel [:-)]. If you can, please categorize each input as being
related to GEMDOS (BIOS/XBIOS/filesystem etc), VDI, AES or DeskTop.
We cannot guarantee, or even hope, to satisfy everyone, but input will be
taken into consideration, and some suggestions which do not make it into
this release will certainly be considered for a future release.
To avoid overloading this category, please email your input directly to me.
Thank you.
-----------------------------------------------------------------------------
Roy J. Good
Product Development, Atari Corporation
Views expressed are my own. Atari may agree or disagree; they have the right.
------------------------------
Date: 11 Mar 88 18:09:32 GMT
From: portal!atari!apratt@uunet.uu.net (Allan Pratt)
Subject: Re: Video interrupts: using or disabling
To: info-atari16@score.stanford.edu
From article <2509@tekig5.TEK.COM>, by wayneck@tekig5.TEK.COM (Wayne Knapp):
> In article <3379@chinet.UUCP>, saj@chinet.UUCP (Stephen Jacobs) writes:
>> I am curious about the horizontal and vertical blank interrupts. How much
>> code can one safely put in a horizontal blank routine?
>> appears to be a flag telling the default vertical blank handler to cut its
>> operation short: what awful thing (if any) would happen if the interrupt
>> threshold was simply set above the vertical blank level?
> Just too much overhead
> to try and handle a iterrupt every 64.5 usec.
> Wayne Knapp
If you disable vblank (i.e. run at IPL 7), the mouse and blinking cursor
will stop, and the floppy motor won't shut off if it's on. That's
about all -- no great bloody crashes. I run this way when remote
debugging sometimes and it works fine.
Oh, but if you move the mouse at IPL 7, the keyboard packet handler will
get out of sync and you may not be able to recover. Sorry.
You can stop the vblank handler by setting the variable 'vblsem' to 0
(it's address 0x452 word). I believe that there is still a counter
running, and when you unblock vblsem the vblank routines get hit as
many times as there were blocked vblanks. Not sure about that.
When the ST was running at IPL 0, and the Hblank routine was just RTE,
we saw 25% performance degradation as compared with running at IPL 3 (no
Hblanks). On the other hand, NEO and Spectrum do stuff at Hblank...
It's not impossible, just hard.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 11 Mar 88 18:21:54 GMT
From: portal!atari!apratt@uunet.uu.net (Allan Pratt)
Subject: Re: Mouse Addresses...
To: info-atari16@score.stanford.edu
From article <4484@garfield.UUCP>, by avp@garfield.UUCP (Anthony Paul):
> Back in October, the addresses went by for the mouse,
> [deleted] - x pos
> [deleted] - y pos
> [deleted] - buttons.
>
> My problem, the article said these don't work on the mega.
> Anyone know what they are on the Mega?
These variables are in fixed locations relative to the Line-A base you
get in A0 when you use Line-A init ($A000).
MOUSE_BT equ -596
M_HID_CT equ -598
GCURY equ -600
GCURX equ -602
dc.w $a000
move.w MOUSE_BT(a0),d0 ; mouse bits (bit 0 is left button)
move.w M_HID_CT(a0),d1 ; mouse hide depth (0=visible)
move.w GCURY(a0),d2 ; mouse pointer Y
move.w GCURX(a0),d3 ; mouse pointer X
These variables are read-only -- unpredictable things will happen if
you write to them. The exception is the hide depth of the mouse.
If you want to show the mouse, do stuff, then restore it to the previous
depth, do this:
dc.w $a000 ; get line-A base to a0
move.l a0,save_base ; save this for later
move.w M_HID_CT(a0),d7 ; get old depth
beq.s already_shown ; already visible
move.w #1,M_HID_CT(a0) ; set new depth of 1
dc.w $a009 ; show mouse
already_shown:
... do stuff ...
tst.w d7 ; was it shown before?
beq.s all_done ; yes - no need to do anything
dc.w $a00a ; hide it
move.l save_base,a0 ; get line-A base again
move.w d7,M_HID_CT(a0) ; set depth to old value
all_done:
rts
.bss
save_base: ds.l 1
The point here is that you can change the depth from one nonzero value
to another nonzero value safely, especially if you restore it later.
But remember if you don't restore it that AES will get out of sync.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 11 Mar 88 04:55:08 GMT
From: mnetor!utzoo!utgpu!water!watmath!isishq!Usenet_News_Of_221/162@uunet.uu.net (Usenet News Of 221/162)
Subject: Re: WARNING ! Atari ST owners look away now....
To: info-atari16@score.stanford.edu
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Date: 10 Mar 88 02:59:17 GMT
Message-ID: <8803100259.AA03230@cory.Berkeley.EDU>
Newsgroups: comp.sys.atari.st,comp.sys.amiga
:>1) The Atari ST's OS has been ported from an IBM PC and has several features
:> removed (no fonts for example) and has had several (hundred ?) bugs
:> introduced (40-folder bug, can't rename a folder, can't rename a disk...).
:>
:Wrong. Porting is modifying existing code to work on a different computer.
:DRI wrote TOS/GEM/GEMDOS entirely from scratch.
Yah, well they obviously didn't think about it much. They borrowed
a lot (en concept, en theory) from the PC OS. For instance, the disk format.
>Yet, in the same machine, we have a midi interface. Those who are interested
>in good sounding music can add a synthesizer and persue a professional career.
>If this is cost cutting, how come no other machine comes with one built-in?
Oh please, isn't this a bit old? Any idiot knows that all you need
for midi is a serial port, a simple serial->midi adaptor (extremely cheap),
and good software. If I really wanted to, I could hook one up to my
low-speed digital logic probe (6502 @ 2.4Mhz, can transmit and receive on
two 76.8KBaud lines simultaniously at full speed without interruption.
--slow-- MIDI is *simple*).
>>4) Virtually all the compilers I've seen (and I've seen plenty of them !) for
>> the ST have been quite disgraceful. They either have numerous bugs, have
>> a user-hostile interface (such as a cryptic command line) or are extremely
>> slow. This just shows that ST software companies are in the market to make
>> a quick buck off people foolish enough to buy an ST in the first place.
>>
>
>Yawn. OSS Pascal, MWC Ver. 3.0, Laser C? What goes for "good" these days?
As he said ... disgraceful. Still better than the compilers I
see on the IBM PC (in C at least...)
>
>>6) As mentioned in comp.sys.atari.st, Atari have been caught red-handed
>> shipping STs with faulty disk drives that don't sense the write-protect
>> notch on a disk correctly...typical of such a cost-cutting compan
--- ConfMail V3.31
* Origin: The Waterloo Window: watmath!isis!171![userid] (1:221/171)
SEEN-BY: 221/0 162 171 171
------------------------------
Date: 4 Mar 88 09:17:54 GMT
From: mcvax!diku!jesper@uunet.uu.net (Jesper L. Lauritsen)
Subject: Re: New version of Turtle?
To: info-atari16@score.stanford.edu
In article <19880301154715.3.JRD@GRACKLE.SCRC.Symbolics.COM> jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes:
>Does anyone have a version of Turtle newer than 2.15? George Woodside
>(the author) tells me there's a 2.16 which fixes the bug that's stopping
>me from doing backups. He said it's floating around Genie, Compuserve,
>maybe some other places, but I haven't seen any mention of it here. If
>anyone has a copy, could you forward it to me or post it to the list?
Please post it.
Thanks in advance
--------
Jesper L.Lauritsen, U of Copenhagen, jesper@diku.UUCP or ibtjll@dkuccc11.BITNET
------------------------------
Date: 8 Mar 88 22:42:01 GMT
From: mcvax!diku!keld@uunet.uu.net (Keld J|rn Simonsen)
Subject: Re: Re: Re: Copyright notices (was: Shareware? Hah!)
To: info-atari16@score.stanford.edu
In article <160@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes:
>My point was that "legal" or not, and regardless of any discussions
>to that effect here or elsewhere: DON'T GET YOUR HOPES UP. The
>authorites showed no desire to help a small software company in Oakland;
>that includes both US and German authorites (police and Fed. agencies).
>Any attempts to bring justice would have meant a law suit in German courts.
>Several US and German copyright lawyers (supposedly some of the top ones
>in the world) advised against doing anything (a strange practice for a
>lawyer with nothing to lose) becuase it would be very costly, and the
>outcome would at best be a court order to stop production, which the
>company could simply ignore anyway since the police had better things
>to do.
I got some more info on the history of international copyright laws.
Apparantly UNESCO is dealing with this, this is the forum that the
Berner Convention is discussed. Software protection has been discussed
here too, and during the 1970-ies they reached a concensus that
software should be protected thru copyright, as a litterary work.
The USA then made the new copyright act in 1980, and some bigger
European countries followed up, notably France and Germany (BRD) in 1985
included software explicitly in the coverage for copyright in their
revisions of copyright laws.
If you had your troubles in Germany before 1985, then it might have
been because German copyright laws did not cover software at
that time. I am no expert on German law, however.
>In other words: you can read and discuss laws and legalities all you want,
>but in the *real world* all this means very little.
I now presume that your experiences is pre-1985, and that German
law did not protect you. That must have been the reason why neither
the police nor your lawyers would help you.
If your product enjoys copyright protection and this is violated,
then this is what I understand the Danish law to be: The offence
is a criminal case, and the state attorney is taking your case,
you will not have to pay any lawyers expenses. The offender can get
sentenced to penalties or in worse cases ordinary imprisonment up
to 3 months. I think your case would be of the worse kind, as it
was for profit. The offended has to go to the police and make an
action on the offence.
Additionally you can claim damages, but this is a civil case.
Having the offender sentenced in the criminal case should make
it easier to get the damages thru in a civil case, though.
I have no experiences of my own on such cases, so your comment on the
real world and slow/uninterested police I cannot offer any real
background for. It is of cause always easier in the books and
and easier if you are near to the offence. It is my impression that
the police takes all criminal offences seriously, especially when
there is much money involved; the courts may be slow though.
I do think though that your German "experience" was caused by lack
of software protection at that time in German laws, and the
situation has improved considerably since then, the conditions for
foreign software producers in Europe are not as bad as you indicate.
Keld Simonsen, U of Copenhagen keld@diku.dk
------------------------------
Date: 4 Mar 88 09:41:47 GMT
From: mcvax!diku!jesper@uunet.uu.net (Jesper L. Lauritsen)
Subject: Re: Re: Problems w/uue files at ATARINET (UH-INFO@UHUPVM1.BITNET)
To: info-atari16@score.stanford.edu
In article <500@uhnix2.UUCP> uace0@uhnix2.UUCP (Michael B. Vederman) writes:
>The problem is REALLY brain-damaged gateways that do BAD translations of
>characters. If you have gotten UUX UUE from ATARINET, this takes care of
>almost all problems. The problem is definitely not ATARINET!
Sure isn't, I have got lots of programs from ATARINET - thanks to UACE.
I do however have to fix all files before I uudecode. The problem is that
our local VM system uses the Danish version of the EBCDIC character set,
and the conversion from US EBCDIC is not done very well. I sugest that
you try to download one of the newer files encoded with the newest version
of uuencode. These files contain a table of the characters used. If you are
in luck you may be able to deduce from that table what characters to
change. It would defenitly be a help i all files was decod with the
newest decoder.
------
Jesper L.Lauritsen, U of Copenhagen, jesper@diku.UUCP or ibtjll@dkuccc11.BITNET
------------------------------
Date: 10 Mar 88 04:17:29 GMT
From: portal!cup.portal.com!Jinfu@uunet.uu.net
Subject: Re: Blitter and Assempro ?
To: info-atari16@score.stanford.edu
wes@obie.UUCP writes:
>
>Have you tried turning off the blitter from the desktop? Most ST
>wordprocessors crash when the blitter is turned on, run OK with it
>turned off.
>
Do you have experience with this or you just heard from somewhere? I
haven't encountered any crashes with BliTTER on with all kind of programs
(not just word processor) except few games (not crash but just too fast
to play).
Don't spread rumors unless you know what you talk about.
/* flame off */
Jinfu Chen (has BLiTTER since last Nov.)
------------------------------
End of Info-Atari16 Digest
**************************
-------