Path: 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 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 Comments: Warning -- original Sender: tag was Info-Atari16-request@Score.Stanford.EDU From: Info-Atari16 Digest Subject: Info-Atari16 Digest V88 #155 To: Michael Hoffos 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