Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 498
Today's Topics:
Accelerators for the ST forsale
All BBS sysops.
ARJ?
Atari.archive monthly posting
BBS request, here is two from NZ.
Deactivating your 520ST RAM (for upgrading)
dump files
Emulate? What about the other way.
ESDI harddrive
Gif viewer
Mega/STE Screen Shifting
Problems upgrading to 4M (was SIMMS from a Mac SE into an ST?)
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: 21 Sep 91 22:37:36 GMT
From:
noao!asuvax!cs.utexas.edu!usc!rpi!usenet.coe.montana.edu!ogicse!sequent!muncher
.sequent.com!ether!bug!stevef@arizona.edu (Steven R Fordyce)
Subject: Accelerators for the ST forsale
To: Info-Atari16@naucse.cse.nau.edu
I have come to possess a large number of Processor Accelerators for the 520,
1040, and Mega ST that I will sell for $65 each shipping included (add $5
for shipping outside the U.S.). I will sell two for $100. These are new
units, in the box, were built by CMI and are fully tested. These
accelerators are on multilayer boards that plug into a socket you solder
onto the 68000. These boards are built around a 16 MHz 68000 and run at
double the standard processor speed. The speed up you get with this product
depends on the software you are running, but it runs from 10 to 30%.
These boards (there is a different one for the 520/Mega or 1040, so let me
know what you want) also accept 68881 floating point unit of any speed,
although it doesn't pay to get one faster than 16 MHz. For software that
uses the math chip you can get speed ups of eight to ten times or more.
There is also a socket for an Atari blitter chip if your machine didn't come
with one. You can get these from your Atari dealer.
These boards originally sold for around $300. Schematics and PAL equations
are available on request. Complete instructions are included. DON'T try to
install one of these if you are not handy with a soldering iron and haven't
done this kind of thing before! I will not be liable for your mistakes.
If you want one of these, call or send a check to:
Steven R. Fordyce
6913 Sunnyview Rd NE
Salem, OR 97305-9543
(503)362-8637
Steven R. Fordyce uunet!sequent!ether!stevef
------------------------------
Date: 23 Sep 91 10:38:44 GMT
From:
arizona.edu!cerritos.edu!orion.oac.uci.edu!usc!wupost!waikato.ac.nz!aukuni.ac.n
z!kcbbs!kc@arizona.edu (Jon Clarke)
Subject: All BBS sysops.
To: Info-Atari16@naucse.cse.nau.edu
To the syops out there with FoReM, Express and the likes.
We have just set up a FNET node here in the Pacific (New Zealand)
which is run by Z*NET South in Wellington. We are looking for
other sysops in the Pacific basin to join in and or in any part of
the world. Please email me or I can drop a note here for all to read
and send to their favorate syops.
To the MBBS users and Sysops out there we have Usenet .MCL file if
you are interested in it please also email us. A copy was sent to the
Bath BBS in the UK but I have never _heard_ back from them so I guess
they went off the air.
- Jon Clarke Z*NET International
Sysop of Z*NET Pacific BBS, in Auckland New Zealand.
{there is even an Atari in Antartica!}
------------------------------
Date: 22 Sep 91 17:59:16 GMT
From:
noao!ncar!asuvax!cs.utexas.edu!samsung!caen!uwm.edu!linac!convex!rosenkra@arizo
na.edu (William Rosenkranz)
Subject: ARJ?
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Sep22.140142.12168@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz
(Roger Sheppard) writes:
>In article <1991Sep19.232557.10878@convex.com> rosenkra@convex.com (William
Rosenkranz) writes:
>> [ i rationally plead for non-GEM version of ARJ, calling for a seperate
>> GEM shell for desktop use, then i see this: ]
>Note: I brought a Atati because of its Gem capabilties, very easy to
>use and learn, but you keep on about CLI, Why do you live in the
>dark ages.
first of all, i am NOT saying don't make ARJ use from the desktop impossible.
i AM saying don't make ARJ use from a command shell impossible (like
using it in scripts or as part of a rule in make). i am not being fascist
here. i am not restricting YOUR life. go ahead an use the desktop. go ahead
and use ARJ from the desktop.
second, most of us that program the codes you use for free, find it
virtually impossible to program from the desktop. it is just not efficient
at all. if you write more than 500 lines of code a week you would agree.
if you are scratching you head right now wondering what "make" is that
i mentioned in the above paragraph, you do not fit in this category.
the "dark ages" are infinitely more productive for programming than the
"ultra-modern" GEM desk top. without multitasking windows (which GEM does
NOT feature), a robust set of GEM-based tools (none of these, either), the
desktop is only ok for running applications. please do not impose on me
or scores of other developers your concept of what we should use. don't
be a fascist...
> If I wanted CLI, I would have brought a PC, I am one for things
>that are easy to use, that is how you get more productivity.
>If you what to stay with your Steam Engine, why not go play with it,
>in the Museum.
geez, what can i say :-)
have you ever used a $250,000 high-end state-of-the-art workstation or
a $25,000,000 supercomputer? i got news for you: they ALL have CLIs for
using them. they ALL use unix (with few exceptions like CTSS, LTSS, COS
for crays). since when does atari's GEM desktop (which is not even
multitasking) better than unix for programming? sheesh.
you are obviously not using the ST the way i do. i WANT the st to look
just like my good ol' vt100 screen which i use at work on unix boxes.
that means a real unix-like shell. for your information, CLI's are
almost always 1) more productive, 2) FAR more versatile, 3) prefered
by programmers. and note that windowing systems on workstations run
CLI's in windows. the only difference is that you get more CLI's on
the screen at once and can cut and paste between them. it is still
a CLI, however. now leave me alone...
the ST is a very nice platform for development because unix utilities
port easily and hence make it nice do work like you would on workstations
and other unix boxes, even supercomputers.
here is another aspect: how do you list all lines in a file which contain
a certain string? you run grep.ttp. but this is not a GEM application
so you type in the dialog box its arguments. now how do you find a file
named "xxx.dat" on a hard disk? you run find.ttp. but that is not a GEM
application either so you type in the dialog box its arguments. keep this up
with about 50 other utilities commonly used by programmers and you see
that you might as well just enter them on a command line anyway. if you
provide me with GEM versions of ALL the utilities i regularly use when
programming i might be persuaded to go to the desktop. i also want to do
the grep and find AT THE SAME TIME like i can with a CLI (with minix or
MiNT). so go ahead and make GEM multitask while you're at it. until then
don't make stupid statements like CLI's are from the "dark ages". in fact
there is only one desktop approach that comes close to productive use without
a CLI and that is probably NeXT. even they offer CLI's, however, since
there are IMPORTANT things to do which can't be done (or are not available)
with a desktop metaphor. the Mac may have reasonable programming tools as
well from its desktop but i don't have a Mac.
and i am a reasonably proficient typist so why should i not use this skill?
i spend 75% of my time typing data into a file with an editor. you would
too if you were a programmer. so why should i move my hands off the keyboard,
slowing me down, if i am spending all my time typing anyway? or do you
have access to some system that programs with mouse clicks? if you do,
i am sure lots of people would be interested.
i also use my ST to connect to my system at work (which is obviously not
GEM based, thank god :-). that means i type. again, no mouse. those of us
born before 1970 (1960?) remember typing our programs on cards with key
punches. an interactive CLI was like a jump into the 25th century by
comparison. the GEM desktop, however, is not. it makes life easy for users
but not for programmers (who write the programs users use). why do you
want to slow us down and cut the production of programs you need/want/use?
an archiver is probably more important for me because of my 80 MB of hard
disk, about 1/3 or more is source code, mostly archived. it has to be solid.
i'll challenge you to a duel: we each write, compile, and execute a
significant application, you exclusively from the desktop, me from a
CLI. we use the same compiler (say gcc). guess who will get done first?
and note that the standard desktop limits the number of args to .ttp
programs. i regularly execute programs with 100's of characters on the
command line. to go thru a GEM version would mean clicking on scores of
buttons to execute say a compiler. and i'd still have to type in file
names anyway (unless the desktop can now read minds :-). to re-execute the
same command could mean re-clicking. with a cli i just type "!c" (to execute
the last command starting with the letter "c", say the compiler "cc") or
equivalent, all without my fingers leaving the keyboard to reach for a mouse.
this is how i use MY st. how you use yours will not in the slighest be
impacted by a GEM shell for ARJ. a GEM-only ARJ will severely impact
me, however. i don't think you really understand the difference. i have
proposed a scheme to allow you to use it the way you want while you
are suggesting a scheme where i cannot. what gives you the right and
the wisdom to do this? who are you to tell me (and other developers)
how we should use our computers? and why should i go out and buy a
compiler for $200+ to get an integrated (perhaps GEM) environment when
i can get a portable compiler (gcc) for free? and it gets updated far
more frequently than say turbo or lattice C. and it is supported by
top-notch programmers (esmith and bammi, et al) who understand my needs
since theirs are similar. and gcc runs on unix boxes and can generate
atari executables. this is not true of borland or lattice compilers as
far as i know.
sorry for the vented spleen, but i just get PO'd when i read stuff like
this...
>What is wrong with Thomas Questers version of Lharc, it is fully
>compatible with the PC version, and a lot better, plus it supports
>all the othere LZH/LARC Formats and Unix ones as well, and Note.
>packs far better than all the otheres, and is blindly fast.
there is no source available. he also added lh5 format which is not
generally available on other platforms. it has also no english docs
or screen help (except possibly only very recently tho 2.01c i believe
still spits out german with no args - and it has been 20 years since
i last read/spoke german [high school]). it is also written
in assembler (mostly?) so it will not port to anything else. i even
volunteered to thomas to help him port the sucker to unix if he sends
me source, but have so far not seen hide nor hair of it (just the
executables). if TQ's lharc is so good, then a unix version will help
make it universal. then it could port to VMS and MSDOS as well. then
TQ will be the lord of lharc :-) as long as he maintains it like rahul
dhesi does with zoo.
also, i think i have a version of TQ's lharc which unpacks files with
the wrong date, tho i have to double check this (i tested about 10 lharc
programs one day and several had this problem, one of which was one of
TQ's, i believe). if this IS the case, this is totally unacceptable.
i need the date to be exactly the same as it is in the archive since i
use tools which only work based on the date of files (e.g. make and RCS).
if an archiver can't get this correct, it is absolutely useless, no matter
how fast or efficient it is.
unfortunately, if it packs with lh5, you may not be able to unpack it on
(say) a unix or VMS system. and believe me, MANY people want to be able
to do this, even if you don't. so tho it can handle any lharc, it itself
generates files which are incompatible. and i don't want to spend half of
my life figuring out what is the latest version of lharc on 2 or 3
different platforms EACH WEEK.
of all the lharc's out there, TQ's seems to be the most robust, tho it
has its problems. there are so many versions out there that for compatibility
alone, zoo should get the nod for information exchange on the net. what
you do at home is your business. go ahead and lharc everything. just
don't shove it down my throat. zoo is centrally supported (like arc) on
all platforms. lharc is not. every system (PC, ST, amiga, etc) has its
own (incompatible) versions, even on the same system. that, pardon my
french, sucks. if you think not, just read some of the pleadings by
other people on this net saying "i can't extract <whatever>.lzh with my
version of lharc". happens every week. i have every version of lharc
i can find on the ST (including 3 or 4 of TQ's programs). this is a huge
waste of disk just to satisfy my paranoia that i will be able to extract
any .lzh that happens my way. in contrast, i have but 2 arc (arc 5.21 and
6.02) and 1 zoo (zoo 2.1). i can extract ANY non-corrupt .arc or .zoo with
these (and in the case of zoo, with fiz i can often extract parts of corrupt
files). this is not possible with lharc either (as far as i know).
zoo 2.1 gives about the same compression ratio as lharc. and i know
it won't get screwed up too badly by 16 people trying to "improve" it.
and it will probably be optimized fairly soon so that it runs like tuned
lharc version. personally, i'd sacrifice 2x the speed (on compression) just
to get the compatibility.
how many times do we have to go thru this? lharc should be banned, no
matter how "blindingly fast" or how tiny it makes files. that is not the
issue at all...
>PFX will pack programs, and will save a lot of disk space.
pfx is nice. i do use it on occasion. i plan to use it more now that i
have switched form alcyon to gcc (compilers). gcc tend to make larger
executables. and if TQ would mail me source to pfx (so i don't have to
disassemble it) i will even send him a shareware contribution (hint, hint,
thomas :-).
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 22 Sep 91 19:52:47 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!samsung!umich!terminator!terminator.cc.umich.e
du!weiner@arizona.edu (Jeff Weiner)
Subject: Atari.archive monthly posting
To: Info-Atari16@naucse.cse.nau.edu
Welcome to atari.archive.umich.edu
This is the monthly posting from the umich atari posse. We hope
it will answer some of those nagging questions that always seem to pop up
from time to time. If you have any additional suggestions, please mail
them to me, at weiner@atari.archive.umich.edu.
[Changes from month to month are marked with a * for easier reading]
1: How do I use BART?
Use bart by mailing atari@atari.archive.umich.edu and using the word
"help" as the body of the message. This *should* send you a help file.
If you have read the help file, and still have questions, please send
them to jon@atari.archive.umich.edu, not me.
2: How can I connect via FTP?
If you are interested in ftp, I recently wrote a beginner's guide. Please
mail me and I will send you a copy. I'll post it every once in a while too.
It's also available in the
3: What if my machine doesn't support name service?
Two things to do here:1) Demand that your sys-admin install it soon,
and 2) use the internet address 141.211.164.8. Be forewarned however,
this may change on a moments notice.
4: I can't download because my hard drive doesn't work and my modem goes
out sometimes and .....HELP!!!
Sorry, outside of the archive I really can't help you....Your best bet is
to find someone at your site with a similar set-up, or post to c.s.a.st
for advice.
5: What are all the ???s in your index?
The ??? symbol means that I have no clue what this file is. If you know
please drop me a note, but be sure to include what directory the file
is in, etc. Thanks.
6: When I try to FTP to the archive's host, I get a message saying that my
machine wasn't recognized and I wasn't allowed to log in. What's up?
We only accept ftp logins from recognized hosts. If you are not allowed
to log in, please try again. It is possible that the DNS took a bit too
long. If you are still denied access, ask your sys-admin to fix your
name servers.
7: Here's a question for you Jeff, how come I can't use 'ftp terminator.cc.etc'
any more to connect?
That's because you're not using atari.archive.umich.edu like we told you
to. Don't say we didn't warn you......The name of the host
and/or the host itself may change soon.
There are a few files you'll really like to have:
archivers/arc602.arc : The latest version of arc
archivers/zoo21bin.zoo : The classic archive program
archivers/compress.zoo : Useful for removing .Z from sounds and binaries
archivers/unlzh172.arc : Unpacks .lzh files
archivers/sttar.arc : Removes those nasty .tar extenders
THEY ARE CONTAINED IN THE SELF EXTRACTING ARCHIVE starter.tos!!! PLEASE USE IT!
* Please don't archive anything for uploading in arc6.02, unless you want
to provide me with the unix sources for it. I didn't think you
wanted to ...... HOWEVER, I'd be happy to accept zoo2.1 uploads.
Thanks to everyone who has uploaded anything lately.....
* Interesting things this month:
1. The other umich archives are starting to gain popularity. You may
want to check them out. They are located at archive.umich.edu. All
except the atari archive are housed there.
BART PROBLEMS:
* There haven't been many lately. Things seem to be moving smoothly.
There was no down time for BART in the past month.
* Once again, BART problems go to JON, not ME.
PLEASE NOTE: FTP service is a privelege, not a right! Please make
a supreme effort to keep heavy FTP use in off-time hours (i.e. after
5 pm EST but before 8 am EST), or else you will be shot. (We mean it).
Any ideas, questions, comments, etc. to me,
weiner@atari.archive.umich.edu
--
Jeff Weiner --- weiner@{ub.cc, um.cc, atari.archive}.umich.edu
Corner of Packard and State, 2nd house from Blue Front on Arbor
Couldn't think of a witty saying to go here - give me some time
------------------------------
Date: 23 Sep 91 10:28:04 GMT
From:
noao!ncar!asuvax!cs.utexas.edu!wupost!waikato.ac.nz!aukuni.ac.nz!kcbbs!kc@arizo
na.edu (Jon Clarke)
Subject: BBS request, here is two from NZ.
To: Info-Atari16@naucse.cse.nau.edu
Name : Z*NET Pacific , STaTus BBS
Phone : (011-649) 606067
(011-649) 608485
Storgae : 1,300 megabytes
Location: Auckland New Zealand
Software: Michtron Version 3.0
Baud : 300,1200,1200/75,2400,9600,14.4k in PEP
-=-=-=-=-=-=-=-=-
Name : Z*NET South , Harbour Board
Phone : (011644) 762852
Storage : 60 megabytes
Location : Wellington, New Zealand
Software : FoReM ST with FNET conferences to the USa and UK
Baud : 300,1200,1200/75,2400
Hope this helps Dennis.
Jon Clarke, Z*Net International Online Magazine
Sysop Z*NET Pacific, the STaTus BBS in Auckland, New Zealand.
(The telecom capital of the global village)
------------------------------
Date: 22 Sep 91 07:37:45 GMT
From: noao!asuvax!cs.utexas.edu!utgpu!watserv1!bmaraldo@arizona.edu (Commander
Brett Maraldo)
Subject: Deactivating your 520ST RAM (for upgrading)
To: Info-Atari16@naucse.cse.nau.edu
In article <A1290082101@thelake.mn.org> steve@thelake.mn.org (Steve Yelvington)
writes:
> > My feeling of this is that you NEED (i never read you did) to remove or
> > at least deactivate the 256K Chips , which normaly reside in BANK 0
> > In the case you forgot that, the hardware gets into VERY big Trouble when
> > reading from the rams at an Address greater than 512K. If you leave the
> > HIGH Address line unconnected (MAD10 i think) the system reads and writes
> > into the same bytes, which shouldn't make any Problems.
>How do you do this (temporarily)? I have an old nearly-original 520 (with
>modulator, without floppy) that has a half-populated Tech Specialties
You do not have to remove the 16 256k drams to deactivate them.
To put the chips into a low power standby mode you put CAS0 and CAS1 high.
This is easily accomplished:
1) locate resistors R135 and R136
2) desolder the left lead from each resistor from the main board
- this is the left lead with the board oriented component-side
up, with the connectors furthest from you.
3) connect the desoldered leads to +5V (pin 8 of the memory chips)
If the 520 doesn't have R136 and R136, you can disable the memory row
by putting RAS high. Cut the trace leading from pin 8 of U15 (RAS on MMU)
to pin 4 of U16 (sometimes U17). connect pin 4 of U16 to +5V.
Brett L Maraldo
--
-------- Unit 36 Research ---------
"Alien Technology Today"
bmaraldo@watserv1.UWaterloo.ca
{uunet!clyde!utai}!watserv1!bmaraldo
------------------------------
Date: 22 Sep 91 06:18:07 GMT
From: noao!ncar!asuvax!ukma!gatech!mailer.cc.fsu.edu!bind!boyd@arizona.edu
(Mickey Boyd)
Subject: dump files
To: Info-Atari16@naucse.cse.nau.edu
In article <LAHTINEN.91Sep19094758@gideon.gideon.fmi.fi>,
lahtinen@gideon.gideon.fmi.fi (Kimmo Lahtinen) writes:
>
>I am looking for a programs that lets you see (in hex and ascii) a file
>and perhaps also edit it. There should be some programs like this, so
>I think it is not worth doing it myself. I have been using DLII, but
>it quite complicted to go to the file editor.
The best one I have seen is Memfile, by the same guy that did Neodesk. It
is PD or Shareware, and available via ftp from atari.archive.umich.edu. It is
a memory/file/sector editor.
There was also a really neat German pd or shareware program, but it did not
like my Neodesk installed font.
--
---------------------------------+-------------------------------------
Mickey R. Boyd | "Kirk to Enterprise. All clear
FSU Computer Science | down here. Beam down
Technical Support Group | yeoman Rand and a six-pack . ."
email: boyd@nu.cs.fsu.edu |
---------------------------------+-------------------------------------
------------------------------
Date: 22 Sep 91 06:26:22 GMT
From: noao!ncar!asuvax!ukma!gatech!mailer.cc.fsu.edu!bind!boyd@arizona.edu
(Mickey Boyd)
Subject: Emulate? What about the other way.
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Sep20.151133.5618@bdt.com>, CATHRYN@bdt.COM writes:
>How about an ST emulator card which would fit into a slot of a PC clone. So I
>could run old ST software and clone software without having computers take
>over the house!
Derek M (the author of STXFormer, the software 8-bit emulator) has stated that
he is/was working on a software ST emulator for 80xx6 platforms. The
"Gemulator" can supposedly blow an ST out of the water on a 486. I have not
heard a followup on this for some time (I read about it in Current Notes
some months ago). This should be interesting if it ever appears . . . .
--
---------------------------------+-------------------------------------
Mickey R. Boyd | "Kirk to Enterprise. All clear
FSU Computer Science | down here. Beam down
Technical Support Group | yeoman Rand and a six-pack . ."
email: boyd@nu.cs.fsu.edu |
---------------------------------+-------------------------------------
------------------------------
Date: 22 Sep 91 06:39:04 GMT
From: netcomsv!seitz@decwrl.dec.com (Matthew Seitz)
Subject: ESDI harddrive
To: Info-Atari16@naucse.cse.nau.edu
In article <8774@squire.cme.nist.gov> chang@lurch.cme.nist.gov (Forrest Chang)
writes:
>
>I figure I'll have to get an atari->scsi host adpater and then a scsi
>to EDSI [sic] adapter if such a beast.
Yes, there is such a thing as an ESDI to SCSI adapter. My company uses the
Emulex MD-23 ESDI-SCSI controllers. Each MD-23 allows up to four ESDI drives
to be accessed from the SCSI bus. One nice benefit of this approach is that
the four ESDI drives share just one SCSI ID (they have different SCSI LUNs).
Theoretically, one could hook up 28 ESDI drives to your system this way.
In theory, this should work. However, I have never attempted to use an MD-23
to hook an ESDI drive to an ST.
--
Matthew Seitz
seitz@netcom.com
------------------------------
Date: 22 Sep 91 08:23:14 GMT
From:
noao!ncar!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!ninjam@arizona.edu
Subject: Gif viewer
To: Info-Atari16@naucse.cse.nau.edu
Does anyone kow where I can get ahold of a GIF viewer for my 520 st?
Thanks.........
------------------------------
Date: 22 Sep 91 11:55:23 GMT
From:
arizona.edu!cerritos.edu!orion.oac.uci.edu!usc!cs.utexas.edu!qt.cs.utexas.edu!@
arizona.edu (LarsErikOsterud)
Subject: Mega/STE Screen Shifting
To: Info-Atari16@naucse.cse.nau.edu
The last weeks several people having the same trouble with their
new MEGA STE has asked me how we fixed mine, and I hope this file
can help you fix it. It's really the best machine Atari has made
so it would be terrible not to have it in perfect condition :-)
Errors on DMA-sound and video on MEGA STE - HOW WE FIXED IT !
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Here's a summary of what we found at service in Norway.
First - the errors on both machines we discovered were:
- Static/noise on DMA sound and MIXed standard ST sound.
- Sync-problems when using Spectrum512 pictures (vertical bars).
- Vertical flickering bars on monochrome (most at 8 MHz).
- Right edge of monochrome screen "flips" over to left edge
when changing screen adress/resolution in mono-mode.
We tried to find a chip that could be the cause of all these
problems and found a big VLSI chip partly hidden under the right
edge of the VME-card holder. It's chip U502 on my MEGA STE and
is called GSTSHIFTER on the print-layout. After looking at the
print-layout on both MEGA STE and standard STE we found the same
chip on standard STE, a combined sound/video chip but with a totally
different part-number. Anyway, we removed the original MEGA STE
chip (made in 1990) and replaced in with the STE chip (from 1989)
and all the problems were gone. If you want to "steal" a chip from
a standard STE it's chip U401 inside the STE (still GSTSHIFTER).
Disclaimer: Even though this solved the problems for us it might not
work for all MEGA STE's and you do this at your own risk
(I still would like Atari Corp to give some official information on
this. It's not "ONLY YOUR MACHINE" anymore. It's quite a few...)
Lars-Erik / Registered Developer / ABK-BBS +47 2132659 / ____ ______
0sterud / w/ Atari Scandinavia / larserio@ifi.uio.no / /___ /
__________/ _______________________/ ______________________/ ____/ /
------------------------------
Date: 22 Sep 91 01:49:00 GMT
From: ubc-cs!fornax!wolfgang@beaver.cs.washington.edu (Wolfgang Jung)
Subject: Problems upgrading to 4M (was SIMMS from a Mac SE into an ST?)
To: Info-Atari16@naucse.cse.nau.edu
In article <A1290082101@thelake.mn.org> steve@thelake.mn.org (Steve Yelvington)
writes:
>[In article <1991Sep21.030908.985@cs.sfu.ca>,
> wolfgang@cs.sfu.ca (Wolfgang Jung) writes ... ]
>
> > My feeling of this is that you NEED (i never read you did) to remove or
> > at least deactivate the 256K Chips , which normaly reside in BANK 0
> > In the case you forgot that, the hardware gets into VERY big Trouble when
> > reading from the rams at an Address greater than 512K. If you leave the
> > HIGH Address line unconnected (MAD10 i think) the system reads and writes
> > into the same bytes, which shouldn't make any Problems.
>
>How do you do this (temporarily)? I have an old nearly-original 520 (with
>modulator, without floppy) that has a half-populated Tech Specialties
>piggyback board. I'd like to bring it up to 4MB, since chips are
>practically free these days, but to do so I need to disable bank 0. I'd
>like to do that without having to get a bunch of chips desoldered -- in
>case it doesn't work and I have to restore the original setup.
There are 3 Lines which need to be disconnected to the old chips and
also to be set to a certain Level (Are they High or low activ, if High active
tie them via a 1Kohm Resistor to GND and if activ low tie them via a resistor
same type to +5V) The Lines are CAS0H CAS0L RAS0. You need those for the
SIMMS, and normaly there are resistors via which CAS0H and CAS0L are connected
so there is an easy way to re/connect them if nescassary.. RAS0 (also RAS1)
has no resistor to use for this kind of thing, BUT it shoulb be running OK
without disconnecting RAS0, becasue only in conjunction with the CAS lines
the RAMS get selected and selects the specific BITS, it will refresh those
old 256K Rams but that should't cause any Problems, except for the
loading the MMU (depends on the builddate .. I think the oldest are the
ones which are capable of accepting the MOST load..
Bye
Wolfgang
--
Note: Please Use woju@cs.sfu.ca as Address after Monday the 9th Sept
After 25th Sept mail to woju@mist.sub.org
------------------------------
End of Info-Atari16 Digest
******************************
