By construction, bcrypt is its own function, and does not use a hash function like SHA-1 or SHA-256. You may be confusing it with PBKDF2.
Your requirement on "entropy" is, at best, severely misguided:
As long as your attackers cannot convert the whole mass of the complete friggin' Galaxy into energy to run some humongous computation, 256 bits of entropy are the Mother of all Overkill. For any practical situation which does not involve battling with hostile extraterrestrial entities, 128 bits are more than enough.
You won't get 256 bits of entropy or even 128 bits. You said "bcrypt": thus, you are processing a password. A password which can be chosen and remembered by a human being cannot reach that much entropy. For typical users, you can consider yourself lucky if you reach, say, 32 bits of entropy; most people cannot do even that. No matter what you do and how many hash functions you throw at it, you will never get more entropy on the output than you had to begin with, entropy being "what the attacker does not know", i.e. the password.
(The important point here is that entropy does not equate length.)
What you really want, here, is a password-processing function which extends a password into as many "key bits" as you need for whatever cryptographic purpose you envision. For instance, you want 256 bits because you do password-based encryption and need 128 bits for symmetric encryption itself, and 128 more bits for a MAC. This is done in two steps:
Hash the password with a password-hashing function which includes the features specific to password protection, which are ways to cope with the inherent weakness of passwords. Namely, salts and configurable slowness. Bcrypt is fine for that. See this answer for details.
Extend the password hash with a deterministic Key Derivation Function. If you just need 256 bits, then just hashing the password hash with SHA-256 is perfectly fine: SHA-256 works well as a KDF as long as you do not need more than 256 bits of output. For arbitrarily long outputs, you may need something a bit more complex; SSL/TLS's "pseudorandom function" is a thoroughly studied example.
Beware that typical bcrypt implementations output a string which encodes the 192-bit output but also the salt and other parameters; for key extension, you want to process only the 192-bit output.
PBKDF2 is a "password-based key derivation function" (hence the name) which combines both operations.