Oktagon 2008 SCSI Issues....

[DiskChris]

So I started having issues read write errors with my hard drive a couple months ago and while at first I thought it was the drive, I've tried 3 different ones in the computer (all test fine with a badblocks test under linux using the same cable and hooked to the amigas power supply) so I removed the eeprom...

Under 2.0 with Oktapussy: Everything's fine (but I need compatibility with 1.3 so it won't work )

Under 1.3 with original software driver: Hard drive shows up reduntantly 8 times in HDInst, HD read errors

It sounds to me like a termination problem...but if it was, then why would it work fine with oktapussy??

EDIT: I've also done a RAM test with MemCheck...everything's fine

[DiskChris]

Alright found out the problem only occurs when copying a file directly from the serial port (AExplorer) to the hard drive...I can copy a large (eg 4 MB file) directly to RAM and then copy that file to the hard drive fine...perhaps the serial port and the PIO interface is just too much for the 68000 to handle?? The odd thing is that using oktapussy everything's fine, and even turning the baud rate down to ridiculously slow speeds, eg 4800 buad, doesn't help....

[carvedeye]

Maybe it's a software issue?

[danbeaver]

I would guess that copying to RAM without problems and not to the hard drive would be a buffer issue with the serial port controller and hard disk drive not able to hold the incoming data until a disk write occurs; however with the limitations you have, just continue to write to RAM.  Tracing down the software problem is likely to be a pain and upgrading the hardware expensive (well to some folks). But there are better add on boards with serial devices better designed/made and hardware for storage solutions that are more scalable.

[DiskChris]

Yeah but Some files exceed 4 MB on size and I do have an a500 on hand I can swap parts with...maybe the CIAs??

[Oldsmobile_Mike]

Just gonna throw this out there, you checked your MaxTransfer values?  That can cause write errors if set too high.  Also I assume you're using standard FFS?

[DiskChris]

Yeah checked MaxTransfer....and looks like I spoke too soon altough the files transfered from ram to the hard drive are the same size, they are corrupted....at least I discovered that before I started ripping out chips:roflmao:

[guest11527]

Yeah checked MaxTransfer....and looks like I spoke too soon altough the files transfered from ram to the hard drive are the same size, they are corrupted....at least I discovered that before I started ripping out chips:roflmao:

Is this the driver set to a synchronous transfer? Does it help to turn this off and switch to asynchronous transfers? The problem with synchronous transfer is that the host adapter need to provide all bytes with the correct timining, i.e. fast enough, as otherwise the drive just samples the data on the SCSI bus. The 68K might be too slow for that.

[DiskChris]

Asynchronus mode did the trick! You sir are a saint, saved me from buying another controller! I had to disable parity check on the controller too through HDInstTools included in the Install disk (which also has the Oktagon driver you put in your expansion folder if you don't have the autoboot rom) and incase anyone else is wondering, here's my Mask & MaxTransfer:

Mask: 0x7FFFFFFC
MaxTransfer: 0x0001FE00

[guest11527]

Mask: 0x7FFFFFFC
MaxTransfer: 0x0001FE00

Actually, you don't need either of them. The oktagon doesn't use DMA and hence can access the complete memory map, a mask is not required. Furthermore, since this is a SCSI disk you're talking to,  the MaxTransfer that is a necessity for the PATA (aka IDE) interface is neither required. SCSI doesn't have this limitation.