terrell@OHIO-STATE.ARPA (Eric Terrell) (05/20/86)
Once again my 520ST is screwed up. This time every time I try to do just about anything with the control panel, the system reboots. Often when I change the date, the background color near the cursor will be wrong. Sometimes some dots on the screen are wrong. I have ROM TOS and a mono screen. A while ago people were discussing the alleged reliability of ATARI ST COMPUTERS. I have had nothing but problems with mine. My first ST lasted about three days until it wouldn't boot (the disk drive would make a terrible noise, etc). The next ST had an unstable screen (text & graphics would quiver slightly). Finally this one is screwed up also. The last time I sent in a computer to ATARI product servce, it took over 6 weeks to get my system back. They were ready to ship very soon after they got my unit, but because they were doing inventory, they kept the unit (ready to ship) in the fucking warehouse for about 3 weeks. This is the kind of treatment I got with my Commodore-64. It looks like ATARI is unprepared both to produce a reliable product and to provide adequate support. Eric Bergman-Terrell
franco@iuvax.UUCP (05/22/86)
I think you might improve the reliability of your machine by doing the 1 meg upgrade. All that soldering may improve the connections to your memory chips (seems to me that is where your problem is) and you can resolder any additional suspicious looking connections. Also, while you have the hood up you can reseat those custom chips that like to pop out of their sockets during shipment. I gave this treatment to my ST and I have not seen a problem since (5 months). Be sure to take the usual anti-static precautions when messing around inside.
sean@ukma.UUCP (Sean Casey) (05/22/86)
In article <8605200418.AA18920@ohio-state.ARPA> terrell@OHIO-STATE.ARPA (Eric Terrell) writes: > >The last time I sent in a computer to ATARI product servce, it took over >6 weeks to get my system back. They were ready to ship very soon after >they got my unit, but because they were doing inventory, they kept the >unit (ready to ship) in the fucking warehouse for about 3 weeks. Although it's not official policy here at the lab where I work, we have found that an effective way to deal with this sort of situation is to call them up every day and ask them what is going on. If you get less than satisfactory answers, get the person's name and ask to talk to management personnel. This usually produces quick shipments. Be sure when you deal with a company that you get a phone number where you can have the order tracked down. We bugged Digital for weeks when our uVax II didn't arrive on time. We'd call them up every day: "Where's our Vax?". The answers were usually pretty funny. :-) Sean -- ------------------------------------------------------------------------------- Sean Casey UUCP: cbosgd!ukma!sean CSNET: sean@uky.csnet University of Kentucky ARPA: ukma!sean@anl-mcs.arpa Lexington, Kentucky BITNET: sean@ukma.bitnet
sean@ukma.UUCP (Sean Casey) (05/22/86)
Oh yes, I also should add that *anytime* you deal with someone through the mail (ordering, having fixed, etc.) you should: 1. Wait about a week. (for things to get to you, for your order to get there) 2. Call them and check on the order. (unless you've already received it) 3. Make sure they've got the order. 4. See if they've shipped it. 5. Find out when they're going to ship it and HOLD THEM TO THAT DATE. By bringing attention to the order, you'll get it out of the TO DO pile and in motion. It also gives you ammunition should they start delaying. "Gee I called and YOU SAID it would be shipped Friday". Once again, if all else fails, start taking down names and calling up management. -- ------------------------------------------------------------------------------- Sean Casey UUCP: cbosgd!ukma!sean CSNET: sean@uky.csnet University of Kentucky ARPA: ukma!sean@anl-mcs.arpa Lexington, Kentucky BITNET: sean@ukma.bitnet
slavenbg@prle2.UUCP (Gert Slavenburg) (05/28/86)
In article <8605200418.AA18920@ohio-state.ARPA> terrell@OHIO-STATE.ARPA.UUCP writes: > >Once again my 520ST is screwed up. This time every time I try to do just >about anything with the control panel, the system reboots. Often when I >change the date, the background color near the cursor will be wrong. > Indeed this reminds me of a problem. Some time ago we massively installed EPROM TOS (because ROM TOS was available late in Europe and secondly we don't believe ROM TOS is bugfree enough yet). We used 250 nSec. access time EPROMs based on the fact that a US component suppliers uses(used ?) those. We found similar problems (you can't move the sliders of the control panel and closing the control panel often causes fail/reboot). Though Eric has no EPROM's, the similarity of the problems causes me to suspect that your machine has access time problems on the ROM's, probably due to extreme tolerances of several components. In that case you better exchange it ! General ADVICE on TOS EPROM's : =============================== We found out that the critical requirement for ROM or EPROM's in the 520ST is that data out should be valid 200 nSec. after applying Chip Enable. The origi- nal Atari ROM's are OK (of course). If you have had EPROM's installed, you should verify the access time of the particular type that your supplier gave you. 250 nSec. EPROM's do not meet the requirements and may cause unexplainable system unreliability (like Eric has). You do need 200 nSec access time EPROMs theoretically, although certain brands or batches of 250 nSec EPROM's work. I wouldn't entrust my data to them though. We are now using 200 nSec. access time 32k*8 CMOS EPROM's without problems. Some confusing FACTS : If you have too slow EPROM's you cannot find out by repeatedly checksumming or otherwise testing the ROM area. Accessing them as data works fine. Executing from them only causes these problem. (can you imagine the time we wasted !?) Atari has a warning out that certain brands of EPROM's do not work. They do not mention an access time problem, nor do they specify access time requirements. We found no brand related problems, just access time problems. Neil (@ Atari), I would like your comments. Gert Slavenburg