bryce@COGSCI.BERKELEY.EDU.UUCP (09/01/87)
As many of you are aware, a company called C Ltd. produces memory and hard disk products. They acknowledge that some of their products (and products from some other manufactures) will act unreliably on some Amiga 1000's, and that if you chain two or more of those (*unbuffered*) devices you run a greater risk of failure. Symptoms range from total refusal to work, to intermittent crashes to intermittent loss of Kickstart (machine crashes all the way to Kickstart). They recommend as a solution replacing two PAL chips inside the machine. My repair person friend, Bruce Takahasi, does not subscribe to this belief. Replacing the PALs has not produced any fantastic improvement in any of the cases that he has tracked. He does have an alternate solution... First, though, here is what C Ltd. has to say:: > ...This problem stems from the speed of the PAL chips used by Commodore in > the manufacture of the Amiga. Early Amigas used PALs manufactured by MMI, > and these chips seemed to work well in almost every case, but at some point > Commodore started using PALs made by Texas Instruments. The TI PALs, > though having the same rating as the MMI parts, simply do not perform as > well causing the problems as stated above. Replacing the parts with the > much faster 16L8B part (any manufacturer's "B" versions are fast enough) > solves the problem. We have researched this problem to 'death' and are > confidant both from analysis of the system with the Texas Instrument PALs > and from experimental analysis of the system with the faster 16L8B PALs > that we know what the problem is and how to fix it... > > ...So in conclusion, the best solution to the problem is replace the PALs. > By the way, if there is blame in this matter it is probably on the > shoulders of Texas Instruments and their PAL chips. [we will sell these > chips and installation, call for details] > > E.J. Lippert II C Ltd. Wichita, KS (316) 267-6321 Bruce's explorations lead to a different solution. The key clue was noise. A high speed 'scope revealed that the ground pins of two of the four PALs on the RAM/ROM daughterboard had a very high 90 milivolts of noise. This is at the very least a potential cause of problems... and one that would not be solved directly by swapping PALs. (Swapping PALs may fix the symptoms, but would not cure the cause). The RAM/ROM daughterboard has 4 layers with one each for ground and +5. One might assume that all four grounds would be securely tied together. This turns out not to be the case. Under a bright light it is revealed that the two PALs with high noise are isolated from the main internal ground layer. The classic reason for isolating grounds is to isolate noise. In this case it appears that these isolated PALs have an insufficient ground. The solution that has worked in several cases is to improve the grounds for these PALs. The ground pins of each of the four PALs are connected, and a clip extends from the last PAL (U6J) down to the motherboard. Here's a diagram: ^ clip | | J K L N ---X---O X---O X---O X---O O---O O---O O---O O---O .......................... The X's indicate pins to be connected. The clip connects to ground on the motherboard at a point just to the left of the power supply connector (There is a row of 8 capacitors with ground on the side nearer the connector). One other modification is made in certain cases. A ground is extended from the negative end of a capacitor at the "diving board" end of the daughterboard to a capacitor in the chip ram array. Newer Amiga 1000's already have this modification from the factory and thus don't need it. Please let the net know if you have tried this, and what your experiences are. While it is not expected, Commodore/Amiga engineers are also invited to comment. Another interesting thing to think about would be removing the daughterboard altogether and just have Kickstart in ROM. This would probably require changes to one or two of the PALs, however. |\ /| . Ack! (NAK, EOT, SOH) {O o} . ( " ) bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce U If "hoser" does not work, try my old address at "cogsci"
nevets@ihlpm.ATT.COM (Steven R Ringwood) (09/04/87)
In article <8709010613.AA05631@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > The solution that has worked in several cases is to improve the grounds for > these PALs. The ground pins of each of the four PALs are connected, and a > clip extends from the last PAL (U6J) down to the motherboard. Here's a > diagram: > > ^ clip > | > | J K L N > ---X---O X---O X---O X---O > O---O O---O O---O O---O > .......................... > > The X's indicate pins to be connected. The clip connects to ground on the > motherboard at a point just to the left of the power supply connector > (There is a row of 8 capacitors with ground on the side nearer the > connector). > > |\ /| . Ack! (NAK, EOT, SOH) > {O o} . > ( " ) bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce > U If "hoser" does not work, try my old address at "cogsci" Bryce sent us this other solution to the bus problem just when I had discovered my Amiga would not work with two devices on the bus. So I decided to try it, opened up the Amiga, took of the shield, and sat and thought about how to do the job. In the end I used wire-wrap wire, a solding iron, and an old alligator clip. Since the pins in question were flat against the board, i first straightened them out. (I used a dentist tool to lift the pins away from the board). Then using a single piece of wire and careful spot stripping, i connected the four pins together. The wire was wrapped around a pin, the a small (very small) drop of solder applied, then on to the next pin. For practical reasons i started at U6J and left extra wire hanging toward where the clip would be attached and worked toward U6L. I then attached the alligator clip, and clipped it to the negative end of one of the capacitors. A note of caution here, not all the capacitors have the negative side toward the connector. The negative side can been told by the large blue strip and large minus sign. Bryce also mention a capacitor on the diving board, i skipped this step. Did it work, for me YES. Before making this change i could not get by 2Meg Starboard II and Supra 30Meg harddisk to work together. After the 'fix', they both work but only if the Supra is first on the bus for some reason. It took me about two hours from start to finish working at a slow pace. Since the job requires solding i would not recommend it to everyone, but if you are confortable with this type of work it is not very difficult. Thanks to Bryce for this tip. BTW: How many people knew that besides the paw print, and many English signatures, two of the signatures are in Chinese? Steven Ringwood ihnp4!ihlpm!nevets
phils@tekigm2.UUCP (09/06/87)
In article <1367@ihlpm.ATT.COM> nevets@ihlpm.ATT.COM (Steven R Ringwood) writes: >In the end I used wire-wrap wire, a solding iron, and an old alligator clip. ^^^^^^^^^^^^^^ > ... > >Did it work, for me YES. > >Before making this change i could not get by 2Meg Starboard II and >Supra 30Meg harddisk to work together. > >After the 'fix', they both work but only if the Supra is first on the >bus for some reason. > ... > >Steven Ringwood >ihnp4!ihlpm!nevets I'm glad to know that Bryce's fix worked for you, but personally, I'm a bit surprised to find it to have been effective with such small wire. Presumably the intent of the fix was to decrease the impedance of the ground path back to the power supply common, in light of inadequately sized conductors on the circuit board. The additional grounding you get from wire wrap wire is questionable. May I make a suggestion? Try using some larger wire, or even some small ground braid (enclosed in some form of suitable insulation). This *may* clear up your position dependency, although I rather suspect that the real reason is that the disk controller's circuitry is more susceptible to the degraded signal timings available at the end of the bus. Another comment: wiring the grounds in series the way Bryce described may result in reduced effectiveness for the device at the end of the chain. This is due to the same effect which causes the problem in the first place: the higher the impedance, the greater the voltage drop across that impedance for a given current returned to common. Putting all of the devices on the same circuit causes coupling of noise from all of the PALs to each other. If the impedance of the ground is low enough (read: large enough wire) the noise level may still be low enough, and it won't matter. However, if you use small wire, it may be more effective to connect each PAL *individually* to your good, solid ground point. Again, congratulations for getting multiple devices running on the expansion bus, and hope these suggestions are something you can use. -- ------------------------------------------------------------------------------ Phil Staub "I do NOT approve. I merely said I UNDERSTAND." tektronix!tekigm2!phils - Spock phils@tekigm2.TEKSpock
hull@hao.UCAR.EDU (Howard Hull) (09/06/87)
In article <2141@tekigm2.TEK.COM>, phils@tekigm2.TEK.COM (Philip E Staub) writes: > In article <1367@ihlpm.ATT.COM> nevets@ihlpm.ATT.COM (Steven R Ringwood) writes: > >In the end I used wire-wrap wire, a solding iron, and an old alligator clip. > ... > > > >Did it work, for me YES. > > > I'm glad to know that Bryce's fix worked for you, but personally, I'm a bit > surprised to find it to have been effective with such small wire. Presumably I am reminded of the time I had to determine an ECO on a flakey async counter board at a field site. I knew it had to be a layout problem, as the wire-wrap prototype had worked ok. I had told the layout artist "Make sure you assign enough pins for the grounds. You need at least two, including the ones on the end of the connector" instead of '...and make sure you assign both sets of the end pins to ground and grid your ground conductors' (This was an all digital board). Looking at the board, there was only one 20 mil ground etch running all the way around the outside of the board to ONE pin at each end. There were two other pins about a cm in from each end that were added to access a couple of trapped IC pins that needed grounds. Being in the field as I was, I got out the braid, copper flashing, and mica. I tried bunches of things with the ground system, and while most things helped, I couldn't get it to do better than one fault per hour (groan). So by then I had gone on to the question of the bypass caps and looking for a problem there. Then I accidently soldered a 0.1 ufd stacked ceramic cap *between the interior and exterior ground pins* - that's ground to ground, y'all. At that point, the problem vanished! I rechecked by replacing the cap with braid strap, and the circuit faulted within 30 seconds of turnon. By then I was out of time and had to rush to make a flight. At any rate, there were no further reports of trouble with the system while we worked on the problem at the home plant. Now that sure would have made a funny looking ECO, wouldn't it... That's why they call those people layout ARTISTS. Of course, we had to redo the layout to kill the spook. It's clear that in the relam of DC vs. 20 MHz., the same board looks quite different to the sensing and referencing electronic elements. The high frequency grid resonances can play an important part in data reliability, and the pin to pin DC drop can displace the amplitude of the ringing (which some people, in my opinion, mistakenly call "noise" - it's not noise, it's really only "aberration"). The result of too large a grid (even using 200 mil lands) will be a flakey design which will not function reliably if produced in mass quantity. Indeed, memory and IC counter manufacturers carefully tailor the rise time of their products so that they are in concert with the set-up, propagation delays, and desired speed of the product line, but not so fast as to generate multi-megaHertz ringing responses in boards that employ good practice and proper layout techniques. For designers to be assured of the correct function of high-speed digital boards, they must either provide a good ground grid or go to multilayer, and correctly utilize an interior ground sheet. Even that implementation requires some artistry. There is an Intel App Note in the Memory Products section about the former method, and a good essay in a back-issue of DTACK Grounded (Hal Hardenberg) about the latter. Unfortunately, I am away from work and my references right now, but I can respond to mail requests from any who want the references (unless your site is behind RUTGERS or CMU - both of which are zero probability addresses from here, it seems). Best Regards, Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull for domain mailers: hull@hao.ucar.edu
jdow@gryphon.CTS.COM (Joanne Dow) (09/11/87)
In article <2141@tekigm2.TEK.COM> phils@tekigm2.UUCP (Philip E Staub) writes: >In article <1367@ihlpm.ATT.COM> nevets@ihlpm.ATT.COM (Steven R Ringwood) writes: >>In the end I used wire-wrap wire, a solding iron, and an old alligator clip. > ^^^^^^^^^^^^^^ >> >... >> >>Did it work, for me YES. >> >>Before making this change i could not get by 2Meg Starboard II and >>Supra 30Meg harddisk to work together. >> >>After the 'fix', they both work but only if the Supra is first on the >>bus for some reason. >> >... >> >>Steven Ringwood >>ihnp4!ihlpm!nevets >This *may* >clear up your position dependency, although I rather suspect that the real >reason is that the disk controller's circuitry is more susceptible to the >degraded signal timings available at the end of the bus. Not likely. (Decided to follow up here as this is of general interest.) I have three expansions working just fine on my Amiga with no PAL fix. (I'm using a CMOS 68000 these days.) Back in the days I only had SB2 and Supra Drive (SD) things worked with them in either order. Then I received a new driver from Supra. This new driver insisted that my SB2 be located outboard of the SD. There is a comment elsewhere that this is tied in with the presence of the MFM, Multi Function Module. This I have not confirmed. This position sensitivity continues today after I added the Spirit Technoligies 1.5 meg ram and clock board. (Which is working just peachy for me.) (An aside re clock modules... Learn how to program it at the hardware level - call Spirit perhaps. Then build a program that records the last time the clock was set, an error parts/million, and an update interval. Have this program run in the background waking up every interval to correct the clock by the error percent. Heck - Amigas are MT machines. Fake it. Clock crystals are designed for wrist temperatures. They have vicious temperature dependancy curves. If your unit runs at an unusual temp then things'll be strange...) Anyway - it seems the problem is either in the SD or the SB2. Since the SB2 worked fine until the new SD software arrived I suspect the SD has a subtle software glitch like an absolute address in I/O space. -- <@_@> BIX:jdow INTERNET:jdow@gryphon.CTS.COM UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was better you left it in the bush with the other one.