🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

(none)

#31631
From: University of Calgary Postmaster
Date: Tue, 29 Mar 1988 15:35
370 lines
16457 bytes
Comment: 550  The supplied name was not found in the system mail table.

--------------------RETURNED MAIL FILE--------------------
Received: from UNCAMULT(NETWORK) by CANADA01 (Mailer X1.24) id 3625;
          Mon, 28 Mar 88 10:25:44 EDT
Received: from UNCACDC by UNCAMULT.BITNET with Mailnet id <2753013988537816@UNCA
Received: by CANADA01 (Mailer X1.24) id 9071; Mon, 28 Mar 88 01:44:44 EDT
Date:         Sun, 27 Mar 88 14:42:47 PST
Reply-To:     Info-Atari16@Score.Stanford.edu
Sender:       INFO-ATARI16 Discussion <INFO-A16@CANADA01>
Comments:     Warning -- original Sender: tag was
              Info-Atari16-request@Score.Stanford.EDU
From:         Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU>
Subject:      Info-Atari16 Digest V88 #155
To:           Michael Hoffos <MWHOFFOS@UNCAMULT>

Info-Atari16 Digest   Sunday, March 27, 1988   Volume 88 : Issue 155

This weeks Editor: Bill Westfield

Today's Topics:

                                (none)
                      Re: LEVEE - bug with LVRC=
                          Re: Auto Ram Disk
                          nethack for the st
                   Re: microEmacs 3.7i (emacs.rc?)
                      Re: smalltalk for the st?
                 Re: accessory and RAM resident stuff
                        Re: Atari no-support?
                       Re: Virus--  suggestion!
                          Re: Auto Ram Disk
                        Re: Atari Disk formats
                         Re: Standardization

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

Date: 24 Mar 88 10:51:57 GMT
From: ems!pwcs!stag!daemon@umn-cs.arpa
Subject: (none)
To: info-atari16@score.stanford.edu


  Mark Fischer describes a problem with Mark Johnson C:
 > When I assemble a program that has any input form external
 > sorces I get this error
 > GETC UNDEFINED.
 > I searched the file LIB.C and GETC is used but never defined.
 > All I need is the code that I must add to LIB.C to define GETC.
 > Thanks for your help.
 > Mark Fischer
 > BITNet: mwf8191@tamvenus

  Please look again. getc(s) should be fairly near the top of LIB.C,  right
after gets(s) and getchar(). If it is indeed missing, your whole library is
suspect and should be replaced.
  If you discover getc(s) is defined but STILL have an error message, this may
be the cause:

  getc(s) is defined ABOVE scanf() in LIB.C!

  If you are using scanf() and no other standard input, the  MJC
assembler-linker will gallop right past getc(), ignoring it  because it is
not (yet) needed. Then, after it assembles scanf()  and finds that it NEEDS
getc(), it can't back up and find it.
  Somewhere in your source file, include this statement:

  if (0) getc(stdin); /* kludge: doesn't execute, but fixes the problem */

   The latest note I received from Mark Johnson indicates that  version 2.0
will be available Real Soon Now (with many enhancements,  including floating
point) and will be posted in the usual places.  Mark's address is: Mark A.
Johnson, 5315 Holmes Place, Boulder, CO 80303
 --------------
 Steve Yelvington@Pell (STadel)
     uucp:   ihnp4!meccts!stag!pell!Steve_Yelvington
     Delphi: YELVINGTON

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

Date: 26 Mar 88 02:13:50 GMT
From: mtunx!whuts!homxb!ho7cad!mgh@rutgers.edu
Subject: Re: LEVEE - bug with LVRC=
To: info-atari16@score.stanford.edu

> We are in the process of mailing out new upgrade info to all registered
> users.  The latest Micro C-Shell is 2.72 (new gem, push/popd), and
> MT C-Shell is 1.20.   The mailings are going out in waves (sorry but
> I can't afford a big mailing right now).  Those of you that are in a
> hurry can send me email, and I can US Mail, or UUCP, or email the files.
> The information is also available for downloading from the BDT bbs at
> (415) 452-4792 (login as 'bbs' at the UNIX prompt).
> --
> David Beckemeyer            : "To understand ranch lingo all yuh
> Beckemeyer Development Tools        : have to do is to know in advance what
> 478 Santa Clara Ave, Oakland, CA 94610    : the other feller means an' then
 pay
> UUCP: ...!ihnp4!hoptoad!bdt!david     : no attention to what he says"

David,

I just purchased a copy of AnsiTerm which I believe is version 1.10
and tried to interface it with M T C-Shell also version 1.10. All I
get is either bombs or AnsiTerm with missing mouse pointer, not too
useful I may ask. I sent all my registration cards in for both. I gather
these two versions are not compatiable with one another. My question is
what versions of each program do I need to get them to work together?

                    Matt Hetman

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

Date: 26 Mar 88 16:13:10 GMT
From: braner@tcgould.tn.cornell.edu  (braner)
Subject: Re: Auto Ram Disk
To: info-atari16@score.stanford.edu

[]

If you are using a floppy to boot, you can use my old program AUTODISK
(I posted an upgrade to the semi-dead binaries group many months ago).
It copies THE WHOLE DISK to the RAMdisk.

If you are using a hard disk you want AUTOCOPY, posted a long time ago.
I have an enhanced version somewhere on my disks...
AUTOCOPY copies a list of files as specified in a data file.

Both programs work from the AUTO folder.

- Moshe Braner

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

Date: 26 Mar 88 06:34:08 GMT
From: att-cb!clyde!watmath!watdragon!trillium!cdbenaiah@ucbvax.Berkeley.EDU
(Charles Benaiah)
Subject: nethack for the st
To: info-atari16@score.stanford.edu

Does anyone know where I can find a copy of Nethack for the st?

Sources would be preferable, but executables are fine.

There was a person on rec.games.hack that said he had a copy but for some
reason, he continously delayed the posting date.

Thanks in advance Charles.

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

Date: 26 Mar 88 14:51:10 GMT
From: nwd@j.cc.purdue.edu  (Daniel Lawrence)
Subject: Re: microEmacs 3.7i (emacs.rc?)
To: info-atari16@score.stanford.edu

In article <1072@sbcs.sunysb.edu> lean@sbcs.sunysb.edu (Lean L. Loh) writes:
>
>I have a question about MicroEmacs 3.7i (the one I got from James Turner
>which supports the 50-line mode in monchrome).  Whenever I invoke emacs.ttp,
>the startup file, emacs.rc, is read from the current directory if it exits.
>
>Say I have both emacs.ttp and emacs.rc in directory d:
>If I invoke d:\emacs.ttp from path e:, the startup file emacs.rc is never
>read.  Is there any way to tell MicroEmacs 3.7i to read the startup file
>from a particular directory, like say setting an environment variable or
>invoking emacs.ttp with some -flag option??

    To my knowledge, there are no "built in" environment variables
in GEMDOS.  Under the MWC shell, or Micro-C Shell MicroEMACS can look
down the PATH environment, but invoked from the desktop, it has no such
option. If you still have source, look in the header file EPATH.H and
add the folder you keep your startup file into the list for the atari.
If not, make a /bin folder in the root of the disk you are invoking
emacs from and put the .rc file there.

    Also, what may be of use to you, is upgrading to a more recent
version of MicroEMACS.  Such is available from my BBS system (listed
below) [version 3.9i] and it does support the 50 line mode again (set
$sres to DENSE).

            Daniel Lawrence        (317) 742-5153
            UUCP:    {ihnp4!pur-ee!}j.cc.purdue.edu!nwd
            ARPA:    nwd@j.cc.purdue.edu
            FIDO:    1:201/2 The Programmer's Room (317) 742-5533

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

Date: 25 Mar 88 12:13:53 GMT
From: mcvax!unido!tub!actisb!federico@uunet.uu.net  (Federico Heinz)
Subject: Re: smalltalk for the st?
To: info-atari16@score.stanford.edu

There is a port of SmallTalk-80 for the ST. It looks pretty complete, and
they claim it runs exactly the same image as the SUN version. It's not
cheap (~ DM 2000, that's 1300 Dollars, I think), but it seems to be
worth it if you are serious on ST SmallTalk.


--
        Federico Heinz                      "In Dubio Pro Libido"
BIX:  fheinz                : Beusselstr. 21
UUCP: ...!unido!tub!actisb!federico    : 1000 Berlin 21
Tel:  (030) 396 77 92            : F.R. Germany.

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

Date: 26 Mar 88 03:30:32 GMT
From: portal!cup.portal.com!Thomas_E_Zerucha@uunet.uu.net
Subject: Re: accessory and RAM resident stuff
To: info-atari16@score.stanford.edu

>You have to take over the screen...
But you have to save the Menu Bar image yourself - that is NOT redrawn with
any GEM AES call that I have found.  In my Emulator revision (Transfer 1.27)
I had to do that (copy from the screen to a buffer, clear and use the screen,
then redraw the menubar and issue the form_???? call to redraw everything
else).

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

Date: 25 Mar 88 18:17:20 GMT
From: portal!atari!good@uunet.uu.net  (Roy Good)
Subject: Re: Atari no-support?
To: info-atari16@score.stanford.edu

In article <54@avsd.UUCP>, govett@avsd.UUCP (David Govett) writes:
>
> At the Hannover Fair last week, one of the Flying Tramiel Brothers said
> that, since iratA gets 60% of its (16-bit ?) revenues from Deutschland,
> the US market would suck hind tit, not to put too fine a point on it.
>
> The grafitti is on the wall.  Time to dump the boat anchor while you
> can still get a decent price for it.  Don't count on Two-Tongue Jack
> to ever support the ST in the US.  All he'll ever provide is crumbs to
> keep the peasants quiet.

I was at Hannover last week, and would contest the above most strongly.
Jack Tramiel's public statement at the Press Conference was almost
entirely in regard to DRAM issues. And he made a very strong point,
which received immediate applause, that "Atari will not increase prices
on account of the inflated DRAM costs. If that means we only make $55M
this year instead of $57M, so be it." I paraphrase considerably, but
nonetheless his message was clear. In addition we are making several
moves within Atari Sunnyvale to improve support for developers, as anyone
who has been following my postings should be able to discern. The effects
of these moves will be seen in the next few months. And we are certainly
not talking about dropping the ST/Mega, or even letting it stagnate. There
is ongoing development effort in several areas.

My personal opinion is that Mr. Govett is way out-of-line in his
interpretation of Mr. ?. Tramiel's remarks (where "?" can only be
Sam or Jack, as the other two were not in Hannover). Maybe he would be
so kind as to state the exact words used, and the originator, as I don't
recall any Atari executive using the words quoted.
-----------------------------------------------------------------------------
Roy J. Good
Product Development, Atari Corporation

Views expressed are my own. Atari may agree or disagree; they have the right.

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

Date: 25 Mar 88 18:55:28 GMT
From: mcvax!ukc!dcl-cs!bath63!pes@uunet.uu.net  (Smee)
Subject: Re: Virus--  suggestion!
To: info-atari16@score.stanford.edu

In article <1288@uop.edu> exodus@uop.edu (EXODUS) writes:
>
>What if someone wrote a 'friendly' virus.  One that fixed the bugs in the
>Operating System.  One that multiplied so everyone's bugs were fixed.

No, no, a million times no.  There is NO SUCH THING as a 'friendly' virus.
Consider the original Amiga virus.  It wasn't meant to have any ill effects.
It was meant simply to sit around for a while, and then to pop up and say
(basically) 'hey look, guys, I'm a clever person who wrote a virus.'  And,
indeed, that's all it does.

EXCEPT that if it finds a write-enabled disk, and installs itself, and the
disk happens to be a (probably expensive) copy-protected program, even that
is deadly.  UK dealers alone have lost thousands of pounds worth of stock
to friendly viruses -- and the UK is hardly the world's biggest micro
market.

The other problem is that it would (unavoidably) interact (at best) or
interfere (at worst) with programs which attach themselves into the system
vector chains for specific known purposes -- and there are a lot of handy
programs which do that.

Even if you could avoid *that* (which I doubt) any resident program is going
to screw up someone's (probably my) very delicate space-allocation juggling
act.  I've got ramdisks, spoolers, and ACCs very delicately balanced on the
various disks I might boot from, to leave just enough room for the major
application I might run in that environment.  A few odd K sucked up for
something else would probably break many of my operating environments, and
then I'd have to go thru finding and de-virusing at least the critical
disks -- no matter HOW friendly the virus was.

I could get into the idea IF it could be demonstrably shown that the losses
would be small, and the gains large -- but I don't believe you could show
that (or guarantee it had been done right).

If you want to write a bug-fixer which an owner can install at will on
disks of his or her own choice, and which you believe will provide fixes
for all the bugs, fine.  But you've got no business running programs on
other people's machines without them being aware you are doing it.  Period.
And that's what your suggestion amounts to.

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

Date: 26 Mar 88 14:33:42 GMT
From: att-cb!clyde!watmath!watmsg!achowe@ucbvax.Berkeley.EDU  (CrackerJack)
Subject: Re: Auto Ram Disk
To: info-atari16@score.stanford.edu

>Does anyone out there know of a program that allows you to boot
>up your system with a ram disk installed complete with files in it?
>
>I am currently using Rdy-disk Ram from MWC.  I would like to be able
>to turn on the power to my system and when my prompt appears I already
>have my ram disk installed with the compiler, editor, etc.
>
>Is there such a program.  It would be a real handy thing to have!

There was a RAM Disk program that had this feature in COMPUTE!'s
Atari ST June '87, Issue 5 Vol2 #3. BUT it DON'T work with Megas.

However Megamatic does and has some nice features. In order to do
the copying into the RAM disk, use BDT csh.tos or startgem the gemcsh
using a login.sh that creates directories, copies, executes a few
programs and logs out. I do this on my WordPerfect disk. Set up
a 1M RAM disk and use csh to copy to WP files to the D:. I then execute
WP with startgem.

--
Anthony C. Howe                         achowe@watmsg.waterloo.edu

"The definition of flying: throwing yourself at the ground and missing."
        - Douglas Adam's  "Life, the Universe and Everything"

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

Date: 26 Mar 88 19:21:25 GMT
From: nuchat!uhnix1!uhnix2!uace0@uunet.uu.net  (Michael B. Vederman)
Subject: Re: Atari Disk formats
To: info-atari16@score.stanford.edu

In article <8803210013.AA22627@icase.arpa> csrobe@ICASE.ARPA (Charles S.
 Roberson) writes:
>I would like some help sorting out the available disk formats.  I've used
>intelligent copy (I only have one disk drive while my HD is being repaired,
>again :-( )).   The most significant thing about DCformat is that it allows
>you to format 82 tracks per disk.  I also remember some people saying that
>certain drives won't let the r/w head go that far -- I think mine is one.
>Would some kind soul take the time to explain DCformat (especially when
>are the options (sectors per track, tracks, side, etc) active).  If I
>am doing a disk copy, do these options have any effect?
etc....
>+-------------------------------------------------------------------------+
>:Chip Roberson                ARPANET:  csrobe@icase.arpa                 :

In fact, none of the disk options (except MAGIC) have any effect during
the disk copy portion of DC Formatter.

You can usually hear your disk head go 'CLUNK' when you reach the last track
of a disk drive that does not allow 82 tracks.

line eater
line eater
Technical Details
Message-ID: <880329083525.0000093A.BINU.D2@UNCACDC>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!rutgers!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!UNCACDC.BITNET!Postmas

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!rutgers!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!UNCACDC.BITNET!Postmas
From: Postmas@UNCACDC.BITNET (University of Calgary Postmaster)
Newsgroups: comp.sys.atari.st
Subject: (none)
Message-ID: <880329083525.0000093A.BINU.D2@UNCACDC>
Date: 29 Mar 88 15:35:25 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 370