During the development of my current project with Turbo Pascal 3 and the graphic extensions, I encountered an odd bug where the pattern of any defined sprite beyond the 16th sprite was getting corrupted. I poured over my extensions code but could not find any problems there. Then I remembered the VDP map posted by Milli here, and upon closer inspection, it looks like the Sprite Descriptor Table (SDT) which holds the patterns for the sprites has enough allocated space for only 16 sprites, not the expected 32! It starts at $3800 and ends at $387F whereas it should extend to $38FF since each sprite pattern is 8 bytes.
After the 16th sprite, the SDT starts overwriting the Sprite Attribute List (SAL) at $3880 and then when the SAL is updated it corrupts any sprite patterns beyond the 16th.
So I figured it should be an easy fix: just move the SAL to $3900 and problem solved, which would only involve changing the value in VDP register 5 to a multiple of $80, i.e. for a base SAL address of $3900, VR5 should contain $72 ($72 x $80 = $3900). Unfortunately, it did not work and all I got was either no visible effect or screen corruption. I tried multiple different technically unused locations within the VDP RAM with similar results.
Major bummer! I'm not sure what the issue is but I suspect that CP/M is writing stuff to the unused areas of the VDP and somebody at Coleco apparently figured that no one was going to use sprites under CP/M any way. Hah!
Major bummer...

One important difference between the set up of the VDP on the ADAM compared to the TI 99/4A is that the bitmap display on the ADAM disables interrupts in VDP register 1 whereas on the TI they are enabled. Therefore, the standard content of VR1 for the ADAM for the bitmap mode is $C0. It took me a while to figure this out while ripping my hair trying to understand why the screen was getting corrupted!