🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #30152

Returned Network Mail

#30152
From: POSTMASTER
Date: Wed, 13 Jan 1988 13:20
581 lines
19174 bytes
Your mail is being returned to you.
Reason for return is:
%MAIL-E-NOSUCHUSR, no such user VY9074 at node VAXB
Returned mail follows:
------------------------------
Received: From CANADA01(MAILER) by BINGVAXB with Jnet id 0546
          for VY9074@BINGVAXB; Wed, 13 Jan 88 08:20 EST
Received: by CANADA01 (Mailer X1.24) id 0451; Wed, 13 Jan 88 07:41:24 EDT
Date:         Tue, 12 Jan 88 10:16:37 PST
Reply-To:     Info-Atari16@Score.Stanford.edu
Sender:       INFO-ATARI16 Discussion <INFO-A16@CANADA01>
From:         Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU>
Subject:      Info-Atari16 Digest V88 #15
To:           andrew stoffel <VY9074@BINGVAXB>

Info-Atari16 Digest   Tuesday, January 12, 1988   Volume 88 : Issue 15

This weeks Editor: Bill Westfield

Today's Topics:

      Fast life program for Atari ST (and other 68000 machines)
                           Re: Observations
                         Re: 40 folder limit
                          Re: Multiuser BBS
                      VCR -> Atari color monitor
                          SH204 disk errors
                             Help wanted
                      UniTerm available for FTP
                     Alcyon (yuck) return codes.
                  Re: Multi-tasking? A nightmare...

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

From:
 clyde!watmath!watnot!watrose!jsgray%rutgers.rutgers.edu%CERNVAX.BITNET@CUNYVM.C
UNY.EDU
Date: 1 Mar 87 16:44:21 GMT
Subject: Fast life program for Atari ST (and other 68000 machines)
To: info-atari16@score.stanford.edu

Here is a fast (400,000 cell-generations/s) life program for monochrome
Atari-ST computers (which should port easily to other 68000 machines).

It animates all 240,000 pixels on the screen.  Feel free to add a
better user-interface!

[that means about 2 full screen updates per second, right ?  Not a record
 by any means - let me tell you about the CAM I saw doing full screen life
 at full video rates (60 (or at least 30) full screens/second).    --BillW]

But how does it go so fast?  It sums the neighbours of 32 cells in one
pass, by synthesizing addition instructions out of logical operators.

The rest of this file is a shar containing
    life.c        - mainline
    gen.s        - quickly compute next generation
    life.uue    - uuencoded life.prg (Atari ST only)

Have fun!

Jan Gray    jsgray@watrose    University of Waterloo    (519) 885-1211 x3870

# This is a shell archive.  Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by watrose!jsgray on Sun Mar  1 11:29:07 EST 1987
# Contents:  life.c gen.s life.uue

echo x - life.c
sed 's/^@//' > "life.c" <<'@//E*O*F life.c//'
/*
 * Fast monochrome life for Atari ST.
 *
 * Written by
 *   Jan Gray
 *   300 Regina St. N Apt. 2-905
 *   Waterloo, Ontario
 *   N2J 4H2
 *   Canada
 *   (jsgray@watrose.UUCP)
 *
 * Copyright (C) 1987 Jan Gray.
 * This program may be freely redistributed if this notice is retained.
 */

#include "define.h"
#include "osbind.h"

#define    MAXX        640
#define    MAXY        400
#define    BPL        32

#define    ROW_LONGS    (MAXX / BPL)
#define SCREEN_LONGS    (ROW_LONGS * MAXY)

long    *Screen;
long    NextScreen[SCREEN_LONGS];

main()
{
    Screen = (long *)Physbase();

    while (!Cconis()) {            /* until key press... */
        clearBorders();
        gen();
        copyScreen();
    }
}


copyScreen()
{
    register long    *p;
    register long    *q;

    for (p = NextScreen, q = Screen; p < &NextScreen[SCREEN_LONGS]; ) {
        *q++ = *p++;
        *q++ = *p++;
        *q++ = *p++;
        *q++ = *p++;
    }
}

clearBorders()
{
    register long    *p;

    for (p = Screen; p < &Screen[ROW_LONGS]; p++)
        *p = 0L;

    for (p = &Screen[(MAXY - 1) * ROW_LONGS]; p < &Screen[MAXY * ROW_LONGS];
 p++)
        *p = 0L;

    for (p = Screen; p < &Screen[SCREEN_LONGS]; p += ROW_LONGS)
        *p &= ~0x80000000L;

    for (p = &Screen[ROW_LONGS-1]; p < &Screen[SCREEN_LONGS]; p += ROW_LONGS)
        *p &= ~1L;
}
@//E*O*F life.c//
chmod u=rw,g=rw,o=r life.c

echo x - gen.s
sed 's/^@//' > "gen.s" <<'@//E*O*F gen.s//'
*
* Fast monochrome life for Atari ST.
*
* Written by
*   Jan Gray
*   300 Regina St. N Apt. 2-905
*   Waterloo, Ontario
*   N2J 4H2
*   Canada
*   (jsgray@watrose.UUCP)
*
* Copyright (C) 1987 Jan Gray.
* This program may be freely redistributed if this notice is retained.
*

*
* gen -- compute the next generation of cells
*
* This code is a transliteration of the the pdp-11 code presented in
* "Life Algorithms" by Mark Niemiec, Byte, 4:1, January 1979.
*
* gen currently does about 400,000 cell-generations/second.  It can go faster.
*
* Forgive the hardwired-in constants, and the terse comments.  It's a hack.
* Think of the fun you'll have figuring out how it works.
*
@.globl _gen
@.text
_gen:
    movem.l    d0-d7/a0-a2,-(sp)

    move.l    _Screen,a0
    move.l    a0,a2
    add.l    #80,a0
    add.l    #31920,a2
    move.l    #_NextScreen+80,a1

* 1 2 3
* 7 * 8
* 4 5 6

* (d1,d0) = neighbours 1+2
again:
    move.l    -80(a0),d0
    move.l    d0,d1
    move.l    d0,d2
    move.b    -81(a0),d7
    roxr.b    #1,d7
    roxr.l    #1,d0
    eor.l    d1,d0
    or.l    d0,d1
    eor.l    d0,d1

* (d1,d0) = neighbours 1+2+3

    move.b    -76(a0),d7
    roxl.b    #1,d7
    roxl.l    #1,d2
    eor.l    d2,d0
    or.l    d0,d2
    eor.l    d0,d2
    or.l    d2,d1

* (d3,d2) = neighbours 4+5

    move.l    80(a0),d2
    move.l    d2,d3
    move.l    d2,d4
    move.b    79(a0),d7
    roxr.b    #1,d7
    roxr.l    #1,d2
    eor.l    d3,d2
    or.l    d2,d3
    eor.l    d2,d3

* (d3,d2) = neighbours 4+5+6

    move.b    84(a0),d7
    roxl.b    #1,d7
    roxl.l    #1,d4
    eor.l    d4,d2
    or.l    d2,d4
    eor.l    d2,d4
    or.l    d4,d3

* (d2,d1,d0) = neighbours 1+2+3+4+5+6

    eor.l    d2,d0
    or.l    d0,d2
    eor.l    d0,d2
    eor.l    d2,d1
    or.l    d1,d2
    eor.l    d1,d2
    eor.l    d3,d1
    or.l    d1,d3
    eor.l    d1,d3
    or.l    d3,d2

* (d4,d3) = neighbours 7+8

    move.l    (a0),d3
    move.l    d3,d4
    move.b    -1(a0),d7
    roxr.b    #1,d7
    roxr.l    #1,d3
    move.b     4(a0),d7
    roxl.b    #1,d7
    roxl.l    #1,d4
    eor.l    d4,d3
    or.l    d3,d4
    eor.l    d3,d4

* (d2,d1,d0) = neighbours 1+2+3+4+5+6+7+8

    eor.l    d3,d0
    or.l    d0,d3
    eor.l    d0,d3
    eor.l    d3,d1
    or.l    d1,d3
    eor.l    d1,d3
    eor.l    d4,d1
    or.l    d1,d4
    eor.l    d1,d4
    or.l    d3,d2
    or.l    d4,d2

* next generation

    or.l    (a0)+,d0
    not.l    d2
    and.l    d2,d0
    and.l    d1,d0
    move.l    d0,(a1)+

    cmp.l    a2,a0
    blt    again
    movem.l    (sp)+,d0-d7/a0-a2
    rts
@//E*O*F gen.s//
chmod u=rw,g=rw,o=r gen.s

echo x - life.uue
sed 's/^@//' > "life.uue" <<'@//E*O*F life.uue//'
begin 664 life.prg

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

Date: 4 Jan 88 18:10:14 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU  (Neil Harris)
Subject: Re: Observations
To: info-atari16@score.stanford.edu

In article <1987Dec28.134829.25209@mntgfx.mentor.com>,
 dclemans@mntgfx.mentor.com (Dave Clemans) writes:

> ST World is apparently going fine; in fact they've now split into
> two separate newsletters:
>     ST World    mainly reviews and show reports
>     ST Informer more general articles, rumors, etc.

Not quite right.  ST World and ST Informer are published by different
companies.  They seem to be rivals.

--
--->Neil Harris, Director of Marketing Communications, Atari Corporation
UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil
GEnie: NHARRIS/ WELL: neil / BIX: neilharris / Delphi: NEILHARRIS
CIS: 70007,1135 / Atari BBS 408-745-5308 / Usually the OFFICIAL Atari opinion

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

Date: 4 Jan 88 18:17:34 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU  (Neil Harris)
Subject: Re: 40 folder limit
To: info-atari16@score.stanford.edu

In article <575@pyuxe.UUCP>, crc6@pyuxe.UUCP (C. Colbert) writes:
> See Atari Explorer Spring 87 (Vol 7 no. 2) page 27
>
> "Mike Schmall, Atari system programmer involved in upgrading the ST
> operating system, talked about how the new OS revision will affect Mega
> system performance:... In addition, we've made some changes that
> overcome natural limitaions of the original OS, such as the 40-folder
> limit."
>
> They also mention an upgrade to existing machines, adding blitters and
> new roms.

Sorry.  The blitter ROMs do not have any changes to the 40-folder limit.
The next ROM rev should take care of this, but it won't be done for a while.
The article must have been written before the ROMs were frozen.



--
--->Neil Harris, Director of Marketing Communications, Atari Corporation
UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil
GEnie: NHARRIS/ WELL: neil / BIX: neilharris / Delphi: NEILHARRIS
CIS: 70007,1135 / Atari BBS 408-745-5308 / Usually the OFFICIAL Atari opinion

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

Date: 4 Jan 88 18:27:52 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU  (Neil Harris)
Subject: Re: Multiuser BBS
To: info-atari16@score.stanford.edu

In article <296@stag.UUCP>, trb@stag.UUCP ( Todd Burkey ) writes:
> In article <918@atari.UUCP> neil@atari.UUCP (Neil Harris) writes:

> Several thoughts. First, STadel seems to be a bit more user-friendly
> now than it did 6 months ago. You might want to log into the STadel
> development system sometime and check it out again (612-377-9239).

Will do, but I have logged in to several STadel boards and still haven't
changed my opinion.  Maybe the reason you find them more friendly now is
that you've had 6 months of experience!

> One other thought. Stadel is best used as a message base system. You
> can log on with minimal fuss, quickly find the section you are
> interested in, read what is appropriate, leave a message, and log off
> a lot faster than any other BBS that I have ever used.

OK, I'll buy that part.  But you can't leave messages "TO" a specific person.

> If you could reserve say three of your systems for downloading

Based on the current usage, I'd have to set up 4 for downloading and 1 for
messaging.  But, I am philosophically opposed to that -- I think it would
reduce message traffic.  Some people call mainly to download but also read
the messages.  And messages are my primary reason for having the board.

Hmmm... maybe I should go with STadel... it would cut down the downloaders
:-)

--
--->Neil Harris, Director of Marketing Communications, Atari Corporation
UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil
GEnie: NHARRIS/ WELL: neil / BIX: neilharris / Delphi: NEILHARRIS
CIS: 70007,1135 / Atari BBS 408-745-5308 / Usually the OFFICIAL Atari opinion

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

Date: 4 Jan 88 21:42:51 GMT
From: engst@tcgould.tn.cornell.edu  (Adam C. Engst)
Subject: VCR -> Atari color monitor
To: info-atari16@score.stanford.edu

Having taken a fair amount of flak from several people who seem to think me
stupid because some site truncated my messaged, I will ignore them and ask
again.  Does anyone know of a cable or interface box which allows one to use
an Atari ST color monitor (SM 1224) to display VCR tapes, movies etc?  It
seems that there should be such a beast, and Allan Pratt agreed with me, but
neither of us has yet found one.  Essentially, it would have to allow
composite output to be displayed on an RGB screen, something which should be
possible.  This would allow you to have a VCR, which has a tuner and all
that sort of TV stuff built in, with your computer monitor, which lacks all
the TV stuff but can show a decent picture.  Please send all information to
me and I will summarize to the net.

                                     Thanks   -    Adam













--
Adam C. Engst                                     engst@tcgould.tn.cornell.edu
                                        pv9y@cornella.bitnet
"If it's not interactive fiction, it's not fun."

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

Date: 4 Jan 88 21:09:53 GMT
From: mtune!lzaz!hcj@rutgers.edu  (HC Johnson)
Subject: SH204 disk errors
To: info-atari16@score.stanford.edu

There have been many posting with regard to strange ST behavior
when using the SH204 disk.
After discussing this with Chris at BMS I learned the following:
1. SH204 seems to report 8 drives per controller.  I saw this with
   the BMS driver on my SH204.  Also Magic -Sac describes this.
2. That isn't the problem.
3. SH204 CANNOT report ANY ERROR to the computer.

So why doesn't everyone die on a disk error?  The Adaptec interface
does the retries, and if successful, all is well.  What happens
if the sector is BAD? You read in junk, fail to get the error message,
and see strange things.

BTW, hdx CANNOT mark as bad the blocks in the root directory or the SAMS.
This creates really strange problems when a block changes, as when
adding files and suddenly 5 megabytes dissapper.

I solved my problems 2 ways.
1. I changed hdx to accept a list of bad blocks and let Adaptec remove
   them permanently.
2. I now use a BMS controller.  Highly recommended.

Any one want to buy a slightly used SH204?

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

Date: 5 Jan 88 00:50:00 GMT
From: franco@iuvax.cs.indiana.edu
Subject: Help wanted
To: info-atari16@score.stanford.edu

Over the past few days I have been contacted by someone from Israel requesting
BITNET addresses of Atari users.  I believe the party wants to feel in touch
with the Atari world.  Unfortunately this person cannot access USENET to get
adresses first hand.  Therefore, I am posting this request for any kind hearted
soul to contact BARAK@HUJICC.BITNET and get him out of his misery.

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

Date: 5 Jan 88 09:05:48 GMT
From: orstcs!mist!hakanson@rutgers.edu  (Marion Hakanson)
Subject: UniTerm available for FTP
To: info-atari16@score.stanford.edu

I have made UniTerm v2.0a (currently 006) available for anonymous FTP
on our host cs.orst.edu.  This machine is on the NSFNET, which means
that it's not unusual for it to be unreachable on occasion.  As usual,
please limit access to after working hours.

The files are in the directory pub/atari/uniterm, and you should
probably get "README" first to see exactly which files you want.

And if you like UniTerm, you should send Simon a check.  I hear he's
saving up for an Amiga (I know I'll regret joking about that -- more
likely he's saving for a color monitor)....

Marion Hakanson         Domain: hakanson@cs.orst.edu
                        CSNET : hakanson%cs.orst.edu@relay.cs.net
                        UUCP  : {hp-pcd,tektronix}!orstcs!hakanson

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

Date: 5 Jan 88 05:01:43 GMT
From:
 mnetor!utzoo!utgpu!jarvis.csri.toronto.edu!dgp.toronto.edu!juancho@uunet.uu.net
  (John Buchanan)
Subject: Alcyon (yuck) return codes.
To: info-atari16@score.stanford.edu

    I am trying to use the alcyon compiler.  (I know big mistake)
I heard a while back that some one at atari was developing patches to
ensure that the different passes would return a code other than 0 if
an error occured during that pass.  My question is

    Was this real or another piece of rumorware.

    If the answer to the question is rumorware then send petitions to
the folks at atari for a hurried implementation of the above, if reality
then please send me the patches so that I don't have to sit here with
my hand on the ^C key.

    Thanks.

             *************
                    **********      *****
                         ***  **    ******
                           ****          **
            Line eater about to              **
            be eated by line.               *
            **************                        *
                      *                 ******
                       ******  **********
                         **

--
=====================================================================
| Typical conversation on comp.[atari|amiga|mac].*            |
=====================================================================
My watch is better than yours.  It has multitasking, windows and

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

Date: 4 Jan 88 10:45:22 GMT
From: mcvax!ukc!stl!stc!praxis!gauss!sfr@uunet.uu.net  (Stephen Rickaby)
Subject: Re: Multi-tasking? A nightmare...
To: info-atari16@score.stanford.edu

In article <886@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes:
>In article <11191@oliveb.UUCP> dragon@olivej.olivetti.com (Give me a quarter or
 I'll touch you) writes:
>>
>>I think that these arguments aren't representative of an *average* user,
>>since an average user is more likely not to own a modem.  Making a backup
>

(and many other contributions)

I think that there is an aspect of this argument which seems to have
escaped many contributors: a good multitasking operating system gives the
user *far more* than merely the ability to launch more than one
application at a time.

Principally, the application designer is able to design multitasking
applications which use daemons for part of their functioning, but appear
to the user as single programs, just cleverer. We all use these
facilities in Un*x without thinking about it (cf. elm), but for the
software designer the benefits are cleaner design of complex programs,
and for the user a nicer, cleverer application (spool printing,
concurrent messaging, simultaneous computation and display in complex
graphics applications, etc etc).

The bottom line here is that the *average user*, if there is such a
person, does not have to bother to understand, or even know he is using,
a multitasking opsys to benefit from it.

Steve Rickaby                                     |    ,,,
Praxis Systems plc                                |  < O_O >
20 Manvers Street, Bath, BA1 1PX, UK              | ==( . )==
Tel: +44 225 444700 Tx: 445848 PRAXIS G           |         Prrrouwf, Wackwacka
sfr%praxis.uuc@ukc.ac.uk                          |
!mcvax!ukc!praxis!sfr                             |
-------------------------------------------------------------------------------
'1$x/\{{[^}]*}\}/\{<1\}/q/' ... do it in lower case, it's more polite.

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

End of Info-Atari16 Digest
**************************
-------
Technical Details
Message-ID: <8801131325.AA19713@ucbvax.Berkeley.EDU>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!uwvax!dogie!uwmcsd1!ig!jade!ucbvax!BINGVAXB.BITNET!POSTMASTER

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!uwvax!dogie!uwmcsd1!ig!jade!ucbvax!BINGVAXB.BITNET!POSTMASTER
From: POSTMASTER@BINGVAXB.BITNET
Newsgroups: comp.sys.atari.st
Subject: Returned Network Mail
Message-ID: <8801131325.AA19713@ucbvax.Berkeley.EDU>
Date: 13 Jan 88 13:20:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 581