Article View: comp.sys.atari.st
Article #29213Undelivered mail
From: Postman
Date: Mon, 16 Nov 1987 00:36
Date: Mon, 16 Nov 1987 00:36
408 lines
18087 bytes
18087 bytes
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
5001 mailbox invalid -> CHARLTO@UOFMCC.BITNET
----------------------------------------------------------------------
Date: Sun, 15 Nov 87 18:36 CST
To: CHARLTO@UOFMCC.BITNET
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #416
Received: by CANADA01 (Mailer X1.24) id 4929; Sun, 15 Nov 87 19:03:26 EDT
Date: Sat 14 Nov 87 09:14:40 PST
Reply-To: Info-Atari16@Score.Stanford.edu
Sender: INFO-ATARI16 Discussion <INFO-A16@CANADA01>
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #416
To: Name Unknown <BUSU@UOFMCC>,
Jim Charlton <CHARLTN@UOFMCC>,
MIKE CHARLTON <CHARLTO@UOFMCC>,
Werner Ens <ENS@UOFMCC>,
Name Unknown <HABKE@UOFMCC>
Info-Atari16 Digest Saturday, November 14, 1987 Volume 87 : Issue 416
This weeks Editor: Bill Westfield
Today's Topics:
IKBD commands/reads
Re: RF Modulator for the 1040?
uw & different fonts for microemacs
ROM availablity
Re: What's the deal with the repair kits, Neil?
Re: Atari/Perihelion Transputer Machine Spec
file i/o functions
Re: Worst product name award
Re: Hard drive problems
Re: Lies (was: Re: Atari/Perihelion Transputer Machine Spec)
Re: PC-ditto
----------------------------------------------------------------------
From: JEMCCABE%MTUS5.BITNET@forsythe.stanford.edu
Date: 13 November 87 14:19-EST
To: INFO-ATARI16@score.stanford.edu
Subject: IKBD commands/reads
Is there an easy way to get the clock time from the keyboard?
It would be nice to use a clock with one second resolution instead
of GEMDOS's 2 second clock.
I would also like to be able to set this clock.
I know that there is an XBIOS call to send bytes to the keyboard,
but how do we receive them? (I have no idea where the keyboard
packets are sent or what format they have or ... you get the picture. :)
Just in case anyone cares, I'm using Personal Pascal.
Jim McCabe
jemccabe @ mtus5.bitnet
------------------------------
Date: 13 Nov 87 23:01:06 GMT
From: web8b.berkeley.edu!c60a-2ae@jade.Berkeley.EDU (John Kawakami -O~O-,510d
or 260E,6431816,6667734)
Subject: Re: RF Modulator for the 1040?
To: info-atari16@score.stanford.edu
Brantly.henr@XEROX.COM asks
]At one time (quite a while ago) there was quite a bit of discussion
]about "Someday SOMEBODY is going to come up with the means to drive a TV
]from a 1040ST".
And so do I!
I know this can be done; there was a description and a sample of a circuit
that would do this in Bruce "sublogic" Artwick's book on computer graphics.
I believe it was titled _Microcomputer_Graphics_and_Animation_.
I also keep hearing about some company called JNL Technologies that
apparantly made one of these dodads.
This device would be a boon to all the ST owners without RF output (520ST[f]s
have RF output as you all know) who want to videotape some screens.
John "why buy a color screen when I know I'll use it only to play
some games" Kawakami
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JoHn KaWaKaMi alias spectacle -O~O- alias c60a-2ae@widow.berkley.edu |
+ +
| OH NO! CLONES -0~0- | \ -o~o- / -<xxxxx>- |
+ -@~@- O 0 O -()-()- ~from +
| ]OO[ > 0 O Star Trek |
+ O \ / The Drek +
| -P=P- | ~+~ Generation |
------------------------------
Date: 14 Nov 87 01:08:58 GMT
From: moe@athena.mit.edu (Moezeddin K. Karimeddiny)
Subject: uw & different fonts for microemacs
To: info-atari16@score.stanford.edu
I have 2 questions for neters concerning uw and emacs:
1. What exactly is uw ? Is it a window manager ? Is it compatible with X
window
system version 11 ? If it is, can it run over dial-up phone line or does
it need to
have a high speed network to work ?
2. Is it possible to load a 6x10 font to be used with mg(micrognuemacs) or
me(microemacs) (I have a ME version 3.9 that has 40 lines display on
monochrome
with font width of 8 pixels, and also a MG version 1a that can display 50
lines
if I run "hi50.tos" first but the width of the character is 8 pixels so
it is
kinda hard to read). Better yet can proprotional fonts be used instead of
monospaced
fonts. I realised that it is hard to used get a font with width of 6 to
work with
TOS (since 640 divided in to 6 is 106. something) but is it impossible?
Thanks in advance for any helpful information,
Hai
PS: I guess that was more than 2 questions...
------------------------------
Date: 13 Nov 87 02:03:07 GMT
From: imagen!atari!portal!cup.portal.com!Mark_H_Brandwein@ucbvax.Berkeley.EDU
Subject: ROM availablity
To: info-atari16@score.stanford.edu
I recently picked up an ANCIENT 520St with the old TOS-on-disk operating
system. I have looked in every mag I can find, but have not found anyone
who carries the TOS rom chips. Any help on this would be immensly
aappreciated.
M. H. Brandwein
------------------------------
Date: 12 Nov 87 05:49:44 GMT
From: ihnp4!homxb!mtuxo!mtgzz!drutx!druhi!med@ucbvax.Berkeley.EDU (DrapalME)
Subject: Re: What's the deal with the repair kits, Neil?
To: info-atari16@score.stanford.edu
In article <881@atari.UUCP>, neil@atari.UUCP (Neil Harris) writes:
> > In any case, I think that the decision on whether or not to buy this repair
> > kit should be the dealers choice, not a prerequisite of becoming an
> > "authorized service center".
>
> I totally disagree.
>
> One current problem is the slow turnaround from repair centers lacking in
> spare parts.
>
> Having the dealer carry a substantial inventory of these is a good way to
> ensure that our consumers get prompt service.
And I guess that is the real problem here... I talked with
one of the local dealers, and they plan to fix MEGAS just like they
fix 520/1040's ===> "Oh, so your ST is sick? Bring it in and we'll charge
you X dollars, and you can take it with you... Never mind that the
serial number is different." That's right... most dealers here fix STs
by simply replacing them with a new one - very "prompt service", and they
don't need (or intend) to use your $4000 worth of parts!
And besides, who do you think really pays for those part
anyway ;-(. I think that this whole thing boils down to Atari wanting
the "image" (or should that be "look and feel" ;-)) of an IBM
dealer - high prices, fast service, and very few customers who can
afford all of that glitter.
Myron Drapal
AT&T
Denver, Co.
..!ihnp4!druhi!med
------------------------------
Date: 12 Nov 87 15:43:58 GMT
From: umn-d-ub!umn-cs!ems!nis!stag!trb@speedy.wisc.edu ( Todd Burkey )
Subject: Re: Atari/Perihelion Transputer Machine Spec
To: info-atari16@score.stanford.edu
If I hadn't seen the exact same CD-ROM being displayed in several
non-Atari booths (i.e. for the IBM PC) I would be skeptical about
whether it would ever make it out either. My only concern is that
it sells for $999 on the PC. It really was the same unit, too. Only
the case color was different. As for the Transputer, I was really
impressed with the progress they (Perihelion) had made. We have some
Transputer's at work (boards for the AT) that are pretty loosely
integrated (kind of like an exerciser kit), and the ABAQ definitely
had progressed far beyond that. I ALMOST ordered the $100 set of
preliminary manuals to become a developer (I can think of lots of
CAD tools that would be nice to port...Place and Route Previewers,
GDSII compatible layout editors, etc...but I couldn't get any good
feel for what the final costs would be to get a full set of developer
hardware.) If any of people actually do order the kit, let us on the
net know how it looks.
-Todd Burkey
trb@stag.UUCP <--faster path
or tburkey@eta.swde.com <--shaky sun<->apollo (I want Aegis 10!)
P.S. I just got through porting HDSCAN to my Symmetrics, the Apollo,
and the Sun. It runs very nicely on any standard 4.2 system (kind
of slow on the Apollo...usable on a 3000). After I clean up a few
things and add some more sort options (gid/uid/other times?) I
will have to decide if I am going to make it public domain at the
source level or what...BTW, it takes a lot longer to traverse
trees using Unix opendir/readdir/stat calls than it does on the
ST ( 3 secs/30 megs on the ST vs 40 secs/24 megs on the SUN 3/60
with Eagle drives...>2 minutes for the same on the Apollo).
------------------------------
Date: 12 Nov 87 17:29:35 GMT
From: umn-d-ub!umn-cs!ems!nis!stag!daemon@speedy.wisc.edu (Dale Schumacher)
Subject: file i/o functions
To: info-atari16@score.stanford.edu
Hopefully the following will help clear up the confusion about file i/o
functions...
Fread() is one of the macros which calls Gemdos through trap #1. This is
an exerpt from the <osbind.h> file containing there macros:
#define Fcreate(fn,mode) gemdos(0x3C,fn,mode)
#define Fopen(fn,mode) gemdos(0x3D,fn,mode)
#define Fclose(h) gemdos(0x3E,h)
#define Fread(h,cnt,buf) gemdos(0x3F,h,cnt,buf)
#define Fwrite(h,cnt,buf) gemdos(0x40,h,cnt,buf)
#define Fdelete(fn) gemdos(0x41,fn)
#define Fseek(where,h,how) gemdos(0x42,where,h,how)
These functions work much like the standard low-level i/o calls. They
use a small integer (returned by Fcreate/Fopen) called a file handle to
refer to the file (the 'h' parameter in other calls). As was mentioned,
the parameter order is different from the standard low-level i/o calls,
and the 'cnt' parameters are long values rather than the int than is normally
used. The following are macros which define some of the low-level i/o
calls in terms of their Gemdos equivalents.
#define open(filename,iomode) ((int)gemdos(0x3D,filename,iomode))
#define close(h) ((int)gemdos(0x3E,h))
#define read(h,data,len) ((int)gemdos(0x3F,h,((long)(len)),data))
#define write(h,data,len) ((int)gemdos(0x40,h,((long)(len)),data))
#define lread(h,data,len) (gemdos(0x3F,h,len,data))
#define lwrite(h,data,len) (gemdos(0x40,h,len,data))
#define unlink(filename) ((int)gemdos(0x41,filename))
#define lseek(h,where,how) gemdos(0x42,where,h,how)
#define tell(h) gemdos(0x42,0L,h,1)
The creat() call is notably missing from the above due to a bug in the
underlying gemdos 0x3C function which sometimes creates a new file with the
same name as an existing file instead of overwriting the old file. Thus
creat() is implemented as a function something like this:
int creat(filename, pmode)
register char *filename;
register int pmode;
{
register int rv;
rv = Fdelete(filename);
if((rv == 0) || (rv == -33)) /* SUCCESS or FILE-NOT-FOUND */
rv = Fcreate(filename, pmode);
return(rv);
}
Now we come to the fread()/fwrite() functions. These are standard i/o
functions which deal with STREAMS rather than simply with FILE HANDLES.
Unlike the above, these functions provided buffering and translation of
newlines, if desired. They are used with fopen()/fclose() functions.
The fopen() function returns a pointer to a FILE structure, which contains
information about the stream that was opened. The fopen() function also
handles the open()/creat() distinction, creat()ing a file if is doesn't
already exists, etc. As was said before, this kind of processing does
make the i/o a little slower, but also easier to use. The fputc()/fgetc()
functions are normally used with streams (getchar()/putchar() are written
in terms of fputc()/fgetc()) to do i/o a character at a time, while
internally buffering the calls to prevent a system call for every character
processed (which would be slow). The fread()/fwrite() functions do
block i/o on streams, and are buffered just like single characters.
In summary, you should avoid using Gemdos calls directly, since it is not
portable and it doesn't gain you any speed. Use the low-level i/o if you're
really concerned about speed and use the stream i/o functions if you're
doing mostly character or string i/o and/or want the buffering done efficiently
for you.
The preceeding examples were taken from the dLibs public domain standard
library for Alcyon C. This implmentation is far freer of bugs and much
more efficient in general than the Alcyon/DRI libraries. dLibs also contains
many Un*x standard functions which were not included in Alcyon/DRI. You
can get a copy of dLibs with complete source code and documentation by
sending $3 to:
Dale Schumacher
399 Beacon Ave.
St. Paul MN 55104
Of course, I won't refuse donations of >$3, but I need to at least break
even with buying the disks and mailers and sending them.
Dale Schumacher
..ihnp4!meccts!stag!syntel!dal
(alias: Dalnefre')
------------------------------
Date: 14 Nov 87 00:12:41 GMT
From: imagen!atari!portal!cup.portal.com!ANKH@ucbvax.Berkeley.EDU
Subject: Re: Worst product name award
To: info-atari16@score.stanford.edu
Moses *did* reach the Promised Land, but he was not allowed to enter it
because he disobeyed God in the wilderness. He died on a mountain just
outside the land.
------------------------------
Date: 13 Nov 87 23:58:41 GMT
From: imagen!atari!portal!cup.portal.com!ANKH@ucbvax.Berkeley.EDU
Subject: Re: Hard drive problems
To: info-atari16@score.stanford.edu
I logged onto the ICD support bbs and saw their listing of products. The
ADAPTEC controller that they are using is 4070A (note the 'A') This may
seem that is same as 4070, but it's quite possible that it is quite a
different thing than you need. Call their bbs and leave mail or whatever
to see if you can get help. The # is 1-815-968-2229. Good Luck
------------------------------
Date: 13 Nov 87 22:49:07 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU (Neil Harris)
Subject: Re: Lies (was: Re: Atari/Perihelion Transputer Machine Spec)
To: info-atari16@score.stanford.edu
> >A single transputer can deliver over ten times the power of
> >an IBM PC AT. However, there's even greater strength in numbers. You can
> >connect two, 10, 100 or even MORE transputers to create a relatively
> >low-cost computer workstation with the power of a supercomputer.
>
> False. The "standard" number of Transputers on the ABAQ system is 1 (ONE).
> The maximum is 13.
Internally.
The ABAQ includes 3 "links", which are 10-megabit-per-second serial
interfaces for talking to off-board transputers.
Jack Lang, in his talk at the Atari press conference at Comdex, supposed a
setup where workers each had their own transputer system on their desks,
with all of them linked together and linked to a separate box containing
many transputers. As an application's need for processing power increased,
it could pull more transputers in. An intriguing concept -- throw the
computer into high gear.
--
--->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: 13 Nov 87 22:26:07 GMT
From: phri!dasys1!schuster@NYU.EDU (Michael Schuster)
Subject: Re: PC-ditto
To: info-atari16@score.stanford.edu
In article <24821L9D@PSUVMA> L9D@PSUVMA.BITNET writes:
>Does anyone know how to get PC-ditto to work with a monochrome monitor? I've
>read that a lot of other people are having problems with using monochrome,
>and I am wondering if a fix has been made yet?
The current version works only with a color monitor as the packaging states.
There is a zap to 'turn on' the screen in a monochrome system but it is
NOT a fix and the resulting screen is barely readable.
Version 3.0 is at the duplicating house. It features mono support, Microsoft
mouse emulation, TOS time/date transfer, bug fixes, etc.
To get it -- SEND IN YOUR REGISTRATION CARD.
--
l\ /l' _ Mike Schuster {sun!hoptoad,cmcl2!phri}!dasys1!schuster
l \/ lll/(_ Big Electric Cat schuster@dasys1.UUCP
l lll\(_ New York, NY USA DELPHI,GEnie:MSCHUSTER CIS:70346,1745
------------------------------
End of Info-Atari16 Digest
**************************
-------
Technical Details
Message-ID:
<8711160057.AA05601@ucbvax.Berkeley.EDU>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!ucbcad!ucbvax!UOFMCC.BITNET!PostmanShow Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!ucbcad!ucbvax!UOFMCC.BITNET!Postman From: Postman@UOFMCC.BITNET Newsgroups: comp.sys.atari.st Subject: Undelivered mail Message-ID: <8711160057.AA05601@ucbvax.Berkeley.EDU> Date: Sun, 15-Nov-87 19:36:00 EST Article-I.D.: ucbvax.8711160057.AA05601 Posted: Sun Nov 15 19:36:00 1987 Date-Received: Tue, 17-Nov-87 00:47:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 408