Puzzled by Pulstar screen transition change in resolution(?) - Page 1

edit

Hi Neo Geo gurus,

I was hoping to resolve the issue of Pulstar seeming to change resolution or display timing when there are screen transitions, e.g. when entering a new stage, or when returning from the CONFIG screen back to the main Title screen.

From CONFIG screen:


back to Title screen:


When running on an OSSC, it consistently does this and cycles between these video attributes received:


I believe the subroutine responsible is at $16C2:


Might anyone have any advice or insights?

I suspect it might be VRAM read/write limits being exceeded. Will try another method to clear the FIX layer.

Ok, it's not due to the $16C2 FIX clear subroutine.

It is definitely caused by this subroutine at $582E.



Some more information:
It's used whenever entering a new screen and seems to do something with palettes(?). Any advice or interpretation is most welcome.

Reducing D3 from 10 down to 02 yields this:
10 down to 0B: normal


0A: green AICOM logo disappears


09: yellow logo disappears


08: blue line disappears


07: orange PULSTAR title disappears
06: lighter orange copyright text disappears
05: unknown
04: unknown
03: light blue text
02: grey text

Lowering D3 also naturally reduces the loop count and directly affects how long it takes the OSSC to find a stable signal, making the image re-appear faster when entering a new stage.

Any clue as to why this is occurring?

there is no information about the possibility to change the display timing via some regs or something similar. even the official(?) development manual of SNK has no information about this.
maybe the timing varies a bit when the VRAM or PALRAM is accessed while the screen is visible?

Hi Blastar, thanks for chiming in. It's bugged me(and some others) for a while and I thought to try to figure it out.

I note that there is absolutely no lag on an emulator. It seems to also affect people running the hardware on CRTs, although to less extent than on LED/LCD screens.

It's definitely something to do with palette loading.

On entering the Start screen, the palette-load subroutine(SR) is run for 16 palettes. It exhibits the "de-sync" on flatscreens (causing it to blank out for a 1-2 seconds).


On exiting the Config screen back to the Start screen, it re-runs this palette-load SR and similarly de-syncs.
As the palette for the Config screen is the same as the Start screen's, there is no need to run this SR again. I shifted it up and bypassed it on return from the Config screen. Sure enough, there is no de-sync now.

For other gameplay screens, the palette list is very long, and it de-syncs for up to 5 seconds.




I looked at Blazing Star to see if it did some optimisation but the SR is the same. A cursory view of Blazing Star's stage palettes show it to be about 1/3 less than Pulstar's. I suspect for Pulstar, all the stages' palettes are loaded at the start of each stage.
It may be possible, albeit laborious, to identify which palettes are not used and only load those needed.
And if it is true that all stages have the same palette list, then it might also be possible to load the entire palette list once on stage 1 and be done with it.

I never had any problems with the sync...maybe my old(!) TFT is a bit more tolerant. maybe you can test the example from the first post on your setup... it updates every 2nd frame 125 palettes at once.

I never had any problems with the sync...maybe my old(!) TFT is a bit more tolerant.

Yeah, I suppose a CRT or multi-sync monitor would help.

What I can't figure out is why the Start screen loading only 14 palettes already manifests this issue. (not 16 as I earlier stated) Far from any reasonable ceiling.
And if entering it from the running animation screens, only 3 additional palettes need to be loaded. Same problem. There must be something to it.

maybe you can test the example from the first post on your setup... it updates every 2nd frame 125 palettes at once.

Insane wealth of information in that post! Thanks! It's going to take me a while to digest it all.
I've built a neo file and ran on the NeoSD Pro for the AES home system. (not MiSTer)
(Kept getting "invalid file structure" with no other information being returned when building it. Checked sufficient padding, the vectors and headers, but then noted your M1 was very sparse. Replaced it with one from puzzledp and builds. Also did not include the extra 220-s1.s1. Not too sure whether that affects anything materially?)

Simple:


Advanced:


Rebuilt Simple and it's still the same.

No screen tearing, de-sync issue from what I can see.

After an unholy amount of testing, I found the principal issue, the reference colour was not set to black.

There's still some slight de-syncing going on and I'll optimise it some other way.

that changing the reference colour has an effect on the sync is very strange

There's a note on the dev wiki.
"The first color of the palette bank ($400000) is the Reference color for the video output. It always has to be pure black ($8000) otherwise monitors won't be happy and other colors won't be displayed correctly."

Not sure how this affects the sync.

On viewing via Kawak's Tile Viewer, the 1st colour does appear black, but on reading directly from the ROM, it showed that it wasn't. Setting it to black solved the bulk of the problem.

blastar (./11) :
that changing the reference colour has an effect on the sync is very strange

Are you using a composite or S-video cable? If so, this is normal. The TV circuits expects certains portions of the video signal to be at the "black" voltage level for reference. If it isn't, it will cause problems, such as counfusing the sync extraction part.

Good to know!