This screen initialization results in garbled graphics on Phoenix...

No ideas, though. It doesn't do anything strange that I can detect. It's an animated ColecoVision screen that screws up, and after the first attract mode when it wraps back around to the Konami screen, everything is okay. So the code is (probably) working. Works in emulation, with or without the SD loader, so it's (probably) not system init. Screen is a completely standard bitmap screen with no masking, every register is initialized and no unused bits are set. Y'got me why it doesn't work. :)

VDPADD >8002 - REG 0 = 02 - bitmap mode
VDPADD >81A2 - REG 1 = A2 - 16k, blank, ints, 16x16 sprites
VDPADD >8206 - REG 2 = 06 - Screen Image table at >1800
VDPADD >83FF - REG 3 = FF - Color table at >2000, mask >1FFF
VDPADD >8403 - REG 4 = 03 - Pattern table at >0000, mask >1FFF
VDPADD >8536 - REG 5 = 36 - Sprite attributes at >1B00
VDPADD >8607 - REG 6 = 07 - Sprite patterns at >3800
VDPADD >8700 - REG 7 = 00 - Background color transparent
VDPADD >4000 - Write to >0000 (pattern table) - (16384 writes - zero VRAM)
VDPADD >5B00 - Write to >1B00 (sprite attributes) - (128 writes - blanks sprite table (actually uses E3 bytes, offscreen))
VDPADD >4808 - Write to >0808 (pattern table) - (784 writes - graphic data for the 'Coleco Vision' logo)
VDPADD >5900 - Write to >1900 (screen image table) - (184 writes - characters for logo)
VDPADD >81E2 - REG 1 = E2 - 16k, visible, ints, 16x16 sprites

VDPADD >6808 - >2808 - (784 writes - color rotation)
VDPADD >6808 - >2808 - (784 writes - color rotation)
VDPADD >6808
VDPADD >6808
VDPADD >6808
VDPADD >6808
...


Basic theory: some startup state leads the game to believe it has already initialized VRAM before the CV logo appears. It does not re-initialize until after a complete attract mode cycle.

What I've tried to reproduce in emulation - no reproduction of issue:
- force bitmap screen addresses at wrong locations
- select wrong graphics mode
- mess with 4k/16k DRAM setting (actually was a red herring)
- force F18A on
- trace startup code through from the ColecoVision BIOS. There are no real notable assumptions made in the startup code.

What I've tried on hardware - same issue
- boot with Coleco BIOS on AtariMax (NOT using my loader)
- clear sprite table with D0 instead of E3
- clear only 16384-256 bytes of VRAM (to avoid wraparound)
- write E2 to VDPR1 from the start
- Loop back to the ColecoVision screen after a cycle rather than the Konami one (C11A vs 8447)

What was interesting but probably a red herring:
- I forced the loader to set i to a non-zero value and hacked the game to not zero it at startup - the middle third of the screen was corrupted until the first attract mode completed (Emulation and hardware both corrupted, but differently)

Unknowns:
- What happens if we boot from a raw ROM (it's just a 32k ROM), no loader? (I think hitting reset in CV BIOS mode with the AtariMax should be pretty much the same thing, though...? This does not change behaviour)
- What happens with AtariMax on real hardware? (My Coleco died...)
- The game seems to use the i register as some kind of state (seems locked in interrupt mode 0). The CV screen is the only time that i is set to 0. Is that an issue? (i is 0 on other games without issue)
- what if we write a demo app that sets the registers the same way?
- is the game detecting hardware and taking a different codepath than in emulation? (I would expect emulation to trip up the same checks though)