Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 92 Issue 041
Info-Atari16 Digest Fri, 24 Jan 92 Volume 92 : Issue 41
Today's Topics:
Amiga geeks, read this
Atarians! Where Are You?! (2 msgs)
blitter questions
Hyperformat disk on a PC
I cant get Zoo to work!
Model questions
Multifinder for Atari-ST ?
New Supra Modem...
PRGFLAGS review (was talk about Tcsh)
Rom chip set switch time?
SST shipdate & Gadgets news
What to do?
Yet another ST for sale
Welcome to the Info-Atari16 Digest. The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out. Please send notifications about broken digests or bogus messages
to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list
instead of the moderators are likely to be lost or ignored.
If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------
Date: 24 Jan 92 00:02:00 GMT
From: fernwood!portal!cup.portal.com!Azog-Thoth@uunet.uu.net (William Thomas
Daugustine)
Subject: Amiga geeks, read this
To: Info-Atari16@naucse.cse.nau.edu
If you are an Atari ST user, and have no desire to move to an Amiga
quit out of this.
If you are an Amiga user who insists on posting derogatory article
GET THE FUCK OUT OF HERE. Notice the name of this news group? It
is "comp.sys.ATARI.st". That ATARI means ATARI, not AMIGA. Go
play in your own amiga land.
There is one asshole: Gregory Miller england@milton.u.washington.edu,
who seems to feel the need to bash the Atari. Maybe he has his
own feelings of insecurity?
Once again, GET THE HELL OUT OF HERE. Go kill yourself, get a life,
die, we wont miss you. Post on your own goddamned newsgroups about
how bad Atari is. I dont read any Amiga newsgroups, nor do I post
there either. But if Greg Miller presists on this childish
behaviour, I can post a few flames myself. But I dont want
to do that. I like to consider myself above such jerkoff
actions. You dont like the Atari, get the fuck away, and shut
the hell up, yes?
I dont like computer wars, and I am sure there are others who
feel the same, but if youll notice, many Atari VS Amiga wars
in comp.sys.atari.st are started by AMIGA GEEKS!
In a thread some bit back, titled Atarians, where are you. I posted
that I would consider an Amiga as a computer (I dont own just
one, I own at least 20 different kinds, and the Amiga would be
just another collection), but I do not want myself linked to people
of such low mentality. Do I judge too hashly? I dunno, but out of
10 Amiga users I met, they all act the same. Its like a fucking
brain virus.
Enough said. Flames, comments, etc, to /dev/null. If you (an Amiga
user) reads this, and gets mad and wishes to flame me, dont bother)
Billy D'Augustine
Azog-Thoth@cup.portal.com
PS: To Greg Miller: I own a brand new 520STe, with 4mb of RAM, and
TOS 1.62, and Ive yet to come across a program that wont run on it.
I cannot play some games, simply because I do not have a colour
monitor. And dont bother starting stupid wars about the different
monitors. Your an asshole
------------------------------
Date: 24 Jan 92 04:01:35 GMT
From: mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!rjc@yale.arpa (Ray)
Subject: Atarians! Where Are You?!
To: Info-Atari16@naucse.cse.nau.edu
In article <25611@skye.dcs.ed.ac.uk> kc@dcs.ed.ac.uk (Kenneth Cameron) writes:
>In article <1992Jan23.071233.10605@milton.u.washington.edu>
> ... (Jeremy C. Norberg) writes:
>>Since the Amiga is a TRUE multitasking machine, we can do more than one thing
>>at a time. Try THAT with your ST! (and don't even bother mentioning
>>multigem.... That's about as good a multitasker as switcher is on the Mac)
>
>You know how the Amiga fanatics flaunt the fact that they have a TRUE
>multitasking machine. Well, apparently when two processes decide to
>access the floppy, they do just that, and the head runs up and down the
>disk as each moves it back and forward never getting where they want.
>Eventually ( after several seconds ) they time out and after a pause one
>restarts first and manages to complete the operation.
This part is wrong. The head walks back and forth between the areas
of the disk where the accessed data is. The difference on the Amiga is,
AmigaDOS (actually trackdisk.device) buffers and caches entire tracks when
it needs to access single sector. Unless the disk is heavily framented
there isn't much of a problem. There also isn't much of a solution.
This subject was debated at length a few months ago in the Amiga groups
and the conclusion was (verified by benchmarks on other systems) that
disk head schleduling algorithms offer little improvement on floppies,
especially fragmented disks. The best solution is a cache.
>Can you say elavator algorithm ?, the Amiga systems programmers did n't.
>(I think the machine by friend bought was new, so this is the current
>release of the OS :-)
You are wrong. The head doesn't ping pong without reaching it's destination.
The head reads some data, runs back to the other side of the disk, reads
some more, etc. When the Amiga accesses a sector, it ALWAYS reads in the
entire track and caches it. You can get a simple improvement just by
doing a "addbuffers" command.
>--
>Kenneth@Edinburgh
>Any opinions expressed above are mine, Edinburgh University can't afford any of
>their own at the moment.
------------------------------
Date: 24 Jan 92 04:42:08 GMT
From: mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!rjc@yale.arpa (Ray)
Subject: Atarians! Where Are You?!
To: Info-Atari16@naucse.cse.nau.edu
In article <1992Jan23.132827.48664@link-1.ts.bcc.ac.uk> ucacmsu@ucl.ac.uk (Mr
Stephen R Usher) writes:
>In article <1992Jan23.071233.10605@milton.u.washington.edu>
tlk@hardy.u.washington.edu (Jeremy C. Norberg) writes:
>>In article <1992Jan18.122843.10678@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz
(Roger Sheppard) writes:
>>>
>>>Also I here that the sales of A500 + is now gone minus, they are all taking
>>>them back as they can't play games on this new machine any more..??
>>>
>>
>>Kinda like the monstrosity known as the STe??? TOS 1.06 hardly runs
anything!!
>>Also, how many of your ST GAMES run on your beloved TT??
>
>How many games will run on the A3000? I suspect none which assume that the
>processor is a 68000 or which assume that the hardware is theirs alone to
>play with. If they don't run, it's the software authors who should be
>blamed, not the hardware.
Commodore has STRONGLY warned developers not to use self-modifying
code, mess with the MMU, use cpu busy-loops for delay, etc since
1986. That's why there's OS calls like GetCC() and CacheClear().
That's the real difference between the Mac/ST and the Amiga. The
Mac used to pass data in the upper 8 bits of an address register
probably because Apple never foresaw full 32-bit addressing. And
alot of ST stuff uses priveleged instructions like move SR,<ea>.
Only the real old european game hacks don't work too well. When did
atari set down CPU rules like don't use move sr,ea, don't put data in the
upper 8 bits of address registers, don't use cpu busy loops (because they
are CPU speed and ram speed dependent), don't use self-modifying code?
>>
>>>And were are all your PD C compilers, this main Amiga chaps here don't
>>>seem to know much about them..
>>>
>>
>>The amiga doesn't NEED a PD compiler. There are still publishers that
>>support us!!
>
>EVERY platform needs a PD C compiler unless it comes with one as standard,
>this allows poor people who can only afford the bare machine to contribute
>to the community.
Well the Amiga has plenty of PD C compilers, I'll list the compilers
I know about.
PDC (PD)
Sozobon (PD)
GCC (PD)
C68k (PD)
DICE (PD)
NorthC (PD)
Lattice/SASC (Commercial)
Manx C (Commercial)
Comeau C++ (Commercial)
There are probably some more thatr I left out, however GCC and DICE
beat all the PD compilers. DICE is more Amiga specific. (BTW, the
author of DICE, Matt Dillon, is porting BSD 4.4 to the Amiga as FreeWare!
Don't think he can't do it either, Matt has single handedly programmed over
20 Amiga developer tools as freeware.)
>>
>PS. The Amiga is a fine machine for graphics, and quite good for sound, but
>it isn't ideal for some things, including I must say, programming in C.
You're gonna have to justify this statement. The Amiga has more
programming tools than I can count. Numerous C compilers, 4 Forth
implementations, Modula-2, Oberon, Smalltalk, Eiffel, Lisp/Scheme,
Basic (plentity of them including ones that produce optimized
assembly), AMOS, Fortran, the list goes on. Almost every
language has been ported. There are a couple PD interface builders
for GUI work, PD debuggers, not to mention that AmigaDOS looks and
smells like Unix from the shell point of view.
There is an entire (PD)C programming manual on disk that teaches
Amiga programming step by step. Not to mention the 590 fish disks
FULL of programs with C source code.
I'd say the Amiga is the second best computer to program C on
besides the NeXT.
>--
>Addresses:-
>JANET:- ucacmsu@uk.ac.ucl or susher@uk.ac.csm
>Internet:- ucacmsu@ucl.ac.uk or susher@csm.ac.uk
------------------------------
Date: 23 Jan 92 23:48:05 GMT
From: fernwood!portal!cup.portal.com!Azog-Thoth@uunet.uu.net (William Thomas
Daugustine)
Subject: blitter questions
To: Info-Atari16@naucse.cse.nau.edu
Hiyas. Ive got a 520STe and am wondering if there is a program of
some sort that I could run to see the difference between turning
the blitter on and off. I chose blitter on from the desktop, and
from any program I run thatll accept it, but I am just wondering
just exactly what it does... (I dont see a difference between
when I turn it off, try things, and turn it on again... btw: if
it makes any difference, I am using a mono monitor)
Thanx
Billy D'Augustine
Azog-Thoth@cup.portal.com
------------------------------
Date: 23 Jan 92 13:46:49 GMT
From:
noao!ncar!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.e
du!ohstpy!miavx1!rlcollins@arizona.edu (Ryan 'Gozar' Collins)
Subject: Hyperformat disk on a PC
To: Info-Atari16@naucse.cse.nau.edu
In article <1992Jan21.145114.25642@unibi.uni-bielefeld.de>,
itschere@techfak.uni-bielefeld.de (Torsten Scherer) writes:
> In article <12475@star.cs.vu.nl>, rfschaa@cs.vu.nl (Schaaf RF) writes:
> |> I have been using hyperformatted disks (11-sectors/track) ever
> |> since I bought Scheibenkleister. A few weeks ago I bought a PC
> |> and assumed the High density drive would be able to handle 11
> |> sectors per track. I was wrong, I am unable to read the disks.
> |> Does anyone know whether it is possible to read Hyperformatted
> |> disk on a PC. The problem isn't DOS (PC-speed works fine with
> |> these disks), so what is the problem?
>
> You're right, it's not a DOS problem. You can even add lines
> like "device=driver.sys /d:1 /t:80 /s:11" to your config.sys and
> it will work on an emulator on ST's. Maybe up to 10 sectors this
> also works on "normal" PC's, but definitely not with 11-sector-disks,
> because the standard PC floppy controller is unable to read/write 11
> sectors on a DD disk.
Well, it also depends on the PC. My roomates Zentih with a HD drive
could read the extended formats. (I don't know if I've tried 11 sectors,
maybe I'll do that tonight and find out.) We joked about how his Zenith
could read and write to my ST disks, saying the computer had the "Atari
Spirit!!" I haven't tried it with a PS/2 or anything though. But I know
the Zentih could read 10 sectors/80 tracks. (CHKDSK came back with 800K
free on the disk.)
Later.......
------======={{{{{{{{((((((Ryan 'Gozar' Collins))))))))}}}}}}}}=======--------
Atari Computers: "The Game is never over" rlcollins@miavx1.BITNET
Power Without The Price R.COLLINS1 on GEnie
------======={{{{{{{{(((((( My 1040STF Rocks!! ))))))))}}}}}}}}=======--------
------------------------------
Date: 24 Jan 92 01:48:45 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!wupost!waikato.ac.nz
!comp.vuw.ac.nz!actrix!Roger.Sheppard@arizona.edu (Roger Sheppard)
Subject: I cant get Zoo to work!
To: Info-Atari16@naucse.cse.nau.edu
In article <1992Jan22.094433.9780@topaz.ucq.edu.au> johnsonc@topaz.ucq.edu.au
writes:
> In article <9201192315.aa15112@Bonnie.ics.uci.edu>,
ehohnbau@Bonnie.ICS.UCI.EDU writes:
> >
> > I've been trying to get Zoo.ttp to work for the last couple of days
> > and even with the recent postings I can't get it to work.
> > I've tried the following with both zoo.ttp and the file zooboy.zoo
> > in the root directory of the a: drive:
> >
> > After I click on zoo.ttp and the the parameter box I tried:
> >
> > x zooboy.zoo
> > x zooboy
> > x [aA]:[\] zooboy[.zoo]
> > In other words, I tried both with and without the .zoo extender
> > on every other option, and I tried both upper and lower case on the
> > drive option, and with and without the backslash.
> >
> > The only thing that happens is that it takes me right back to the
> > GEM desktop.
> >
> > zooboy is supposed to be a graphical interface for zoo but you need
> > to be able to use zoo to unzoo Zooboy!!!!! #@&*%$!!
> >
> > I'd dearly appreciate someone mailing me a way out of this!
> >
> > Thanx,
> > Eric Hohnbaum
>
> It's not the best solution about but what I do is copy the .zoo file to
> an IBM disk, put in PC-DITTO and run the IBM version of Zoo 2.1 on the .zoo
> file. It's okay if you have the emulator but I thought I'd tell everyone
> anyway as the algorithms between machine versions (IBM and ST) appear to
> the same for LHARC (but not the PC's LHA), (ARC and PKXARC[?]) and
> (UUD and UUDECODE).
>> It's slow but does the trick.
> Chris.
NO ! this is like going backwards, get the arcgsh40.zoo from A.A.
this will make like easyer..
--
*** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz ***
*** 85 Donovan Rd * * GEnie. R.SHEPPARD5 ***
*** Kapiti At least I don't Flicker, ***
*** New Zealand.. * not like a dying light globe ***
------------------------------
Date: 23 Jan 92 23:56:20 GMT
From: psinntp!ultb!ritvax.isc.rit.edu!JWS7793@uunet.uu.net
Subject: Model questions
To: Info-Atari16@naucse.cse.nau.edu
I am new to the Atari ST line of computers. I posted a note earlier asking
for any cheap ST's for sale. I have had some offers. If you have one for sale
send Email.
Anyway what I would like to know is what is the difference between a
520 ST FM and a 520 STe?
If someone wouldn't mind giving a run down of all of the ST models spec-wise
that'd be cool too.
Thanks for your time.
James
------------------------------
Date: 24 Jan 92 02:46:46 GMT
From: boulder!csn!cherokee!agni!tls@uunet.uu.net (Terry Simmons)
Subject: Multifinder for Atari-ST ?
To: Info-Atari16@naucse.cse.nau.edu
In article <1992Jan23.133054.6471@cs.nott.ac.uk> dpg@cs.nott.ac.uk (`Grave' Dave
Gymer) writes:
>In article <29446@imag.imag.fr> maraninx@imag.fr (Florence Maraninchi) writes:
>>I need something like the equivalent of the Macintosh multifinder ...
>>Does it exist ?
>
>Not really. Yet.
>
I was just reading an add in the ST Informer about MultiGem which
claims to be just like a multifinder for the ST. Having never used
MultiGem or Multifinder could someone else shed some light on this
subject?
Thanx
Terry
PS the views expressed here are my own and are probably not understood
by my employer.
--
=============================================================================
Terry Simmons e-mail tls@uswest.com
U S WEST Advanced Technologies
------------------------------
Date: 24 Jan 92 02:14:29 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!Rog
er.Sheppard@arizona.edu (Roger Sheppard)
Subject: New Supra Modem...
To: Info-Atari16@naucse.cse.nau.edu
In article <1992Jan23.171744.29869@watserv1.waterloo.edu>
jparker@caddac1.waterloo.edu (James Parker) writes:
> In article <1992Jan23.102316.400@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz
(Roger Sheppard) writes:
> >In article <1992Jan22.194723.23878@milton.u.washington.edu>
tymbrimi@milton.u.washington.edu (Ben Gilbert) writes:
> >> Hi, I recently saw an ad in a friend's computer magazine for a new
> >> Supra modem, something like the Supra 2400 PLUS, it says it has
> >> asynchronous 300,1200,2400 bps (that's the usual I suppose), 4800 bps
> >> with MNP 5, and 9600 bps with v32.bis or v42.bis (can't remember which).
> >> So can I actually pay the CHEAP $130 bucks for this modem and dial up
> >> my school net at 9600 baud? Sounds like a good deal to me, I know that
> >> my school dial-in IS this new v32(42).bis thing, someone tell me, 9600
> >> baud would be awesome for only $130 mail order...
> >>
>
> I have a somewhat related question concerning my Supra 2400 modem.
> I have been using it satisfactorily for several years until recently
> new modems were installed on the server here at the university.
> Now I cannot connect at 2400 baud (tho' it does still work at 1200).
>
> According to the docs, the dial-in lines use V.42bis at 2400 baud.
> My Supra 2400 manual says it is V.22bis. Is there an inherent
> incompatibility here? Do I need to get a new modem using V.42bis
> to talk at 2400? Please say no! I know nil about what V.42, V.22 etc
> means so be easy on me.
>
> thanks for any help.
> james
>
Well it should not be this way, V42 is a error correcting protocal
and V42 bis is a compression Protocal, you have a option to turn them off/on,
they are not part of the line standard, that is your V22,
if the don't let you connect then I would say that the system has been
programed incorrectly..
Check to see if there new modems support that line standard V22...
--
*** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz ***
*** 85 Donovan Rd * * GEnie. R.SHEPPARD5 ***
*** Kapiti At least I don't Flicker, ***
*** New Zealand.. * not like a dying light globe ***
------------------------------
Date: 23 Jan 92 18:54:00 GMT
From: imagen!atari!apratt@sun.com (Allan Pratt)
Subject: PRGFLAGS review (was talk about Tcsh)
To: Info-Atari16@naucse.cse.nau.edu
This is a review of what PRGFLAGS means; some people don't know and
are asking.
Starting with TOS 1.4, a previously-undefined field of the program header
(the first 0x1c bytes of every program file) acquired a meaning. It's
called PRGFLAGS, and contains bits and numeric fields which control
various things about the program.
The fast-load bit is Bit 0 in the PRGFLAGS field. Normally it is clear.
When it's clear, or if your TOS is older than 1.4, then all the memory the
process starts out with is cleared before the process is started. This
includes the BSS space that the program declared, and also the "heap" space
between the end of the BSS and the top of the memory the process gets.
Clearing this memory takes time, especially on a 4MB 68000 machine. If you
set the "fast-load" bit, TOS 1.4 and newer will save time by not bothering
to clear the "heap" memory. It still clears the BSS -- the BSS is
guaranteed to be clear when your program starts up.
Nobody ever guaranteed that the "heap" would be clear, but the original
GEMDOS cleared it, and some programs rely on this, either on purpose (i.e.
the programmer knew it would be clear and was counting on it) or by
accident (the program has a bug in which, for example, an uninitialized
field of a structure obtained from malloc() is expected to be zero). Thus,
for compatibility, the default action is to go on clearing this memory, and
if you ask for it (by setting that bit) the memory won't be cleared, and
the program will start faster.
Bits 1 and 2 of PRGFLAGS are concerned with the eligibility of alternative
RAM for loading the program and for satisfying Malloc calls, respectively.
The concept of alternative RAM comes into play if there is memory in
your machine which is not like ST RAM. This is the case in TT's and
in some 68030 accelerator systems. Also, bits 28-31 encode a four-bit
number which is also used when deciding whether to load the program
in alternative RAM.
All other bits in the PRGFLAGS field of the program header are reserved for
use by Atari, and should be set to zero unless you know what you're doing.
There is a program from Atari called PRGFLAGS which lets you examine and
set the flags in the headers of your program files. Check for it on
atari.archive, local archive servers, or the Atari roundtable on GEnie.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 24 Jan 92 01:45:02 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!th
ink.com!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!Roger.Sheppard@arizona.edu
(Roger Sheppard)
Subject: Rom chip set switch time?
To: Info-Atari16@naucse.cse.nau.edu
In article <9201222340.aa17848@Bonnie.ics.uci.edu> ehohnbau@Bonnie.ICS.UCI.EDU
writes:
>
> I've got a 1040 at least 5 years old and I'm pretty sure it has the 6-chip
> Rom set but I'm not certain and I'd rather not open it up if I don't have to.
> I'm looking to buy a set of 1.4 chips (used if anyone is wanting to sell)
> but I need to be sure if mine is the 6 chip set.
>
> Can anyone tell me for sure when the switch was made from the 6 to the
> 2 chip set? This machine was made before the Mega's came out because my
> Grandfather gave me this when he got his new Mega not too long after the
> Mega's came out.
>
> Thanx
Get a copy of the install docs, there are some 3/4 mother boards
shown, and some to me look very old, like rames under the left of the keyboard
--
*** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz ***
*** 85 Donovan Rd * * GEnie. R.SHEPPARD5 ***
*** Kapiti At least I don't Flicker, ***
*** New Zealand.. * not like a dying light globe ***
------------------------------
Date: 23 Jan 92 09:34:11 GMT
From: noao!ncar!elroy.jpl.nasa.gov!usc!apple!well!dsmall@arizona.edu (David
Small)
Subject: SST shipdate & Gadgets news
To: Info-Atari16@naucse.cse.nau.edu
Here's some updates on the SST, Spectre, MegaTalk, and so forth, for
those who aren't on the GEnie / Compuserve networks (was posted there
this week).
We expect to start shipping SST's this week, barring Murphy's
law causing some minor problem. The software, hardware, and manuals are
ready, as well as a lot of mailing labels ... :-)
We're sorry for the delay in shipping. It was vital to track down
a serious bug in the hard disk "life support" for hard disks that were
SST RAM (fastram) unaware; it turned out to be a buffer overlaying code.
But it took weeks to nail down and led me down many false paths. Fun.
Several people have asked about the manual. Currently it is 2.8
megabytes long in Quark X*Press on Sandy's Mac. It works out to around 140
pages, plus or minus a few, on 8 1/2 x 11 paper. It's our best ever, with
plenty of interludes.
MegaTalk was held up on its production run by having one PAL on
every board be bad, probably from the factory. (SST had 4 bad GAL's from
the factory -- what's this Built in America stuff? Sheesh, talk about
getting good at switching chips). The MegaTalk batch here is about 75%
tested, and once you replace the PAL controlling serial I/O, they work
fine. They'll ship as soon as we get the SST shipping smoothly; both are
backlogged "to the gills" <-- Americanism.
Spectre is still at 3.0. Work is being done now on TT SCSI hard disks
so the internal drive and other SCSI devices can be accessed; that'll take
a little doing but isn't the end of the world. The code to fix the cached
accelerator bug on <4 meg machines is very minor (10 minutes?). Finally,
System 7 is giving me absolute conniption fits as I trace it, with the ZAX
set to "twang" and stop on any access to location 0 (typical Zerostore
goblins);
I don't understand why any sane programmer would read the entire contents
of battery-backed up extended parameter RAM into location 0 on up, thus
destroying all the 68000 exception vectors.
I'll fix that one, and keep on slogging through until the thing
boots up and quits hallucinating about its available memory (current symptom).
Problem is, I have NO WAY to predict how many bugs lie between where I am
now and bootup time; I just have to fix one and let it "G"o, and see where
it crashes NeXT ... *grin*. It's like debugging anything else, I guess.
This means, in simple terms, Spectre 3.1 does not exist.
Anyone advertising it? I have heard rumours. It just plain does not
exist.
It's been an interesting few weeks, as you might imagine, and
I've seen plenty of Colorado sunrises since I can get work done at night.
I have not been on the Net as much as I would like, nor any network; I have
had to focus time on SST's hard disk snag, as that was holding up the
manual and the disks, and it turned out to be difficult. (ST-Report ran the
final story; it's around 450 lines of text.)
I'll try to be answering back e-mail over the next few days; I still
have a couple minor "clean up" things to do (READ.ME files on the release
disks, for instance.). Currently, SST is at version 1.21.
We will begin the sixth Gadgets Newsletter as soon as I have something
to report on 3.1. I believe we are planning on FREE distribution of 3.1
unless something comes up to snag it (I can remember someone claiming that
posting s/w to the nets made it "public domain" ... yeah, right). I don't
know if the size, around 400K, will overload the net; I can't FTP and never
have, and don't know that side of things whatsoever. Maybe someone can let me
in on it. I'd like to get 3.1 around as quickly as possible.
Finally, we have isolated several different problems that TT's can
have with GCR's. Briefly, they are:
* The floppies are getting EMI from the monitor -- move it.
* The cartridge port fuse, on the +5 line, is blown. Common.
Check pins 14 and 28 for 0 and +5 volts (or close) respectively.
* The floppy drives may not be 100% if you have the caches on.
A lot depends on how fast the 68030 runs, which can depend on if
the program ends up paragraph aligned at a critical point. (True!)
Try clicking the caches off from the Spectre menu.
* DO NOT TT-RAM flag SPECTRE.PRG, LAUNCH.PRG, or GCRTEST.PRG.
* Finally, there can be a timing bug that relates to 68030's in
general and the GCR. It really all depends on the particular TT and on a
particular chip's speed in the GCR; if your GCR works, don't fix it!!!
We have a fix for this timing snag that appears to cure this problem
after much testing. I will try to get it from GEnie and upload it here. It
involves adding one IC piggyback and an RC network for fine tuning.
In the USA a "fix" involving piggybacking 7406 chips was published
by Atari User; no one checked with us. We have no idea why this would affect
the GCR on the TT whatsoever, and have talked to people who have gone to the
trouble of making the change to find it makes no difference. HONEST, the 7406
is NOT IN THE PATH OF THE MAC DATA being made by the GCR and sent to the disk;
the GCR drives the write-data line directly! I do not understand what this
7406 fix is about.
We have built up several hundred modified GCR's for TT's (they also
work on ST's still!) and are getting them into the pipeline.
Sorry for the overly long note; I had to route MANY rumours to
/dev/rumour/null.
-- thanks, Dave Small / Tired Bottle Washer / Gadgets by Small, Inc.
GEnie: DAVESMALL CIS: 76004,2136 Here: dsmall@well.sf.ca.us
FAX: USA (303) 791-0253, phone (303) 791-6098 mon-wed-fri (it is often busy).
------------------------------
Date: 24 Jan 92 01:39:45 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!wupost!waikato.ac.nz!comp.vuw.ac.nz!act
rix!Roger.Sheppard@arizona.edu (Roger Sheppard)
Subject: What to do?
To: Info-Atari16@naucse.cse.nau.edu
In article <4f3rxzd@rpi.edu> pinelr@aix.rpi.edu (Robert Jeffrey Pinelli) writes:
> In article <1992Jan23.031750.19244@verdix.com> scotty@verdix.com (Scott R.
Chilcote) writes:
> >
> >Hey, Ken, this isn't as twisted as it sounds!
>
> --Rob
>
> p.s. To get an idea how old my mega is, it has the 6 chip ROM set in it that
> almost NO Megas have! Boy am I glad I didn't take Toad Computer's word for
> it when ordering my TOS 1.4 upgrade!
>
Can you tell me what the problem was , as these machines can take both,
the 2 chip set is far better as it has less buss loading..
The only problem could be with very old ST's and ones with 2 rom sockets
as they can only take this 2 chip set, with out adding the extra sockets..
--
*** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz ***
*** 85 Donovan Rd * * GEnie. R.SHEPPARD5 ***
*** Kapiti At least I don't Flicker, ***
*** New Zealand.. * not like a dying light globe ***
------------------------------
Date: 24 Jan 92 02:02:04 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!Rog
er.Sheppard@arizona.edu (Roger Sheppard)
Subject: Yet another ST for sale
To: Info-Atari16@naucse.cse.nau.edu
In article <31717@natinst.natinst.com> glens@natinst.com (Glen Sescila) writes:
> england@u.washington.edu writes ...
>
> > Heh heh.... Like a rat scrambling to abandon a sinking ship, yet another
> > Atarian offers up his 'computer' hoping that some fool will be stupid enough
> > to buy it.
>
> I just wanted to mention that I can see at least 4X as many Amigas
> for sale per week as Ataris. In fact they had to create a whole seperate
> newsgroup just for unloading Amigas!
Well I quoted negative sales, meaning that they are taking there A500 Plus
back to the shops as they don't play games any more.
One shop here stated to me that only 2 games in the shop would work on
the New A500 +.
The games that are packed with the machine, most don't work, Commodore
include a list with the machine of the games that don't work..
And even Lemmings does not work, is that a old game..??
All this has been confirmed by 2 other Amiga Shops here
Hey this new work bench that they have still can't lasso files, to
copy or delete..
And they still use Sum Checks on all there disks..!!
> > Heh heh....
> -----------------------------------------------------------------------------
> "Now You're Playing With Power Without The Price!" Glen Sescila |||
> / | \
> My opinions do not necessarily reflect those of my employer and probably are
> exact opposites. glens@natinst.com
> -----------------------------------------------------------------------------
--
*** Roger W. Sheppard * Roger.Sheppard@bbs.actrix.gen.nz ***
*** 85 Donovan Rd * * GEnie. R.SHEPPARD5 ***
*** Kapiti At least I don't Flicker, ***
*** New Zealand.. * not like a dying light globe ***
------------------------------
End of Info-Atari16 Digest
******************************
