PFS memorymask error after installing TF534

[psoma]

Hi,

Just added a TF534 to my A500 and while the 4MB of RAM is successfully being added to the 8MB on the SCRAM500 (giving 12MB), the disk is now reporting that the memory mask no longer matches the memory type.

The mask on both my PFS partitions is 0xfffffe and I can’t change it while it’s in this mode (machine freezes when I hit save), so I’ll need to remove the TF534 and make the change, but I suspect I’ll only get one shot at it otherwise I lose the partition - so, what do I set the mask to? 0x7ffffffe?

Cheers!

[thomas]

You should be able to disable the partition in the early startup menu and boot from floppy disk. Then you can change the value without removing the accelerator.

Mask normally only affects DMA controllers. So if your controller does not do DMA you should set Mask to 0xffffffff.
0x7ffffffe should be safe, too. You won't ever see memory allocations at odd addresses and the high-order bit is used by AmigaOS internally, so you won't see memory there, too.

[psoma]

Thanks thomas,

Interesting - I set the Mask to 0xffffffff (which adjusted itself to 0xfffffffe) and the machine started up without complaining about the memory mask... but as soon as WB loaded, it froze. Same spot every time. I tried with a WB floppy - same scenario. Unplugged the TF - working fine again.

If I disconnected my SCSI HDD and just had my ZIP drive connected (with an FFS partition), it would work fine, so I converted my SCSI HDD partitions to FFS. It too freezes, even a tad earlier than with PFS.

Not sure if the TF534 IDE is clashing with the scram device driver, or the SCRAM is just incompatible with the 32-bit RAM (but then... why does the ZIP drive work?!?), but it's not giving me a lot of love at the moment!

[psoma]

Update: when I copy the System files onto the ZIP drive and boot off it, I get that freezing too. Super weird!!

[thomas]

I could reproduce the Mask error in WinUAE. IMHO PFS is misbehaving here. Thor some time ago explained how FFS handles Mask and it sounded quite logical: it checks the buffer it gets from the application against the Mask, if it matches, ok, if it does not match it allocates a new buffer using BufMemType and copies the data over. This is a slight performance impact but it assures that the right type of memory is used for DMA.

In WinUAE it does not matter if I change the Mask to 0xFFFFFFFE, it does not freeze. But on your real machine obviously the scram freezes if memory on the TF board is used. So for you Mask = 0x00FFFFFE is the right one and BufMemType = MEMF_24BITDMA would be right, too. Unfortunately HDToolbox does not allow to edit BufMemType.

However, I tried Mask = 0x00FFFFE and BufMemType = MEMF_24BITDMA in WinUAE and PFS still did not accept it. So I conclude that PFS does it wrong.

BTW, you can boot with the PFS partition active if you hold down Left-Amiga + B. This is the shortcut for Ok in the requester and by holding the keys down you can bypass many of these requesters in short time

[psoma]

Ahah, thanks for the tip on that So it seems like it's only on writes that it freezes as when it boots with a mismatched memory mapping, it marks the disks as read only and the machine is (partially) usable.

Been playing around with it in FFS. No luck here either... still freezes irrespective of Mask *and* I've tried a few different settings on BufMemType (any, chip and fast).

I think straight up, the SCRAM SCSI just won't work with the TF534 - I'll see if I load up an IDE disk whether the SCRAM still works for the ZIP drive and CD-ROM at least... otherwise I need to make a decision as to what to keep. Chances are it'll be the SCRAM as 4MB isn't enough for WHDLoad.

[Jope]

Originally Posted by thomas

However, I tried Mask = 0x00FFFFE and BufMemType = MEMF_24BITDMA in WinUAE and PFS still did not accept it. So I conclude that PFS does it wrong.

Good to hear that you also think that it shouldn't behave this way. This feature of PFS3 has always annoyed me, basically forcing me to go back to FFS in the rare situations when limiting the mask is the only way to get the drive working in a non-optimal combination of expansions.

[psoma]

Turns out the 8MB in the SCRAM doesn't work well with the 4MB in the TF534 anyway. Pretty much every game I launched caused a reset or Guru so... I'm keeping the SCRAM.

[Jope]

Originally Posted by Jope

Good to hear that you also think that it shouldn't behave this way. This feature of PFS3 has always annoyed me, basically forcing me to go back to FFS in the rare situations when limiting the mask is the only way to get the drive working in a non-optimal combination of expansions.

Decided to look at the code, it actually does what is expected of it and allocates a separate buffer and copies the data if the mask is wrong. The warning is there on every init though, which makes it annoying in prolonged (mis)use. I guess I'll just build a separate version that doesn't show the requester for those situations where I cannot change the mask to be optimal in PFS3's opinion.

[thomas]

Originally Posted by Jope

where I cannot change the mask to be optimal in PFS3's opinion.

Actually the warning is not about the mask but about the memory used. A file system is not in the position to have an opinion about what a good mask is. The HDD controller defines which kind of memory it can use for DMA. The mask is a means for the file system to check the memory.

IMHO the warning should be moved a bit. It should check the memory again after allocating a new buffer and if it still not matches the mask then it should issue the warning because then there is a real issue.

[Jope]

Originally Posted by thomas

Actually the warning is not about the mask but about the memory used. A file system is not in the position to have an opinion about what a good mask is. The HDD controller defines which kind of memory it can use for DMA. The mask is a means for the file system to check the memory.

I agree that the filesystem shouldn't have an opinion about it, instead using what I specify in the RDB. But ok, can you explain a bit more about the mask? I always thought that it instructs the HD controller's driver to do the right thing, but is it in reality there for the filesystem to provide the HD controller with a buffer in the right place?

IMHO the warning should be moved a bit. It should check the memory again after allocating a new buffer and if it still not matches the mask then it should issue the warning because then there is a real issue.

Shouldn't the HD controller's driver default to PIO in this case? Sure it will slow everything down, but at least the user wouldn't lose data.

[psoma]

I'll just re-iterate that when the warning comes up, the disk goes into read-only mode so it's more than a nuisance... it actually renders this disk unusable as a system disk.

[thomas]

I always thought that it instructs the HD controller's driver to do the right thing

No, there is almost nothing in the RDB which is meant for the driver. Only a few flags like last LUN, last ID, last target, synchronous and per partition whether it should be mounted or not.

Everything else is for DOS. An entry in the partition table basically is a mountlist stored in binary rather than text.

The hardware driver knows the hardware, that's its purpose. It does not need to be instructed to do anything.

Shouldn't the HD controller's driver default to PIO in this case?

Yes, it should.