CF / SD and large drives FAQ

[fitzsteve]

I came across a lot of CF cards that failed to boot with SCSI.DEVICE of BB2 (guru on setpatch) only workaround was to skip the scsi.device of BB2 and use another for large drive support.

[fgh]

It was confirmed back in 2015 with Toni Wilen’s help.
43.43 includes faulty lba48 code which is used only when drive reports lba48 capability and drive size is > 4G. (even is partition is inside first 4G)
I’ve seen the bug two times myself, and have seen others encounter it a few times as well.

Edit: Here is Toni’s explanation of the bug itself:
scsi.device LBA48 bug = commands are correctly executed but when drive signals command done interrupt, driver interrupt routine gets confused because it can't find what command type it just executed, I think it defaulted to "no data to transfer" command type

[manicx]

I did try 43.43 as well as 43.45. They both work so I stay with 43.45. Thanks for your feedback guys.

[RaveGuru]

Guys, I've been struggling to set up my old A600 with Kickstart 2.0 (37.350) 2Mb with an IDE-SD converter and a 32 gig card and ClassicWB 2.1.

It kinda works but with these limitations:
- Max 2 Gb partitions
- DOS Identifier must be set to DOS5 (0x444f5305) or else it uses the default FFS or doesn't recognize the file system.
- Disk speed is abysmal (497 Kb/s). I don't know if this is because of DOS5 (dir cache?)

I'm using scsi.device v43.24 and FFS 44.5 (both from ClassicWB). Unfortunately I can't find the A600 version of scsi.device 43.45.

I've used HDToolBox to create a bunch of 2 Gb partitions and it seems to work ok. But...

* I would prefer to use DOS3 (or DOS7) instead of DOS5, since I assume directory caching is unsuitable for hard drives and slow. But how can this be achieved?

* Some sources suggest loading FFS as a module, but isn't the filesystem stored in the RDB already? What's the reason to load it as a module also?

* Should I use other scsi/FFS versions?


Cheers
RG

[Jope]

You should install the FFS into the RDB as 0x444F5301, this way it should replace the one in ROM.

As mentioned, please do not use dir cache on hard disks.

You can patch an a600 compatible 43.35 yourself with the package from aminet: http://aminet.net/package/driver/media/SCSI4345p

You should be able to use DOS3 by installing the FFS with the above dostype and then selecting Standard File System from the cycle gadget in File System Characteristics, then using the tick boxes to select FFS and international.

Now a counter question, why FFS and why not pfs3aio?

[RaveGuru]

Hi Jope,

Originally Posted by Jope

You should install the FFS into the RDB as 0x444F5301, this way it should replace the one in ROM.

I've basically been following this guide: http://translate.google.co.uk/transl...hdd/index.html

But whenever I use 0x444F5301 or 0x444F5303 for my partitions, they show up as ver 36.200 in Check4GB, so I assume they use the FFS in ROM.

Originally Posted by Jope

Now a counter question, why FFS and why not pfs3aio?

I tried and it works but it's way too memory hungry. With 3 partitions it consumes almost half of my 2 Mb. So I decided to stick with FFS despite its disadvantages.

[Jope]

Are you using the same old HDToolBox version as in the tutorial?

You could cheat PFS3 and select a very small number of buffers. If you leave the buffers value as the default, it will ignore it and automatically give you much more.

http://eab.abime.net/showthread.php?...79#post1163679

[RaveGuru]

Originally Posted by Jope

Are you using the same old HDToolBox version as in the tutorial?

Yes, the very same one.
Is the file system installed to the RDB when partitioning (using HDToolBox) or during formatting?

Originally Posted by Jope

You could cheat PFS3 and select a very small number of buffers. If you leave the buffers value as the default, it will ignore it and automatically give you much more.

http://eab.abime.net/showthread.php?...79#post1163679

Yes, I set them to 75 which I think is the lowest, and it was better but still using too much RAM.

[thomas]

Originally Posted by RaveGuru

Is the file system installed to the RDB when partitioning (using HDToolBox) or during formatting?

Neither. You have to do it manually using the advanced options checkbox and the add/update button.

[RaveGuru]

Originally Posted by thomas

Neither. You have to do it manually using the advanced options checkbox and the add/update button.

Hi Thomas. Yes, that's what I meant, sorry for being unclear. But why is Check4gb listing my volumes as using ROM file system?

Here's a screen capture (from UAE with my A600 ROM, SD card and identical setup):





Edit: changed fs to DOS3. The results are the same.

[thomas]

Originally Posted by RaveGuru

But why is Check4gb listing my volumes as using ROM file system?

Because the DosType does not match. The DosType is the key which connects a file system to a partition.

You have so many different DosTypes assigned to your partitions, you should set them all to DOS\3 (444f5303) and the file system, too.

Bear in mind that you have to confirm each input with Enter or Tab, otherwise it will not be taken.

And finally after each change in HDToolbox you have to reboot to make it active.

[RaveGuru]

I realize my pictures were a bit confusing.

So I deleted all partitions and started from scratch and recorded a video instead:


https://www.dropbox.com/s/ij55vijm1c...utput.m4v?dl=0

[Jope]

Did you also try installing only one ffs to your RDB with the dostype 444f5301 instead? Feel free to keep the partition at 444f5303.

[thomas]

There might be an issue with how version and revision numbers are stored. IIRC later OS versions use the upper 16 bits for the version and the lower 16 bits for the revision. The older HDToolbox does not reflect this. So if you enter 43 into the version field it might be interpreted as 0.43 (version 0, revision 43) which is much lower than 36.200 (version 36 revision 200).

Try to enter 2818049 into the version field which is 43 * 2^16 + 1 a.k.a. version 43 revision 1.

Originally Posted by Jope

Did you also try installing only one ffs to your RDB with the dostype 444f5301 instead? Feel free to keep the partition at 444f5303.

This does not make any sense. DosType of file system and partition must match.

[Jope]

Originally Posted by thomas

This does not make any sense. DosType of file system and partition must match.

I should have tried it myself instead of asking RaveGuru to try it out for me.

The line of thought behind this nonsense idea: All the HDToolBoxes automatically install FFS for you as DosType 444f5301, if FFS is found in L when you define the drive for the first time. In the HDToolBox shipped with 3.x you then select International with a check box later on, but as far as I remember, it doesn't change the DosType of the FFS that was installed for you, only the partition's DosType is changed. You can also specify international when formatting a disk later, having a 444f5301 partition that (as far as I remember) is formatted with DOS\03 headers.

Which again made me think that perhaps FFS is a bit more special than it seems with regards to dostypes it shows up as and how the ROM FFS should really be replaced.

But I'll step aside now to avoid any further waste of time / mental anguish. I hope I have some time later in the weekend to check this out for myself in WinUAE.

Edit: Did some tests on an RDB hardfile using scsi.device, 37.350 and 40.63. A600 quickstart. I didn't touch the two partitions automatically made by HDTB.

My partitions were both 444f5301 as the default that HDTB 2.22 from the Install2.1 disk generated. Install2.1 had FFS revision 36.104, which automatically got installed to the RDB, but I never saw this version in Check4GB or version udh0: as the HDTB 2.22 installed it with version 0 and the ROM FFS was newer.

First I tried my recipe for enabling international mode:
I formatted UDH0: with format drive udh0: name ffs3 ffs intl noicons quick.
I formatted UDH1: with format drive udh1: name ffs1 ffs noicons quick.

I created files äÄ and Ää to udh0: with echo >Ää and echo >äÄ. List udh0: confirms only one file is in the dir list.
I created files äÄ and Ää to udh1: with echo >Ää and echo >äÄ. List udh1: confirms both files are present.

Looking at my new HDF with a hex editor, UDH0: begins with DOS\03, UDH1: begins with DOS\01.

So this is international FFS working as I have come to expect with DosType 444f5301 and format INTL. No need to adjust its DosType in the RDB, format intl is enough.

Then I investigated loading FFS from the RDB under V37 and V40.

First I had my own FFS as 444f5301 in my RDB. The ROM FFS was always preferred no matter what FFS I tried or what I typed into the version field in HDTB using those two kickstarts. I verified this with the version udh0: command and with Check4GB. Check4GB showed 36.200 for the DOS\01 partition in V37 and 40.1 under V40.

Next I tried FFS 36.104 as 444f5303 (DOS\03) and version 36. The ROM FS was preferred.
Third try was with FFS 44.5 as 444f5303 version 44. Again the ROM FS was preferred.

Then I tried FFS 36.104 as 444f5309 (DOS\09) and I typed in version 36 for it in the RDB. I changed udh0: to use custom fs + this dostype. This time version udh0: showed fs 36.104 and version udh1: showed the ROM fs.
My DOS\09 partition is version 0.36 when viewed with Check4GB under both ROM releases.
Fifth try, FFS 44.5, 444f5309 version 44. As expected, version dh0: results in fs 44.5 and Check4GB shows 0.44.

Now more experiments with the mount command.
All filesystem drivers were removed from the RDB and I generated a mountlist based on my RDB with giggledisk. The UDH0: automount flag was turned off.
Mounting with dostype 444f5301 and ffs 44.5 resulted in version udh0: saying fs 44.5, version udh1: stayed at the rom fs version.
Mounting with dostype 444f5303 and ffs 44.5 resulted in version udh0: saying fs 44.5, I didn't check udh1:
Mounting with dostype 444f5309 and ffs 44.5 resulted in version udh0: saying fs 44.5, I didn't check udh1:

So what on earth. Is it actually impossible to upgrade FFS with the ROM scsi.device?
More experiments needed.
I reverted udh0: to automount and installed ffs 44.5 to the RDB with dostype 444f5301 and version 44
37.350 and scsi.device 37.55, the ROM fs is preferred.
37.350 and scsi.device 43.45, the ROM fs is preferred.
40.63 and scsi.device 40.5, the ROM fs is preferred.
40.63 and scsi.device 43.45, the ROM fs is preferred.
Have I made a mistake? Am I losing my sanity?

Ok, one more try with V40 and scsidev 43.23. Still the ROM fs is preferred.

Seems the only way you can replace the ROM fs with scsi.device is to invent your own DosType that doesn't clash with the ROM fs DosTypes. I never ran across this FFS quirk, as I went PFS2, then PFS3 really early on.

Loadmodule fastfilesystem worked with all setups I tried.

Others are free to do more tests and of course please point out where I made a mistake above.

[RaveGuru]

I think Thomas is right. I clicked "Upgrade Filesystem" in HDTB 2.1 and entered Version 2818068, which is the BCD representation of 43.20, and now Check4Gb shows the correct FFS version and "Ok" on all partitions.

I also had to re-format all DOS3 partitions which I suppose prove that the newer FFS is now active.

I did try this once before but it didn't work at that time. Maybe because I was using the wrong filesystem Identifiers or somehow failed to write to RDB.

I'm now trying this setup out. One thing I noticed is that partitions seem to be limited to somewhere between 6.0 and 6.5 Gb which seems like a strange number. I will test some more and report back.

[Jope]

Ah, I missed the one about BCD, was too focused on replies to my messages. Makes sense, the old HDTB does not ask for version/revision separately. Just tried it and it now works for me too.

Any day I learn something new about old stuff is a day not wasted and as a bonus Thomas' esteem for me is probably already so negative it's flowing over to +127! I don't mind you Thomas, even though you always have nasty words for me when I'm too quick to speak. <3 <3 :-D

[RaveGuru]

Originally Posted by RaveGuru

I'm now trying this setup out. One thing I noticed is that partitions seem to be limited to somewhere between 6.0 and 6.5 Gb which seems like a strange number. I will test some more and report back.

So I promised to get back after doing some more testing. Turns out, when using FFS, the largest partition you can format is depending on the amount of RAM. I tried maxing out the memory in UAE on A600 settings (9.5 Mb I believe) which allowed me to format a partition of around 14 Gb.

Note that I'm talking about formatting partitions, not creating them. PFS3 doesn't seem to have this limitation.

Anyway, I found this pretty amusing.

[Jope]

Originally Posted by RaveGuru

I tried maxing out the memory in UAE on A600 settings (9.5 Mb I believe) which allowed me to format a partition of around 14 Gb.

Did you try with various block sizes, or was this with the stock 512?

[RaveGuru]

Originally Posted by Jope

Did you try with various block sizes, or was this with the stock 512?

I'm using a block size of 1008 since my SD/IDE adapter reports "illegal" CSH values.