AA3000+ Accelerator

[Thomas Richter]

Originally Posted by SpeedGeek

The problem with mask is it only affects filesystem transfers. But what about SCSI direct transfers? In particular, reading the RDB from the drive, which of course needs to be done first in order to boot from the drive.

Actually, it affects all transfers, no matter how or by whom they are initialized. It is only a workaround at the file system level. The FFS from 3.1.4 onwards speaks also SCSI_HDCMD, and surely the mask there applies as well, but the same problem affects any other program that accesses the harddisk bypassing the file system.


IOWs, clearly, programs like SCSIQuery, HDToolBox, the DEV-Handler are in that sense "affected".



You may wonder where these programs take the "mask" from, and the answer is "it depends". SCSIQuery and the DEV-Handler take it from the mount node of the file system, or assume a worst-case mask, and HDToolBox from 3.1.4 onwards also makes a worst-case assumption on this issue. I believe there is a tooltype where you can set the memory type it uses.


But yes, the Os team is (or at least was) aware of the problem.

[Thomas Richter]

One addition: Clearly, the MASK is also honored by the other Os-provided file systems (CrossDos and CDFileSystem), but note that Mask is more a bug-workaround than a feature. A well-written device driver needs to support any buffer that was provided by the user, and needs to find the best possible strategy to fill (or transmit) its contents.

One may wonder why HDToolBox and friends worked before on some devices. This is more by accident than by design. A couple of devices simply use PIO if the amount of transmitted data is small, and then the mask and buffer problem does not arise. For HDToolBox in particular, the transmitted data are only those of the SCSI mode pages, and this accounts for less than 256 bytes, which is "by accident" fine for most devices as they don't initiate DMA for such small fragments.

[Thomas Richter]

*double post*

[SpeedGeek]

Originally Posted by Thomas Richter

Actually, it affects all transfers, no matter how or by whom they are initialized. It is only a workaround at the file system level. The FFS from 3.1.4 onwards speaks also SCSI_HDCMD, and surely the mask there applies as well, but the same problem affects any other program that accesses the harddisk bypassing the file system.


IOWs, clearly, programs like SCSIQuery, HDToolBox, the DEV-Handler are in that sense "affected".



You may wonder where these programs take the "mask" from, and the answer is "it depends". SCSIQuery and the DEV-Handler take it from the mount node of the file system, or assume a worst-case mask, and HDToolBox from 3.1.4 onwards also makes a worst-case assumption on this issue. I believe there is a tooltype where you can set the memory type it uses.


But yes, the Os team is (or at least was) aware of the problem.

You can't expect that all users are going to be using "OS 3.1.4 Onwards". If these versions do provide some sort of work around in Software for what is practically a "Broken by Design" Hardware problem than that's fine with me but your attitude towards backward compatibility always seems to be a condescending one.

[Thomas Richter]

I don't understand your complain. The older FFS doesn't speak DirectSCSI, so the problem doesn't appear for the FFS. It may appear for some other file systems that do not use MASK or use HDSCSICmd without checking for the mask. The older HDToolBox does use HDSCSICmd potentially with memory buffers not compatible to some device drivers.

Sorry for not having a time machine and fixing this backwards for you, but nobody has sources for all device drivers in existence, and I'm so terribly sorry of being able to offer a workaround for bugs other people made and they won't fix anymore, and I'm terribly sorry that this is addressed in a newer release, and not in an older release.

Wait, what exactly is your problem now? That you need to buy new versions to add workarounds for bugs other people made?

[nyteshade]

Honestly folks, remember I’m talking about my AA3000+ which is running 3.2.1. I have a A3660 and a BigRAM card and a ZZ9000. So more RAM than I can poke a stick at but it’s slow.

[SpeedGeek]

Originally Posted by Thomas Richter

I don't understand your complain. The older FFS doesn't speak DirectSCSI, so the problem doesn't appear for the FFS. It may appear for some other file systems that do not use MASK or use HDSCSICmd without checking for the mask. The older HDToolBox does use HDSCSICmd potentially with memory buffers not compatible to some device drivers.

Sorry for not having a time machine and fixing this backwards for you, but nobody has sources for all device drivers in existence, and I'm so terribly sorry of being able to offer a workaround for bugs other people made and they won't fix anymore, and I'm terribly sorry that this is addressed in a newer release, and not in an older release.

Wait, what exactly is your problem now? That you need to buy new versions to add workarounds for bugs other people made?

In your previous post, you wrote "Actually it affects all transfers" but somehow you were also trying to explain this only applies to OS 3.1.4 onward. You then provided several examples of transfers not affected by mask. Please get your facts straight.

I am not going to purchase any new version of Amiga OS to workaround this specific hardware bug (broken memory expansions for the A3640 or A3660). Chucky warned users about "Support Hell" and I would suggest that everyone heed his warning (rather than announce OS 3.1.4 onward as a practical solution to the problem).