HomeForumsWhat's newResources 
 
 
Need Some Help On An Inexplicable Issue
kronikoverkill - May 13, 2023
  kronikoverkill May 13, 2023
Hi all,

After banging my head against the wall, I cannot get certain lines of code to execute.

I'm currently trying to modify some SBL examples, specifically the SPR Sample 7 (SMPSPR70). I'm trying to instrument the code with DBG outputs after a line of code is complete, pausing execution unit pad input. Here is an example below:


  
	
	

		
		

			colAddr = (Uint16*)SCL_AllocColRam(SCL_SPR,48,OFF);

      

        SCL_SetColRam(SCL_SPR,0,48,colorData);

        while(1)

        {

                DBG_SetCursol(0,0);

                DBG_Printf("Last function called SCL_SetColRam()");

                DBG_SetCursol(0,1);

                DBG_Printf("Pad data is equal to: %d", PadData1);

                if (PadData1 == PAD_A)

                        break;

                              

        }



        SPR_3Initial(&work3D);          /* 3D sprite display initialization */

        while(1){

                DBG_SetCursol(0,0);

                DBG_Printf("Last function called SPR_3Initial()");

                DBG_SetCursol(0,1);

                DBG_Printf("Pad data is equal to: %d", PadData1);

                if (PadData1 == PAD_A)

                        break;

                               

        }


The first DBG output fires, and the code waits for pad input. The second does not and the program proceeds to the main loop displaying the polygon example (which is a really creepy model if you've ever compiled it and watched it...).

I have zero idea whats going on after trying to trace through the code with break points in Yabause, Kronos and examining the objdump.

I'm using SSSDK v8 I got from here.

I'm attaching the ISO and ELF and objdump text file (which is from a COF output which is converted to binary to build the ISO).

Really appreciate any help on this incredibly confusing issue...

 Ponut May 13, 2023
Oh, oh, this is simpler than I expected!
Inputs are captured from the controller ports at Vblank. It is not necessarily always the case, but that's how the SMPC is usually set up.

Because of that, when you hit pad A, it will be hit for the duration of that vblank. To capture and hold on the next wait, you must change the button used or change how the inputs are sampled. I also think in SBL there is a ``wait_vlank`` function. Changing the button is going to be far simpler.

 kronikoverkill May 13, 2023

Ponut said:

Many thanks Ponut! Changing the button was the easy solution. But now I'm trying to figure out how to properly sample the SMPC to sample the button release. I couldn't find "wait_vblank" like function in SBL, but after reading the documentation, I would've thought SCL_DisplayFrame() was the right function to put after the first loop. But no dice. Gonna keep digging but many thanks!!

 Ponut May 14, 2023
Trying to stop button presses from carrying over after first sampled in a frame is folley without being aware of when the inputs are sampled and being able to decouple "check if button pressed" from "sample inputs from port". I'm sure in SBL there is some way to do this, but I have a way of doing it which might be helpful to you (though I admit it's not going to solve this exact problem without modification).

(you can find the respective header there too, and ofc, operate_digital_pad1 goes at vblank)