Mailer@ECLA.USC.EDU.UUCP (05/16/87)
Message undelivered after 1 day -- will try for another 2 days: *PS:<BBOARD>INFO-ATARI.TXT@GUMBY.#DECnet: Cannot connect to host ------------ Received: from SCORE.STANFORD.EDU by ECLA.USC.EDU; Thu 14 May 87 23:22:26-PDT Date: Thu 14 May 87 22:05:42 PDT Subject: Info-Atari16 Digest V87 #214 From: Info-Atari16 Digest <Info-Atari16@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 -------
Mailer@ECLA.USC.EDU (The Mailer Daemon) (05/17/87)
Message undelivered after 2 days -- will try for another 1 day: *PS:<BBOARD>INFO-ATARI.TXT@GUMBY.#DECnet: Cannot connect to host ------------ Received: from SCORE.STANFORD.EDU by ECLA.USC.EDU; Thu 14 May 87 23:22:26-PDT Date: Thu 14 May 87 22:05:42 PDT Subject: Info-Atari16 Digest V87 #214 From: Info-Atari16 Digest <Info-Atari16@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 -------
Mailer@ECLA.USC.EDU (The Mailer Daemon) (05/18/87)
Message undeliverable and dequeued after 3 days:
*PS:<BBOARD>INFO-ATARI.TXT@GUMBY.#DECnet: Cannot connect to host
------------
Received: from SCORE.STANFORD.EDU by ECLA.USC.EDU; Thu 14 May 87 23:22:26-PDT
Date: Thu 14 May 87 22:05:42 PDT
Subject: Info-Atari16 Digest V87 #214
From: Info-Atari16 Digest <Info-Atari16@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 Thursday, May 14, 1987 Volume 87 : Issue 214
This weeks Editor: Bill Westfield
Today's Topics:
Re: Better Windows? (LONG)
Re: Mark Williams ver 2.0 info
Re: Bug report: 'The Russian Doll' sp. nova (?)
Citadel<->UUCP
Re: os bug..also hdscan 1.3/2.3
Auto-baud UNITERM Problem
Fsfirst, Fsnext Bug??
Re: Interactive fiction
Free RAM locations, anywhere?
Re: Mark Williams C 2.0 benchmark
Hard Disks and 40 Folder Limit
Re: ...GEMBOOT... (really usage of shell_p)
----------------------------------------------------------------------
Date: 13 May 87 03:37:57 GMT
From: mnetor!utgpu!pete@seismo.css.gov (Peter Santangeli)
Subject: Re: Better Windows? (LONG)
To: info-atari16@score.stanford.edu
Hi Yall,
On the subject of Window recursion, the one part of most windowing systems
I find counter -intuitive is the difference between the desktop and a window.
Wouldn't it make more sence to allow WINDOWS to have there own menu systems?
These could be modal (only the active windows menus available) or semi-modal
(active and desktop available). This kind of scheme would make multitasking
much more intuitive.
Now if someone could come up with a graphic rendition of Pipes and
I/O routing, we'd be laughing...
Pete
------------------------------
Date: 12 May 87 15:34:34 GMT
From: tektronix!sequent!mntgfx!dclemans@ucbvax.Berkeley.EDU (Dave Clemans)
Subject: Re: Mark Williams ver 2.0 info
To: info-atari16@score.stanford.edu
Another Mark Williams C 2.0 bug;
there is as least one case where the compiler will, in an expression
that has generated a 16-bit signed temporary result and that temporary result
needs to be extended to 32 bits (again signed), generate the incorrect
code to do the sign extension. Instead of the correct "ext.l" instruction,
it generates "ext.w", which clobbers the top byte of the 16 bit temporary
result. Assuming that their assembler is written in C, the previously
reported bug in the assembler might even be caused by this.
dgc
------------------------------
Date: 12 May 87 15:51:59 GMT
From: tektronix!sequent!mntgfx!dclemans@ucbvax.Berkeley.EDU (Dave Clemans)
Subject: Re: Bug report: 'The Russian Doll' sp. nova (?)
To: info-atari16@score.stanford.edu
There is a bug in the floppy driver in the current TOS ROM's that can
very easily cause symptoms like those described in the article that
this message references.
Basically, the problem is that while the WD1772 floppy controller does
have a built-in read multiple sectors command, that command is somewhat
brain damaged; the only official way to terminate the read is to reset
the controller (and taking any time hit that that reset causes).
However, if you look at the floppy disk driver code you find that the
driver is using the "read multiple sectors" command of the 1772 for
all (all that I've found so far at least) floppy reads. And under
"normal" circumstances the driver tries to never reset the controller;
i.e. it puts the read length into the DMA controller, and depends on
the floppy controller timing out because the DMA controller stops
talking to it.
This works "most" of the time... But if your really trying to push
data through the system "fast" you have a non-zero chance of seeing
a timing problem pop up.
This problem does not affect floppy writes; only floppy reads. The
best way to work around it, and still use "fast" formats, is to write
the disk in whatever way you desire, but NEVER try to read more than
one sector at a time (or to start out reading multiple sectors, but
switch to single sectors if an error appears). An example of this
is the "slowread" routine in the twister restore code.
Unfortunately you don't always have control over the sizes of read
requests made by various packages...
dgc
------------------------------
Date: 13 May 87 05:18:30 GMT
From: dayton!meccts!zeke!stag!trb@RUTGERS.EDU ( Todd Burkey )
Subject: Citadel<->UUCP
To: info-atari16@score.stanford.edu
Lately, several local programmers have been staying indoors on incredibly
nice days (anything about 40 degrees is nice in Minnesota if the sun is out),
and developing a networking capability on a PD ST BBS called Citadel. Citadel
is a message base oriented bbs with a so-so file ul/dl capability. Recently,
(i.e. this weekend), two way mail was set up between citadel and my unix box
primarily through the efforts of Dale Schumacher's extensive hacking apart and
eventual rewriting of the uuslave/uucp stuff that came over the ST and PC
sections of usenet. If you want to get more info on citadels local networking
features (i.e. between ST citadels), give the development board a call at
612-377-9239. If you want more info on the citadel/uucp link, I am sure dale
would appreciate mail (in fact it will probably surprise the hell out of him)
at ...ihnp4!meccts!zeke!stag!syntel!dal Note that syntel is a citadel node
running on a ST (not sure if he has his hard disk attached yet...citadel can
run quite successfully on a 520ST and one drive.) Please don't send me mail
asking about uucp protocols...I plan on trying very hard to forget all I had
to learn looking at the stupid -x9 reports...
-Todd Burkey
...ihnp4!meccts!zeke!stag!trb
------------------------------
Date: 13 May 87 05:00:55 GMT
From: dayton!meccts!zeke!stag!trb@RUTGERS.EDU ( Todd Burkey )
Subject: Re: os bug..also hdscan 1.3/2.3
To: info-atari16@score.stanford.edu
Well, I sat down this weekend and added the following features to hdscan
1.3 (shareware) and 2.3 (professional):
1) Pressing S (as opposed to s) will allow subsearches of a currently
selected set of files (i.e. you can select all the .c files on drive
E for example). Oh yeah, you can do searches by extension as well.
Plus you can specify selection of all tagged files.
2) Enhanced sort option.
3) Mass copy now supports options to allow multi-disk copy to floppies,
copying a file and retaining its date and attributes, etc.
4) R option now allows file rename and/or attribute changing (i.e. it
is now simple to make files read only, hidden, system, etc).
And there were some other things that were cleaned up. The problem of
reading from a 'changed' floppy still remains, but I got fed up with all
the other little nuances I had to learn this weekend getting the above stuff
to work to spend much time on it. I tried fopens, Fopens, opens, etc. to no
avail and I really don't care to go in and figure out how to vector a
'desktop' ESC or whatever it takes to get GEM to recognize the floppies!
Speaking of nuances, I spent several hours just getting Fdatime to work. Make
a note that doing a Fcreate, then setting the files time with Fdatime, and
then Fclosing the file will not work. You have to Fcreate, write out your
whatever to the file, Fclose the file, Fopen the file, Fdatime it, and then
Fclose it again. That is a lot of F'ing around...:) I also found out how to
create totally unerasable directories that are hidden, unaccesible from the
desktop, and read-only to boot. Apparently it is not a good idea to do a
Fattrib (reading the attributes) right after an Frename...the result has
all of it's bits set. Has any of you ST guru types out there put together
a list of these kinds of quirks? I have the pertinent sections of the developer
kit, the Mark Williams C 2.0 manual (the compleate ST manual as far as I am
concerned), the ST Tacklebox (ditto if you are a Pascal enthusiast), and
a variety of 'reference' books from abacus, but nowhere could I find anything
that could have prevented the 20 or so compiles I went through...
-Todd Burkey
...ihnp4!meccts!stag!trb or ..ihnp4!meccts!zeke!stag!trb
p.s. To those of you who sent in for the professional version, now you know
why I was a tad bit slow getting it out...I hate the idea of old, dated
software out there...soon. Also, since 1.22 never made it past turners'
queue I will either mail 1.30 out directly if you want it or post it
if I get sufficient interest. Let me know.
------------------------------
From: David Maden <maden%rzsin.sin.chunet@RELAY.CS.NET>
To: Digest <Info-Atari16@SCORE.STANFORD.EDU>
Subject: Auto-baud UNITERM Problem
Return-Receipt-To: David Maden <maden@rzsin.sin.chunet>
In Digest #207, Nik Zapantis reports problems with UNITERM connected to
an autobauding port on a VAX.
I have seen this problem too. As I understand it, UNITERM sends some preliminary
characters (probably XON or XOFF) down the RS232 line and this confuses the
VAX's autobaud algorithm. The VAX is expecting <Return> characters and, if it
sees something else, it tries to be clever in deducing what the baud rate
actually is based on what it has seen. The algorithm it uses obviously breaks
down if characters other than <Return> are sent.
My solution is to not touch the keyboard for 15 seconds or so - difficult
for a hacker, I know, but sometimes effective. The VAX sign-on sequence then
times out and the autobaud then resets itself. Now you type <Return> a few
times and the VAX gets the correct baud rate in the end.
I hope this helps. It's not ideal, I know, but it's better than turning off
auto-bauding (at least in our environment).
David Maden,
Swiss Institute for Nuclear Research, 5234 Villigen
------------------------------
Date: 11 May 87 23:11:11 GMT
From: oliveb!pyramid!prls!philabs!tg!dasys1!stevef@ames.arpa (Steve A. Feinstein)
Subject: Fsfirst, Fsnext Bug??
To: info-atari16@score.stanford.edu
Does anyone know of any bugs in the use of Fsfirst, Fsnext while using
Megamax,
When I use;
Fsfirst("c:*.*, 0);
it works fine, but when I add a path name;
Fsfirst(c:\auto\*.*, 0);
All I get is nothing returned. Does anyone have any ideas ?? Has
anyone encountered this?? Am I doing something wrong??
--
Steve Feinstein {allegra,philabs,cmcl2}!phri\
{bellcore,harpo,cmcl2}!cucard!dasys1!stevef
New York, NY, USA {philabs}!tg/
------------------------------
Date: 13 May 87 09:17:16 GMT
From: tybalt.caltech.edu!wetter@csvax.caltech.edu (Pierce T. Wetter)
Subject: Re: Interactive fiction
To: info-atari16@score.stanford.edu
>
> In the last issue of BYTE magazine a LISP-like interactive
>fiction authoring system was described. The listing is in C and is
>available on BIX. Anyone with a BIX account like to download it and
>post it to some newsgroup that we all have access to? I for one wouldn't
The program you are referring to is called ADVSYS, and there is a mac version
on Sumex-aim.stanford.edu under directory info-mac.
Pierce
Wetter
California, n.:
From Latin "calor", meaning "heat" (as in English "calorie" or
Spanish "caliente"); and "fornia'" for "sexual intercourse" or
"fornication." Hence: Tierra de California, "the land of hot sex."
-- Ed Moran
--------------------------------------------
wetter@tybalt.caltech.edu
------------------------------
Date: 13 May 87 04:02:11 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: Free RAM locations, anywhere?
To: info-atari16@score.stanford.edu
[]
This may be naive (or heretical) but is there any area in the ST RAM space
that is "unused" and could be used for temporary communication between
utilities, etc? I know that you can Ptermres() and so on, and that you
should not put utilities into "free" areas (like $300 on the good ol' Apple II)
since the moment you overlay _two_ utilities you're in trouble. But it
would still be handy to have a few bytes at a known absolute location for
end-user use... Are there? (Yeah, I know, there are "environment variables"
-can somebody explain those? Is there any real standard on how they are
used?)
- Moshe Braner
------------------------------
Date: 13 May 87 04:30:30 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: Re: Mark Williams C 2.0 benchmark
To: info-atari16@score.stanford.edu
[]
OK, I finally sat down and timed Megamax compiling a large program.
System: 1040STf (1 meg, internal floppy drive unused), 576K RAMdisk
(_everything_ done there), Megamax v1.1, micro-C-Shell.
Program: 22K (1000 lines, _not_ heavily commented) C source plus some
#include files, 3 external precompiled (.o) modules. Final (executable)
program size 45K. Program mostly does FP calcs.
Timings (in seconds):
6 Enter microEMACS, read source, write source
20 compile
35 link
---
61 total
Compare with about 220 for MWC compiling a smaller program, as posted.
Megamax v2.0 (promised "soon") will supposedly have a faster linker.
- Moshe Braner
Disclaimer: I have no affiliation with Megamax except as a customer.
There are many infuriating bugs in the Megamax C Language system, v1.1
(some of which I posted) - as there are in all the other systems...
The current Megamax FP lib is _terrible_!
------------------------------
Date: Wed, 13 May 87 12:50:01 EDT
From: Flash%UMASS.BITNET@wiscvm.wisc.edu
Subject: Hard Disks and 40 Folder Limit
To: Info-Atari16@Score.Stanford.EDU
In responce to the Amiga owner who keeps asking what happens if we boot
off a disk without a 40 folder fix.
I have, since I bought my hard disk, booted off the hard disk. This is
trivial, and for faster booting, I have been known to UNPLUG my disk
drive, and use my ST as a hard_disk based system. In the AUTO folder of
my hard disk, you will find GEMBOOT.PRG in there, which makes sure I
do not run into any problems. So, NONE of my disks have any fix or
booter on them. All is hard disk based.
Ok, so you ask, what do I do if I want to boot off floppy for one of those
copy-protected programs that auto-boot? Simple, I just hold down the
CONTROL-SHIFT-ALTERNATE trio during booting, and the harddisk booter
will recognize what I want, and not install the hard disk, and let the
system boot off the floppy. Viola. Since the hard disk is NOT installed,
there is no way any floppy program can get to the hard disk, and there
is no 40 folder limit problem to bother of.
In other words, since the GEMBOOT program is RIGHT on the auto folder of the
hard disk, there is NO way I can by-pass it when booting.
System Used:
520ST+
Supra 20 Meg Hard Disk
Version 2.61 of hard disk software
GEMBOOT version 1.06
Rick Flashman
1040 N. Pleasant Street, #381, Amherst, MA 01002. (413) 549-0173
Flash@UMASS.BITNET -or- Flash%UMASS.BITNET@WISCVM.WISC.EDU
R-FLASHMAN on GEnie
P.s. I had this Amiga, you know. After buying it, and realizing that
there was no software, I decided. "So what? I can just write a terminal
program in BASIC and use it as a terminal until some comes out." After
severe frustration, I was informed by Commodore.."We forgot to include the
RS-232 support in this version of BASIC, it will be implemented in the
next version." Oh of course, how silly me.
------------------------------
Date: Wed, 13 May 87 16:37:41 EDT
From: Michael Fischer <fischer-michael@YALE.ARPA>
Subject: Re: ...GEMBOOT... (really usage of shell_p)
To: info-atari16@score.stanford.edu
Allan Pratt reports:
> I have investigated the alleged use of _shell_p by the AES and
> the Mark Williams shell, and I can't see that either of them uses this
> variable.
It's not surprising that none of these programs access location
0x4f6. However, they obviously do use the string that is pointed
to by that location. There are probably other pointers to it floating
around as well. I think the Mark Williams shell receives this string
as its environment string when it is invoked, so it presumably
accesses it through its basepage. To find out how the basepage
gets set and why, you'll have to look at the DESKTOP and/or the
code for Pexec. Perhaps the DESKTOP passes the value of _shell_p
to Pexec when you double click on a .PRG file. Or perhaps the desktop
supplies a 0 to Pexec, and Pexec simply passes on the DESKTOP's
own environment string, which it in turn probably gets from GEMBOOT.
Hope this helps.
--Mike Fischer
Arpanet: <fischer@yale.arpa>
UUCP: <imagen!yale!fischer>
Bitnet: <fischer@yalecs>
------------------------------
Date: Wed, 13 May 87 16:45:16 EDT
From: USEREK5X%mts.rpi.edu%itsgw@CSV.RPI.EDU
To: info-atari16@score.stanford.edu
signoff
------------------------------
End of Info-Atari16 Digest
**************************
-------
-------engst@batcomputer.tn.cornell.edu (Adam C. Engst) (05/18/87)
Would someone please shoot the MAILER-DAEMON that keeps posting junk mail? It's getting tiring and must be wasting a lot of net money.