Problems with a SCSI chain in CyberStorm PPC

  • Thread starter Thread starter arnljot
  • Start date Start date
  • Replies Replies 34
  • Views Views 3572
I can not offer any help with regard to SmartFileSystem m8. Sorry. :|

No help in the Documentation? :shrug:

Charlie
 
Very little.

Atm my mask is 0x7FFFFFFC, and transfer is 0x00FFFFFF.

I think this is "bad", because when I copy files slowly, IE: with console output. It works good.

But when I do it quiet, it buggers up and crashes.
 
For using the 32bit memory (or any available, for that matter), mask must be 0xFFFFFFFF
 
One guy said to me that mask had to be 0x7FFFFFFC because of the amiga 2gb addressing limit. But I though it is a mask to ram types?

But I'm more concerned that the culprit might be the max transfer value. That it's so high that data gets corrupted, SFS confused and then crash?
 
@Kin: max transfer is only needed to go lower if corruption occurs in fast transfers, as our friend arnljot is experiencing.

Start with 0x1FE00 and if still crashes, low it by an octet: 0x1FD00 and so on.
 
Thanks for the clarification rkauer. :thumbsup:

I was always of the opinion the later versions of Hard Drive toolbox automatically set the Mask & Transfer values according to your Amiga's HW configuration.

@ Arnljot

If you set 0xFFFFFFFF, what then?

Also, whilst being a lilttle backwards, try the above with a patched FastFileSystem just to compare. I'm leaning towards SFS being the culprit.

Kin
 
Re testing FFS for comparison - that's a brilliant idea! :) Will do that.

The SFS manual on max transfer
The MaxTransfer field can be used to tell a filesystem that the device
which comes with your (harddisk) controller can't handle more than a
specific amount of data in a single access. This problem usually
occurs with IDE drives, which usually have a limit of 64 or 128 kB
which can be transfered at once.

When a device has been properly written it should be able to cope with
any amount of data being transfered. These devices can have a
MaxTransfer value of 0x7FFFFFFF. Only badly written or very old
devices need to set a smaller value in MaxTransfer -- in other words,
the MaxTransfer value is a compatibility kludge to fix broken devices.

In any case, if you have a SCSI drive, then a MaxTransfer value of
0x7FFFFFFF should be just fine. For IDE drives, you probably need to
set it to 0x1FFFE or to 0xFFFE. Those values represent 128 kB minus 2
bytes and 64 kB minus 2 bytes respectively.

An incorrect MaxTransfer value can usually be detected by copying a
few large files (more than 200 kB) to such a partition. If the large
files are damaged while smaller files are undamaged then this is
usually an indication that the MaxTransfer value is too large.

Remember, the MaxTransfer value needs to be set for each partition.
Just changing one MaxTransfer value will only affect a single
partition, not the entire drive.

On mask:
The Mask field can be used to tell a filesystem that the device which
comes with your (harddisk) controller cannot directly access its data
in all regions of memory available on your system.

When a device has been properly written it should be able to cope with
data located anywhere in memory. For those devices the Mask should be
set to 0xFFFFFFFF. Only badly written or very old devices need a
different Mask -- in other words, the Mask value is a compatibility
kludge to fix broken devices.

For example, some devices can't access data starting at an uneven
address in memory. Some even can only access data when it starts at
an address which can be divided by four. In the first case you would
set the Mask field to end in 'FFFE', and in the second case to 'FFFC'.
If your controller can handle addresses without alignment restrictions
then you can set it to 'FFFF' (which is of course the preferred
value).

There are also devices which can only access memory in the 24-bit
memory area (everything below the 16 MB boundary). Usually these are
Zorro-II controllers which cannot directly access memory located on,
for example, an accelerator card. For these devices you set the mask
to 0x00FFFFFF, indicating that the device can only access data in the
24-bit address space.

Devices which can access data located anywhere in memory (a SCSI
controller which is embedded on an accelerator card, or a Zorro-III
IDE or SCSI controller) should have a mask of 0xFFFFFFFF.

Here is an overview to clarify the Mask setting:

xxxxxxxF - Use a Mask ending with a 'F' if you're device is written
correctly and can handle transfers to and from memory with
any alignment.

xxxxxxxE - Use this if you're device can only handle 16-bit or WORD
aligned transfers.

xxxxxxxC - Use this if you're device can only handle 32-bit or LONG
aligned transfers.

FFFFFFFx - Use this Mask if you're device is written correctly and
can work with any memory in the system. The first 'F'
may also be '7' since there are no Amiga's which can have
more than 2 GB of memory.

00FFFFFx - This Mask restricts transfers to the 24-bit address space,
meaning it can only access ChipRAM and FastRAM in the
24-bit area (The 24-bit area is 0x00000000 to 0x00FFFFFF).

001FFFFx - This Mask restricts transfers to ChipRAM only (the old
trackdisk.device needed this for example).

Always use the least restrictive Mask possible. The ideal Mask is
0xFFFFFFFF.

Remember, the Mask value needs to be set for each partition. Just
changing one Mask value will only affect a single partition, not the
entire drive.

Then it goes on:
What Mask setting should I use?
-------------------------------

If you're in doubt, check your controller's manual and find out what
Mask setting they recommend. You can also experiment a bit with
different Mask values, but you got to be careful there. Preferably
experiment with a dummy partition which doesn't contain any important
data.

If you intend to experiment, follow the scheme below to find out the
best Mask value for you. To determine if a specific Mask value works,
you'll need to read and write some data to the disk. Copying files is
not enough. Preferably unpack a few LhA or LZX archives to the disk,
and see if they are unpacked undamaged.

And the following illustration:
Code:
+----------------+           +----------------+
 | Try 0x00FFFFFF |    Yes    | Try 0xFFFFFFFF |    Yes
 |                |  ------>  |                |  ------>  done.
 |  Did it work?  |           |  Did it work?  |
 +----------------+           +----------------|

         |                            |
         |                         No |
      No |                            V
         |
         |                      Use 0x00FFFFFF
         V

 +----------------+           +----------------+
 | Try 0x00FFFFFE |    Yes    | Try 0xFFFFFFFE |    Yes
 |                |  ------>  |                |  ------>  done.
 |  Did it work?  |           |  Did it work?  |
 +----------------+           +----------------|

         |                            |
         |                         No |
      No |                            V
         |
         |                      Use 0x00FFFFFE
         V

 +----------------+           +----------------+
 | Try 0x00FFFFFC |    Yes    | Try 0xFFFFFFFC |    Yes
 |                |  ------>  |                |  ------>  done.
 |  Did it work?  |           |  Did it work?  |
 +----------------+           +----------------|

         |                            |
      No |                         No |
         V                            V

   Unknown Mask!                Use 0x00FFFFFC
   (contact me)


---------- Post added at 12:09 ---------- Previous post was at 11:29 ----------

Seems like FFS handled 0x7FFFFFFF as max transfer.

SFS1.279 didn't, it got a corrupted directory structure @0x7FFFFFFF.

Next is 0x1FFFE, as I've tried 0xFFFFFF before... Grrr...

---------- Post added at 12:33 ---------- Previous post was at 12:09 ----------

It's SFS.

With 0x0001FFFE, FFS is rock steady, and SFS crashes...

Now, should I deggrade the SFS version? Or just use FFS? :-(
 
Use FFS & learn how to set up SFS for a hobby. :lol:

PFS would have had you pulling your hair out by now. :nod:

Charlie
 
What I find strange is that I've used SFS a lot under WinUAE without any problems, and on my CF cards on my other two A1200s and A4000s.

But this setup, scsi with sfs completey refuses to cooperate :-(
 
Amiga Hardware is specific. No Emulator can do a proper job & don't forget, most boxes running WinUAE are on IDE not SCSI.

Get the real hardware/software out & play, or don't bother in my book ;)

Kin
 
Well, version 1.277 seems stable at transfer 0x0001FFFE

It wrote my sys partition to a backup folder and back twice without incident, on par with the FFS partition.
 
Back
Top Bottom