CF / SD and large drives FAQ

[paulo_becas]

Originally Posted by fgh

No Paulo, this is completely wrong.
OS3.5/3.9 uses setpatch to update scsi.device to 43.34/35/43 to support up to 128GB.

What Steve is describing is a way to run a custom ROM with the MapROM feature of a turbo board. (And to update specifically to 43.45 as you requested)

Yes, you are right when saying that i can load a custom rom like that but it's not intended to, i was only searching for a way to update scsi.device, and it worked like a charme with those instructions.
I see that this is a issue that raises to many doubts, a lot of people agrees with you, and i'm not saying that you are wrong, i'm only saying that it worked with me.

The MapRom feature is used with ACATune and not LoadModule

This is the commands you use for both

c:acatune -maprom c:kick.rom -fastchip on -cache on -burst on -vbrmove >nil:
c:loadmodule devs:scsi.device

[fgh]

No. what you are primarily saying is that you have to update scsi.device for os3.5/3.9 to use above 8GB and this is simply not true.

[paulo_becas]

Originally Posted by fgh

No. what you are primarily saying is that you have to update scsi.device for os3.5/3.9 to use above 8GB and this is simply not true.

I think i should have explain myself better.
When you use IDE HD you don't have to do this, only with CF cards, at least that's the conclusion i reached when trying to use CF cards above 8Gb.
Inicially i thought that something was wrong with the cards i was using because when i used IDE HDs i didn't have this issue.
Solved it when i update scsi.device.

I'm not an expert on this things i'm just saying using my experience on the matter.

[fgh]

Still wrong. People don't generally have to patch scsi.device again to use above 8GB on 3.5/3.9 with CF cards either.

If the problem you experienced indeed turns out to be a bug in scsi.device 43.34/35/43 with certain CF cards or hardware setups, I'm interested to look into it with such a card. But you are reaching the wrong conclusions when you decided that 'all CF cards fail' and everyone should update scsi.device on 3.5/3.9.
I understand it is well meant though

Edit one year later:
OS3.9 Boing Bag 2 has a bug affecting drives/cards that support 48bit LBA. This is probably the root of this misunderstanding. See 'boing ball 2 issue' in the first post.

[paulo_becas]

It seems that you are better informed than me
From the searches i've done, it seems that theres something wrong with BB2, and it causes some problems, this kind of info is way over my head

I'm also using ClassicWB 3.9, i don't know if that's a issue too.´

The cards i used are a Kingston like this http://eab.abime.net/showpost.php?p=...&postcount=102

And a transcend like this http://www.abelcine.com/store/image....e=T&id=1001633

Both started to work correctly after i updated scsi.device

[Mikeat1200]

0x1FE00

I'm using a buffered interface (3.5") with my Dual CF-IDE40 adapter now:
should I still use this max transfer value or a different one?

[fgh]

That's the right one

[eebuckeye]

I installed OS3.9 and tried to set the max transfer rate on my partitions to 0x1FE00.. Every time I edit it (making sure I press return before I save the change) the setting is changed back to 0x0001FE00.. Is this still ok? The mask is 0x7FFFFFFE and I can not change the max transfer rate from 0x0001FE00.

I changed the max transfer rate in 3.1 many times for my CF with no problem.

Is 0X0001FE00 ok to use?

[fgh]

Morning!
Yes that's the same. 0x just indicates that it's a hex number. Leading zeroes do not change the value. (like 1 and 0001 is the same)

[Mikeat1200]

Originally Posted by fgh

That's the right one

Are you sure?
And WHY should I not use maxtransfer:
0x0FFFFFFF (maximum)
when I'm using a buffered IDE interface?

[fgh]

You could, as long as you use idefix, but the only thing that would be different is that you would be vulnerable if the drives are ever used without idefix.
It is the max transfer SIZE, not rate. It has no effect on speed.

Edit: Pfs3aio also has a workaround for the bug, so if you use it, there is no risk at any point by using a higher value, but there is also still no benefit

[Mikeat1200]

I don't use IDEfix, I'm using 4xEIDE'99 software.
So there is no way to get faster transfer with a buffered interface (only safer transfer as I already became aware of)?

[fgh]

Ok. The 4xEIDE'99 readme doesn't mention that the max transfer size bug is fixed, so I would certainly leave it at 1fe00 then.
The buffered IDE interfaces are buffered to work with longer cables and with two IDE channels, so those buffers also have nothing to do with speed
For higher speed you need something like the Fast ATA.

[Mikeat1200]

OK.
That was a clear statement.
Thank you!

[Jope]

Yep, a protective signal buffer, not buffer memory. :-)

[fgh]

Originally Posted by paulo_becas

It seems that you are better informed than me
From the searches i've done, it seems that theres something wrong with BB2, and it causes some problems, this kind of info is way over my head

I'm also using ClassicWB 3.9, i don't know if that's a issue too.´

The cards i used are a Kingston like this http://eab.abime.net/showpost.php?p=...&postcount=102

And a transcend like this http://www.abelcine.com/store/image....e=T&id=1001633

Both started to work correctly after i updated scsi.device

Out of curiosity I tested this today, as I also have a 16GB Kingston 266x CF card (image attached).
My KS3.1 A4000D runs plain WorkBench 3.9 BB2 and ClassicWB 3.9 (v28) fine from it with the normal BB2 scsi.device 43.43 and PFS3AiO v2.2.

Of course I cannot rule out that 43.43 has issues in some specific setup, but at least it works for me (and others).

Edit, one year later:
OS3.9 Boing Bag 2 does have a bug affecting drives/cards that support 48bit LBA. See 'Boing ball 2 issue' in the first post.

[TheDarkCoder]

After I opened a new thread to ask suggestions with cards, I discovered this wonderful one!

I have some questions:
1) It seems to me that most people prefer CF to SDs, for use with Amiga. Are there reasons?

2) I intend to use a CF or SD to IDE adapter on the onboard IDE of an A4000 and an A4000T. I read that onboard controllers support "removable"media. Does it mean that I might remove the card with the Amiga powered up, just like a floppy?

3) One reason for me to prefer SD could be that my Mac has an SD port. Is it possible for FS-UAE on Mac to see an amiga-formatted SD?

[Toni Wilen]

Originally Posted by TheDarkCoder

After I opened a new thread to ask suggestions with cards, I discovered this wonderful one!

I have some questions:
1) It seems to me that most people prefer CF to SDs, for use with Amiga. Are there reasons?

CF to IDE adapters are (were?) more commonly available and cheaper than SD adapters but SD is probably better choice today, cheaper cards, direct scsi filesystem (with most/all adapters?) breaks usual 8G barrier with original ROM built-in driver.

2) I intend to use a CF or SD to IDE adapter on the onboard IDE of an A4000 and an A4000T. I read that onboard controllers support "removable"media. Does it mean that I might remove the card with the Amiga powered up, just like a floppy?

No. Amiga IDE driver does not support removable harddrives. (Removable harddrive = whole harddrive disappears, including HD's controller. Removable media = only media disappears, controller remains, driver can still talk to the controller and query status of media. Very different things)

3) One reason for me to prefer SD could be that my Mac has an SD port. Is it possible for FS-UAE on Mac to see an amiga-formatted SD?

Most likely.

[fgh]

I've used lots of SD cards, they work just fine.
The reason for the SD vs CF adapter price difference is that SD adapters are active (modifying the signals with ICs), and CF adapters are passive (simply rerouting the pins to a different connector).
For big box amigas like yours, the CF has one added advantage, super cheap bracket adapters

[paulo_becas]

Originally Posted by fgh

Out of curiosity I tested this today, as I also have a 16GB Kingston 266x CF card (image attached).
My KS3.1 A4000D runs plain WorkBench 3.9 BB2 and ClassicWB 3.9 (v28) fine from it with the normal BB2 scsi.device 43.43 and PFS3AiO v2.2.

Of course I cannot rule out that 43.43 has issues in some specific setup, but at least it works for me (and others).

After talking to a few people, looks like this problem is due to Amigas specific setup. Looks like mine has a lot of issues