Info-Atari16@SCORE.STANFORD.EDU (Info-Atari16 Digest) (11/05/86)
Info-Atari16 Digest Wednesday, November 5, 1986 Volume 86 : Issue 6
This weeks Editor: Bill Westfield
Today's Topics:
Re: Advertising methods
RE: Limit on number of files on Atari disks?
Re: Redirection of stdout and chaining
Pascal programming
UNITERM documentation
signing up
Re: 1040 & composite monitors
New ST models?
Re: GDOS, GDOS, GDOS, GDOS ...
Re: GDOS, GDOS, GDOS, GDOS ...
----------------------------------------------------------------------
Date: 3 Nov 86 16:35:36 GMT
From: oyster@unix.macc.wisc.edu (Vicarious Oyster)
Subject: Re: Advertising methods
To: info-atari16@score.stanford.edu
In article <2322@princeton.UUCP> chiu@princeton.UUCP (Kenneth Chiu) writes:
>In article <426@uwmacc.UUCP> oyster@uwmacc.UUCP (Vicarious Oyster) writes:
>>In article <1142@tekigm2.UUCP> wrd@tekigm2.UUCP (Bill Dippert) writes:
>>>. . .personally I hate mice and windows with a passion.
>>
>> Me too, at least as a development environment. That's why I use Micro
>>C-Shell. However, for some applications (end-user programs, editors, games,
>>etc), a windowing system is ideal. It's nice to have the flexibility; it's
>>even nicer to be able to push the mouse aside and get some *real* work done.
>
>Are you saying that you would rather program on a 24 x 80 terminal than a 19"-
>screen, bit-mapped workstation? (e.g. Sun)
Huh? Are you saying that green cheese falls from the sky in .6 micron
spheroids? Can you say confused? How about non sequitur?
.....
Just to keep this Atari-related, a question:
Why are things like ST Rogue usually advertised using grungy IBM screen
photos? The ST version is wonderfully detailed, and is almost worth the
price just to admire the artwork. The IBM version uses those silly
IBM screen "graphics" characters, while the ST has individual mini-icons
for the rogue, for each type of monster (they even all have shadows!), and
for each type of item or trap, as well as good representations of passageways
(with cobblestones) and rooms (rather than the IBM/mainframe style of dots
and dashes). Even the Atari Explorer (BTW, nice pic, Neil...) had an IBM-style
photo along with the ST Rogue article. Why give people a poor impression of
a nice machine and superior version of the software?
--
- Joel Plutchak
uucp: {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster
ARPA: oyster@unix.macc.wisc.edu
------------------------------
Date: Tue, 04 Nov 86 01:50:39 GMT
To: info-atari16@su-score.ARPA
From: K538915%CZHRZU1A.BITNET@WISCVM.WISC.EDU
Return-Receipt-To: K538915@CZHRZU1A.BITNET
Subject: RE: Limit on number of files on Atari disks?
Yes, the limit on the number of files in the ROOT directory is 112 (just like
on a IBM-PC or so), but you should be able to but as many as you want in to
a Subdirectory (this is naturally limited by the size of the FAT, but you
wont have that many files:-)).......the nasty thing is that it bombs on you...
BTW it seems as if the file_selector can only handle 112 entrys as well....
which is very annoying with the large directorys you have to have with a hard
disk (when is this going to be fixed?). More reading on the structure of
MS-DOS or TOS Disks -> Norton's Inside the IBM PC.
Simon
------------------------------
Date: Mon, 03 Nov 86 11:24:26 PLT
From: Don Howes <HOWESDW%WSUVM1.BITNET@WISCVM.WISC.EDU>
Subject: Re: Redirection of stdout and chaining
To: INFO-ATARI16@SU-SCORE.ARPA
Stdout can be redirected using "freopen()". The documentation for the
Alcyon compiler is very terse about this function, but a good description
is given in Harbison & Steele (p. 192 I believe). The freopen() function
is normally used to reassign the stream handles for stdin, stdout or
stderr to another stream (generally a file). Note that freopen() will
return a NULL pointer on failure or the stream handle if successful. Also,
freopen() will *always* close the input stream, even on failure, so be
careful.
A generalized stream redirection function can be written as follows (I
haven't had a chance to test this, since my machine is down):
FILE *redirect(infile,outfile,mode)
FILE *infile;
char *outfile, mode;
{
FILE *stream, *freopen();
if ((stream = freopen(outfile,mode,infile)) == NULL)
{
fprintf(stderr,"Could not redirect to file %s\n",outfile);
return(NULL);
}
else
return(stream);
} /* end of redirect() */
a use of this function to redirect stdout would be:
main()
{
FILE *redirect(), *str_ptr;
.
.
/* some stuff */
if ((str_ptr = redirect(stdout,"errors.txt","w")) == NULL)
.
.
/* some more stuff */
}
I wasn't able to find out any information about whether the Alcyon compiler
sets any error flags. It must do so internally, but I don't know whether
those would be available to an external program. If an error flag is set
in the CPU, then things would be set. Does anyone out there have any
info on the compiler operation?
Don Howes BITNET: HOWESDW@WSUVM1
------------------------------
Date: Mon, 03 Nov 86 21:25:07 PLT
From: Brian Henry <20370843%WSUVM1.BITNET@WISCVM.WISC.EDU>
Subject: Pascal programming
To: Atari Mailing List <info-atari16@score.stanford.edu>
Does anybody out there have experience using Personal Pascal? I would
like to try using sprites with it but need a way to define them. As far
as I can tell, Pascal doesn't have any facility for including data with
the program--- It would be nice to have a segment of the program devoted
just to the hex data for some sprite without using a separate assignment
statement for every byte. This problem extends to other areas as well,
such as perhaps storing instructions for a program without having a bunch
of WRITELN statements. If I haven't made myself clear yet, what I want
is the equivalent of a DC.W statement for Pascal.
Thanks in advance for comments.
--B. Henry
------------------------------
Date: 3 Nov 86 15:29:20 GMT
From: ihnp4!inuxc!inuxj!wolenty@ucbvax.Berkeley.EDU (R Wolenty)
Subject: UNITERM documentation
To: info-atari16@score.stanford.edu
In shuffling versions of code around it seems I inadvertantly deleted
the documentation files for UNITERM. Could someone please mail me
a copy of the documentation? I have been using version 1.5 with
no problems and would also like to add my kudos to Simon Poole for
job well done.
Ron Wolenty
------------------------------
Date: 3 November 86 18:20 CST
From: hacee%uno.BITNET@WISCVM.WISC.EDU
To: info-atari16@su-score
Subject: signing up
Dear Atari16,
This is my second attempt at getting on a mailing list on arpanet and so I'm
not too sure how to go about it . Maybe this time I'll be more sucessfull.
I'm not too sure how these lists work but I'm willing to try it.
I own an atari 520st which I've had since july '85. It's my second one
actually (the first one, may it rest in peace, was replaced by atari
last month for $95.00).
If there are programs that I can download I'm hoping that I can find out how
to do this. I am also interested in networking ST's.
If perhaps this letter is ending up in the wrong place please drop me a line
and tell me what's happening. I wonder if there are any special things which
have to be done since I'm coming from Bitnet.
Howard Chandler
University of New Orleans
------------------------------
Date: 4 Nov 86 07:47:12 GMT
From: jpexg@HERMES.AI.MIT.EDU (John Purbrick)
Subject: Re: 1040 & composite monitors
To: info-atari16@score.stanford.edu
> Does anyone know for certain if a 1040 will output a color composite
> signal? I know a 520 will (I have a friend with a 520 who hooks it up
> to a composite monitor), but my 1040 doesn't seem to output composite,
> even though the pin diagram in the back of the 1040 manual indicates
> that it should. I read a short piece in Compute's ST magizine that
> said 1040's don't have composite, only 520's do. My dealer doesn't
> know. Help please -- my monochrome screen is extra sharp & nice, but I'd like
> to see FujiBoink at least once on my own ST.
> Whom: Rick Westerman Phone: +1-317-494-8341
Maybe sometime in the future, but not now. This really ticked me off when I got
my 1040. The decision to release them without composite or RF output seems to
have been made at the last minute, as the manual shows you where to hook it up,
and there's a different texture in the plastic at the rear of the case where
the RF output ought to be. Plus they give Neochrome away with the computer so
you can watch it not work on a mono screen. If someone knows a way to get
composite output I'd like to know how.
------------------------------
Date: 3 Nov 86 20:49:26 GMT
From: ihnp4!inuxc!iuvax!ndmath!milo@ucbvax.Berkeley.EDU (Greg Corson)
Subject: New ST models?
To: info-atari16@score.stanford.edu
There was a short note in this month's BYTE magazine mentioning that Atari had
released a 2 and 4 megabyte version of the ST in europe somewhere. Does anyone
out there (ATARI??) have some more information on this? The new machine was
said to have a bit-blit chip. I would be very interested to know if there
are any new graphics modes with more colors/higher resolutions.
Greg Corson
{pur-ee,seismo}!iuvax!kangaro!milo
------------------------------
Date: 3 Nov 86 18:00:42 GMT
From: imagen!atari!neil@ucbvax.Berkeley.EDU (Neil Harris)
Subject: Re: GDOS, GDOS, GDOS, GDOS ...
To: info-atari16@score.stanford.edu
In article <8610302053.AA05161@ames-prandtl.ARPA>, getty@AMES-PRANDTL.ARPA
writes:
> I was in the store the other day looking at the Easydraw program, and I
> was suprised to discover that GDOS is being distributed with this program.
> Included with this GDOS were some fonts, device drivers, and a program named
> OUTPUT.PRG.
>
> After trying Easydraw I got a copy of PaintPro (Abacus) and tried running
> it. PaintPro simply would not run with GDOS installed on the system, but
> ran just fine when the system was booted without GDOS. The README file
> that comes with PaintPro claimed that it would work with GDOS installed.
Apparently the README file was wrong. We have been looking into the
compatibility issue, and have found some trouble spots -- one big problem is
that programs compiled with OSS Personal Pascal don't work with GDOS. We
have told OSS how to fix this.
> This all disturbs me. Apparently GDOS is already being given away in some
> form with commercial software, but you are telling us that we are going to
> have to pay money for it. Will the GDOS given away with software in the
> future be the same thing that is going to be sold for money separately?
Why should it disturb you? We are licensing GDOS for use with commercial
packages -- if you get the package, you get GDOS. The current thinking is
to package GDOS separately for consumers who want it.
EasyDraw uses a very early GDOS, under strict directions to their
programmers to use only the functions we explicitely told them were working.
The final version is complete now.
--
--->Neil @ Atari
...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil
BIX: neilharris CIS: 70007,1135 Delphi: NEILHARRIS
GENIE: nharris WELL: neil Atari Corp. BBS 408-745-5308
US Mail: Atari Corp.
1196 Borregas Ave.
Sunnyvale, CA 94086
"I'm a 20th century man but I don't want to die here." -- Ray Davies
------------------------------
Date: 3 Nov 86 23:07:33 GMT
From: tikal!slovax!michael@beaver.cs.washington.edu (Michael Longe)
Subject: Re: GDOS, GDOS, GDOS, GDOS ...
To: info-atari16@score.stanford.edu
Just for the record (I used to work for Migraph):
> The GDOS.PRG that Migraph has been sending ...
> is strictly a prerelease version ...
More accurately, it is strictly the only version that has been available
to an ST developer up to this point. Apparently it was a direct port by DRI
from the PC ("We Port Bugs"). Migraph requested it and DRI gave the go-ahead
to release it (and Output) with Easy-Draw.
> Migraph was apparently working in an IBM -> ST
> cross-development environment (the IBM PC version of GDOS/VDI works fine,
> I guess...) ...
No, on genuine first-generation 520's. Trying to do it from the PC would
have been even more of a nightmare. The PC version of GDOS works. Just.
Easy-Draw was the first program designed to use ALL of the features of GEM
(working or not!).
> Atari ...
> worked on getting Migraph a version of GDOS that worked
> well enough to get EasyDraw out the door.
Atari did all they could to help, under the circumstances (some of this
stuff was apparently never explicitly licensed to Atari by DRI). They
also helped Migraph *beg* DRI for the changes we all may receive shortly.
> Don't get too upset at Neil and the rest of the folks at Atari... I
> would rather wait than get a GDOS that Atari has to continually fix.
Amen! I was the lucky person who got find some of the BUGS in that
version and report them to Atari and DRI. If all goes well, the new
version should include mulitple font loading, hard disk support, and none
of those silly boot-drive defaults (like OUTPUT.RSC and font files).
Incidentally, Migraph did not "give away" GDOS with Easy-Draw. Each
developer should make their own agreement with Atari and DRI, not take
the stuff off the Easy-Draw disk.
Finally, I suspect (and refer this to Neil for confirmation) that the
GDOS itself will not be the item for sale, but the *very expensive* fonts
and device drivers which it uses.
Michael Longe'
..!tikal!slovax!michael
------- standard disclaimer -------
Rumors are free and easy to give.
------- usual disclaimer --------
Qui, moi?
------------------------------
End of Info-Atari16 Digest
**************************
-------