Postmaster%ADMIN@UNCAEDU.BITNET (12/05/87)
Message undeliverable and dequeued after 3 days:
WRSturm@INS.#DECnet: Cannot connect to host
------------
Received: from UcEdu.UNCA.AdhocNet.CA by ADMIN; Wed 2 Dec 87 14:03:01-MDT
Received: from CANADA01 by UNCAEDU.BITnet via BITNET ;
Wed, 2 Dec 87 13:24:27 MST
Received: From CANADA01(MAILER) by UNCAEDU with RSCS id 5971
for RFORSTER@UNCAEDU; Wed, 2 Dec 87 12:40 MDT
Message-Id: <871202132429.06d@UcEdu.UNCA.AdhocNet.CA>
Received: by CANADA01 (Mailer X1.24) id 5929; Tue, 01 Dec 87 23:25:18 EDT
Date: Tue 1 Dec 87 16:50:00-PST
Reply-To: <Info-Atari16@Score.Stanford.edu>
Sender: INFO-ATARI16 Discussion <INFO-A16@CANADA01>
Comments: Resent-From: William "Chops" Westfield <BILLW@Score.Stanford.EDU>
Comments: Originally-From: Info-Atari16 Digest
<Info-Atari16@Score.Stanford.EDU>
From: William Chops Westfield <BILLW@SCORE.STANFORD.EDU>
Subject: Info-Atari16 Digest V87 #392
Comments: To: info-a16%MARIST.BITNET@WISCVM.WISC.EDU
To: name unknown <EDSTROM@UNCAEDU>,
"'Russell M. Forster'" <RFORSTER@UNCAEDU>
Info-Atari16 Digest Friday, October 30, 1987 Volume 87 : Issue 392
This weeks Editor: Bill Westfield
Today's Topics:
Re: Questions about Publishing Partner
Atari CD-ROM to be shown at Comdex
Re: Empire
Re: Atari/Perihelion Transputer Machine Spec
where to post
floating-point format
Re: Info-Atari16 Digest V87 #382
Sizes and types (was: 32bit = 16bit x 16bit)
----------------------------------------------------------------------
Date: 27 Oct 87 21:17:00 GMT
From: apollo!weber_w@EDDIE.MIT.EDU (Walt Weber)
Subject: Re: Questions about Publishing Partner
To: info-atari16@score.stanford.edu
In article <483@tnosel.UUCP> remco@tnosel.UUCP (Remco Bruyne) writes:
>I have a few questions about Publishing Partner:
> 1) Are more fonts available than the standard delivered ?
Yes - they can be purchased directly from SoftLogic, or a dealer can
purchase at discount and sell at retail. Clip art (both mono and color)
is also available, in DEGAS format. Included are newer printer drivers,
which require PP version 1.02 to execute properly.
> I always use postscript output; does this have consequences for
> the files you need to use a specific font ?
I don't believe so, since the existing fonts are drawn on the output page,
and not printed as characters.
> 2) Can fonts only be used for postscript output when the laserprinter
> supports the required font or can a font be downloaded ?
One of the newer postscript drivers includes screen fonts for fonts which
exist in the laserprinter's local memory, and a driver which uses the
correct commands to invoke the resident fonts. I do not believe there is
support WITHIN PUBLISHING PARTNER for downloading of fonts, but you might
be able to insert a "header" to the file which would give postscript commands
to remap a font you had already loaded to an existing font, which would then
be called by your PP-generated postscript output file.
> 3) Can text which is routed from column A to column B be un-routed
> (i.e. can all text be put back in column A) ?
Does it still show the "text overflowed" icon at the bottom of the column?
If yes, have you tried changing the point size of the entire column until it
all fits? I do not recall any specific problems here, so this is the approach
I would take in investigating the issue.
--
Walt Weber PHONE: (617) 256-6600 x7004
Apollo Computer GENIE: W.WEBER
Chelmsford, People's Republic of Massachusetts
------------------------------
Date: 27 Oct 87 20:13:26 GMT
From: voder!kevin@ucbvax.Berkeley.EDU (The Last Bugfighter)
Subject: Atari CD-ROM to be shown at Comdex
To: info-atari16@score.stanford.edu
In the Monday, October 26 issue of Electronic Engineering Times there is
an article on page 49 on the new Atari CD-ROM drive which Atari is expected
to show at the Comdex show next week. The half-height drive is slated for
U.S. delivery before the end of the year and may be in the $500-$650 range.
The drive will feature an SCSI-like port that will allow it to link to
both the Atari PC and the ST series and, with slight modifications, other
systems. The drive is being supplied by an unnamed Japaneses manufacturer
and will also have stereo audio playback for use with CD laser-audio disks.
The article also mentions the Apple CD-ROM but gives no introduction date.
--
Kevin Thompson {ucbvax,pyramid,nsc}!voder!kevin
"It's a sort of threat, you see. I've never been very good at them
myself but I'm told they can be very effective."
------------------------------
Date: 27 Oct 87 20:23:41 GMT
From: PT.CS.CMU.EDU!andrew.cmu.edu!ws1i+@cs.rochester.edu (William Manchester
Shubert)
Subject: Re: Empire
To: info-atari16@score.stanford.edu
I have a public domain version of Empire...well, at least the listings. I
know the guy who ported Empire to C on the IBM, then took a bunch of his
listings, and moved them to the ST. They worked, but just barely (although
they were amazingly fast...it seems that since Empire took up more than 64K
it ran very slow on the IBM, so on the ST it was blinding.)
Anyway, I was never much of a fan of Empire, so since it still had a few
problems I sort of gave up. If anybody really really wants the listing (to
finish the job) send me mail. The listing is NOT public domain, so I would
first have to ask my friend for permission.
PS - What doesn't work is the "?" command and saving/loading.
------------------------------
Date: 27 Oct 87 00:32:23 GMT
From: xanth!kent@ames.arpa (Kent Paul Dolan)
Subject: Re: Atari/Perihelion Transputer Machine Spec
To: info-atari16@score.stanford.edu
Yeowie! I want to see this thing with a 3D joystick, roaming the
Mandelbrot set in real time and 16 colors at > 1K x 1K resolution.
Whee! What the heck, how about _two_ joysticks, 1, 3D and 1, 2D, and
we can take a wild cruise through the Julia sets, or that 4D version
of the Mandelbrot set hinted at in the last Scientific American
Computer Recreations column. If it's fast enough, and will do NTSC
out of that 512 x ? x 32 bpp mode, you could preprogram a cruise and
record it in real time without worrying about single frame video.
Awesome! I may actually have to work for a living for a few months to
scrape together the price.
(Naaah, calm down Kent; you're getting irrational again. ;-)
Kent, the (totally weird) man from xanth.
Running for president on a pound of caffeine, an ounce of sense, and a
program of increased exploration and exploitation of space. Support
your (probably non-existent - get busy!) local branch of the Birthright
Party: "The birthright of mankind is the stars!"
Hey, it's better than dwelling on your stock portfolio; at least here
you've got a chance for a laugh or two. ;-) Yum! Eat them plastic
chickens, brethren! Call me when I'm elected; 'til then, I'm going to
take a nap.
------------------------------
Date: 27 Oct 87 23:38:27 GMT
From: phoenix!mpsimon@princeton.edu (M. Patrick Simon)
Subject: where to post
To: info-atari16@score.stanford.edu
In a recently posted article on comp.sys.atari.st Dale Schumacher writes:
....
> I've sent direct mail to a few people, including Jim Turner, about how
>I should make sources for MicroEMACS 2.18 and dLibs v1.0 available to the
>largest number of people. So far I've gotten no responses which included
>any directions for posting procedures I should follow. The only reponse
>I did get suggested reaching Jim Turner.
> I've received requests from a few people for these sources and would
>very much like to fill those requests, but would like to avoid using the
>postal service if possible. This "node" is an ST running my own implmentation
>of something like UUCICO, so I can't FTP, etc., but I can do direct mail.
>Would someone please send me directions for posting this code?
>
> Dale Schumacher
> ..ihnp4!meccts!stag!syntel!dal
> (alias: Dalnefre')
The following are the various ways I have seen mentioned to post something:
1. The ATARINET subserver on bitnet has the following three lines in the
index file:
+** ATARINET is a subserver of UH-INFO **
+** Send comments and files for **
+** ATARINET to UACE0 at UHUPVM1. **
Keep in mind that this is on bitnet (so mail would go to
UACE0@UHUPVM1.BITNET). Also, if you post to ATARINET, you
might want to seek out a volunteer with interactive bitnet
access to test the validity of your posted program as it appears
on the server. (Occasionally, ATARINET has a corrupted file
on its public distribution list.)
2. The following message appeared on comp.sys.atari.st a while ago. Note that
all addresses mentioned refer to arpanet, so from a non arpanet site, you
would need to append .ARPA to the end of each e-mail address.
+The Arpanet/DDN archives for the atari are ready for use. FTP to
+RADC-SOFTVAX, and login as GUEST with password GUEST. The current list
+of files is 'atari16/files.doc', GET this file for an updated list of
+what's available. If anyone has a particular program they want, send a
+message to us, and we'll see what we can do. The maintainers of the
+archives are: Rodney Peck (Peck@RADC-MULTICS) and Marc Poulin
+(Poulin@RADC-MULTICS). Enjoy.
+ >>Marc
+-----------------------------------------------------------------------------
+ Marc C. Poulin AT&T: (315)336-7564
+ MicroByte Distributors ARPA: Poulin@RADC-MULTICS
+ 6480 Monument Road Archive@RADC-SOFTVAX
+ Rome, NY 13440-7210 CIS: 72737,2703
+-----------------------------------------------------------------------------
+ 'Xerox your lunch and file it under "sex offenders!"'
+ -Zippy
3. Score, the machine that info-atari16 flows from/through, also has a
public domain library that is ftp'able. I am not sure how to post to
that archive, but I suggest you send an e-mail message to
INFO-ATARI-REQUEST@SCORE.STANFORD.EDU asking for instructions.
4. LISTSERV@CANADA01 and LISTSERV@FINHUTC are servers that keep track of
info-atari16 articles and I am not sure what all else. I don't use these
because I have never really needed to. Both of them are on bitnet (add
.BITNET to the mailing address). Also, I think FINHUTC is in Europe, so
if your programs will not run on European machines, I would suggest you
not post there.
5. The following article was posted to comp.sys.atari.st not too long ago:
+Article 3933 of comp.sys.atari.st:
+Path: phoenix!princeton!udel!rochester!bbn!husc6!cmcl2!rutgers!sri-spam!ames!
+ amdcad!sun!imagen!atari!daisy!turner
+From: turner@daisy.UUCP (D'arc Angel)
+Newsgroups: comp.sys.atari.st
+Subject: comp.*.atari.st
+Message-ID: <572@daisy.UUCP>
+Date: 26 Oct 87 15:30:26 GMT
+References: <8710191910.AA16187@ucbvax.Berkeley.EDU>
+Organization: The Houses of the Holy
+Lines: 36
+
+>
+> When someone says he has posted a program to comp.binaries.atari.st, just
+> what does that mean? Where is it? How does on access it? Is it accessible
+> from arpanet?
+
+comp.binaries.atari.st and comp.sources.atari.st are moderated newsgroups
+(by yours truly) for the postings of (i'll bet you guessed) source programs
+and binaries fot the atari st series. If a program is posted by me it means
+that i have tested it (to the best of my abilities), put it into a packaged
+form (arc or shar), unpackaged it just to be sure, checksummed the pieces,\
+and finally posted it.
+
+I am also currently mailing all postings to ...umix!hyc (Howard Chu) who
+has promised to make them available on alternate nets.
+
+other archive sites are INFO-ATARI16 and UHACE, i'm sorry to say that i've
+forgotten the full addresses to those sites
+
+To submit a program(s) for posting please mail to:
+
+....{ucbvax|decwrl}!imagen!atari!daisy!turner
+
+or
+
+....nsc!daisy!turner
+
+If you need copies of arc or uudecode/uuencode to decode the posting, please
+send me email
+
+I hope this helps...
+
+--
+C'est la vie, C'est la guerre, C'est la pomme de terre
+...{decwrl|ucbvax}!imagen!atari!daisy!turner (James M. Turner)
+Daisy Systems, 700 E. Middlefield Rd, P.O. Box 7006,
+Mountain View CA 94039-7006. (415)960-0123
+
I hope you have better luck translating addresses like ...!daisy!turner
than I do. I think these operate for a different network than the one
I am on. In any event, I am pretty sure that turner can be
reached at TURNER@DAISY.UUCP. Please note that
for whatever reason (new job hopefully) Jim Turner seems to be running
a bit behind schedule (i.e. it may take a few weeks from the time you
mail to him until he posts; I assume this is because he is busy but also
because he checks everything that is posted to make sure it works).
Good luck. I hope something is this little note is of some help.
--Patrick Simon mpsimon@phoenix.princeton.edu 10-27-87
------------------------------
Date: 28 Oct 87 01:56:19 GMT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Subject: floating-point format
To: info-atari16@score.stanford.edu
While in the process of trying to find out why my Lisp cross-compiler
wouldn't handle floating point constants properly, I found a goof in
the Alcyon C V4.14 documentation. It claims that, in the Motorola FFP
format, the exponent in bits 0..6 is stored in its two's complement
representation, but in reality it appears to be biased by 64 and stored
as an integer in the range 0..127. Bit 7 is the sign bit and the unsigned
mantissa is in bits 8-31; there is no "hidden bit".
-Sandra
------------------------------
To: Info-Atari16@SCORE.STANFORD.EDU,
Subject: Re: Info-Atari16 Digest V87 #382
In-Reply-To: Your message of Mon 26 Oct 87 14:07:53 PST.
Date: 27 Oct 87 08:33:41 PST (Tue)
From: kend%tekchips.tek.com@RELAY.CS.NET
PLEASE REMOVE ME FROM YOUR MAILING LIST
------------------------------
Date: 28 Oct 87 04:20:12 GMT
From: eris!mwm@jade.Berkeley.EDU (Mike (My watch has windows) Meyer)
Subject: Sizes and types (was: 32bit = 16bit x 16bit)
To: info-atari16@score.stanford.edu
[Followups have been pointed to net.lang.c.]
In article <3626@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes:
<In article <2262@sfsup.UUCP> mpl@sfsup.UUCP (M.P.Lindner) writes:
<>3. as for the people who say "Never use the basic types", I say the following:
<> 1. use "char" to mean a character or a byte (guaranteed in K&R)
<
<Use char to mean a character. Use "typedef char applicationtype" when the best
<implementation for the intended use happens to be a char on your machine. My
<six bit char may not give the range you assumed because of your chars are
<twelve bits.
<
Sigh. This seems to come up every so often, and generates the same
discussion each time. Why not go right to the end this time?
First, lets discuss sizes. K&R says that shorts are no bigger than
ints, and longs are no shorter than ints. dpANS adds that shorts are
at least 16 bits, and longs at least 32. Since K&R alone allows a
simple a 2-bit typefor short, int and long, it's kind of useless. So
we'll assume the dpANS.
Given those sizes, the "simple" rules are as follows (MP linder got
them right).
1. Use "char" to mean characters, or bytes.
2. Use "short" for small integers which need to be small.
3. Use "int" for small objects for which size doesn't matter.
4. Use "long" for anything that won't fit in 16 bits.
Now, some notes:
1) Never use "char" to hold something being used as an integer. You
have no idea how big it may be on some other machine. Of course, if
something external requires a byte instead of a short for such, you
have no choice.
2) "Small" integers fit in 16 bits. If they don't fit in 16 bits, use
long, period.
3) ints should be the fastest type that holds at least 16 bits.
Unfortunately, dpANS kept the K&R "most natural" wording, which means
there may be environments where ints *aren't* the fastest type.
The above will mean your code ports to dpANS compilers with no
problem, except for longs > 32 bits on your machine. Also, if your
machine doesn't look like an "ansi" machine (18 bit shorts, say), then
you may not be getting the best type for the machine. To avoid that,
you can add a level of artificial types between the compiler and your
code.
To wit, you create typedefs for "int#" and "uint#". These types are
signed (unsigned) ints with # bits of magnitutde. This kind of thing
is trivial to do. For instance the following works for most
byte-addressed machines with eight-bit bytes:
typedef signed char int1, int2, int3, int4, int5, int6, int7;
typedef unsigned char uint1, uint2, uint3, uint4, uint5, uint6, uint7, uint8;
typedef signed short int8, int9, int10, int11, int12, int13, in14, int15;
typedef unsigned short uint9, uint10, uint11, uint12, uint13, uin14, uint15,
uint16;
typedef signed long int16, int17, int18, int19, int20, int21, int22, int23,
int24, int25, int26, int27, int28, int29, int30, int31;
typedef unsigned long uint17, uint18, uint19, uint20, uint21, uint22, uint23,
uint24, uint25, uint26, uint27, uint28, uint29, uint30,
uint31, uint32.
Include the file (which should be tuned for your machine, and then
declare everything that needs to be larger than 16 bits, or everything
for which being small is important, of the type appropriate for it's
size. For things that fit in 16 bits for which size doesn't matter,
use int. Portability to any architechture that supports the limits
you've chosen, and (if the file is set up right) you get the smallest
size that works correctly for your application.
Notes again:
1) I chose the smallest size for each that worked. Things for which
size matters win this way. Small things that need to be fast wind up
as int. So all that's left is things larger than 16 bits that need to
be fast. Doing "fint#" and "fuint#" would be possible, but it's not
clear how useful such is.
2) Not an int# is # bits of *magnitutde*. Thus, there's no int32 on a
machine with 32 bit longs. Likewise int16 needs to be a long, and int8
needs to be a short.
3) I violated the rule about using chars as small integers. But the
file is set up on a per-machine basis, and so should be right for the
machine you're on.
4) This obviously takes care of machines with odd-sized words not
getting the smallest size that works under the simple rules. However,
it also helps with the problem of applicatins that really need longs
larger than the dpANS minimum, because those types won't exist on
machines that don't support them. The resulting code dies at compile
time when moved to such a machine, and names the variables that need
more bits than they can get. While not as good as running correctly
and dieing on overflows, this is much better than producing incorrect
results when the "long" would have overflown.
Finally, as Lawrence Crowl notes, you should use typedefs for
applications sizes whenever it's appropriate. If you're following the
simple rules, this makes it easier to change the code to take
advantage of odd-sized words on machines that have them. It leads to
more readable code in either case.
The sized int rules are still a win even if everything is typedef'ed
to some application name, because 1) the size used by the object is
always documented, and 2) all the size-specific types can be fixed by
editing one short file.
<mike
--
[Our regularly scheduled .signature preempted.] Mike Meyer
The Amiga 1000: Let's build _the_ hackers machine. mwm@berkeley.edu
The Amiga 500: Let's build one as cheaply as possible! ucbvax!mwm
The Amiga 2000: Let's build one inside an IBM PC! mwm@ucbjade.BITNET
------------------------------
End of Info-Atari16 Digest
**************************
-------
-------