A590 Mask and Max transfer values in HD Toolbox?

[DanC]

Hi!

Today i had a look at my A590 HDToolbox settings.
I have a Quantum 105 Mb SCSI drive with 2 partitions with FFS.
The A590 have 2 meg ram.
On both my partitions Mask is set to 0xffffffff
and Max Transfer 0x1000000

This seems not correct or?
What values would you suggest?

[r.cade]

MaxTransfer issues don't apply to SCSI. What you have is fine.

[Kin Hell]

Originally Posted by DanC

Hi!

Today i had a look at my A590 HDToolbox settings.
I have a Quantum 105 Mb SCSI drive with 2 partitions with FFS.
The A590 have 2 meg ram.
On both my partitions Mask is set to 0xffffffff
and Max Transfer 0x1000000

This seems not correct or?
What values would you suggest?

Originally Posted by r.cade

MaxTransfer issues don't apply to SCSI. What you have is fine.

Originally Posted by Boing-Ball

I Disagree there..

I had to set my MaxTransfer to 0x1FE00 on my Z2 Oktagon 2008 using a SCSI card reader. If I stuck with the default of 0XFFFFFF then on bootup I was getting cannot read errors on multiple sectors. This on 3.2.

What I would recommend is using PFS3 as your filesystem. But if not then stick with FFS..

A500 is not Zorro2....

rcade is correct....

@ DanC

If it ain't broke..... Don't fix it bud!

[Jope]

1) The A500 AmigaBus connector is similar enough to Zorro 2 in terms of autoconfig, usable address spaces and DMA to 32bit problems, that the same rules apply for mask settings
2) There is an A500 version of the Oktagon 2008, which is called the Oktagon 508, it is quite similar in function to the 2008.
3) Max transfer problems are specific to certain hard disk / driver / controller combinations. Thus it is perfectly possible that some buggy SCSI controller or some buggy SCSI target device also requires you to limit the max transfer size.

Seems the Oktagon can suffer from a max transfer problem. We should not shun this information but instead make a note of it for when someone has read errors when using an Oktagon SCSI controller.

Perhaps it is related to the card reader in question, perhaps it is this card reader + Oktagon combination, but we can't know this based on the info we have to work with.

[Toni Wilen]

There are some SCSI controllers that do have max transfer problem but it usually only happens when single transfer is multiple megabytes. Which practically don't ever happen in normal use.

I don't remember which one but I think it was 53C94 based and driver didn't split >16M transfers (SCSI chip has 24 bit DMA length counter). Or maybe it was "only" >8M transfer.

But, as I said, it won't happen normally but SCSI max transfer bugs do exist

[DanC]

Thnks all!

So max transfer is not critical then?

But what about the Mask setting?

[Jope]

As long as you don't have 32bit RAM in your A500, you don't have to worry about the mask at all.

[DanC]

Originally Posted by Jope

As long as you don't have 32bit RAM in your A500, you don't have to worry about the mask at all.

Thnks! Then i can leave the values as it is.

[thomas]

Originally Posted by Boing-Ball

I had to set my MaxTransfer to 0x1FE00 on my Z2 Oktagon 2008 using a SCSI card reader.

This was probably not related to SCSI but the issue was the card reader. It probably can only do 1:1 translation from SCSI to IDE commands. But IDE has a transfer limit of 128KB, so large SCSI transfers would have to be split into multiple IDE commands which the card reader cannot do.

Early Acard SCSIDE converters had the same issue.

Generally speaking it does not hurt to set MaxTransfer to 0x1fe00 or 0x20000 always and everywhere. Then you are safe in any case.

The Mask value OTOH really depends on the hardware and RAM configuration. Whether the controller can do DMA and if DMA is limited to certain memory areas. In all other cases Mask should be set to 0xFFFFFFFF. Every bit which is cleared in the mask may cause the driver to allocate new buffers and copy memory accross. This is unnecessary overhead and reduces transfer speed. So keep all bits set unless you really need to limit the kind of RAM.

[thomas]

Originally Posted by Toni Wilen

There are some SCSI controllers that do have max transfer problem

The SCSI command READ(6) has an 8 bits length field which limits transfers to 256 sectors. But it also has an LBA of only 21 bits which limits the disk size to 1 GB. Only very old firmwares would use this (CDTV SCSI comes to mind).

The usual command to be used is READ(10). It has a 16 bits length field. So the transfer limit is 65536 sectors or 32 MB. Must be a very rare case which exceeds this.

LBA is 32 bits which leads to the 2 TB disk size limit with 512 byte sectors.

[Toni Wilen]

Originally Posted by thomas

The SCSI command READ(6) has an 8 bits length field which limits transfers to 256 sectors. But it also has an LBA of only 21 bits which limits the disk size to 1 GB. Only very old firmwares would use this (CDTV SCSI comes to mind).

Yeah, CDTV SCSI and pre-v7.0 A590/A2091 are the most "popular" boards that only use 6 byte commands (direct scsi file system fixes this)

The usual command to be used is READ(10). It has a 16 bits length field. So the transfer limit is 65536 sectors or 32 MB. Must be a very rare case which exceeds this.

LBA is 32 bits which leads to the 2 TB disk size limit with 512 byte sectors.

Yes but the onchip NCR 53C94 DMA counter is 24 bits (counter is also used also in pseudo-DMA controllers) and it counts transferred bytes which is the reason for 8M/16M limit (8M if driver confuses it as a signed value) if driver does not split the transfer automatically.

There was some max transfer test reports (test program exists but I don't remember the name either) I got years ago and it mentioned some SCSI controllers that had problems with very large single transfers and it was less than 32 megabytes.

It still is not a problem in normal use compared to infamous Commodore IDE scsi.device max transfer bug.