DKB 2632 won't start in OS 3.9

[Thomas]

I guess your issue is not the DKB but the HC+8. And it has nothing to do with OS 3.9.

The SCSI controller does DMA into FastRAM. As soon as you add the 2632's memory, it uses that for buffers. But a Zorro card can only do DMA into Zorro memory. When it tries to do DMA into the 2632's memory, it fails.

You say when you enter the 2632 command from a floppy, it works. But does it still allow to access the FS3 partition after you entered the command? Probably not.

I guess you can tweak the FS3 partition with special values for Mask and BufMemType. However, there is no public tool to edit BufMemType AFAIK.

[Thomas]

Error 41's (whatever that is)

41 means DMA error.

http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0043.html

This is well understandable if the HC-8+ tries to do DMA into the DKB's memory, which is not possible.

[Thomas]

You might remember that I told you about this problem already in my very first reply: https://forum.amiga.org/index.php?topic=75365.msg853537#msg853537

In the meantime I change one of my programs to support BufMemType. It's attached to this post. Copy that lha file to your Amiga and unpack it somewhere where it can be found by the CLI, for example to the C directory of your boot partition. (remove the .zip extension, it was only added because the forum software does not allow .lha files)

It's a command line program. It takes the partition to act on and the parameters which shall be changed as argutments. If no parameters are given it just outputs the current values.

So open an Shell window and enter

changebootpri fs3:

Check the values for Mask and BufMemType.

Now enter

changebootpri fs3: mask ffffff bufmemtype 200

Repeat that step for all partitions on the HC+8.

Now reboot. It's probably a bit slower than before, because it has to copy buffers forth and back. But it should no longer throw DMA errors.

[Thomas]

It's rather a cold issue than a heat issue

Next time you get a read error please use Retry first and check if you get exactly the same error again or if the block number changes.

If you get a read error at first but on retry can read the block and fail on another one which also is successful on retry and so on, then it's probably a hardware error. Maybe a loose contect on the cable or bad termination.

Although I would have expected that the mask / bufmemtype changes would not show any difference without the DKB memory. Those changes just tell the system that if a buffer is not in 24bit memory then allocate a new buffer in that memory and copy the data across. If there is no other memory than the 24bit memory on the HC+8, there should not be any difference whether these settings are active or not.