As far as I understand, besides the ed25519 and sr25519 signatures, there is a compatibility mode for ECDSA keypairs that should use the secp256k1 curve.
Both Bitcoin and Ethereum use the secp256k1 curve parameters for their accounts and signatures. But how do the Substrate ECDSA keys differ from Bitcoin/Ethereum keys? Why are they not compatible?
The process of how the private keys are derived is slightly different. This applies to both the how the (parent) key is generated and then subsequent derivations on this.
In BTC/ETC and most (all other) blockchains, when you enter the mnemonic, it normalized that and then does the pbkdf2 rounds on it. In Substrate, the mnemonic is first taken to entropy before the pbkdf2 rounds are applied. This means that the same mnemonic will yield 2 different private keys in the Sustrate vs other blockchain projects.
On top of this, you have the derivation, which is also different, the HD paths vs the Substrate paths.
Having said all this, there are some wallets (most notably those supporting multi blockchain currencies) that uses their "normal ed25519/secp256k1" keys on a Substrate environment. So one you have a key and can sign, it doesn't matter. The difference is rather how you get to the key.
As a note, when connecting to an ETH-compatible chain, e.g Moonbeam, the apps UI does give an option to use ETH-standard mnemonic -> seed as well as the ETH standard derivation paths.
In Substrate related blockchains the account id is derived from the public key using SS58 encoding. See here: https://docs.substrate.io/v3/advanced/ss58/
ECDSA (Non BTC/ETH compatible. Sorry, I should have been clearer.