MaxTransfer rate and Mask on CompactFlash hd's

[jahc]

Today I installed an IDE to CompactFlash adapter, and now I'm using a 2gb memory card as my A1200's hard drive. I transferred backup's over null modem, and they extracted fine, and I had my system back up fine.

But now that my internet files are back, I'm transferring demos etc from my FTP server using the PCMCIA ethernet card, and I'm getting up to about 90,000cps using Miami and AmiTradeCenter.. however, my archives seem to be getting corrupted during transfer. I need to do some more tests, but in the meantime, whats a safe MaxTransfer and Mask values for CF memory cards in HDToolBox? I'm limiting my cps to 50,000cps for now.. I think my Max Transfer rate is set to 0x77777 at the moment.

[countzero]

try max transfer 0x01fe0000

[mrmkl]

MaxTransfer is not about "rate" (speed) but size of a single data request to device driver. Try 0xFE00 or something less than 128 Kbytes transfers.


Link found by googleing. (SFS)

[alexh]

countzero wrote:
try max transfer 0x01fe0000

Where did you get that value from?? Never heard that one recommended before.

I've only heard of 0x1FFFE and 0x1FE00 (as mentioned above both) which are used because they are below 128Kbyte which is a well used size for IDE devices.

0xFE00 also make sense as 64Kbyte is another well known default IDE transfer size.

[countzero]

alexh wrote:

countzero wrote:
try max transfer 0x01fe0000

Where did you get that value from?? Never heard that one recommended before.

I got it from my arse  :lol: it was in the EAB CF thread, mentioned by zetro. I'm too lazy to power up and check my installation ... well basicly you just have to slide the 1fe among the zeros till you find the right value ...

by the way, 0x1fe00 is an ambigous value. if you don't specify the full 8 bits the software tends to pad the zeros itself. hdinsttools pads the zeros to the end, so it becomes 0x1fe00000 while hdtoolbox pads them to the beginning giving 0x0001fe00. be careful.

[Piru]

by the way, 0x1fe00 is an ambigous value. if you don't specify the full 8 bits the software tends to pad the zeros itself. hdinsttools pads the zeros to the end, so it becomes 0x1fe00000 while hdtoolbox pads them to the beginning giving 0x0001fe00. be careful.

Actually the value itself isn't ambiguous at all, but hdinsttools. :-)

That is clearly a bug in the app, numbers should never be zeropadded from the right.

It's 8 nibbles btw, not 8 bits.

[ddniUK]

So if I want to use 0X1FFFE with HDToolBox, I should actually enter 0x1FFFE000 ?

[djbase]

ddniUK wrote:
So if I want to use 0X1FFFE with HDToolBox, I should actually enter 0x1FFFE000 ?

0x0001FFFE

[Piru]

@ddniUK

HDToolBox doesn't have this problem, 0x1FFFE works just fine.

0x1FFFE000 is incorrect regardless of the software.