HDTenEightyP/NetNews huggingface dataset:
From: dtarico@violet.ccit.arizona.edu
Newsgroups: comp.sys.atari.st.tech
Subject: Spectre GCR troubles
Date: 18 Nov 92 20:01:17 GMT
Distribution: world,local
Nntp-Posting-User: dtarico

My spectre GCR has been acting up recently.  It is pretty stable running from
the hard drive, but the floppy drives have been having trouble.  I am
running a Mega 4 ST, Spectre 3.0, and system 6.0.5.  I also have an external
floppy drive.  The internal drive always gives errors on the 8 sec/track
part of the GCR test.  That could be related to interference, and since I have
the external drive, I just use it.  The external drive passes all of the
GCR tests.  But under Mac mode, I get some weird problems.  Disk errors happen
fairly often.  What is even stranger, is that I can copy files to and from
the hard drive and things work ok.  But when I try to use files on the
floppy drive, I get errors.  For example, I work with Macwrite a lot.  If I
copy the file from the floppy to the hard disk and work with it there, I have
no problems.  But if I try to work with the file on the floppy disk, the file
gets screwed up pretty bad.  Real Macs don't have any trouble working from
the same disks that the GCR has trouble with.
Does anybody have any ideas what could be causing this?  Yes, I have checked
all the cables, tried adjusting the dashpot.  Is Macwrite not completely stable
under Spectre?  Could it be that something is messed up on my hard disk?  
Thanks for any help!
----------------------------------------------------------------------------
         Doug Tarico                      
    dtarico@ccit.arizona.edu       This message has been brought to you
      doug@sie.arizona.edu           by the letter E and the number 2.
From: knarf@nasim.sta.sub.org (Frank Bartels)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: TOS 2.05 vs 2.06 ?
Date: 23 Nov 92 22:14:40 GMT
Organization: Knarf's UUCP-Center, Munich, West-Germany
X-News: HERMES MMAIL 1.04 Rev. Sep  5 1992

hutch@bellman.lanl.gov (John Hutchinson) writes:

>OK, here's an easy one.  Someone asked me the other day what the differences
>between TOS 2.05 and 2.06 were.  I understood there were just a couple of
>minor bug fixes but is there more?  Does 2.05 support the 1.44Mb format?
>Just curious so I'll have the right answers the next time.

You do not need any serial patch for the RTS/CTS bug in earlier
TOS Versions!

Question: Does anybody use TURBOCTS with the MUPFEL CLI? With the
TURBOCTS in the AUTO folder, MUPFEL doesn't execute any command?! The
problem was fixed using RS232ENC from the RUFUS package. But why?

Knarf
-- 
+-----------------------------------------------------------------+
| Frank Bartels - knarf@nasim.sta.sub.org - Munich - West-Germany |
+-----------------------------------------------------------------+
From: an938@cleveland.Freenet.Edu (George II Lenzer)
Newsgroups: comp.sys.atari.st.tech
Subject: Need HELP!!! with Memory expansion
Date: 16 Nov 1992 04:05:13 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


	I am having trouble with adding memory to my 520 STfm.
Everything is connected according to the instructions (From the
Umich Atari archives) but the upper bank of memory will not respond.
I remember that someone mentioned a few additional modifications
needed to be  put in.  I noticed that the CAS1 High and CAS1 Low
lines require resistors along with the RAS line.  But, what values
must be used?  Besides that, I can't think of anything else but a 
faulty MMU.  I believe that a person named Annius Groelink? knew 
what to do, but I do not have full Internet access so I can't
find the E-mail address.
	One other question is: can I use Mac SIMMs for the ST
mod since they have an 8 bit data bus, (and are considerably
cheaper!!).
						Thanks in Advnc,
						George II Lenzer
-- 
"I'll let you in on a little secret.
	The whole universe is totally INSANE!!!!"
						Mr. Natural

Newsgroups: comp.sys.atari.st.tech
From: grier@bnr.ca (Brian Grier)
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
Organization: Bell Northern Research
Date: Mon, 23 Nov 1992 17:38:37 GMT


> But how can this be? The 68030 has a 32bit data bus or are Atari using an
> adapted version?

> Ta!

The 68030 has a flexible bus architecture. It can happily live on 
an 8 bit, 16 bit or 32 bit bus.

The 68040 requires a 32 bit bus, unless the design team wants to add
a lot of hardware to do it. :^(

Brian, WS1S
Bell Northern Research
Research Triangle Park, NC
bjgrier@bnr.ca
Newsgroups: comp.sys.atari.st.tech
From: paetau@mits.mdata.fi (Rasmus Paetau)
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
Organization: Microdata Oy, Helsinki, Finland
Distribution: eunet
Date: Mon, 16 Nov 1992 16:32:46 GMT

In article <1992Nov16.132737.24016@rhrk.uni-kl.de> peter@rhrk.uni-kl.de (Gunter Bitz) writes:
>paetau@mits.mdata.fi (Rasmus Paetau) writes:
>
>>In article <1992Nov11.204525.11194@rmece49.upr.clu.edu> raist@rmece02.upr.clu.edu (Ricardo Hernandez) writes:
>>>   Reading from the above converstion, it looks like the Falcon
>>>68030 bus to memory is:
>>>
>>>   * 16 bit wide
>>>   * can't do the 68030's burst mode
>>>
>>>   Can someone with real Atari specs clarify this?
>>>
>>>- Raist
>>>
>
>>All "real" Atari specs say that the bus is 32-bit wide, and Quick
>>Index gives results of about 50% of a TT, which sounds reasonable as
>>the TT has 2x Falcon's clock frequency. I don't think this would be
>
>That's not true. The 68030 in the TT runs at 32 MHz but slows down
>to 16MHz during Ram access. Now explain me please, why a TT is
>two times faster than the Falcon !

It does? Are you sure?? I guess you are. Anyway, I wouldn't know
anything about TT RAM-access. I'm going to get a heart attack if
Falcon turns up with a 16-bit data bus. After that I'll go hunting for
a Tramiel scalp :). Please God, don't let Falcon have a 16-bit bus!
Do you think the faster TT-RAM could be the reason why the TT would
still be faster?

>>possible with a 16-bit bus. I still believe the Falcon has a 32-bit
>>wide data bus.
>
>>--
>>-----------------------------------------------------------------------
>>| Rasmus Paetau (paetau@mits.mdata.fi) | Waiting for the Atari Falcon |
>>-----------------------------------------------------------------------
>


--
-----------------------------------------------------------------------
| Rasmus Paetau (paetau@mits.mdata.fi) | Waiting for the Atari Falcon |
-----------------------------------------------------------------------

Newsgroups: comp.sys.atari.st.tech
From: kruel@phys-chemie.uni-wuerzburg.dbp.de (Thomas-Martin Kruel)
Subject: Re: Ethernet for the Atari ST ?
Organization: Institut fuer Physikalische Chemie / Uni Wuerzburg
Date: Mon, 16 Nov 1992 16:15:42 GMT

In article <1992Nov10.181900.190226@rrz.uni-koeln.de> 
kim@vax.mpiz-koeln.mpg.dbp.de  describes various Ethernet solutions for the ST;

In addition to that, I was aware of a genuine Atari product on that. I 
remember that thing was shown at the CeBit fair 2 or 3 years ago. The guy
told me Atari had thousands of them in stock and they were going to ship them
REALLY SOON NOW. 

Since then I've never heard about it any more.

So anybody knows what has happened ?

The card shown to me was designed to fit into the bus adaptor of an ordinary
Mega ST, connecting to the outside through the "slot" at the rear side of the
case. 

In contrast to PAMSnet and Biodata, which come in a separate case, this
seems to be the better solution.

In any case, Ethernet solutions for Atari are far more expensive than for
the PC (to my knowledge PAMSnet and Biodata are still around $500 or more,
whereas a PC ethernet card can be obtained at $170).

This is one major reason why ST's have been obsoleted in our department
and replaced step by step by PC's (sigh :-(

Thomas.
-- 

Th.-M. Kruel   Institut fuer Physikalische Chemie der Universitaet Wuerzburg
               Marcusstr. 9-11,  D-8700 Wuerzburg (Germany)
               Phone: +49 931 31579
Newsgroups: comp.sys.atari.st.tech
From: Colin.Toal@nautical.r-node.gts.org (Colin Toal)
Date: Sun, 22 Nov 92 21:45:03 EST
Organization: R-node Public Access UNIX Information System (416-249-5366)
Subject: The Falcon Bus Thing..
Distribution: world
Reply-To: Colin.Toal@nautical.r-node.gts.org (Colin Toal)
X-Posting-Software: UniBoard 1.10a S/N 120921

Okay, from my limited knowledge of the situation and what I have read from
the folks at Atari, someone said (I am not sure if it was Jim Allen->Fast
Tech or Bill Rehbock) that 16 bit Data Bus was done to ensure ST
compatibility, and that it would be easy to upgrade to 32-bit Ram using the
Ram Expansion Connector in the Falcon. The DaughterBoard Falcon Ram
essentially gives you another Expansion port, and 32 Bit Ram can be placed
in here to increase '030 performance. Claiming the Falcon is crippled
because it is 16 bit Data bus is silly. I think a major reason it was done
was because having the CPU on a 16 bit Data Bus and the VIDEL on a 32-bit
Bus would relieve any possibilities of Contention. Hopefully in the
Falcon040, they will have a 040 32 Bit Data Bus and a 64 Bit VIDEL Bus (like
TT Video Ram).. Out of Curiosity, the TT also has a split bus with ST Ram
being 16 bit and TT Ram being 32 bit.

"Megalon is Vanquished!!"....    Colin Toal aka Spaceman Spiff

--
Colin Toal, user of the UniBoard System @ r-node.gts.org
E-Mail: Colin.Toal@nautical.r-node.gts.org


R-node Public Access Unix/BBS - Free Access to the World thru Usenet
                 Data: 1-416-249-5366 (3 Lines)
     Shell Accounts Available - Contact marc@r-node.gts.org
Newsgroups: comp.sys.atari.st.tech
From: wmagro@uiuc.edu (William Magro)
Subject: Surface mounted 68030?
Organization: University of Illinois at Urbana
Date: Fri, 20 Nov 1992 21:29:26 GMT

I've read here that the 68030 in the Falcon is surface mounted.  Does  
anyone know of a good reason for that?  Wouldn't it be reasonably cheap  
and forward thinking to put it in a socket?

--
William Magro                                       NeXTMail welcome
wmagro@uiuc.edu
From: michael.smith@f842.n800.z3.fido.zeta.org.au (michael smith)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: getmpb
Date: 9 Nov 92 07:37:02 GMT
Organization: Fidonet. Gate admin is fido@socs.uts.edu.au

Original to: pcxkrm@unicorn.nott.ac.uk
In a message of <02 Nov 92 18:12:40>, pcxkrm@unicorn.nott.ac.uk (3:713/602)
writes:

 p> Hi,

G'day!

 p> As a person who has spent the last ten years programming almost solely
 p> in BASIC, the ins and outs of memory management are fairly new to me.
 p> I'm currently trying to write a program which needs to know where it is
 p> in memory. My GEMDOS information tells me that the 'C' call getmpb
 p> should do this - but it seems to return only the top of system memory or
 p> something - it gives the same thing every time with no pointer to a
second
 p> block.
 p> Am I being very thick or is there some other way to find out my
 p> program's basepage? I'm running an STe with 2Mb of memory and TOS 1.62.

Why do you want to find the basepage??  If you are looking for paramters,
that's the wrong way to do it...

Your library's startup code should define a variable called _baseptr (or
something similar) that points to it anyway.

 p> Keith.

\`miff`                                                       /|\

--- ScanMail 0.68 X0501
 * Origin: That Which Is Not, ST in SA. 61-8-232-5722 (3:800/842)
Organization: Penn State University
Date: Fri, 20 Nov 1992 21:30:58 EST
From: J.J. Lehett <JJL101@psuvm.psu.edu>
Newsgroups: comp.sys.atari.st.tech
Subject: Re: TOS 2.05 vs 2.06 ?
Distribution: world,local
 <1992Nov20.122630.4011@arizona.edu>

    The main difference between the two TOS's (2.05 and 2.06) is that while
both can will and format 1.44 density disks, only those formatted with 2.06
will be compatible with IBM format 1.44 disks.  (of course for 2.05, you could
always just format on a ibm 1.44 and then bring it home to a 2.05 machine to
use it also).
------------------
J.J. Lehett     : Atari's, puzzles, games, chaos, fractals, math....

  - Work: JJL101@psuvm.psu.edu           Penn State CAC
  - Genie: J.LEHETT2
  - Delphi: JLEHETT@delphi.com
Newsgroups: comp.sys.atari.st.tech
From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: Scrollable list boxes
Organization: SAR Systems Development & Processing, JPL
Date: Sun, 22 Nov 1992 08:36:09 GMT

In article <1992Nov12.140816.14051@aber.ac.uk> hrs@aber.ac.uk (Herbert Martin Sauro) writes:
>I am writing an application were I need scrollable list boxes in dialog
>boxes (eg. like the file selector list). Rather than write my own I was
>wondering whether anybody has any code already written to do this? Failing
>that what is the best strategy for writing a scrollable list? I have worked
>out that in order to make the scrolling fast and smooth I need to do some
>blitting, i.e.\ blit n-1 of the entries (n=no of items in scroll window)
>and write out the new line either at the top or bottom of the

I've been thinking about that as well, surely this is an often-enough used
bit of code that someone has published a standard way to do it... My
approach was simply to create a box, then create a bunch of string objects
as children of the box. Scrolling the text in the box is then only a matter
of changing the string pointers and calling objc_draw to redraw the box.

>list. And what is the best strategy to write a smooth moving slider which
>will sit next to the list box? I have managed to write a relatively
>smooth moving slider but it's not perfect.

Did you already look at graf_slidebox in the AES? Probably a lot easier...
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

All true wisdom is conveyed in one-line witticisms.
From: marks@castle.ed.ac.uk (Mark Steyn)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
Date: 19 Nov 92 12:42:51 GMT
Organization: Edinburgh University

hutch@bellman.lanl.gov (John Hutchinson) writes:

>C'mon folks, let's get real here, OK?

>Personally, I don't give a twit if the Falcon has a 32, 16, 8 or 2-3/4 data
>bus... as long as it performs and performs well in consideration of its cost!

But the point is that a '030 on a 16 bit data bus isn't going to perform
nearly as well as an '030 on a 32 bit bus.  The 16 bit bus will affect
almost all aspects of the machines performance.  There were rumours that
the 'true colour' modes would cause contention over a 32 bit bus.  The
16 bit bus will not improve graphics throughput any.

>That's like saying, I don't like this program because it was written in
>BASIC (or pick your favorite "non-favorite" language).  Even though it may be
>the greatest thing since sliced bread you still don't like it?  Who cares?

No - it's like saying I don't like this program because it could have
been so much better, and I can see alternatives programs availible which
look better.

The Falcon is not without competition.  The A1200 looks considerably
better, simply due to the fact that it is a true 32 machine.

The fact that the Falcon only has a 16 bit bus might not deter people
who own an ST from upgrading to the Falcon, but Atari desperately needs
to attract buyers who would otherwise have purchased a PC.  Crippling
the Falcon to reduce the price was not the way to do it.

>Sure, a lower throughput bus probably would limit the _potential_ of the
>machine, but there _are_ considerations that were made for compatability with
>older ST/STe software.  You don't have to like it, but be reasonable.

No, these consideration were due to one thing only - cost.
As for compatability, a UK magazine testing games on the Falcon found that
they all worked fine provided they did not use the sound chip.
A grand total of 3 I believe.

>All IMHO, of course.  :)

Of course.

	Mark
From: hutch@bellman.lanl.gov (John Hutchinson)
Subject: Re: Installation of TOS 1.4 (6 chip set)
Reply-To: hutch@bellman.lanl.gov
Organization: Los Alamos National Laboratory
Date: Wed, 18 Nov 1992 16:19:03 GMT

In article a6wLmlL3OuU@nasim.sta.sub.org, knarf@nasim.sta.sub.org (Frank Bartels) writes:
>
>Could anyone please tell me the Part No.'s of the six EPROMS I'll need
>to use for making TOS 1.4 EPROMS?

Ouch!  Being just a little bit bold, aren't you Frank?  The software encoded
in Atari TOS ROMs (any version) is _still_ copyrighted and may not be
legally duplicated without authorization from Atari.

I suggest you carry this discussion via email, or better yet, drop the idea
and just buy a legal set of TOS ROMs.

---

___________________________ John "HUTCH" Hutchinson _________________________
_________________ Fair Dinkum Technologies     Member - IAAD  _______________
________________ "No worries, mate... it's from Fair Dinkum!" _______________
____________ email: hutch@bellman.lanl.gov   GEnie: FAIR-DINKUM _____________
Newsgroups: comp.sys.atari.st.tech
From: apelled@cix.compulink.co.uk (Adam Pelled)
Subject: Re: Using an IBM keyboard with an Atari ST
Reply-To: apelled@cix.compulink.co.uk
Date: Thu, 19 Nov 1992 18:36:00 +0000


In article <1992Nov17.153244.11952@newshost.lanl.gov>, hutch@bellman.lanl.gov (John Hutchinson) writes:
>The D.E.K.A. keyboard adapter kit has received some pretty good reviews of
>late (most recently in Current Notes, Nov 92, pg 75).  Adopting a MSTE
>keyboard would be the easiest, but if you must go with a PC unit, the D.E.K.A.
>thingie offers a good solution, it seems.

    This Current Notes; What is it, and where can i get it from ?

    Incidentally, i have heard much the same regarding D.E.K.A.

    Adam.
From: jornmoe@fredrik.atari.no (Joern Moe)
Newsgroups: comp.sys.atari.st.tech
Organization: Atari Corp. Scand. AB (Norway)
Subject: Re: Falcon '030 BUS: 16 or 32 bit?
	<H.QHklPxgdMm2@fredrik.atari.no> <28341@castle.ed.ac.uk>
	<1992Nov19.043306.17354@elroy.jpl.nasa.gov> <28422@castle.ed.ac.uk>
Reply-To: jornmoe@fredrik.atari.no
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Fri, 20 Nov 1992 21:57:50 MET

In <28422@castle.ed.ac.uk>, Mark Steyn writes:
**** some stuff deleted ****
>wait to use the machine to see.  I have my concerns about the speed of
>the graphics over a 16 bit bus, though.  16 bit graphics over a 16 bit
>bus, sharing access with the processor does not sound as though it will
>be particularly fast.

The memory is 32 bit wide, the CPU <-> memory bus is 16 bit wide but the 
videochips <-> memory bus is 32 bit wide! This is WERY similar to the TTs
videomemeory, except that the TTs videomemory is 64 bit wide (YES, i said 
64 bit wide, and I have the scematics, so there's no doubt about it) but
the CPU (68030) of course acsesses this memory through a 32 bit wide bus!

>And how do you intend to plug your 32 Ram expansion in?
>The PDS internal slot is 16/24 bit.
>The processor is surface mounted.
>Umm... not much else is there?

The coprocessor socket have the full databus of the 68030, then the problem 
would be the address bus, but with soldering only TWO leads directly to the 
68030s adresslines and taking the 24 lower addresslines from the expansionbus, 
one can have 32MB of Fast-ram. Shouldn't be too hard to do, or what?

-- 
  _______________________________________________________
 / Joern F. Moe /  All above is my own personal opinion! \
/ Oslo, Norway /  Any lack of opinion above is also mine! \
-----------------------------------------------------------
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: CPX v1.00 Bug?
Date: 16 Nov 92 01:25:20 GMT
Reply-To: warwick@cs.uq.oz.au

cs90ijr@brunel.ac.uk (Ian J Ray) writes:

>Now, *sometimes* XControl misses a _single_ pixel line along the left edge
>of the redraw area.

>i.e.
>	            +---------------+
>	   +--------|       |       |
>	   |===Contr|      / \      |
>	   |        |               |
>	   |        |   Atari....   |
>	   |        |               |
>	   +--------|               |
>		    |    [ OK ]     |
>		    +---------------+

>	   +--------|----------+
>	   |===Contr|l Panel===|
>	   |        |          |
>	   |        |          |
>	   |        |          |
>	   +--------|----------+

>                    ^single pixel line left.

>This problem seems to depend on the 'alignment' of the XControl window
>on the desktop. Has anyone else had this problem? What is the latest
>version of XControl?

This happens with almost every acc in existence.  The problem is that the fill patterns
are not aligned to the object being drawn.  For example, using the 50% fill pattern will
give you either:

   ###################
   # # # # # # # # # #
   ## # # # # # # # ##
   # # # # # # # # # #
   ## # # # # # # # ##
   # # # # # # # # # #
   ## # # # # # # # ##
   # # # # # # # # # #
   ## # # # # # # # ##
   ###################

or 

   ###################
   ## # # # # # # # ##
   # # # # # # # # # #
   ## # # # # # # # ##
   # # # # # # # # # #
   ## # # # # # # # ##
   # # # # # # # # # #
   ## # # # # # # # ##
   # # # # # # # # # #
   ###################

depending on where you draw the screen.  The trouble then occurs when the GEM window move
code ***raster copies*** your window, rather than redrawing it.  If it redrew the object,
all work work (although MUCH slower).

The only solution I know is to align you windows according to what pattern appears in
them (eg. allign on odd (or even) pixels for the 2x2 fills, and 4-pixel boundaries for
the 4x4 fills... and so on).

... or don't use the VDI fill routines.

IMO, it isn't a problem.  It just looks a bit ugly on those RARE occasions when it occurs.

--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /
From: jared@midiline.la.ca.us (Luposian Knightwolf)
Newsgroups: comp.sys.atari.st.tech
Subject: Wanted
Date: Wed, 18 Nov 92 01:18:08 PST
Organization: MIDILine BBS - Altadena, CA - (818) 797-3285

Someone proficient in the knowlege of the 68030 processor and computer 
design/engineering of a computer, using such a processor chip.
 
Reply in Email to: jared@midiline.la.ca.us
 
Jared

-----
jared@midiline.la.ca.us (Luposian Knightwolf) 
MIDILine BBS (midiline.la.ca.us) - Altadena CA - (818)797-3285
From: mae@hplb.hpl.hp.com (Mark Eve)
Date: Mon, 16 Nov 1992 09:56:22 GMT
Subject: Wanted: Site with Gemview 2.1
Organization: Hewlett-Packard Laboratories
Newsgroups: comp.sys.atari.st.tech
Reply-To: mae@hplb.hpl.hp.com (Mark Eve)


Is there an ftp site with GEMVIEW 2.1 known or is the only way to obtain this
application by direct mail to its author?

Thanks in advance for any help,

Mark Eve.
Newsgroups: comp.sys.atari.st.tech
From: mho@uniware.de (Michael Hopp)
Subject: Re: Soldering to the shifter ?
Organization: UniWare Computer GmbH
Date: Thu, 19 Nov 1992 15:38:16 GMT
X-Newsreader: Tin 1.1 PL4

cdw@dcs.ed.ac.uk (Christopher Walton) writes:
: I am considering doing a memory upgrade on my STFM and it will involve
: soldering a socket on top of my shifter.  Can anyone tell me how vulnerable
: this chip is as I am not very experienced with a soldering iron ...
: 
since the shifter is quite expensive, you should consider to get your
connections from a socket between the old shifter socket and the shifter
itself or from a board whith two pin-lines (?) on the downward and
a socket for the shifter on the upward side, as i did for my memory upgrade.

you probably need to re-bend the shifter's shielding cover then.

of course this won't do if your shifter isn't socketed yet. in this case
i would adwise you to first get some solder on the socket and shifter pins
seperately where they later touch each other. be careful on the shifter,
touching the pins only for 1 sec., allowing them to cool a few seconds
inbetween and work in an nonadjecent order.
so prepared, when you get the socket in place, the iron needs a shorter
time to establish a connection because the solder only has to melt
together and not to coat both surface then, thus less heat for the chip.

and be sure to make the +5V & ground connections thick wires, b/c
memory chips need a high current at peak levels.
Newsgroups: comp.sys.atari.st.tech