When setting Color Ram Mode = 0, the palette read address for layers NBG1 and NBG3 changes from 0x05F00420 to 0x05F0C20. How do I return the read address 0x05F00420?
First, I found a palette for layers NBG1 and NBG3 (it is located at 0x05F00420). When I change CRM = 0, the image for the NBG1 and NBG3 layers deteriorates (see the first image from post #22). I found out that in this case the reading address of the palette for the above layers changes and the count begins from 0x05F0C20. Why this happens I do not know. Changing parameters at addresses (180032-180036) and 1800E4 does not give the desired result. Since changing the CRM parameter does not affect the display of the NBG0 and NBG2 layers, it seems to me that the whole point is that these layers use different VRAM bank partitions (18000E). Changing the values of 8 and 9 bits at this address affects the display of all layers.How did you get those addresses ? I would expect them to change the other way when changing CRAM type from 1 to 0, since there's only 2048 bytes of content in color RAM mode 0, versus 4096 in mode 1. On p. 216 of VDP2 manual : "When the color RAM mode is 0 or 2, the color RAM address MSB is ignored.", so CRAM addresses should become smaller, not bigger.
Was wondering what games show that..EDIT: antime already awnsered to the question that was here.
Ever seen a SNES game with a curtain effect, like the Super Mario World opening (the cartoon-style "ball" fade-in)? It's a setting that "clips" a BG to a given size. Saturn has the mother of all clippers... SNES had horizontal clippers only to a given color. Saturn can do clipping on the horizontal and vertical locations, and show the inside, the outside, overimpose two windows with AND (a way to create transparency without cost) and er... lots of other fancy stuff.
To add to that, you had to make a special DMA mode in SNES to let the window do fancy drawings, that had some processor cost. VDP2 eats stuff like that for breakfastIt's very exciting stuff ^^;;;