CPS1 palette copy weirdness

ack

Ninja Combat Warrior
15 Year Member
Joined
Apr 9, 2009
Posts
540
I've been messing around writing some code the cps1, but getting some weird behavior related to asking the cpsa/b chips to copy the palette data from gfxram to the real palette chips. From what I've read/seen this should get triggered by writing to the your palette address to $80010a. Doing this works in mame, but on real hardware there seems to be some additional condition that is needed for it to happen.

After setting up the necessary registers and print some text on screen (bad colors). I have a simple while loop such that

if player 1 A button is pressed, it will write the palette address to $80010a
if player 1 B button is pressed, it will enable interrupts. The interrupt handler for vblank will write to the palette address to $80010a, then interrupts are disabled.

If I hit A button a bunch of times it will eventually trigger the palette copy and fix the colors of the on screen text
If I hit B button it instantly does the palette copy

It almost seems like the copy request is ignored unless its done while a vblank is happening? Curious if anyone has run into this before and/or knows how to trigger a the copy without using the interrupt handler method.
 

tcdev

NEST Puppet
Joined
Aug 22, 2002
Posts
168
I know nothing about the CPS, but is the palette data (either source or destination) done via address/pointer registers that may be modified in the VBLANK ISR? I ask this because on the Neo Geo all sprite registers are done via VRAM address registers, so you must be careful to disable the VBLANK interrupt while you're updating VRAM outside the ISR.

Either that or the hardware only allows access to the palette during VBLANK... wouldn't be crazy if that was the case.
 

Razoola

Divine Hand of the UniBIOS,
Staff member
20 Year Member
Joined
Nov 12, 2002
Posts
4,662
I can confirm CPS2 works that way.... The palette needs to be updated during vblank for the palette to update correctly. This is the reason CPS2 games on original hardware have bad colors during the initial boot check screen (before the warnings), but not every single time. Once the vblank interrupt is enabled, and registers are written during vblank, the pallettes are displayed correctly. I guess CPS1 is the same way.

If you don't want to use the VB interrupt, you can use the scanline counter to detect if the scanline is off screen and do it that way also.

(edit) dug out some old CPS-2 code for you to do above (the scanline register may be different depending on the CPS1 board your using).

Code:
vbloop1   move.w  $804150,d0          wait untill inside vblank
          cmp.w   #$0106,d0
          bne.s   vbloop1
          move    #$9280,$0080410A    Palette Ram Base
 
Last edited:
Top