Why can't the VIC-II handle ECM and Multicolor at once?

Question

On the Commodore 64 there are a few different graphical mode selection bits we can enable. This question is about three of them:

• Multicolor mode (hereinafter MCM), where pixels are joined pairwise horizontally for half the resolution, but twice the colors.

• Bitmap Mode (hereinafter BMM), where instead of fetching a character pointer, those eight bits are sent to the pixel out shift register, and it's rigged somehow to fetch 8 kilobytes instead of one.

• Extended Background Color mode (hereinafter ECM), where we reduce the possible tileset from 256 tiles to 64, in exchange for a selection of four different background colors, selected by the top two bits in the fetched char.

These three bits are all described here

This question is about what that page calls Invalid text or bitmap modes. It looks as though as soon as ECM is set and at least one of MCM and BMM are set, the mode is an invalid one and the VIC-II outputs only black pixels on top of everything. Even sprites are invisible. I have not verified any of this, neither on real hardware nor on an emulator. But I've read that the sprite collision detection still works as you'd expect. This would seem to point to the possibility that all graphics are generated correctly internally, and that only the color selection in later stages is foobarred somehow.

I wouldn't expect ECM+MCM or ECM+BMM to be useful, exactly, but I also I can't see any reason why anyone would want to spend their transistor budget on removing or disabling hardware support for those combinations, so we must assume that there's some kind of hardware-based reason why these modes don't gel together. Or something. But I simply can't think of a reason. The multicolor mode has a background color if the two bits are 00, and this I would expect to be taken from one of $d021, $d022, $d023, $d024, as selected by the two bits in the character pointer, but it doesn't if ECM is enabled. Why is this?

Answer 1

According to this document, all three invalid combinations actually produce pixels that can be read out via sprite collisions.

ECM pulls bit 9 and 10 for bitmap access low (while bits 11 and 12 keep getting valid values), "so the graphics is - roughly said - made up of four 'sections' that are each repeated four times." Therefore these modes were probably considered not useful at all.

The linked text is not clear about the problem with the illegal ECM text mode, but if I had to guess, I'd assume it confuses the color generation, as the existing circuitry is probably not enough sensibly assign some color for the two-bit pairs.

so we must assume that there's some kind of hardware-based reason why these modes don't gel together.

I don't think so; if the sprite collision works, then pixels are produced, and I assume there is just a tiny bit of additional circuitry that pulls all color bits low in the three invalid modes.

I can't see any reason why anyone would want to spend their transistor budget on removing or disabling hardware support for those combinations,

You really only need a handful of transistors for this, so this is not an issue.

Some manager seeing an output during one of the illegal mode and saying "let's disable this, we don't want anyone to say that the C64 is broken if they accidentally set this mode" is probably enough reason to get it implemented.

But your speculation as to "why" is as good as mine.