Surely, just guessing. Just it's 4 bits info, thus 16 colours, that mades me thinking it's similar to the 16 colour Nick "internal" mode. But I can be totally wrong Anyway, since it is designed for future sprite support there should be some "sane logic" how it should work, just needs to be figured out. For attribute mode: I would _guess_ (!!!!) that it does not matter. It may be implemented simply, that Nick generates its pixel whatever it is video and colour mode. And the external colour mode generated pixel just shown "above" (better say "instead") the Nick generated pixel, that is, simple "priority decoder" or something like that.

Btw! Just come into my mind: if I remember correctly, we have some kind of Nick internals document or something ... Hasn't that contain some information to answer these kind of questions?

Wow, finally some specifics
I had not thought before about TVC64. Only recently I learned about its history, and that is very similar to the Enterprise.
Something else is analyzing the schematics on the paper, and something totally different opportunity to see in the operation of the actual hardware, without fear that the feeler "will fall to the place in which can cause the most damage" (according to Murphy's Law).
Thank you very much for the links.
Could use even the contents of ROM-s. Please

My idea was, that a sprite unit would work this way: it has two "data structures" for a sprite. First, there is the "shape information". That is, controls /EXTC, this is 1 bit info per sprite pixel. Can be also thought as the "alpha channel" in modern gfx things, just we have only on/off, no "semi-transparency" etc. And then there is 4 bits of colour info for the given pixel, which does not count at all if /EXTC is not (low) active. Now it's interesting that it _seems_ I was right, in the "palette-less" 256 colour mode, the external colour still uses the palette. That makes sense, as this external colour feature is created for "sprites" keeping in mind in the future, this it would be a bit odd, that sprites can have only fixed colours for the first 16 EP palette colours. And anyway, in 256 colour mode the palette by Nick internal pixel generation is not used, so it's kinda handy to use it for something at least Surely, for a more simple sprite unit, some can say, that external colour value 0 means the transparency, then no need for shape/colour info, but only a simple logic, to drive /EXTC for low active if 4 bits of EC are all zero. This would mean - if I am correct - that 0 would mean transparent, 1-15 would select the corresponding internal Nick palette (8 LPB palette values + FIXBIAS for the second . Thus we lost one colour with this technique. The price for not having separated sprite "shape" and "colour" info in the external sprite unit ...

They mention a camera input. May be the easiest way to experiment is to try a video input, with some circuit slicing a synchronised composite signal into its 4 bit EP-colour components, with Extcol always active.

They mention a camera input. May be the easiest way to experiment is to try a video input, with some circuit slicing a synchronised composite signal into its 4 bit EP-colour components, with Extcol always active.

Yes, I guess. That's about the same what I meant about having a "nice resolution 16 colour mode" generated externally on the external colour inputs. As far as I see then, on TVC this method was used by the hardware ZX Spectrum emulator as well, basically, what Zozo mentioned above? Ok, that's TVC and not EP, but I think the theory is the same, after all.

There is the interesting question: Nick is a custom chip, what the developers wanted it, putted in.
But at the TVC used a existing chip (6845). How adapted this special features? And fully adapted?

As far as I can see, TVC uses also a custom "logic", not "a single chip" though, as with EP/Nick. In TVC, the 6845 only generates memory addresses, sync pulses, and things like that, but the actual pixel creation, modes, memory reading, CPU/video bus "sharing", etc are not task of the CRTC at all (and it seems these are all implemented by discrete logic?). Maybe that was (the part) of TVC's problem for being too costly to manufacture: it basically uses "discrete logic" for the task, where this was built-in all in a custom chip in the EP (it's another question, that a relatively high-integration custom stuff is also costly ... some must find the balance ...).

Interesting, but it sounds me funny, if TVC would use Dave/Nick, it would be exactly an EP128, and not a TVC Well, or maybe they would have manufactured EPs for real, just "made in Hungary" and that was not possible? Anyway, I see USSR launching missiles but programming LPBs first for Nick in them