VDP memory organization

[Wmaalouli]

This is a repost of Milli's excellent breakdown of the VDP memory organization table for those interested in accessing graphics via assembly language (form the AtariAge forum). I thought it would be easier to find and more relevant here. I just clarified the titles of each section based on the TI nomenclature.

-------------------------------------------------------------------------------------

Notes: CPM breaks the screen up into thirds: TOP, MID, BOT
CPM uses a sprite for the cursor

0000h - 07FFh Font patterns for the top 8 lines of screen (Pattern Descriptor Table)

0800h - 0FFFh Font patterns for the middle 8 lines of screen

1000h - 17FFh Font patterns for the bottom 8 lines of screen

1800h - 18FFh Characters for the top 8 lines (Screen Image Table)

1900h - 19FFh Characters for the middle 8 lines

1A00h - 1AFFh Characters for the bottom 8 lines

1B00h - 1FFFh Unused, CP/M may use for scratch RAM

2000h - 27FFh Colors for the top 8 lines of the screen (Color Table)

2800h - 3FFFh Colors for the middle 8 lines of the screen

3000h - 37FFh Colors for the bottom 8 lines of the screen

3800h - 387Fh (Sprite Descriptor Table)

3880h - 38FFh (Sprite Attribute List)

3900h - 3FFFh Unused, CP/M may use for scratch RAM
Milli

[Wmaalouli]

I thought this might be useful for anyone trying to understand how the VDP is organized and how to use it. It's an excerpt for the TI 99/4A computer Editor/Assembler manual, and it goes into great detail not otherwise easily available for the Adam.

[Milli]

Thank you for posting this - once I get back in to coding in a week or 2 this will come in handy.

[Wmaalouli]

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!

[Milli]

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!

I bet this is my problem too! It works fine in the Emulator but on real hardware garbage

[Wmaalouli]

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...

[Milli]

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...

How about moving it to this open location (56h for register 5)?

1B00h - 1FFFh Unused, CP/M may use for scratch RAM

[Wmaalouli]

56h is used by the pattern descriptor table.
I just realized that CP/M on the Adam does use some sprites for the cursor and the I-VI key display, so it's probably taking the upper 16 sprites for its own use.