COMSAT@MC.LCS.MIT.EDU (Communications Satellite) (10/22/87)
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; 21 OCT 87 22:22:33 EDT
Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU with Chaos/SMTP; Wed 21 Oct 87 22:21:42-EDT
Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 21 Oct 87 22:21:00-EDT
Date: Wed 21 Oct 87 16:28:18 PDT
Subject: Info-Atari16 Digest V87 #378
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 Wednesday, October 21, 1987 Volume 87 : Issue 378
This weeks Editor: Bill Westfield
Today's Topics:
Re: Terminal emulation on ST (questions)
Re: What's wrong with OSS?
More on PPascal
Re: Prolog Search
Re: Weighty instructions
Two books
Re: GEM WINDOWS
Re: Q. Two HD20 on 1040ST?
Recursive directory!?
BITNET mail follows
----------------------------------------------------------------------
Date: 18 Oct 87 15:53:19 GMT
From: rosevax!ems!nis!stag!trb@uunet.uu.net ( Todd Burkey )
Subject: Re: Terminal emulation on ST (questions)
To: info-atari16@score.stanford.edu
In article <319@uthelios.toronto.edu> fieldus@uthelios.UUCP (Mike Fieldus)
writes (about using Atari ST's as terminals:
> 1. the relative merit of this idea
I personally think the ST makes a great terminal when hooked up to
either a VAX or an Apollo. You get an incredibly large 'buffer', local
editting when the host gets slow (or is down), and you can do your
local compiling of test routines on the ST faster than on the Apollo
(esp if your Apollo's are on a LARGE ring). Another nice feature is
that the ST has almost an exact mapping of keys to that of a vt102, so
you don't screw around with trying to remember that the GOLD key is
Shift F1 (as you do on the PC)...
> 2. the possible (best?) emulator programs
Depends on speed. I like PC/Intercom when connected at 9600 or 19200
because it allows immediate pause (via the insert key<->scroll lock)
without screwing up the flow control. If you want more features, then
FLASH is nice (although PC/Intercomm's KERMIT seems safer and
cleaner). The feature of FLASH I use occasionaly is the editable
capture buffer, but FLASH is generally better for telecommunicating
than direct connect...(remember, personal opinion only...no flames).
Then there are a LOT of PD programs that you can try out...Simon's I
am sure you are familiar with.
> 3. how one can read IBM PC disks on the atari.
If the PC disks are 3.5 inch then just stick them in and you are all
set (I move stuff back and forth between my Kaypro 2000 and the ST all
the time). If you have 5 1/4 inch and really, really want to read them
on the ST, you can buy a 5 1/4 inch drive for the ST for an incredible
amount of money (about $200) or you can add a 3.5 inch drive on your
PC for about $130 or so (much preferable).
-Todd Burkey
trb@stag.UUCP
------------------------------
Date: 19 Oct 87 20:17:20 GMT
From: cunyvm!ndsuvm1.bitnet!ud140469%psuvm.bitnet@ucbvax.Berkeley.EDU
Subject: Re: What's wrong with OSS?
To: info-atari16@score.stanford.edu
billed-now, pay latter. That they warned cardholders ahead of time worries me
even more than if they hadn't--it's been my experience that companies that need
your money (cashwise, from the credit card) before they are able to supply the
product are either on shakey financial footing or might be up to no good....
As for manuals, it's true that they could just have picked an overly busy
printing company to do the job.... My biggest complaint still stands--the
handing out of mis-information about individual shipping dates (dare I say
lies?). I did call OSS and "confront" them about the problem (I didn't mention
credit cards or late manuals)--boy, did I feel like a heel even though I think
it is a legitimate complaint. The fellow I was talking to got real quiet (if
I was him, I'd probably have been mad, but since it's a customer on the phone,
you can't really gripe back)... He didn't give me any specific answer other
than saying he'd pass it (my complaint) to the others....
Scott Udell
UD140469@NDSUVM1.BITNET
(PPascal is still my favorite language on the ST, and OSS is still one of my
favorite software companies--I just don't want them degenerating into something
else...)
x
------------------------------
Date: 18 Oct 87 01:14:28 GMT
From: cunyvm!ndsuvm1.bitnet!ud140469%psuvm.bitnet@ucbvax.Berkeley.EDU
Subject: More on PPascal
To: info-atari16@score.stanford.edu
and have run across some interesting new goodies. It seems that the new items
are usually towards the end of a chapter, but sometimes they are mixed in with
the old stuff (and they've changed the placement/layout quite a bit), so you're
going to have to read the whole book (or scan it carefully) to get all the new
stuff out of it... Some of the new functions/procedures/features include:
*some of the VT-52 functions have been given names (like GotoXY, etc.)
*two formatted string conversion procedures (now we can finally Draw_String
integers without having to use our own conversion code!)
*machine access subprograms, including commands to put you in supervisor
mode, peeks & pokes, memory move procedures, address functions, etc.
*C-to-Pascal-and-back string conversions (really nice for working w/ OS
calls)
*procedures to save and restore screens into buffers, and to/from disk
(using the D.E.G.A.S format)--these should be really helpful
*a more detailed description of using 'generic calls' (including port
configuration, i/o, etc.)
*instructions on how to use PPascal with a CLI (things to pass the various
programs, etc)
*talk on modular compilation and desk accesories
*an index!
*notes and cautions index
*an ad for Tackle Box through OSS ($69.95+$5.00 shipping).
This is just stuff I've found paging through the manual--when I actually READ
the thing (probably XMas break!), I will probably find more. I still haven't
tested it for speed (and my system will make-or-break it: I have nearly the
minimum system (thank goodness one of my drives is DS)).
Scott Udell
UD140469@NDSUVM1.BITNET
P.S. For the gentleman out there (I've even forgotten your name!), as soon
as I dig your message out of a 300k download file, I'll try to answer
your technical questions!
x
------------------------------
Date: 19 Oct 87 12:35:47 GMT
From: mnetor!charles@uunet.uu.net (Charles Benaiah)
Subject: Re: Prolog Search
To: info-atari16@score.stanford.edu
>Now, public question #357-B: Are there currently any shell-style programs
>that allow multi-tasking? I vaguely remember hearing about such a thing,
>but never saw one.
>
>And #357-C: Has anybody heard whether PC-Ditto will ever
>run on monochrome?
I was speaking with a couple of Atari reps on Saturday, and they told me
(unoffically) that there will be a third party Multi-tasking shell on
display at COMDEX in November.
Also, PC-DITTO has been completed and partially tested in mono, and should
be released within 6 weeks.
------------------------------
Date: 20 Oct 87 10:06:50 GMT
From: mcvax!steven@uunet.uu.net (Steven Pemberton)
Subject: Re: Weighty instructions
To: info-atari16@score.stanford.edu
In article <557@rover.UUCP> mph@rover.UUCP (Mark Huth) writes:
> It seems to me that if one programs in C, then the C compiler is part
> of the environment. The fact that the compiler distorts the raw
> machine power to some extent is true, but unless you are an assembly
> guru [...] you cannot generate code to fully utilize a giver
> archetecture'r power. Therefore, the high-level language benchmarks
> are very useful.
>
> We are able to improve the Dhrystone ratings of our systems by as much
> as 33% by improving the compiler. This is real good news, as all
> programs get some considerable performance gain by recompilation as
> better compilers become available.
Well, this is exactly what I meant. The problem with a MIPS rating is
that you know little about what sort of instructions are involved. At
least a Dhrystone rating gives you an objective number, but it is
still not a completely good indication of pure machine power because
the compiler distorts the figure (although it does at least give a
lower bound). Just look at the figures for different C compilers on
different makes of 8 MHz 68000: they run from 330 to 1370! The fact
that you could tune your compiler to give 33% better performance only
goes to show that the Dhrystone figure is only loosely related to the
machine performance.
Steven Pemberton, CWI, Amsterdam; steven@cwi.nl
------------------------------
Date: 18 Oct 87 00:59:38 GMT
From: cunyvm!ndsuvm1.bitnet!ud140469%psuvm.bitnet@ucbvax.Berkeley.EDU
Subject: Two books
To: info-atari16@score.stanford.edu
the net, so I thought I bring them up. The first is Compute!'s Technical
Reference Guide, Atari ST Volume One: VDI. As one might expect, it's all
about the VDI. I realize this one's been out a while, but I still haven't
seen any mention of it. I've read through it, and it seems fairly complete,
but since I haven't yet tried to do much with VDI I don't know... The first
half of the book leads you through VDI, showing you examples on the way. The
second half is a reference on all the VDI functions (each entry gets a page in
the book). There are several appendices, including three indices (indexes?).
Example programs are in BASIC, assembly, and (mostly) C. It lists for $18.95.
The second book just, as far as I know, came out. It's called Atari ST
Application Programming, from Bantam Computer Books. It covers a whole bunch
of stuff, including sound, graphics techniques, AES/VDI, windows, etc. It has
a "C function reference guide" which looks to contain most of the calls (in
alphabetical order). There isn't any in depth discussion of BIOS/XBIOS/GEMDOS
as far as I've found (although the individual calls are discussed in the ref.
guide). Sample programs appear to be all in C. Again there are several nice
appendices and a complete index. The book is 530 pages long (the Compute!
book is 343 pages long).
Anyone else see any new books? Frankly, I was shocked to see B. Dalton's/
Waldens carrying these books, especially in North Dakota (of course, they seem
to get in two copies of each and that's it).
Scott Udell
UD140469@NDSUVM1.BITNET
(Path? Path you ask? Ich habe
keine Ahnung...)--sorry for the
bad German, I couldn't resist...
------------------------------
Date: 19 Oct 87 15:49:17 GMT
From: tektronix!sequent!mntgfx!dclemans@ucbvax.Berkeley.EDU (Dave Clemans)
Subject: Re: GEM WINDOWS
To: info-atari16@score.stanford.edu
As I understand it, GEM doesn't really have the concept of a window being active or
not being active for input. Instead you just have the currently active "process"
which should be sitting in an event wait system call waiting for, among other things,
input messages. That "process" can then apply the events to any window that it wants.
If a "process" wants to have output going to multiple windows "simultaneously", that's
up to the "process".
The only complication here are desk accessory "processes". While they can try to also
wait for input events in addition to the foreground "process", from the experiments
I've run it doesn't seem to be deterministic as to which process will get the input.
So desk accessory "processes" normally just wait for activation events, and when they
are activated and in control of system resources they then can wait for input.
I use the term "process" above because GEM is a limited multi-tasking system. It
(on the Atari ST) supports one foreground process, and up to six background processes.
The foreground process is the desktop, or a program run from the desktop. The
background processes are desk accessories. Process switching only occurs when a
process voluntarily waits; i.e. there is NO preemptive scheduler.
Note that this "multi-tasking" is implemented only in the GEM AES module. This is
why desk accessories are not available from a non-GEM program; a non-GEM program
never enters GEM AES, thus it never does an AES event wait; thus AES never gets a
chance to schedule a desk accessory (background) process.
dgc
------------------------------
Date: 19 Oct 87 18:21:18 GMT
From: tektronix!sequent!mntgfx!dclemans@ucbvax.Berkeley.EDU (Dave Clemans)
Subject: Re: Q. Two HD20 on 1040ST?
To: info-atari16@score.stanford.edu
About multiple hard disks on a single ST:
There are two basic ways to go (assuming you are starting from SH204's).
"alternative a"
If the SH204's are old enough so that you are starting from 5 1/4" drives
with separate SCSI adapters (for example the first production run of SH204's
used ST-225 drives and Adaptec 4000 SCSI adapters), you could just use the
second port on the Adaptec card. Just get a case big enough to hold both
drives with appropriate power (for example an IBM PC clone case with a
135 watt or 150 watt power supply). Then using your new drive (say another
ST-225) and the parts from the original SH-204 (another ST-225, Adaptec
card, Atari interface card) and the necessary cables, just mount everything
in the new box. Both the Supra and the ICD hard disk driver software
packages will handle this configuration.
"alternative b"
The other choice is to get the necessary DB-19's and two lengths of
ten pair shielded cable. The idea is to solder one end of both lengths
of cable to the same DB-19, and a DB-19 to each of the other ends
(a total of 3 DB-19's; use appropriate sexes of course). All pins are
just wired through straight 1-1, 2-2, 3-3, etc. This gives
you a y-cable. Use the y-cable to connect both SH-204's; note that to
do this you'll need to open up the case of one and change the address
switches on the small Atari interface board. The latest release of
the Atari hard disk driver software (the one that autoboots when the
ST is turned on without needing a floppy to boot from), or the Supra
or ICD driver packages will handle this configuration.
I've been running "alternative a" now for more than six months with
no problems (though I'm using larger drives to get a total of 170 meg
of disk space). I know a couple of people who are using the 19 pin
Y cable approach (alternative b); once they got the cable debugged
they haven't had any problems.
dgc
------------------------------
Date: 19 Oct 87 17:15:46 GMT
From: mcvax!steven@uunet.uu.net (Steven Pemberton)
Subject: Recursive directory!?
To: info-atari16@score.stanford.edu
I've just been trying to backup my hard-disk (with turtle), and it
kept crashing on the same directory. After some investigation, I
discovered that the offending directory includes another directory
*with no name*, that itself only includes another such nameless
directory. That directory itself contains another nameless directory,
and so on, and so on, and so on.
The question is, does anybody know how to get rid of such a directory?
It's only visible from the desk-top; gulam 'ls' ignores it. If I try
to drag it to the trash, I get an alert with the message: "An item
with this name already exists in the directory, or this item is set to
Read-only status." While it's there I can't back it up, I can't copy
it anywhere (the desk-top goes into an infinite loop creating
directories), I can't do anything with it. HELP!
Steven Pemberton, CWI, Amsterdam; steven@cwi.nl
------------------------------
From: JEMCCABE%MTUS5.BITNET@forsythe.stanford.edu
Date: 20 October 87 09:22-EST
To: INFO-ATARI16@score.stanford.edu
Subject: BITNET mail follows
Date: 20 October 1987, 09:11:00 EST
From: Jim McCabe JEMCCABE at MTUS5
G31 East Coed Hall
Michigan Technological University
Houghton, MI
49931
To: INFO-ATARI16 at SCORE.STANFORD.EDU
[ Does Bitnet have line-eater problems too? ]
I've got a question for someone who knows a little about the
GEMDOS directory management.
I'm writing a program where it is necessary for the user to
take out the disk that the program was loaded from and insert
a data disk. From this program, when I try to access a file
after swapping disks, it can find files just fine if they are
in the root directory, but subdirectories cause error -33 (at least
I think that's what error it was... haven't looked at it in
a month or so...) which means that the pathname isn't found
or whatever. Just to test this out, I wrote a small program
to do the exact same file I/O, but it works as it should with
the test program! Somehow things aren't working in my real
program, and I am fairly certain that it isn't the fault of
the program.
If I could just force GEMDOS into loading the new directory tree...
With my test program, GEMDOS recognizes the fact that the disk
has been changed and loads the directory info off the new disk.
However, with my real program, it doesn't work. (It doesn't
even access the disk! I guess GEMDOS is just saying "I don't
have that subdirectory in my directory tree, and the disk
hasn't been changed since you accessed the root directory, nyah!")
I tried to set the "dirty" flags in the directory buffers (as
described breifly in the Abacus ST Internals book) and then
reaccess the disk, but nothing different happens. How does
the GEM Item Selector box automatically get the new directory
when we tell it to? How does the desktop do this when we hit
the <ESCAPE> key? If I could only do this, I bet my problem
would go away...
Confused,
Jim
------------------------------
End of Info-Atari16 Digest
**************************
-------870646c@aucs.UUCP (comer) (10/23/87)
Summary:Help with file transfers Being new to the net has posed some problems, the biggest being how to turn binaries back into programs, I have downloaded some of the binaries, but have not been able to convert. Is there some program for converting them? Also I have be using the latest version of Magic Sac(4.52), when I boot it up with the hard disk boot, the floppies will continue to run until I eject them????. Later Barry