Both DPC+ kernel and custom assembly kernel in one game?

[gauauu]

I have a project I'm working on where most of the game uses the bB DPC+ kernel. But for some other parts (menus, etc), I want to do some custom things that I'd need to implement my own kernel from scratch.

 

What all needs to be done in my main loop to let me break out cleanly and run my own kernel code? I assume the "drawscreen" bb command waits until the vblank timer is done, jumps into a kernel loop, then sets a new timer. Can I just hijack that, and instead of calling drawscreen, jump to my own loop where I wait for the timer, run my own kernel, then set a new timer?

 

Are there additional considerations that I need to keep in mind being DPC+?

[+Karl G]

Someone else can probably answer in better detail, but I was thinking that the Titlescreen Kernel would be a good example of this. One calls it from a loop, with "gosub titledrawscreen" replacing the usual bB drawscreen command, so the bB display kernel is never run while it is active.

[gauauu]

Yeah. I figure if nobody responds I can just look at the generated assembly of doing what you're talking about. But if somebody knows the details (particularly the interaction with the DPC+ data fetchers/etc) it'd be easier than digging through code.

[RevEng]

It's pretty much as you thought. Just wait for overscan to end, run your own vsync, set+wait for vblank, run your kernel, then set the timer for overscan as bB expects it, and return to the bB code.

 

No messing with fetchers or any other ARM hand-holding. As kdgarris advises, the Titlescreen Kernel would be a good place to start. Otherwise, study how bB sets the overscan and vblank timers, and copy it. bB sets them a bit differently than most homebrews.

[gauauu]

Cool, thanks.