Info-Atari16@SCORE.STANFORD.EDU (Info-Atari16 Digest) (11/13/86)
Info-Atari16 Digest Thursday, November 13, 1986 Volume 86 : Issue 14
This weeks Editor: Bill Westfield
Today's Topics:
Re: Micro-EMACS 3.7i -- bugs and comments
More about uEmacs37 bugs
new people
inexpensive 520ST monochrome systems?
0 file directory listings
Vixx and acc_load
Formatter
Computer fair at UH
MANDLBOX Update
stcopy3 lost, vixx andacc_load
U-char and void in the Alcyon tools
Debugger at C source level
stspeech ???
----------------------------------------------------------------------
Date: 11 Nov 86 13:32:30 PST (Tuesday)
From: Bicer.ES@Xerox.COM
Subject: Re: Micro-EMACS 3.7i -- bugs and comments
In-reply-to: ram's message of 4 Nov 86 10:36:09 EST (Tue)
To: Ashwin Ram <ram@YALE.ARPA>
Does anyone know the keyboard mapping of the ALT keys so that they can
be bound to EMACS commands in the EMACS.RC file? (Function keys are
represented as FNx, are ALT keys ALTx?)
Thanks
Jack
Bicer.ES@Xerox.COM
------------------------------
Date: Tue, 11 Nov 86 15:39 EDT
From: <RDROYA01%ULKYVX.BITNET@WISCVM.WISC.EDU> (Robert
Subject: More about uEmacs37 bugs
To: info-atari16@su-score.ARPA
X-Original-To: info-atari16@su-score.ARPA
I have found two bugs in MEv37 and possibly three. One is connected
to the end of line character. The first bug I have verified and
checked using other software, but it is a very "wierd" bug. First,
say you are at the desktop and ME is on the open directory C:\UEMACS\
which is the logged in dir:. Also, you have drive E: open to \FILES\
dir:. If I double click on uemacs.ttp and type E:\FILENAME.MSS (and
that file is actually E:\FILES\FILENAME.MSS), ME will find the file
but label it E:\FILENAME.MSS. Now, if that file was from another
editor that uses a CR/LF pair for EOL and you make changes in that
file, when you issue the save file command, you will get a disk write
error approximately 3200K of the way through. However, if you issue
the write file command, you can save the file, but not to the name
that opened it. When you exit and look at the file, some lines will
still have the CR/LF pair, but others will not.
Error two: When you transfer files from a CP/M source using Xmodem or
Kermit, ME cannot find the proper EOF. There will always be a CTRL-Z
visible near the end. If that file is a C file and you send it
through the preprocessor, after saving it with ME, the preprocessor
will often report an "unexpected EOF" about one sector before the end.
The only way to fix this is to reopen the file and append blank lines
to it. A similar problem arises when ME37 is used to write files that
are parsed by scanf.
Error three: ME 37 has a major problem keeping up with blinep (the
header line). It will often display the first line of the file at the
bottom of a window when you are actually at the end of the file.
Redraw and update do not fix this. Only a file save will cure it.
This bug is, I believe, responsible for ME's crashing on me a few
times a few commands after a fill-paragraph was issued. It behaves
the way I have seen earlier versions behave when they has lost a pointer
to the header line in a buffer. Often the crash comes somewhat
after the pointer is lost, it shows up as a dead cursor (no blinking)
which usually means the program is "doing something."
I wonder whether these are bugs in the compiler that was used to
generate the code or whether they could be caused by pointers are not
shorts problems? The latter problem was the one I finally tracked
down in the code for an older version of ME ported to CP/M-68K. The
file problems look to me as if the compiler is opening binary files.
For example go to the end of the buffer and show position. It should
report that the current character is 0x0A, but it always reports that
it is 0x3D.
------------------------------
Date: Tue, 11 Nov 86 18:12 EST
From: Rodney <Peck@RADC-MULTICS.ARPA>
Subject: new people
To: info-atari16@SU-SCORE.ARPA
Not meaning to annoy anyone with intro stuff (it always bothers me)
but I'm new to this atari thing, I just bought a color 1040. What do
you all reccomend for software??
I'm fairly good at C so I'd like to get a compiler. What is the best
(or most commonly used one)? Another question: What exactly is
uudecode? I assume its some sort of program that converts binary files
into ascii so the net can handle them.
Where can I get
a copy of uudecode and the de-archiver? I'll be able to get kermit
from cu20-b soon, but can't ftp right now. (Give me a week.)
Finally, where else besides su-score::<info-atari> is there pd st
software on the net? (bitnet or arpanet)
Finally, finally, what books/reference manuals do you reccomend? I
have k&r's _The C Programming Language_ from when I took C at Rensselaer
Polytechnic Institute. I hear that this is a good c book. What else
should I get to get into gem etc.
(I haven't actually received the computer yet, its in the mail, so
maybe it comes with decent manuals...hope..hope...)
Thanks,
Rodney Peck
ARPA: rodp@RADC-Multics.arpa
Anywhere else: standard gateways...I'm not going to type them.
------------------------------
Date: Tue, 11 Nov 86 18:00:06 EST
From: mek%UMass.BITNET@WISCVM.WISC.EDU
Subject: inexpensive 520ST monochrome systems?
To: info-atari16@score.stanford.edu
Hi!
Does anybody out there know where I can get a 520ST monochrome
system for $500 or less? Perferably mail-order or in Massachusetts.
Please reply to me privately or through this digest. Thanks very
much in advance!!
Matt Kimmel,
mek@UMass.BITNET (BITNet)
mek%UMass.BITNET@wiscvm.ARPA (ARPANet)
------------------------------
Date: Tue 11 Nov 86 18:38:54-EST
From: Brian Totty <G.BRI%DEEP-THOUGHT@EDDIE.MIT.EDU>
Subject: 0 file directory listings
To: info-atari16@SU-SCORE.ARPA
In article <758@zen.BERKELEY.EDU> c9c-bg@buddy.Berkeley.EDU (James A. Landay) writes:
>Has anyone had the problem of their ST upon booting (TOS in ROM) saying
>that every disk was empty. (i.e. 0K in 0 folders). Mine is doing this.
>I have a single sided drive.
>Help!!!
>
>
>James Landay
>c9c-bg@buddy.berkeley.edu
Sorry about sending this to everyone, but my mailer couldn't
find buddy.berkeley.edu. As far as problems with 0 file/0 byte directories,
I did have problems, and fixed them by reseating all the chips. I think
this may likely be the cause, esp. the custom chips. (I later had trouble
with strange bit patterns on the screen at boot-up leading to more
bombs than I could count. After reseating the chips, this went away
also). Might want to give this a try, and make sure your keyboard
connector is connected firmly.
--- Bri
g.bri@deep-thought.mit.edu
...!eddie!bri
------------------------------
Date: 12 NOV 86 09:53-N
From: U00170%HASARA5.BITNET@WISCVM.WISC.EDU
To: INFO-ATARI16@SU-SCORE.ARPA
Subject: Vixx and acc_load
Hello,
Who can send me Vixx.ttp, the docs and the Accessorie loader.
Both programs did not reached europe I believe.
Maybe it must be reposted as an Atari16 digest.
This way of sending the Atari16 messages seems to
work fine.
Berend.
U00170@HASARA5.BITNET
------------------------------
Date: Wed, 12 Nov 86 08:27:57 CST
From: Mike Vederman <ACS19%UHUPVM1.BITNET@WISCVM.WISC.EDU>
Subject: Formatter
To: ST Users <INFO-ATARI16@SU-SCORE.ARPA>
The Formatter which I posted recently does this to the disk...
It places three bad sectors at the end of each track. It does this by
creating the sector, then placing a bad crc in the header. When the WD1772
sees the crc error, it gives up unconditionally. This accounts for the
increased speed.
NOTE: The 10 sector format does not give an enhanced speed, this is probably
due to the I/O buffer, but I don't know for sure. The fastest speed is gained
from single sided with 9 sectors per track, on either 80 or 82 tracks. Double-
sided disks seem to be a bit faster, but it is not as noticable as with SS.
If you want raw storage, then go to 10 sectors on 82 tracks. Yes, TOS will
disk copy 9 sectors on 82 tracks, it is not THAT dumb, and you will even see
the status box go past the end when it reaches the last 2 tracks. TOS will
NOT however properly copy 10 sector formats. I am currently working on a
copier that will do this, and probably add it to the formatter.
I have never seen any disks formatted beyond 82 tracks, altho I have seen
copiers which allow for 83. The drives seem to vary in capabilities. I have
a friend who cannot format 82 tracks on one of his drives, but can on the
other drive. The one that CAN'T just clunks at the end. Be cautious and
alert when you do extended formats. I have NEVER had any problems, and most
of the people I know don't either, but there is always the exception.
Mike
------------------------------
Date: Wed, 12 Nov 86 08:38:44 CST
From: Mike Vederman <ACS19%UHUPVM1.BITNET@WISCVM.WISC.EDU>
Subject: Computer fair at UH
To: ST Users <INFO-ATARI16@SU-SCORE.ARPA>
Well, last week we had a computer fair on the University of Houston
campus. In attendance was IBM (they had half of the ballroom), AT&T, Apple,
and Zenith hardware manufactures. On the software end was Microsoft, Ashton-
Tate, Palantir, D2(d-squared), etc... and Sony with a disk booth.
Also there was our campus user group (the ONLY user group). Since I work
at the computing center, and I know the guy running the show, I got a booth.
The rest of the booths had to pay $200, we got ours for free (being an
*Official* campus organization).
Well... we had a hard disk, a midi, Hippo sound digitizer, a Magic Sac
(I called Data Pacific and they sent me a complimentary cartridge) and
another machine running games. We also had Atari banners (back from the
Warner days) and Atari T-shirts galore to give away.
We were the only ones who had music at the show, and let me tell you, it was
a god-send. The music, mostly Tocatta Fugue in D minor (Bach) from EZ-Track
was the ticket. Our booth was extremely crowded both days, and needless to
say, I feel we stole the show. Interest in the capabilities of the ST was
phenomenal, and as a result, we are giving a demo to the computer science
department out at the Clear Lake UH campus today.
The weekend before that, we had a show at a mall at Texas A&M and that was
very good, too.
The point is this, Atari is VERY well suited to an academic environment. We
were lucky that we had a chance to break the ice and really show off the
machine to the campus public. We are going to try to push Atari into the
campus scene, but we don't know if we can do it alone.
I sent two letters to Atari, one to Neil Harris, and one to Ed Klein (regional
sales) without a reply from them. If we can get some backing from Atari, I
know we can get the campus store to start selling the machine. I have asked
the manager about this, and he would very much like to sell the machine, even
tho the *official* campus machines are Mac, IBM, and Zenith PCs.
Our group is very interested in putting on a Spring-time Atari only fair on the
campus. We can get $1000 seed money for sponsoring a campus event, but we
need to know that the big guys will be willing to have it.
Sooo... if you are a software manufacturer, hardware manufacturer, or ATARI,
please send E-mail to me stating if you would be interested in a show on the
University of Houston campus. I am not talking small time stuff here, the show
last week had a huge turn-out. The time is ripe, and we would like to have
Houston as an integral part of the Atari scene. After all, we are the fourth
largest city in the US. There is no reason that Houston should not be a
leading edge city.
What about it Neil?
Comments are appreciated, from anyone.
Michael Vederman
ACS19 at UHUPVM1 (on BITNET)
------------------------------
Date: Wed, 12 Nov 86 12:50:29 EST
From: Bill Dorsey <iarocci@eneevax.umd.edu>
To: Info-Atari16@Score.Stanford.edu
MT C-SHELL
Being a unix fan, and having recently seen a number of favorable reviews of
Beckemeyer Development Tool's MT C-SHELL, I decided to give them one more
chance and bought the package. I have previously purchased Micro C-Shell and
Micro C-Tools and been disappointed due to the multitude of bugs, compatibil-
ity problems, and poor documentation.
Having had MT C-shell up and running for several days now, I can say that I
am quite disappointed in the product and would certainly not recommend it to
anyone. In fact, I would caution people against buying it. It has many prob-
lems including bugs, compatibility, and poor documentation. I have listed
some of the problems with it below.
MT C-Shell is a massive memory hog. It is most certainly useless on a 512k
machine as one will be unable to run all but the smallest of programs. Even
on my 1 meg machine, I cannot always compile in the background and run the
editor. Consider, I have approximately 900k free before running MT C-Shell
and I can't even run a compiler (each file is less than about 80k) and an
editor (approximately 50k). This is truly ridiculous. I have seen unix
boxes with less than 1 meg of core run more and bigger programs than this
without using a virtual memory system.
Another major problem is compatibility. The package claims compatibility with
TOS programs. I have found that for every TOS program that runs under MT C-
Shell, another one doesn't. And even more annoying is those TOS programs
which seem to run, only to crash the system at a later time. The same goes
for GEM programs executed using the GEM command, only here even fewer programs
work properly.
Of course, there's the problem of the documentation (or lack of it). While
the documentation provided is reasonably clear, much remains to be said. One
would normally expect two to three times the volume of documentation with a
similar product. For those of you not familiar with the operation of unix,
setting up the system and getting it to work could be a major hassle. But I
suppose the subject on which the documentation is especially lacking is
technical information. If you are a programmer and want to write programs to
be run in the MT C-shell environment, there is no documentation to tell you
what to do or not to do. Can you say "Trial and error?"
Well, those are the major problems I have encountered with MT C-Shell. There
are many others some of which I'll mention below. Many of these can be fixed
with a "kludge." However, kludges should not be necessay with a commercial
product.
If your current working directory is on a drive different from that which you
booted, and you try to execute any of the utility commands which refer to the
passwd file (finger, passwd, etc.), they won't work. Apparently these com-
mands refer to \etc\passwd instead of c:\etc\passwd assuming you booted from
drive c:. This can be quite annoying, especially when your home directory is
not the same as the boot directory.
Speaking of home directories, if you wish an account to have a home directory
on a drive other than the one from which you booted, you must use another
"kludge." Since the delimiters in the passwd file are colons and the drive
delimiters are also colons, the system will get confused is you try to specify
a drive in the pathname for the home directory. So, you must create a home
directory on the boot drive and put a login shell in the directory to change
the home directory to the desired drive and then change directories to it.
You would think someone capable of writing a multi-tasking operating system
could think of a way around this!
There are many more lesser bugs like the two above. Lesser because there
exist kludges to circumvent them. For example, the ~ command always returns
\usr\name where name is the argument. In cases where the home directory is
other than \usr\name, problems can arise. I could go on, but I think you
get the point.
My advice to prospective buyers of MT C-Shell: STAY AWAY! Look into OS9 or
XINU. Unless Beckemeyer Development Tools Inc. gets their act together and
releases a bug-free well-documented version of this product, it isn't worth
the time or hassle much less the money. In my opinion, BDT, Inc., has a
history of releasing products before they are ready. MT C-Shell V1.00
(I believe this is the latest version) should really be V0.01! And until
I am certain they have changed, I shall never again purchase one of their
products.
------------------------------
Date: Wed, 12 Nov 86 11:35:24 EST
From: Allen King <aking@bfly-vax.bbn.com>
To: info-atari16@su-score.ARPA
Subject: MANDLBOX Update
There is a bug in MANDLBOX on a 1040 because it appears to have TOO
MUCH MEMORY. Eric Clausen in California reports that running MANDLBOX
on a 1040 with a RAMDISK of at least 200K (TOS in ROM) makes it work.
All I can say is that I only have 512K, and if anybody wants to
connect me with 16 1M chips I'll test it in all sizes to 2M!
So those of you with who went through the pain of UUDECODING only to view
terrorist activities on the screen might want to give it another "shot".
I've been unable to shoot this bug to date (boy, all these war images, I
don't know! I guess its the guilt of drawing number 350 in the Viet Nam
Lottery). When I do, I'll post a small note. For those of you who unpacked
the sources of MANDLBOX which just went out, you can easily play with
the call in stitch.c to malloc which allocates the data structure for
the screen box structures.
Hope the rest of you with 512's (and color) have been enjoying. If so,
let me know (ucbvax!aking@bfly-vax.bbn.com). Feedback so far indicates that
the next version will have screen-save/restor to disk.
------------------------------
Date: Wed, 12 Nov 86 13:04:26 PST
From: <KJBSF@slacvm.bitnet>
Reply-To: KJBSF%SLACVM.BITNET@forsythe.stanford.edu
To: INFO-ATARI16@score.stanford.edu
Subject: stcopy3 lost, vixx andacc_load
Date: 12 November 86 13:05-PST
From: KJBSF@SLACVM
To: INFO-ATARI16@SCORE
Subject: stcopy3 lost, vixx andacc_load
Date: 12 November 1986, 13:04:30 PST
From: Kevin J. Burnett x3330 <KJBSF@SLACVM>
To: <INFO-ATARI16@SCORE.STANFORD>
Subject: stcopy3 lost, vixx andacc_load
Forwarded-from: KJBSF
Somehow I got this message; I'm just forwarding it to the rest of the list.
- - - - Forwarded Text - - - -
Date: Wed, 12-NOV-1986 18:59 N
From: Berend de Vries, Biochem, UVA, AMC <U00170@HASARA5>
Subject: stcopy3 lost, vixx andacc_load
To: KJBSF@SLACVM
Original_To: @JNET.MAI,U00170
Hello bitnetters.
Can some of you please send me the uuencoded vixx.ttp,
acc_load and a Dutch program called stcopy3.prg in uuencoded
form.
I lost the stcopy3.prg when I reformatted a disk.
Thanks in advance:
Berend de Vries
U00170@HASARA5
------------------------------
Date: Wed, 12 Nov 86 21:03 EDT
From: <RDROYA01%ULKYVX.BITNET@WISCVM.WISC.EDU> (Robert
Subject: U-char and void in the Alcyon tools
To: info-atari16@su-score.arpa
X-Original-To: info-atari16@su-score.arpa,bammi@case.cs-net.relay.arpa
I finally received my DEV pack in the mail today, but I didn't find
anything in the package to tell what version it is. I had assumed it would
be the latest version, the one that supports void and unsigned char. But
this version does not support either of those (nor is enum or unsigned long
supported). I remember Jahwar Bammi [sic] saying in one of his notes that
v. 4.14 definitely support the void and unsigned char. Is this true? And
if so why would a recently shipped version not support these? BTW the
latest dated file was gemstart.s which includes instructions for setting up
different memory sizes and a way to pass exit codes to parent processes.
That file was dated in July 1986. I did not receive any registration cards
in the box. The package was POed through a dealer, so Atari would have no
way of registering my name without some return card. Also the dealer showed
me an invoice from Atari showing the product was shipped from them last
week.
I'm interested in the u-char void thing particularly because a number of the
programs I have gotten off the net (originally from Case) will not compile
properly without those data types. And ignoring those types leads to
runtime breakdown. ??How did they compile in the first place using the
Alcyon tools without those data types? Does Case have special status or
something?
------------------------------
Date: 13 Nov 86 02:37:05 GMT
From: zen!zooey.Berkeley.EDU!c160-fk@cad.Berkeley.EDU (Duy Le)
Subject: Debugger at C source level
To: info-atari16@score.stanford.edu
Hello there,
Can someone tell me if I can use the debugger at C source level from a company
named "Mark Williams" with either Alcyon C or Lattice? If I am correct,
in order to debug at C source level, the compiler has to include symbols from
the C source with the executable file. How can I do such thing with either
Lattice C or Alcyon C compiler?
Thanks in advance.
Duy
UUCP: c160-fk@zooey.Berkeley.EDU
------------------------------
Date: Thu, 13 Nov 86 07:08:27 cst
From: moore@ncsc.ARPA (Moore)
To: info-atari16@su-score.ARPA
Subject: stspeech ???
Is there a way to tell stspeech to read its input from a file rather than the
keyboard? Imagine: talking 1ST_Word!!!
Jim
Moore@NCSC.arpa
------------------------------
End of Info-Atari16 Digest
**************************
-------