So the scsi.device 45.7 that comes with the A600 kickstart has a certain maxtransfer value hardcoded, and does under no circumstances use values configured by HDToolBox?
No, Kolla. You cannot, possibly, by any means, transmit more than 255 sectors in a row by the PIO IDE protocol. It is the protocol that has this value "hardcoded". Previous versions of the scsi.device falsely assumed that the limit was 256 blocks, not 255 blocks. This was, actually, true in some previous versions of the protocol which used the sector count 0 to indicate 256 sectors, but that is no longer true as the IDE protocol changed "under the feed of the scsi.device". The scsi.device was not adapted for this protocol change. If the scsi.device (in its IDE implementation) receives the request to transmit more than 255 blocks in a row, it *has* to break them up, but this transfer split happens transparent to its user, and it has to happen exactly this way.
There are similar limitations for SCSI in the number of sectors that can be read at once, but they are not quite as draconian as in the IDE protocol.
It is neither the scsi.device that looks at MaxTransfer. It is the file system, typically the FFS, to implement that. Previous versions of CrossDos and CDFS also simply ignored this value (as part of more defects), and I do not know for other file systems whether they handle this correct, but the FFS does.