greg@isrnix.UUCP (05/05/87)
My Amiga tends to trash disks fairly regularly. Enough to be very
frustrating. I can usually (but NOT always) trash a disk with the following
scenario: emacs a file, start a subcli, emacs another file within it,
write the file - BANG - disk I/O error.
Other times I can be just working along (doing 'dir's, 'info's whatever and
not changing disks at all)
and out of the blue - disk I/O error. Most of the time it's just track 40
that gets munged and I can 'disksalv' everything. Yesterday it seemed to
trash the whole thing though. The disks always re-format fine. It
usually (but, again, not always) happens on my external floppy.
My disks are not physically mistreated, nor exposed to magnetic
fields (i.e. I keep them well away from the monitor). Note that disks which
I never write to do not get trashed.
I've read the articles about disks going bad, etc, but my problem is bad
enough that I feel that if others were experiencing the same frequency
of trashed disks there would be a general uprising. As it is it's
nearly impossible to do serious development.
Now, my Amiga also has another problem. When I display the 'brick.img'
ray-traced DBW picture a section of a line (about 1 inch long) half way down
the screen will flicker from what it should be to a solid line of
another color. The 1 inch section usually has a bit of blue and some
red/white for part of a brick but when it flickers the whole section turns
(momentarily) the same color. The same thing >JUST< started happening (i.e.
the picture used to be fine)
on another line higher on the monitor when displaying 'marble.img', except
that now there are TWO flickering segments only about 1 mm long. So far
I've only seen the problem when displaying HAM images.
The 'flicker' problem does not seem to be a memory error, as it always
happens in the same position of the picture regardless of where the
program is loaded. Also memory diagnostics don't point anything
obvious out. If I pull the screen down with the mouse the flickering
section moves down in step with the picture.
I recently added a TechniSoft 2m expansion to my Amiga and upgraded
the PAL's. The problem has not changed in any way since I added/upgraded
them.
Is it possible that the two problems are related? Do Floppy I/O and
video generation ever hang out together on any of the custom
chips?
Thanks for any help on either of these VERY annoying problems.
--
Gregory R. Travis
Institute for Social Research - Indiana University - Bloomington, In
ihnp4!inuxc!isrnix!greg
{pur-ee,allegra,qusavx}!isrnix!gregdillon@CORY.BERKELEY.EDU (Matt Dillon) (05/06/87)
>My Amiga tends to trash disks fairly regularly. Enough to be very >frustrating. I can usually (but NOT always) trash a disk with the following >scenario: emacs a file, start a subcli, emacs another file within it, >write the file - BANG - disk I/O error. If this is the EMACS that Mike Meyer is supporting, you should report the version number and problem to him. The 'track 40 blues' bug has been traced to two AmigaDOS calls: Delay(0) and WaitForChar(Fh, 0) When given 0 delay values, they tend to crash the Amiga... especially whatever track the disk head is over when a WRITE to disk is made (and since AmigaDOS usually r/w's the superblock first, it is usually track 40 that gets smashed). If this is another EMACS, I suggest you stop using it. >Now, my Amiga also has another problem. When I display the 'brick.img' >ray-traced DBW picture a section of a line (about 1 inch long) half way down >the screen will flicker from what it should be to a solid line of The DWB ray-traced pictures are INTERLACE HAM pictures. Thus, unless you have a high persistance display, you get the interlace flicker. -Matt
grr@cbmvax.cbm.UUCP (George Robbins) (05/06/87)
In article <8705060633.AA10982@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >>Now, my Amiga also has another problem. When I display the 'brick.img' >>ray-traced DBW picture a section of a line (about 1 inch long) half way down >>the screen will flicker from what it should be to a solid line of > > The DWB ray-traced pictures are INTERLACE HAM pictures. Thus, unless >you have a high persistance display, you get the interlace flicker. Also, some older Amiga's contain have Denise chips that aren't too awfully good at Ham mode. You man need to obtain a Rev 6 or later Denise upgrade... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jacc@tekigm2.TEK.COM (Jonathan A. Colby) (05/10/87)
News/NSA line eater sharefood: terrorist cryptography DES drugs cipher LSD In article <867@isrnix.UUCP> you write: >My Amiga tends to trash disks fairly regularly. Enough to be very >frustrating... >Now, my Amiga also has another problem. When I display the 'brick.img' >ray-traced DBW picture a section of a line (about 1 inch long) half way down >the screen will flicker from what it should be to a solid line of >another color.... >I recently added a TechniSoft 2m expansion to my Amiga and upgraded >the PAL's. The problem has not changed in any way since I added/upgraded >them. >Is it possible that the two problems are related? Do Floppy I/O and >video generation ever hang out together on any of the custom >chips? I recently added the 1 meg Aminetics "Squeeze-Ram" board and experienced a set of symptoms that my offer a clue to your problem. After the 3-4 hour assembly and installation, the Amiga booted right up, but a number of programs had problems. Textcraft didn't work: "blotchers appeared where the sprite cursor should have. Quicknibble exhibited "bit-rot" (a few pixels here and there were the wrong color), and hung as soon as you tried to copy a disk. And emacs STARTED CRASHING DISKS! I removed the Squeeze-Ram and all worked well. Aminetics provided a fix, and so far, all is well. Significantly, the fix was to add .047uf caps to the memory address decode chips to clean up the signals. My experience strongly suggests that interference with Chip ram memory timing can crash disks. Have you attached anything else to your Amiga that might affect Chip ram timing? Check out the fixes for the C-Ltd SCSI adapter; I seem to recall that some of the suggestions delt with cleaning up timing and signals. Jac Colby - they disclaim me around here, too. Personal Engineering Products Project, Tektronix Inc. UUCP: {ucbvax,decvax,pur-ee,cbosg,ihnss}!tektronix!tekigm2!jacc -or- jacc@tekigm2.TEK.COM 5529 SW Patton Rd, Portland, OR 97221 (503) 292-1609 -or- MS 02-386, PO Box 500, Beaverton, OR, 97077 (503) 627-4534
stever@videovax.UUCP (05/11/87)
In article <1731@tekigm2.TEK.COM>, Jac Colby (jacc@tekigm2.TEK.COM) writes: [ description of bit-rot and other problems caused by an added board ] > I removed the Squeeze-Ram and all worked well. Aminetics > provided a fix, and so far, all is well. Significantly, the fix > was to add .047uf caps to the memory address decode chips to > clean up the signals. . . . Those capacitors should have been there in the first place! A good rule of thumb is to use one 0.1 uF capacitor at *each* 74ALSxxx, 74ASxxx, and 74Fxxx chip, one 0.1 uF capacitor at each PAL, and one 0.1 uF capacitor for each two 74LSxxx and 74HCxxx parts. Each memory part should have its own capacitor (0.1 uF for 64K DRAMs, 0.33 uF for 256K and 1Meg DRAMs). If the capacitors aren't there, when the part tries to yank an output down (transition times are on the order of 2-10 nanoseconds), the part merely succeeds in bringing +5 volts and ground closer together for a short time (voltage spikes in excess of 2 volts on the +5 volt supply are not uncommon). This can feed CRUD (Continuous and Random Unwanted Disturbances) into the rest of your system. One generally-reliable measure of quality is the placement of decoupling capacitors. If *every* part is properly decoupled (appropriately-sized decoupling capacitor located adjacent to the part; short, wide runs or power and ground plane connections between each capacitor and its part), the chances are much better the product will work correctly. Steve Rice ----------------------------------------------------------------------------- Copyright 1987 by Steven E. Rice, P.E. All Rights Reserved. This material may be redistributed only where such redistribution is without charge and without restrictions on further redistribution. Incorporation of this material in a compilation or other collective work constitutes permission from the intermediary to all recipients to freely redistribute the entire collection. All other uses are prohibited. ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!stever