Hi! I'll be brief - I can't read a word from CRAM. Here's my test case: ; Write to colour 0,0 move.l #0xC0000000, vdp_control move.w #0xABCD, vdp_data ; Read from colour 0,0 move.l #0x00000020, vdp_control move.w vdp_data, d0 d0 contains 0x0ACC. I've used TmEE's VDP Address Calculator to verify the command is correct, and double checked it against the bit table in that SEGA2F.DOC doing the rounds. The write works fine, I have palettes looking slick all over the show. All other VDP features are working reliably. Nothing in the VDP regs seems to affect CRAM so I'm not sure I can bodge anything like this up during initialisation. It's not mandatory that I can do this, I'm trying to crossfade from one palette to another so keeping the current palette in a scratch buffer in RAM is no big deal, but I'd love to track down the cause.
Hmm, it seems the problem extends to VSRAM. A variety of reads of VRAM proves okay, but reads from CRAM or VSRAM fetches garbage. The VRAM is on a chip external to the VDP, whilst CRAM and VSRAM are on banks inside. Does this mean there's a different routine for reading data from them?
Solved! The problem wasn't a problem at all, it was my lack of understanding that the bits written are modified to fit into the 9-bit component layout. I thought it was just "a bank of RAM" with no special tricks. A written word is masked before storage, as: ---- BBB- GGG- RRR- ...so my A is shelved, and the least significant bits of my B, C and D are zeroed. Tested by writing 0x02EC, which reads back intact. I'm assuming the VSRAM has a similar trick, depending on the scroll mode set in the regs. I'll keep that firmly in mind. Sauce: http://gendev.spritesmind.net/forum...tdays=0&postorder=asc&highlight=vsram&start=0 http://cgfm2.emuviews.com/txt/genvdp.txt
