Re: DMA Errors - weird fix?

From: Oliver Skelton <oskelton_at_cix.compulink.co.uk>
Date: Sun, 30 Nov 97 03:19 GMT0

In-Reply-To: <199711291306.OAA06670_at_haddock.cd.chalmers.se>


Well I have an 800mb IDE anyway - but want to continue using my Jaz + HP
DAT + CDROM + want to get a scanner - Probably Microtek E6.... so want to
sort the DMA problems out.

>> >From memory:
>> 14 bytes are shifted +16 bytes in position in the file but I think 2
>> bytes are somehow skipped.
>> Then alternate runs of 16 bytes are exchanged.
>> At some point an extra 2 bytes is inserted and the corruption ends.
>
>That actually sounds almost like exactly the problems I have!
>When I get them, they are usually accompanied by a SCSI lockup, though.
>(That is, a DMA transfer is never reported as completed.)

Yup - same here, copying about 22mB of files around with Kobold from IDE
to SCSI Jaz (Kobold reports 'Verify on' when writing).
If you wait 2 minutes then HDDRIVER presumably resets the bus - the copy
resumes and Kobold usually indicates whether it is a FAT or data area
problem.
Unsuprisingly what I find is that the hangup occurs worst in high colour
modes (TC 600x544 with Blow-Up Hard 1).


Another thing - even when the copy appears to complete OK without any
hangs.. there are often corrupted files... e.g. in 256 colour mode.
I guess the 'verify' is just the drive checking what it wrote to disk is
what it received... not a check back to the Falcon. Or perhaps it only
applies to drives A & B?

To my suprise - the frequency of hangups is reduced by turning _on_
Nemesis(Lo) [I mostly run with it off as I get the odd pair of bombs when
it is on.]


On the subject of Nemesis - mine has 3 capacitors - and I found some
messages stating that the newer boards should have 2 removed, and they
also don't need the DMA patch. How can I tell which rev my Nemesis is?
It was fitted on behalf of Titan around the end of April.


Anyway - I have made progress this weekend... finally traced and fixed an
annoying problem in my floppy caused by a bit of bent wire.
Also - seem to have got rid of the black screens on boot and hangs after
transferring ROM to RAM - I attribute this to adding an extra (3rd?) earth
to the Nemesis from the point on the front of the board.
(Though maybe not statistically enough evidence to be sure of this yet as
I did another thing - removed the 1kohm resistor wedged in parallel with
the 110ohm DMA patch which may well also have affected this, though I had
the hangs before I fitted it.)

>I'd really like to know how those rotations take place. That might give some
>clue as to what's going on.

Agreed. I wish Doug was around as he might know. The thing which intrigues
me the most is not the 16 byte runs... but the fact it always starts with
a 14 byte run.

I got a similar answer from Uwe when I reported that autobooting with
HDRRIVER 7.13 was giving me some problems when the Jaz spins down and
restarts... partitions J-O have the same contents as I.. in fact I think
if I write to them it actually (thank god!) writes to I.
[As I previously said I can work around it by turning off AB caches and
running MEDIACHANGE.TOS, then re-reading each partition before turning
caches back on]
Although Uwe didn't think it was a HDDRIVER problem he did say he would
check the HDDRIVER.

Oliver
Received on sø. nov. 30 1997 - 13:25:00 CET