Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 89 Issue 614
INFO-ATARI16 Digest Mon, 6 Nov 89 Volume 89 : Issue 614
Today's Topics:
>RE> Atrocious Atari Dealer (Zephyr/Microworld)
archive sites
DOES ATARI LASER PRINTER WORK ONLY WITH MORE THAN 1 MEG RAM STs:
floppy stepping rate
GEMDOS Extended Argument Spec (LONG)
GNU C and sizeof(int)
Micro Emacs 3.10
Prolog 10, Common LISP
TOS, Zoo, or Zen?
TOS, Zoo, or Zen? (DTA stuff)
Trying to read an Atari St Gem-Dos disk on a Mac SE using FD/HD
TT
unix on the TT
----------------------------------------------------------------------
Date: 7 Nov 89 01:46:53 GMT
From: tahoe!wheeler!mikew@apple.com (Mike Whitbeck)
Subject: >RE> Atrocious Atari Dealer (Zephyr/Microworld)
In article <8911060807.AA19911@ucbvax.Berkeley.EDU> UUCJEFF@ECNCDC.BITNET (jeff
beer) writes:
!!
!!Once home, I was filing the receipt away when I noticed that the total on
!!the receipt and the total on the charge slip didn't match... Upon closer
!!inspection, I discovered that I couldn't decipher the receipt at all!
!!
!I would protest this with your credit card company, showing the original
!receipt being different than the charge ticket. It is obvious Microworld is
!a shady outfit, and you should use all avenues to put persure on them.
!
!I will definitely stay away from Zephyr.
!
!Jeff
DITTO! I too have had trouble with these guys! But never again.
(Once fooled shame on them- twice fooled shame on me)
------------------------------
Date: 7 Nov 89 01:57:52 GMT
From:
cs.utexas.edu!samsung!shadooby!sharkey!math.lsa.umich.edu!hyc@tut.cis.ohio-stat
e.edu (Howard Chu)
Subject: archive sites
In article <1707@quiche.cs.mcgill.ca> depeche@quiche.cs.mcgill.ca (Sam Alan
EZUST) writes:
%I am trying to get ahold of FATSPEED. On xanth.cs.odu.edu the atari
%directory is empty.
%on him1.cc.umich.edu I downloaded about four files and all of the
%ones are .arc files which I can't extract due to bad headers.
%
%does anyone know
%1] why xanth's atari directory is empty?
%2] why I can't de-arc anything from him1?
%3] how I can get FATSPEED?
%
%thanks in advance.
I just checked, the copy of FATSPEED.ARC on HIM1 is perfectly fine.
You must not have downloaded it in binary mode. Or you must not have
ftp'd it in binary mode. No other explanation.
--
-=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1]
and You Too can have a Personal Electronic Relationship with God!
------------------------------
Date: 6 Nov 89 20:23:21 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: DOES ATARI LASER PRINTER WORK ONLY WITH MORE THAN 1 MEG RAM STs:
alderaan@tubopal.UUCP (Thomas Cervera) writes:
>(Imran Anwar) writes:
>> DOES ATARI LASER PRINTER NEED MORE THAN 1 MEG RAM ?
> Yep.
Nope. You can use the Diablo 630 emulator to get text output using any
GDOS font using practically no memory. While the page is being
imaged, the CPU is building band-buffers, keeping ahead of the beam.
You can't get GDOS output: the GDOS SLM driver needs to image the page
all at once, then print it, because it can't image bands fast enough
(they can be arbitrarily complex!).
Even the Diablo output has limits: if a line or group of lines
is too complex, it can't keep up. This isn't normally a problem,
but something like nroff/tbl output, with lots of overstrikes
and reverse linefeeds can cause trouble.
The Diablo emulator will also draw horizontal and vertical lines and
print bitmapped images anywhere on the page, as large as will fit in
memory, but it will magnify at 1x1, 2x2, and 4x4 printer pixels per bit
in memory.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 6 Nov 89 18:27:47 GMT
From:
cs.utexas.edu!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!larry!polyslo!vlsi
3b15!saic.com!steveg@tut.cis.ohio-state.edu (stephen harold goldstein)
Subject: floppy stepping rate
Try using the following program in your AUTO folder.
It works just fine with my 'official' (04 06 19 89) Rainbow TOS,
And sets the floppy step/seek rate to 6ms.
(Many thanks to the netter who orginally sent this to me when my old
step rate program 'died' upon TOS 1.4 installation...)
Stephen Goldstein steveg@saic.com
My first Atari system? A 24K Atari 800, Rev. A ROMS, C(not G)TIA graphics
Disclaimer: That's not what I said.
-------- cut here --------
begin 644 pcf554.prg
M8!H $B $AY C#\\ E.05Q/0J<_
M/ @3D%<3R\ /SP ("!X!/(~* "3D%<3[Y\ 0!G ! OGP! F< #!"9S\\
M $_/ I3DY<3S\\__\_/ !/SP *4Y.7$]*0&< !Q(>0 --@ 80?@*
M3& 9!~ H&0F@ !DAY ~C\\ E.05Q/0F=.04K\"@T@&W @(" @(" @
M(%!#1C4U-"!D<FEV97(@(" @(" @(!MQ"@T@0V]P>7)I9VAT(+T@,3DX."P@
M071A<FD@0V]R<"X*#0 @&W @0V]U;&1N)W0@<V5T(#9M<R!S965K(')A=&4A
M(!MQ"@T*#0 @&W @(" V;7,@<V5E:R!R871E('-E="!O;B!".B @(!MQ"@T*
M#0 EX:
8
end
--
Stephen Goldstein steveg@saic.com
My first Atari system? A 24K Atari 800, Rev. A ROMS, C(not G)TIA graphics
Disclaimer: That's not what I said.
------------------------------
Date: Mon, 6 Nov 89 20:43:19 EST
From: csrobe@cs.wm.edu (Chip Roberson)
Subject: GEMDOS Extended Argument Spec (LONG)
I was looking over the code in your article on the EAS posted in digest
V89 #595 trying to comprehend the method, when I think I discovered
a typo. It is in the while loop that is supposed to "put as much in
the tail as will fit":
while ((lentail < 126) && (penvargs < pchildenv))
lentail is initialized to 0 above and never changed in the body of
the loop. Given that the tail cannot be longer than 125 bytes, I am
supposing that lentail should either be post-incremented here, or
incremented in the body of the loop? Is this correct?
Thanks,
-c
-=- Charles S. Roberson ARPANET: csrobe@cs.wm.edu -=-
-=- VA Remote Sensing Study UUCP: ...!uunet!cs.wm.edu!csrobe -=-
-=- Dept of Comp. Sci. Compu$erve: 71500.2056@compuserve.com -=-
-=- College of William and Mary BIX: csrobe -=-
-=- Williamsburg, VA 23185 Ma Bell: (804) 253-4393 -=-
Fur Thought: Put on a fur and slip into something dead.
------------------------------
Date: 6 Nov 89 20:25:45 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: GNU C and sizeof(int)
stephen@oahu.cs.ucla.edu (Steve Whitney) writes:
>rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
>>Has anyone made a 16-bit GCC and library and done a comparison?
>You can always use this simple hack:
>#define int short
>But you have to be careful with constants. If you pass 3 as an argument
>to a routine expecting a 16 bit integer, it will pass 00 00 00 03 instead
>of 00 03. To get around that, pass your constants as (short)3 instead.
...or you can use -mshort on the GCC command line. ...or you can use
prototypes, which cause the compiler to cast actuals to the types of
the formals (and generate warnings, etc., based on that). Since 3 is a
valid short as well as int, there's no problem.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 6 Nov 89 15:18:11 GMT
From:
cs.utexas.edu!samsung!rex!uflorida!stat!vsserv!prism!iadt3tb@tut.cis.ohio-state
.edu (T. Terrell Banks)
Subject: Micro Emacs 3.10
?Just what is the difference between v3.10 and 3.9?
?
.8
It's gonna be that kind of week!
Cheers,
TB
--
T. Terrell Banks uucp: ? 'insert a backbone name here' ?!gatech!prism!iadt3tb
Georgia Insitute of Technology - I.S.A. Internet: iadt3tb@prism.gatech.edu
190 Third Street NW Bitnet : iadt3tb@gitvm1
Atlanta, Georgia 30332-0185
------------------------------
Date: 7 Nov 89 02:03:54 GMT
From:
quanta.eng.ohio-state.edu!raksha.eng.ohio-state.edu!rob@tut.cis.ohio-state.edu
(Rob Carriere)
Subject: Prolog 10, Common LISP
In article <36500071@silver> jkain@silver.bacs.indiana.edu writes:
>
>/* ---------- "Prolog 10, Common LISP" ---------- */
>I address this especially to continental European ST users:
>
[message in German deleted]
>Well isn't *this* a fine how-do-you-do? Even if we live in the U.S.
>perhaps we would like to know what you're saying.
[Spanish(?) reply deleted]
Even better, he is assuming Europe == Germany. Think about the knee-jerk
potential here!
Anyway,
"I know Cambridge LISP and MProlog, but they are not what I am looking for.
I am sorry that my German isn't very good, but since so may ST users are
German, I believe that they don't want to always read English here."
> David Megginson, Centre for Medieval Studies, Toronto
No cause for paranoia, meseems :-)
SR
------------------------------
Date: 6 Nov 89 21:15:15 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher)
Subject: TOS, Zoo, or Zen?
covertr@force.UUCP (Richard E. Covert) writes:
| Will MWC have to be changed to support the new TOS 1.4??
In terms of DTA management, no. The point of my original posting was
something that went out in the Developer Rainbow TOS relese notes:
GEMDOS DTA handling has changed. If you relied on undocumented features
of GEMDOS DTA handling, you may lose under Rainbow TOS. The thing that
may catch you unawares is that GEMDOS _will_ trash your DTA after an
Fsnext() that fails. Apparently, previous GEMDOS versions left the
filename part of the DTA alone after a failed Fsnext(). So if you're
searching for a bunch of files, copy what you need out of the DTA
before each Fsnext() operation, and you won't get bitten.
--
||| Ken Badertscher (ames!atari!kbad)
||| Atari R&D System Software Engine
/ | \ #include <disclaimer>
------------------------------
Date: 6 Nov 89 20:39:42 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: TOS, Zoo, or Zen? (DTA stuff)
Let me clear up what Ken said:
Point 1: You can't use the private part of the DTA, and if you do, your
program won't work on TOS 1.4 because the private part of the DTA
changed entirely. Even if you figure out what it's used for, you
will lose when a new TOS comes along and blows your program up
again.
Point 2: If a Fsnext() returns ENMFILES ("no more files"), the public
part of the DTA contains nothing useful. It does not, for example,
contain the data from the file which matched the previous Fsnext(). If
you want to do Fsnext() until it fails, and you care about what was
there before it failed, you have to copy it out.
You don't have to copy out ALL of the DTA, of course, just the public
parts, and of that, just the parts you care about.
No part of the DTA needs to be saved or preserved if you don't want to
do another Fsnext on it: there is no vital GEMDOS information there.
Fsfirst completely reinitalizes the DTA (or returns "file not found" or
"path not found").
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 6 Nov 89 21:18:25 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher)
Subject: Trying to read an Atari St Gem-Dos disk on a Mac SE using FD/HD
pnh@pmin24.osf.org (Peter Harbo) writes:
| I don't think it's possible w/ Apple File Exchange (I know it isn't, because
| it recognizes the disks as MS/DOS, 720 K but can't read the directory
| structure and only offers to format them)...
This could be because disks created on pre-Rainbow TOS versions would not
correctly time/date stamp the "current" and "parent" directory entries.
Some DOS machines have the same problem with ST disks.
--
||| Ken Badertscher (ames!atari!kbad)
||| Atari R&D System Software Engine
/ | \ #include <disclaimer>
------------------------------
Date: 6 Nov 89 20:46:19 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: TT
ramsiri@blake.acs.washington.edu (Enartloc Nhoj) writes:
>The strange thing is that i have a hard time believing that i
>am still considering buying an 030 that won't multitask all that
>niffty GEM software i have on my drive.
Why on Earth do you find this difficult to believe? You clearly
have not thought through the implications of a multitasking TOS.
What parts of the system are task-specific, and need to be switched
with the task's context? The CPU registers, sure, and GEMDOS's
current-process pointer. But what about the "Bconin() returns the
shift key state" bit in _conterm? What about the critical error
handler? What about the 200Hz interrupt vector (or, worse, something
in the MIDDLE of the 200Hz interrupt vector chain)?
No multitasker can satisfy "all that nifty GEM software" you have. What
CAN be done is this: we can lay down rules for multitasking, and write
a multitasker within those rules, and programs written with those rules
in mind will work. Furthermore, programs written *without* those rules
in mind, but which follow them anyway, will work. Therefore the rules
should be broad enough to cover a wide range of existing programs.
What I'm trying to say is THIS IS NOT EASY. It's not even Moderately
Difficult. This is A Hard Problem. The presence of a 68030 doesn't
make it any easier.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 6 Nov 89 21:40:59 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher)
Subject: unix on the TT
covertr@force.UUCP (Richard E. Covert) writes:
| In article <1768@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes:
| > depeche@quiche.cs.mcgill.ca (Sam Alan EZUST) writes:
| > [ read in a magazine... ]
| > | THE DESKTOP MODEL WILL NEVER WORK WITH UNIX only the TOWER will....
| > | if this is true, WHY?????
| > Because the magazines don't know what they're talking about.
| I personally couldn't care less what you put on the TT/Plastic as I don't
| plan to buy another Atari computer w/o plenty of card slots.
Perhaps I should clarify what I posted before. I'm getting sick and
tired of seeing rumors and misinformation bandied about as facts here
and elsewhere.
If it's a TT, it'll run Unix. It may require adding memory or disk storage,
but it will run Unix.
I don't recall a public release of Atari specifications at all for any
tower configuration of TT ever. So if you read or write anything
specific about any such machine, it's pure fabrication.
Subject to change without notice.
Your mileage may vary.
Do not remove tag under penatly of law.
--
||| Ken Badertscher (ames!atari!kbad)
||| Atari R&D System Software Engine
/ | \ #include <disclaimer>
------------------------------
End of INFO-ATARI16 Digest V89 Issue #614
*****************************************
=========================================================================
