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 22:36:56-PDT Date: Thu 14 May 87 21:58:48 PDT Subject: Info-Atari16 Digest V87 #213 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 22:36:56-PDT Date: Thu 14 May 87 21:58:48 PDT Subject: Info-Atari16 Digest V87 #213 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.Stangradompompoer Der
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 22:36:56-PDT
Date: Thu 14 May 87 21:58:48 PDT
Subject: Info-Atari16 Digest V87 #213
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 213
This weeks Editor: Bill Westfield
Today's Topics:
micro-C-Shell quirks (was: Re: os bug?)
PD music writing program wabted
NOTE from WALDI
Request for ARC source
Re: Bad Floppies
Re: Dallas Atarifest (warning: LONG)
Re: Mark Williams C 2.0 benchmark
Re: 40 Folder Fix from Atari
Re: Bug report: 'The Russian Doll' sp. nova (?)
Re: Corner Clock (Atari: please fix another botch)
Yet another disklist program, lists contents of ARC files
Re: Megamax inline assembly woes
Re: Megamax inline assembly woes
Re: ...GEMBOOT... (really usage of shell_p)
----------------------------------------------------------------------
Date: 11 May 87 22:13:21 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: micro-C-Shell quirks (was: Re: os bug?)
To: info-atari16@score.stanford.edu
[]
Inside micro-C-Shell too, if I replace the floppy and say "cp a:\file ."
(where '.' is the RAMdisk) it works fine, but if the first thing I do with
the newly-inserted disk is "cp a:\folder\file ." it says "not found".
I got used to typing "ls a:\" immediately after inserting a new floppy.
Why is that? And also: when is that backslash needed? And why is it
prohibited inside shell scripts in cases where it is possibly redundant
but accepted from the keyboard?
- Moshe Braner
------------------------------
Date: 12 MAY 87 11:44-N
From: U00170%HASARA5.BITNET@wiscvm.wisc.edu
To: INFO-ATARI16 @ SCORE.STANFORD.EDU
Subject: PD music writing program wabted
Hello,
I sing in a choir and the cunductor also writes songs.
However, his handwriting is terrible so I am looking for
a public domain "music write" program.
Is there anyone who has experience in writing music on a ST ?
Berend de Vries.
U00170@HASARA5.BITNET
------------------------------
Date: Tue, 12 May 87 13:31:02 SET
To: info-atari16@score.stanford.EDU
From: WALDI%DHDIHEP1.BITNET@wiscvm.wisc.edu
Subject: NOTE from WALDI
Date: 12 May 1987, 12:20:58 SET
From: Roland Waldi phone (6221) 564334 WALDI at DHDIHEP1
D-6900 Heidelberg / F.R. Germany
To: INFO-ATARI16
Topic: fixed addresses like _shell_p, $440...
Several people discussed on the net the use of the variable _shell_p
at location $4F6, e.g.:
> Using the location at $4F6 for different purposes will crash more than one
> program. If one needs to use anything, use some of the space at either the
> $500 range, or in the $300 range ( before the save area for the registers
> ....
> Jos Vermaseren
> t68@nikhefh.uucp
According to Simon Poole's reply it is used by GEM/AES.
Let me tell you my observations:
1. According to the documentations I could access, it is for use
of the OS Shell. I assume, this is meant to be GEM usually, so
it would be consistent with Simon's observations. A command line
shell, which is supposed not to invoke GEM, might then also safely
use this for any purpose, but not if it may call GEM-applications.
2. I looked into this variable with a debugger, while running
a GEM program. I could not verify it's use by GEM/AES, since
it was ALWAYS 00000000. So my question to Simon: When can one
find a real address at this place? Actually, there were such
"PATH='... data in memory, But I could not find a place with
a pointer to them. (I have TOS in ROM).
3. To ATARI: Can anyone comment on the proper use of this storage
location?
The suggestion to use locations at $500 is very dangerous. Though these
locations are not documented, they are nevertheless used by TOS!
There are several pointers to printer (Centronics) output routines,
and a pointer to the PUN used for harddisk access is close above $500!
So please no one use these for private programs, if you want to
avoid system crashes. Whether the place before the post-mortem-savearea
is save, I don't know.
Another location that was discussed is $440 / $A08, A0C to control
the floppy seek rate:
> Apparently, there is a location (0x0A08) that contains the
> current seek rate. This location is one WORD long. It
> .....
> What about the documented, 0x0440 location? Well, I ran some
> .....
> John Ogawa
>
> NET: ...ucbvax!sdcsvax!sdcc13!ps136sag
Actually, I can confirm locations $A08 and $A0c for the floppy drives' seek
rate. SInce it is undocumented, it may --however-- not be ported to other
TOS versions (the adresses may change). A more save way is to use
the documented location $440. Then, after changing, you have to inform
the OS by calling a hdv_init (which does not initialize hard disk, but
rather floppy i/o). This can be called via its (documented) pointer
at $46A, e.g. try:
move #2,$440
move.l $46A,A0
jsr (A0)
or something similar (not tested). Again, could anyone from Atari comment?
Roland Waldi, WALDI@DHDIHEP1.BITNET
------------------------------
Date: Tue, 12 May 87 12:01:28 EDT
From: USERFL4E%mts.rpi.edu%itsgw@CSV.RPI.EDU
To: info-atari16@score.stanford.edu
SIGNOFF
------------------------------
Date: 12 May 87 13:57:01 GMT
From: ravi@mcnc.org (Ravi Subrahmanyan)
Subject: Request for ARC source
To: info-atari16@score.stanford.edu
I'm looking for the sources for the ST version of ARC. Are
they available? If so, I'd be grateful for either the sources or
pointers. I can FTP them if they're available on some arpa site.
If they're very large, I'll send a disk and SASE. Please reply by email.
Thanks in advance,
-ravi
ravi%mcnc.org (ARPA)
{decvax, seismo, ihnp4, ucbvax}!mcnc!ravi (UUCP)
------------------------------
Date: 11 May 87 12:51:50 GMT
From: cca!mirror!rayssd!brunix!nancy!rjd@husc6.harvard.edu (Rob DeMillo)
Subject: Re: Bad Floppies
To: info-atari16@score.stanford.edu
In article <8705090050.AA25476@ucbvax.Berkeley.EDU> cew@ELVIRA.ISI.EDU writes:
>I might as well put my two cents in for this. The only floppy to fail
>me was a Verbatim ValueLife DSDD. This is their low end disk so I guess
>I should have expected it. Their top line disks (only SS) have performed
>like champions...
My experience (recently) with Verbatim has been poor. Before leaving my
old job, I purchased a box of Verbatim disks *issued "For Government and
Educational Use"* Whether these disks are Verbatim's normal brand, or
whether they are retreads sold to unsuspecting government and educational
institutions is anyone's guess.
The statistics? Out of a box of 10 DSDD diskettes, a whopping 8 disks
have failed in a six month period. (The failed disks even refuse to format.)
At first I thought it was my drive, but I have access to many Atari and
MacIntosh drives and the results are the same. If Verbatim is selling
retreads to the US govt and universities, they should be ashamed of themselves.
If these disks are their normal product line, they should be doubly ashamed of
themselves. In the several years I have been using floppies (3.5", 5.25",
or the old large format floppies) I have *never* come across a failure
rate like that.
- Rob DeMillo
Brown University - Planetary Science Group
UUCP: ...{seismo!harpo}!ihnp4!brunix!rjd -- or --
...{seismo!harpo}!ihnp4!brunix!europa!rd
BITNET: GE702025@BROWNVM
SPAN: BRNPSG::RD
CompuServe: 73537,2737
------
"...I am not so sure what you want me for!
Either your machine is a fool, or me..." -- "WarGames", CSN
------------------------------
Date: 12 May 87 16:52:46 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU (Neil Harris)
Subject: Re: Dallas Atarifest (warning: LONG)
To: info-atari16@score.stanford.edu
In article <8705111650.AA11146@ucbvax.Berkeley.EDU>, UACE0@UHUPVM1.BITNET writes:
> ATARI PC - not until 1988, at the earliest.
That's not what I said!! The rest of the report from my talk on where Atari
is going is accurate, but you should be aware that the PC is still scheduled
to begin delivery in late June or early July.
--
--->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: 12 May 87 23:23:07 GMT
From: decvax!minow@ucbvax.Berkeley.EDU (Martin Minow)
Subject: Re: Mark Williams C 2.0 benchmark
To: info-atari16@score.stanford.edu
In article <942@batcomputer.tn.cornell.edu>, Moshe Braner asks about
MWC V2.0 compiler performance. Here are some very informal numbers.
Configuration: compiler, editor, linker, temp files, and libc.a in ramdisk;
sources, #include files, objects, and gem/vdi libraries on disk. (1040ST
with one floppy, 512K ramdisk).
Source file 18930 bytes, 728 lines (+ 5 #include files).
0:44 Compilation, detect syntax error, restart Microemacs
0:09 Microemacs reads source and error file and points to bad line.
1:21 Exit editor (after writing file) and successfully compile source.
2:08 Link the 8 object modules with the various libraries, writing
a 32 Kbyte program.
While these numbers are greater than the "20 seconds for a small program"
Moshe reports, note that these numbers are for a large source file,
part of a large program.
Martin Minow
decvax!minow
------------------------------
Date: 12 May 87 18:50:00 GMT
From: apollo!weber_w@beaver.cs.washington.edu (Walt Weber)
Subject: Re: 40 Folder Fix from Atari
To: info-atari16@score.stanford.edu
In article <1191@imagen.UUCP> turner@imagen.UUCP (D'arc Angel) writes:
+in article <3499fce5.1f6@apollo.uucp>, weber_w@apollo.uucp (Walt Weber) says:
++---------------------------------------------------------
++
++ In article <459@uhccux.UUCP> yuan@uhccux.UUCP (Yuan Chang) writes:
+++ I was wondering, what if your decided to boot your ST from floppy one day,
+++and finds out that it doesn't contain GEMBOOT nor FOLDRXXX.PRG? Slight
+++instant disaster I suppose?
++
++ This would not be a problem, providing that your DESKTOP.INF used during
++ the boot process did NOT automatically open a window (or windows) such that
++ more than 40 folders (including the top-level one for each open disk)
++ would not be "visible", and you were careful about how many folders you
++ see or visit during a single boot session.
++
++---------------------------------------------------------
+i think you might do well to check that out, i believe that it is
+the number of directories that the system "sees" not the luser.
I plead guilty to speaking anthropomorphically, you quick-eyed rascal! :-)
--
Walt Weber PHONE: (617) 256-6600 x7004
Apollo Computer GENIE: W.WEBER
Chelmsford, Mass. COMPUSERVE: 76515,2423
------------------------------
Date: 11 May 87 09:57:40 GMT
From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov (Paul Smee)
Subject: Re: Bug report: 'The Russian Doll' sp. nova (?)
To: info-atari16@score.stanford.edu
Sorry, I'm having a bit of trouble following your description, but I'll
make a guess anyway. (While I don't believe I've seen any warnings about
it in the Atari manual --mine's antique anyway, so probably not definitive
-- it is true that)
If you copy something from somewhere to drive <x> (for any <x>) and you
have a window open on the screen which the system thinks is a folder
(or the top level of) drive <x>, and that window does *not* in fact
refer to (was not derived from) the actual disk which is presently
really in drive <x>, then you're likely to get into all sorts of trouble.
Sound like that could be your problem?
------------------------------
Date: 11 May 87 11:17:51 GMT
From: decvax!watmath!jsgray@ucbvax.Berkeley.EDU (Jan Gray)
Subject: Re: Corner Clock (Atari: please fix another botch)
To: info-atari16@score.stanford.edu
In article <870510114656.000002C8.AKMV.MA@UMass> Flash@UMASS.BITNET (Rick Flashman) writes:
>Someone mentioned that they had a corner clock that does not take up
>an accessory slot...
Why must we be limited to six desk accessory slots?
Some bozo hard codes the number '6' in somewhere and we all get stuck
juggling DAs for all time.
If future ROMs remove the arbitrary 40 folder limit, and the arbitrary
n Malloc block limit, could they also remove the arbitrary six DA limit?
(I know that resource files only come with six slots, but there must be
some way to munge resource trees upon loading to conform to however
many DAs are loaded.
Jan Gray jsgray@watrose University of Waterloo (519) 885-1211 x3870
------------------------------
Date: 12 May 87 23:50:31 GMT
From: ptsfa!varian!madvax!cw@ames.arpa (Carl Weidling)
Subject: Yet another disklist program, lists contents of ARC files
To: info-atari16@score.stanford.edu
I have posted to comp.[sources|binaries].atari.st a pair of
programs to help manage files on disks. Robert Ritter wrote and
donated a disklist program which was about the first program I ever
used off of USENET, and Todd Burkey wrote the very slick disktop
program. My new wrinkle is that when my program encounters a file with
.ARC extension, it tries to list them too. The program is called
"lsit" because that's what I get half the time when I try to type
A 2nd program called "group" reads the output of "lsit" and groups
files with the same name together.
A 3rd program is a little formatting utility. If you want to
print out a list that would leave all white space on the right side of
the paper, you can run the file through "double.ttp" and get it double
columned.
Bon appetit.
Regards,
Carl Weidling
------------------------------
Date: 11 May 87 22:31:32 GMT
From: infotel!pollux!megamax!peter@ngp.utexas.edu (Peter Taliancich)
Subject: Re: Megamax inline assembly woes
To: info-atari16@score.stanford.edu
The problem that you are having with the move multiple instruction is due
to the fact that register names must be capitalized. If you capitalize the
register names your problem will go away. (i.e.
asm {
movem.l D0-D7/A0-A3, -(A7)
}
)
If you want to use the mnemonic `sp' for the stack pointer then all you
have to do is to
#define sp A7
asm {
movem.l D0-D7/A0-A3, -(sp)
}
peter@megamax
uucp: {texsun,killer,infotel}!pollux!megamax!peter
voice: (214) 987-4931
------------------------------
Date: 12 May 87 17:52:20 GMT
From: dayton!viper!john@RUTGERS.EDU (John Stanley)
Subject: Re: Megamax inline assembly woes
To: info-atari16@score.stanford.edu
In article <940@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally (Man Insane)) writes:
>In article <8705030519.AA18707@ucbvax.Berkeley.EDU> KIMMEL@ecs.umass.EDU (Matt Kimmel) writes:
>>
>>movem.l d0-d7/a0-a6,-(sp)
>>movem.l (sp)+,d0-d7/a0-a6
>>
>>-Matt Kimmel
>
>Register names have to be in upper case. Also, SP is not defined --
>use A6.
Sorry Mike... Last time I looked, SP was A7, -not- A6...
If Matt does what you told him to do, his programs will be toast...
---
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
------------------------------
Date: 12 May 87 23:08:18 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: Re: ...GEMBOOT... (really usage of shell_p)
To: info-atari16@score.stanford.edu
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.
We have a logic analyzer here at Atari, and you can set it to stop when
the 68000 reads from a certain memory location. I did this, triggering
on 000004f6 (the address of _shell_p). Neither the AES (in looking for
a resource) nor MSH (the Mark Williams shell) made any reference to this
location, reading or writing. This includes starting programs which need
resources, without that resource file present.
Would somebody please enlighten me? I can't verify any of the claims
made for the _shell_p variable by people in this newsgroup (Michael
Fischer@yale and "Simon" at CZHRZU1A on BITNET), and I would like to.
Can anybody please tell me exactly what steps I can take, with a GEM
program and its resource, the Mark Williams shell, and/or GEMBOOT, to
prove to myself that this stuff really works?
Thanks in advance...
/----------------------------------------------\
| Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp.
| reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt
------------------------------
End of Info-Atari16 Digest
**************************
-------
-------