[fgh]

Thanks guys. And thanks to whoever made it sticky
Tony: I have changed the text based on your comments.


Edit: After hitting the maximum post length, I've moved the second half into this post:



General info, continued...

Removable vs fixed flash media (short version)

Original scsi.device IDE drivers works well with both fixed and removable type CF cards.
The Amiga PCMCIA driver compactflash.device also works with both types of cards.
Some CF cards do not work with compactflash.device, but this is for other reasons.

IDE drivers confirmed NOT working with removable type CF cards:

• IDEfix (Elaborate Bytes)
• Buddha (Elaborate Bytes/Individual Computers)
• XSurf (Elaborate Bytes/Individual Computers)
• Catweasel (Elaborate Bytes/Individual Computers)

When loading these drivers (usually during boot) with a removable type card, the amiga will hang/freeze.

Doobrey has made patches for IDEfix and the other Elaborate Bytes IDE drivers, that correctly identify CF cards, and allow removable type cards to work correctly.

SD cards are neither removable or fixed in themselves, as they are not ATA devices.
It's therefore up to the IDE-SD adapter which response is given. (Examples under 'Clever SD-IDE adapters' above.)

See 'reasons for incompatibility' below for more information..

HDinstTool vs HDToolbox

Never use HDinstTool with a drive that was partitioned using HDToolbox if you want to keep any data on it.
HDinstTool has a nasty bug that will destroy partitions that are not defined and saved by HDinstTool originally.

About wear levelling

Due to the concept of 'wear levelling' on flash media, it is smart to avoid block-by-block writing, like a normal format, or writing back an image file over the entire card.
On a hard drive, if you write to a certain block, this exact physical block will be written to every time.
On flash media, the firmware will spread out the writes (and keep track of them) to even the strain on the fragile flash cells.
When a cell is damaged (worn out or faulty), the firmware will notice, and move the data to an unused cell, and avoid using the damaged cell again.

The problem with a full format or writing an image over the entire card is that it writes to ALL the blocks and makes the card's firmware consider them all used (It doesn't know your file system).
Therefore none of those cells can be used as replacement for damaged cells any more, and data will be corrupted faster.
Most cards have some over provisioning, meaning some extra cells available to the firmware for such tasks. But you never know if older/cheaper cards do.
So always use quick format, and if you'd like to maximise the lifespan of your card, copy files to it rather than writing an image to it.
(And don't even think about low level format, there is -physically- no way of low level formatting flash media.)
You could also leave some space unpartioned at the end of the drive, to avoid using all the cells. (= Your own over provisioning)

You might have heard about TRIM. This is used to keep the firmware informed when blocks become unused again, to optimise wear levelling to improve life span and performance.
But TRIM is only available on SSDs and requires software support that does not exist for Amiga.

Removable media troubleshooting

My CF or SD works in WinUAE but not in my real Amiga

This is often caused by a WinUAE configuration that does not match the real hardware. (amiga model, kickstart versions, ram, etc), so certain software would work in WinUAE but not on real hw.
If the filesystem that you have installed requires a certain CPU or kickstart that your real hardware does not have, the machine would guru before it starts booting the hdd.
(SFS requires 68020 and KS2.04, PFS3 works with 68000 but requires KS2.04, PFS3AiO works on 68000 and KS1.3)

Another filesystem scenario is when using a drive larger than 4GB with original PFS3 version in non-DS mode.
Unless you are using IDEfix, original PFS3 needs to be in DS mode. (See compatibility table above, PFS3 supports TD64, not NSD)
The reason it would work in WinUAE is that WinUAE gets the IDE drive size from windows, and is not limited by lack of correct TD64/NSD support. (Applies to both UAE and IDE hdd-controller selections).
Solution: Use PFS3DS or PFS3 AiO version by Toni Wilen instead.

Otherwise you might have other software installed that is incompatible with your real amiga hardware. In this case you should still have access to the drive if booting without startup-sequence:
Hold both mouse buttons down during boot, check that all expected partitions show up, select boot without startup-sequence and check that you have access to the boot partition.
(Access to partitions above 4GB will not be available until a scsi.device patch has been run)
Then you can troubleshoot your startup-sequence etc to figure out what's causing the problem.

Another scenario that came up a couple of times after I started this FAQ is that the area that WinUAE accesses is not starting entirely at the beginning of the drive.
A couple of guys ended up with a drive without windows partitons, where WinUAE still didn´t have access from the very beginning. In both cases there was 8MB of unused space before the first partition, indicating that the drive might have been GPT formatted, and not entirely recovered.

If you don't think these are the reasons:
Try hdtoolbox on the real hardware (boot with workbench install disk or any other wb installation).
Make sure that hdtoolbox is using the original scsi.device (SCSI_DEVICE_NAME tooltype) and that you are not running unpatched IDEfix, or other IDE drivers.

If the drive shows up, you might have to check your favourite hd prepping tutorial. If your drive is 4GB or smaller, or you know the geometry so you can enter the size values manually, you could quick format it on the amiga before filling it up in WinUAE.

If it does not show up in hdtoolbox, or does not work reliably, It might be one of those cards/drives that are simply not compatible with the old drivers, and I have no suggestions at this point. (Suggestions please!)

Hdtoolbox says 'Unit is not a disk (Type 7)'

Don't worry, nothing is wrong. Your removable type card is mistaken for an optical removable media (CDR, etc) by hdtoolbox.
This occurs with all cards that report as removable media (848A), when you go to 'change drive type' and select 'read configuration'.
Just ignore the message, fill out your own manufacturer and model info and proceed to partition the card.
(HDToolbox from wb 2.x/3.0/3.1 will show negative capacity for large drives (>2gb?). Ignore it, don't worry unless the partition page shows the wrong size.)
Also, if you use WinUAE to prepare the cards you should not have this issue (even if you mount the CF using IDE0).

Rare issue: Drive shows up as 'no disk in drive' after partitioning?

You have partitioned the drive normally, then after a reboot, instead of showing up as NDOS / not a dos disk, some or all FFS partitions don't appear on workbench at all, and C:Info lists all missing partitions with "no disk in drive" state. (HDToolbox still shows all partitions correctly.)

This is a rare DOS/FFS bug described by Toni Wilen.
If the first 4 bytes of the first block of the partition contains bytes $FFFFFFFF, the FFS file system gets confused and thinks there is no disk.. (It might confuse dos disk type $FFFFFFFF = -1 = ID_NO_DISK_PRESENT with real dos type)
This bug can trigger even if drive is new, for example some DOM's or solid state memory cards may contain random looking non-zero data from factory. (Test patterns?) Fix is to wipe the drive completely, or better: Use this little program by Thomas.
OS3.9BB2 works (reports correct "not a dos disk" state), I haven't tested OS3.5-OS3.9BB1. 3.1 and probably older versions have the bug.

Booting with Boing Bag 2 freezes system

If your OS3.9 Boing Bag 2 system manages to get to the setpatch reboot, but freeze immediately after the reboot, you may have fallen victim to scsi.device 43.43's LBA48 bug.
See 'OS 3.9 Boing Bag 2 issue' paragraph above.

CF or SD does not work in PCMCIA adapter

First - you need to install compactflash.device (pcmcia CF driver) and Fat95 (file system).
For automount, move CF0 from Storage/Dosdrivers to Devs/Dosdrivers.
And make sure to use the latest version as compatibility increased over the years.
Specifically, if your machine freezes when inserting the card/adapter, the first thing you should do is update to the latest version of compactflash.device. (v1.32 at time of writing)

Your amiga can access cards in FAT (windows) format or in amiga formats through the PCMCIA.
It is most common to use FAT, so your PC can access the card as well.
The CF0 mountfile specifies the file system. If CF0 is set up with Fat95 (default), you can read a FAT16/32 card.
If you want to read a card with amiga filesystem, you need to change filesystem in the CF0 mountfile PLUS define the size etc of the card.
(FAT95 does this automagically.) You may use Giggledisk on aminet to create the mountfiles.

FAT-formatted card (accessible on pc) shows up as CF0:NDOS in PCMCIA adapter
New cards come formatted either as superfloppy (without MBR partition table) or with a MBR partition table with one partition.
It seems that Fat95 accepts both types but not all variants.
Specifically FAT12 format seems to show up as NDOS, but there may be others as well. Let me know if you find out
Anyway, quick-formatting the card on the amiga should solve it.

Other possible problems

If your amiga has kickstart 3.1 and a memory expansion or accelerator that can take maximum 8MB RAM, adding any fast RAM above 4MB will conflict with PCMCIA address space and the PCMCIA port will be disabled.
Many cards of this type have a jumper to limit RAM to 4MB to avoid this conflict. Use it.
Kickstart 3.0 does not disable the PCMCIA port, so storage and I/O cards will still work with 8MB, but any PCMCIA SRAM will conflict with other fast RAM >4MB.

A1200 also has an PCMCIA issue that requires reinserting the card after a reboot. (Hardware (Gayle) changed, but kickstart ROM did not..)
CFD v1.21 (2003) and newer fixes this. (As does the cardreset software). A600 does not have this issue.

People often suggest installing Cardpatch when troubleshooting CF over PCMCIA.
I don’t know if it is required for storage media, but it will not harm. (Applies to both a600 and a1200)

SDHC card does not work in PCMCIA SD- or multi-adapter

So far I have not found a single PCMCIA adapter that supports SDHC cards (4-32GB).
All the SDHC compatible adapters I have found are 32bit Cardbus, not 16bit PCMCIA.
Look specifically for a 16bit PCMCIA adapter supporting SDHC (SD High Capacity), and let me know when you find one!
For SD cards (2GB and below) there are still cheap PCMCIA adapters around, but expect them to become increasingly rare.

Only my first FAT partition partition shows up

FAT95 does not automatically mount multiple partitions.
You need to create seperate mountfiles for these. (See giggledisk on aminet)

Reasons for incompatibility

Background

The ATA standard supports lots of different types of media, both fixed and removable types.
IDE drivers communicate with devices using the ATA protocol, and require devices to identify as removable media or not.
For the CF card itself this type info does not change anything, but it has to give an answer.
Many CF cards are set to report as removable media, but not all, and it's hard to know in advance. ('Industrial' level cards are usually fixed type)
The information is stored on CF card's CIS (Central information structure) and communicated by the ATA controller inside the card when replying to the ATA IDENTIFY DEVICE command.

The problem with certain amiga IDE drivers and 'removable' media

As mentioned above, original scsi.device IDE drivers have no problem with removable type CF cards or SD cards.
However, drivers by Elaborate Bytes - idefix97 and individual computers product drivers - do not work with removable type devices.

The drivers do not comply with the ATA-4 (or newer) specification.
IDE drivers use the ATA command IDENTIFY DEVICE to get all kinds of information from the device.

The first word of the device reply (word 0, 'General configuration') is 848Ah for removable type CF cards, and 044Ah or 0040h for fixed type CF cards.



First, bit 15 set in the reply (cards reporting 848A) can cause drivers to fail.
Drivers not written in accordance to ATA-4 (or newer) do not expect bit 15 set for ATA devices.

• ATA-4 standard ( 1998 ) says that bit 15 in word 0 shall be 0 for ATA devices (page 95), but can be 1 (848Ah) for CF compatible cards (page 52).
  It also says that ATAPI devices shall not respond to IDENTIFY DEVICE, but reply to IDENTIFY PACKET DEVICE instead (page 41)
• ATA-3 standard ( 1997 ) says it must be 0 for ATA devices and 1 for ATAPI devices (page 49)
• ATA-2 standard ( 1996 ) says it is 'reserved for non-magnetic devices' (page 37)
• ATA-1 standard ( 1994 ) says it is 'reserved for non-magnetic devices' (page 44)
• CF specification v3.0 ( 2004 ) says word 0 standard is 848Ah, but can alternatively be 044Ah or 0040h to "turn off removable media". ( page 130 )

Second, bit 7 set indicates that a device is removable media. This did not change since the original ATA-1 specification.
(Additionally bit 6 could be set to specifically mark a disk as fixed, but this was removed in ATA-6 standard (2002) so I guess modern drivers use bit 7.)

See attachments
Attached are ATA specifications 1-5, CF spec 3, and the entire IDENTIFY DEVICE replies from my four CF cards and one SD card/adapter.

Amiga IDE drivers that fail with removable type CF cards probably expect bit 15 to be 0 for ATA devices, and therefore either give up on the device, or regard it as an ATAPI device and fail.
It's confirmed by Doobrey that Elaborate Bytes drivers simply stop processing the device if bit 15 is set in the reply.
It's possible that other drivers might accept bit 15 set but still fail with removable type CF cards because bit 7 is set.

A CF card's reply can not be changed manually except on a few old cards where the manufacturer (Sandisk, Lexar) provided tools to ‘flip the removable bit’.
My Transcend 4GB 133x, Kingston 4GB (flower img) and Kingston 16GB 266x cards report as fixed (word 0 = 044A)

The ATA Identify Device replies can be read with the BusTrace program.

J.Schönfeld made the TrueIDE dual CF-IDE adapter that works around the problem with his amiga drivers. (And also lets windows users partition and boot from removable type CF cards)
This adapter modifies the CF cards IDENTIFY DEVICE reply to allow removable type cards on drivers that only work with fixed CF cards.

Regarding PCMCIA operation and incompatibility

Compact Flash storage devices operate in three modes:

• PC Card Memory Mode
• PC Card I/O Mode
• True IDE Mode

Compact Flash devices must support operation in all three modes, but operate only in a single mode at any given time.
The CF card senses (using pin #9) if it's connected to IDE or PCMCIA, and switches modes accordingly.
Connected to IDE, it uses True IDE mode, and becomes a hardware-level PATA IDE device.
Connected to PCMCIA, things are getting more complex, as it takes the role of both IDE controller and IDE device, using PC Card I/O mode.
CF cards needs to support several different PCMCIA access modes, different register locations, etc.

Some CF cards (Kingston 4Gb etc) work with IDE/scsi.device but not with pcmcia/compactflash.device.
This can theoretically be due to the card, the driver or the amiga pcmcia implementation.
It is confirmed (by Toni Wilen) that some cards do not support all mandatory register locations, causing problems with amiga pcmcia operation.

Let me know if you have more information

Regarding SD cards

SD cards are not ATA devices and have less complex controllers than CF cards.
Therefore there are far less differences between SD cards than between CF cards.
For the same reason SD-IDE adapters need to be active adapters, not just passive like most CF-IDE or CF-PCMCIA adapters.

As I wanted to experiment with SD cards, I have successfully tested 12 different 8GB SDHC cards on my a600 (PFS3 direct-scsi and ROM resident scsi.device) with a £6 SD-IDE adapter.

When connected to a PC (over IDE), the adapter reported as a removable type CF card (word 0 = 848Ah).
Therefore, drivers having problems with removable type CF cards will also have problems with such adapters.

I have later tested the newer SDXC capable version of this SD adapter, and this one reports as a fixed device.

Relevance of PCMCIA / CF card voltage ratings?

The PCMCIA specification allows 3,3 or 5 volt devices, and the amiga pcmcia implementation only works with 5v devices.
The ‘low voltage key’ (physical incompatibility) on 3.3v pcmcia devices prevent using a 3.3v device in an amiga.
But if a 3.3v only CF card existed, and was used in a generic PCMCIA adapter, this could be a problem…
However: According to this document on the Compact Flash Association, all CF cards are able to operate on both 3.3v and 5v operation.
So voltage rating should not be relevant.

That’s it for now, well done if you are still reading!
There certainly are incompatible cards, but I hope some will find their card is compatible after all with this little guide.
Additions and suggestions are welcome! Thanks