=========================================================================
 
INFO-ATARI16 Digest         Fri, 12 Jan 90       Volume 90 : Issue   36
 
Today's Topics:
               ARC 6.02-bug (was Re: ARC 6.0) (2 msgs)
               BUG REPORT AND PATCH FOR TOS 1.4 AND 1.6
                               CTS bug
             Mac II screen colors (Was: Genlock Inquiry)
                            MIXED (2 msgs)
                       nethack 3pl6 for atarist
                           Poolfix problem
                           ProGem articles
                          Spectre GCR Review
                             STE problem
                              TOS 1.6...
                             Unix Windows
                   Unix Windows - Unix side needed
----------------------------------------------------------------------
 
Date: 11 Jan 90 21:56:12 GMT
From: rochester!kodak!nelson@louie.udel.edu  (Bruce Nelson)
Subject: ARC 6.02-bug (was Re: ARC 6.0)
Message-ID: <2263@kodak.UUCP>
 
Another bug I found in arc 6.02 is the definition of the "p" command:
 
         p   = copy files from archive to standard output
 
Arc 6.02 prints the file to the line printer. Previous versions (5.21 and
earlier) outputted the file to the screen or could be redirected via
the ">" operator.
 
If anyone near Phoneix could point this out to Darin Wayrynen on his bbs
(Next Gen BBS (602) 938-8288) I'd appreciate it.
 
Bruce Nelson
 
------------------------------
 
Date: 11 Jan 90 18:58:34 GMT
From:
 cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc@tut.cis.
 ohio-state.edu  (Howard Chu)
Subject: ARC 6.02-bug (was Re: ARC 6.0)
Message-ID: <10615@stag.math.lsa.umich.edu>
 
In article <814@opal.tubopal.UUCP> ripley@tubopal.UUCP (Hans-Ch. Eckert) writes:
>IMMEDIATELY STOPS INSTEAD? If I do "arc v fubar.arc" and fubar contains
>files which are squashed, I want arc to show me the contents of the
>archive-file. If I do "arc x fubar.arc" I want arc to skip these
>files such as "fubar.xyz - unknown compression method. Skipped.".
>What I don't want arc to do is to abort the whole task.
>
>This has been done by transitioning from arc 5.12 to wunderful(?) arc 5.21
>with its squashing algorithm. This fault has been repeated on arc 5.21,
>which can now be seen when listing an arc 6.xx archive which contains
>sub-directories. Sigh.
>
 
That does seem to be a problem that the docs don't point to. Dunno why
they did things that way... I'd fix it, but don't have the 6.02 sources.
(Deep sigh.  ?-)
 
>.complaining off
>
>Another one, which is more of a *real* (and heavy) bug:
>Arc lost it's capability of dealing with overlong filenames.
 
Well, it was pretty non-standard anyway, and the main idea was to maintain
compatibility with the PC version of ARC. (But it was certainly trivial to
allow for arbitrarily long names, really.) The official "fix" I posted for
the Unix side was to make it automatically truncate long names to fit into
12 characters. So it goes. You could easily add back in the code to allow
for long names though. Dunno what you'd do with them when you try to extract
them, but at least it wouldn't choke...
 -- Howard
 
>Greetings,
>                               RIPLEY
--
 -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1]
 and You Too can have a Personal Electronic Relationship with God!
 
------------------------------
 
Date: 11 Jan 90 19:03:08 GMT
From: shlump.nac.dec.com!engles.enet.dec.com!powers@decwrl.dec.com  (Bill
 Powers)
Subject: BUG REPORT AND PATCH FOR TOS 1.4 AND 1.6
Message-ID: <7396@shlump.nac.dec.com>
 
In article <1944@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes:
>
> Atari Corp., January 10, 1990
>
> There is a rare bug in Rainbow TOS (1.4) and STe TOS (1.6) involving
> the way GEMDOS handles its internal memory.  You probably have never
> seen this bug, and if you use this patch program, you never will.
 
Allan,
 
    I use an editor on my ST which used to handle files larger than
available memory.  It used to work on tos 1.0, the other day I was
editing something that was larger than available memory with tos 1.4
and my system hung, and printed a three line message at the top of
the screen telling me about memory problems, and I should use
foldrxxx.prg.  Is this message possibly coming out TOS?  I kind of
get the impression it is.  If so, is this the bug you are fixing
with your patch, and if so, is it really necessary to still use
foldrxxx.prg even with tos 1.4?
 
thanks
 
Bill Powers
----
Digital Equipment Corp. - Advanced Service Delivery Systems - Stow MA
The opinions expressed above are my own, not my employers, so there.
TELEPHONE - (508) 496 - 8725
E-MAIL - powers@harpo.enet.dec.com
       - ...!decwrl!harpo!powers
 
------------------------------
 
Date: 11 Jan 90 18:26:33 GMT
From: dartvax!eleazar.dartmouth.edu@CS.BU.EDU  (Clark L. Breyman)
Subject: CTS bug
Message-ID: <18443@dartvax.Dartmouth.EDU>
 
I have run in to a problem with the CTS bug metioned in Abacus's
ST internals. Supposedly the OS (where is not mentioned) requires
the CTS line to jiggle after each bye sent. I'm just switching to
a system that uses full duplex, GND and DTD lines and ties the
RTS (ready to send), CTS(clear to send) and pin 6 whatever that is.
 
I'm using a 520STfm recieved may 89 with uniterm and EMULATOR.ACC
 
Is there a fix. Has this already been fixed and I have something else
wrong. Will this be a problem with Magic Sac/Spectre?
 
        Thanks, Clark
 
------------------------------
 
Date: 11 Jan 90 10:16:56 GMT
From: mcsun!ukc!dcl-cs!gdt!gdr!exspes@uunet.uu.net  (P E Smee)
Subject: Mac II screen colors (Was: Genlock Inquiry)
Message-ID: <1990Jan11.101656.18975@gdt.bath.ac.uk>
 
In article <9001091511.AA13450@ucbvax.Berkeley.EDU> MBERNAR@ERENJ.BITNET
 (Marcelino Bernardo) writes:
>You're dead wrong on this one.  The Mac II series does provide for 16.7
>million colors.  Whether you get it or not depends on the video display
>board installed on the Nubus.  In front of me is an ad from Radius for
>their DirectColor/24 which can simultaneously access every one of the Mac's
>16.7 million colors.  They also make a 16-bit board (32,768 colors simul-
 
Do they also make a 4096x4096 pixel screen, so that you can get all 16.7
million colors out into the world at once?
 
--
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132
 Smee@bristol.ac.uk  :-)  (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
 
------------------------------
 
Date: 11 Jan 90 19:57:46 GMT
From: matthews@umd5.umd.edu  (Mike Matthews)
Subject: MIXED
Message-ID: <5929@umd5.umd.edu>
 
In article <10616@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu)
 writes:
>By hardware you can open it up and tweak some potentiometers inside to
>expand the video image.. By software, probably the nicer way to go, you
>can get the OVERSCAN software and *use* that black frame for more pixels.
>688x480 on a fresh-out-of-the-box SM124.
>
Two quick questions:
 
1) Where is this software?  I can do anonymous ftp, so a site name would be
   muchly appreciated.
 
2) Do ST programs such as PageStream recognize this?  Or, better yet (?),
   Spectre GCR?
 
(hope my .signature file works this time)
 
------------------------------
 
Date: 11 Jan 90 19:11:26 GMT
From:
 pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc@tut
 .cis.ohio-state.edu  (Howard Chu)
Subject: MIXED
Message-ID: <10616@stag.math.lsa.umich.edu>
 
In article <9001050802.AA10246@ucbvax.Berkeley.EDU> so01@dmarum8.BITNET (Thomas
 Neser) writes:
>Hello back in the nineties,
>a few querstions for today:
>1) Is is possible via soft- or hardware to kill the black frame of the
>   atari sm124 monitor?
By hardware you can open it up and tweak some potentiometers inside to
expand the video image.. By software, probably the nicer way to go, you
can get the OVERSCAN software and *use* that black frame for more pixels.
688x480 on a fresh-out-of-the-box SM124.
 
--
 -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1]
 and You Too can have a Personal Electronic Relationship with God!
 
------------------------------
 
Date: 11 Jan 90 20:52:17 GMT
From: rti!ret@mcnc.org  (Raymond Thomas)
Subject: nethack 3pl6 for atarist
Message-ID: <3411@rti.UUCP>
 
Hello, I am looking for a site that has nethack for an atari
st with patches through level 6 applied. The two sites I have
found, panarthea and ncsu, only have patches through level 3.
If sites are not available could some kind soul contact
me through e-mail about transferring the file.
I would be most appreciative.
 
address ret@rti.rti.org
 
thanks.
 
 
------------------------------
 
Date: 11 Jan 90 19:50:58 GMT
From: matthews@umd5.umd.edu  (Mike Matthews)
Subject: Poolfix problem
Message-ID: <5928@umd5.umd.edu>
 
I just grabbed and installed poolfix.prg (which apratt posted <thanks!>), and
have come across one minor problem.
 
It and Neodesk 2.05 don't get along at all.  Everything works fine from the
desktop.  This is true with and without shel_fix.prg.
 
I just had some problems with my ROM chips (the dealer who installed them did
a pretty lousy job; chips are NOT supposed to be crooked), and I'm _pretty_
sure I reseated them OK.  In short, can anybody confirm this?
 
------------------------------
 
Date: 11 Jan 90 21:17:13 GMT
From: pyramid!athertn!alex@hplabs.hpl.hp.com  (Alex Leavens)
Subject: ProGem articles
Message-ID: <16471@laurel.athertn.Atherton.COM>
 
I'm unable to get through to terminator.cc.umich.edu, so I can't
get the ProGem.arc and ProSrc.arc articles.  Can anyone suggest
another site that I can get to that has these?  (I can use
the mail server, but I can't ftp).  Or does anyone have them
in uuencoded form and be willing to mail them to me?
 
Thanks in advance...
 
--
|----------------------------------------------------------|
|--alex |   'My mind is my own', and so are my opinions    |
|Now who are you gonna believe--me, or your own lyin' eyes?|
|----------------------------------------------------------|
 
------------------------------
 
Date: 10 Jan 90 16:55:56 GMT
From: mcsun!ukc!stl!stc!root44!hrc63!mrcu!ya16@uunet.uu.net  (Ian Powell)
Subject: Spectre GCR Review
Message-ID: <369@mrcu>
 
I found this in the Info-Mac Digest and thougt it of interest to the
Atari Community.
****************************
Date: 14 DEC 89 14:01:53 CST
From: Z4648252 <Z4648252%SFAUSTIN.BITNET@forsythe.stanford.edu>
Subject: Emulating the Mac Plus via Spectre GCR
 
    I've been requested to give an evaluation of the Spectre GCR,
the Atari ST Macintosh emulator.
    I have access to a Mac SE FD/HD (a mouthful!) and am
constantly on both the Atari Spectre GCR Mac emulator and Mac so
hopefully, this evaluation will be of value.  The Atari ST used
is a four megabyte ST equipped with a SeaGate 296n hard drive and
Atari paper-white 12" monitor.  No accelerators are in use to
speed up this particular ST.
    The Spectre uses Macintosh 128k ROMs and can emulate either a
Mac 512KE or Mac Plus.  A key press will toggle either system.
All systems work, including 6.0.3.  All ram has been surrendered
to the "Mac side" allowing some hefty applications to work
together via MultiFinder, i.e., FullWrite, Hypercard, RedRyder.
In fact, that is what is on the system right now.  I'm typing
this with FullWrite, Hypercard and RedRyder lurking in
the background.
    Hard drive support is a simple plug in and go via the Atari
ST's hard drive DMA port, therefore, data transfer is fast, if
not faster than the real thing, depending upon the hard drive
mechanism.  External Macintosh hard drives also work.
    Macintosh ramdisks work perfectly and, like the real Mac,
all but required if a one-drive system is used.  This can help in
ending the Mac Floppy Shuffle.
    Control Panel settings are not saved, therefore a Mac PD
utility, DiskParam, will do the job.  It works perfectly and was
written by a Macintosher, Mr. Webb, who lost his Param circuit on
his Macintosh.
    Because of the Atari ST's faster clock speed, graphics and
sound are noticeably faster.  Sound is a touch "squeaky".
Graphics are snappier than that of a Plus and SE.  Indeed, Aldus
FreeHand's self-running demo will be about four pages ahead of
the same demo on an SE after about two minutes into the demo.
    Mouse handling is great and the mouse does not slow down
during disk access. Also, the ST mouse has two buttons.  The left
is the standard "point and click" button, the right is a shift
key equivalent.  This allows for selective file maintenance
without your having to touch the keyboard!
    Floppy disk access is ok.  The Spectre GCR can read Macintosh
disks directly at the same speed as a real Mac if the ALTernate
key is pressed prior to accessing the disk.  Otherwise, the read
attempt will sample the disk and check to see if it is an Atari
(Spectre) or Mac disk.  Pressing the ALTernate key will bypass
the check.  Writing is direct and since the disk has already been
sampled when it was inserted, the emulator knows already whether
the disk is Atari or Mac. Mac formating can be done along with
duplication of real Mac disks.  Again, there is no speed loss.
    Some STs are having problems writing to Mac disks due to a
particular batch of drive mechanisms which think the Mac data is
noise.  However, these seem to have no problem writing to Mac
disks via Spectre's own utility program.  Again, the process is
fast.
    Although Spectre GCR can support Atari's RGB screen, the
cheaper ($90.00 at some stores) and crisp paper-white Atari
monochrome monitor is the best.  It is 12" and uses 640 X 400
resolution.  There is no flicker and the scan lines are barely
seen.  The display is clean and bright.  The larger screen does
not increase the size of the characters, instead the user has a
greater viewing area close to that of the $400.00 Macintosh
monochrome monitor.  Gray scale, I think, is the same.
   Memory allocation is transparent.  The user will lose about
300k for emulation overhead.  The rest is all his, if he wants
it.  Gee, I love this 3.5 meg or so of available memory!!!
   Macintosh emulation on the Atari ST with the Spectre GCR has
reached beyond the "hacker" level.  For all practical purposes
which include data I/O speed, program execution, and screen
display, the ST becomes a Macintosh Plus, thus, greatly extending
the use and power of the Atari ST and yet, with very little
compromise for either Atari ST in its host mode or in "Mac" mode.
 
Larry Rymal:  |East Texas Atari 68NNNers| <Z4648252@SFAUSTIN.BITNET>
 
------------------------------
 
------------------------------
 
Date: 11 Jan 90 16:43:42 GMT
From: mcsun!ukc!newcastle.ac.uk!turing!q1cbw@uunet.uu.net  (D.C. Halliday)
Subject: STE problem
Message-ID: <1990Jan11.164342.15604@newcastle.ac.uk>
 
I think I have found a bug in the STE. When booting from a floppy with a colour
display, the machine allways comes up in low res. The window positions etc are
correct however if the res is then changed to medium. This problem happens when
using a desktop.inf saved on the STE and with the file saved on a TOS1.2 ST.
 
Anybody know a way around this?
 
On the compatability front the only program I have found that will not run on
the STE is palace software's Barbarian.
 
Dave Halliday.
 
(JANET: d.c.halliday@uk.ac.newcastle)
 
------------------------------
 
Date: 11 Jan 90 18:23:05 GMT
From: att!chinet!saj@ucbvax.Berkeley.EDU  (Stephen Jacobs)
Subject: TOS 1.6...
Message-ID: <1990Jan11.182305.24007@chinet.chi.il.us>
 
In article <1252@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
>
>actually, darek mihocka and myself have an STE and we've disassembled the
>exception handlers in TOS 1.6, and sure enough, it checks some
>system variable which tells the software what type of stack frame it can
>expect. therefore, if its a 68000 processor, it uses an offset begeinning
 
This is what serious developers do when source to critical parts of an OS
isn't made available, and when the documentation is sparse  (in case there's
any confusion, I think it's a good thing to do under the circumstances, as
long as it doesn't lead to use of version-specific and accidental features.
I attach no moral color, good or bad to Atari's reluctance to disclose TOS
source to registered developers.  The sparse documentation is unfortunate,
but not evil).  My point is that all the stuff Atari hopes to prevent by
keeping the source confidential, even from those who have signed non-disclosure
agreements can happen anyway.  Here we have 2 people who've earned a reputation
as cautious programmers doing their own dissembly.  Guys with PC game experience
and a lot less caution can do the same.  On any timescale I can imagine, it
would be better for Atari and its customers if developers had an easy way to
check EXACTLY what TOS would do in a given situation (and any commented source,
no matter how 'ugly', beats a dissassembly).
 
[whining off]
                                   Steve J.
 
------------------------------
 
Date: 11 Jan 90 19:15:00 GMT
From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc@tut.cis.ohio-state.edu
 (Howard Chu)
Subject: Unix Windows
Message-ID: <10617@stag.math.lsa.umich.edu>
 
In article <21617@uflorida.cis.ufl.EDU> cr1@beach.cis.ufl.edu (Christopher Roth)
 writes:
>Can anybody out there tell me if UW (unix windows) works with tos 1.4?
>I've been trying to get it to work, but alas, to no avail.  Strange things
>happen..sometimes it bombs, sometimes I get no lower case letters (try
>THAT on unix...) and sometimes it just plain does not work.  I am , of
>course, using a monochrome monitor, a 1040 ST with 1 meg.  Perhaps I
>am missing something...
>
Which version of UW are you using on the ST? I use the version in uwbin.arc
from terminator, it works fine on my Mega w/TOS 1.4. It also works with the
overscan mod, which makes it that much nicer...
 
This uw version also has a bare-bones kermit client. Handy...
--
 -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1]
 and You Too can have a Personal Electronic Relationship with God!
 
------------------------------
 
Date: 11 Jan 90 21:58:16 GMT
From: rochester!kodak!nelson@louie.udel.edu  (Bruce Nelson)
Subject: Unix Windows - Unix side needed
Message-ID: <2264@kodak.UUCP>
 
Would someone kindly point me towards a copy of the Unix-side source
for Unix Windows?
 
Thanks.
 
Bruce Nelson
 
------------------------------
 
End of INFO-ATARI16 Digest V90 Issue #36
****************************************