Runtime callbacks about ngdevkit HOT 11 CLOSED

Is there a way to emulate the hblank irq with gngeo?

Late answer, but it turned out there was a bug [1] in GnGeo that prevented an arbitrary HBlank value to be reported properly to the ROM program.

I've fixed it now, so latest gngeo package should allow you to interact with hblank as you wish. I've built a new example in ngdevkit-example [2] to showcase the possibility.

[1] dciabrin/gngeo@f4bd33a
[2] dciabrin/ngdevkit-examples@11356b1

from ngdevkit.

I understand, according to the runtime configuration in ngdevkit.ld (along with ngdekit-crt0.S) that I can override default behavior by providing code in the main C program.

correct

It's working just fine with rom_callback_VBlank(), but I can't get another one working.
For examples:

* If I provide a rom_eye_catcher() function and I set rom_eye_catcher_mode=1 (with --defsym,rom_eye_catcher_mode=1), then I expected the rom_eye_catcher() callback to be triggered.

That would be the right course of, however i think the GAME's eye catcher requires a bit more work to get called properly. For instance, when the VBlank interrupts is triggered, the handler will see byte value 0x2 in 0x10fd80 (BIOS_SYSTEM_MODE) to notify that the game eye-catcher is in progress. I'm trying to come up with a complete example in ngdevkit-examples (urrently I can't get it to run either).

* Same with the player_start() callback. I can't get it triggered the same way.

Have you checked recent commits in ngdevkit-examples? Example 07-attract-and-game makes use of that.

* Seems rom_callback_Timer() isn't called as well but I'm probably doing something wrong here.

I remember the original VBlank_callback had a bug a long time ago, maybe the Timer_callback has the same.
It could also be because by default, gngeo doesn't emulate the hblank IRQ. Not sure which emu you're using?

from ngdevkit.

Also, as per the neogeodev wiki [1], command 1 is only called by default on AES (only once at startup), on the MVS some additional tweak must be done and it only shows after a first attract sequence is finished.

[1] https://wiki.neogeodev.org/index.php?title=USER_subroutine#Command_1

from ngdevkit.

Still related to runtime override, looks like, if I understand well, that I could provide a custom rom_NGH_ID on the main C side correct?
I tried different things but I'm getting a linker error:
relocation truncated to fit: R_68K_16 against symbol rom_NGH_ID' defined in .data section in rom.elf`
Which, to my knowledge, means I'm trying to set fill a larger address than I should in an already defined space.
Do you have an idea?

Could you check if the new example 08-software-dips answers your question? It's using a customized rom_NGH_ID so hopefully it answers your question.

from ngdevkit.

I didn't noticed the new example so thank you for pointing them out to me. I will have a look asap.
Thank you for your continued support!

from ngdevkit.

I'm using gngeo by the way :)

from ngdevkit.

Is there a way to emulate the hblank irq with gngeo? Or do you recommend using another emulator for this purpose?
Otherwise the attract and game sample was exactly what I needed to understand the player_start mechanism. Thanks

from ngdevkit.

Still related to runtime override, looks like, if I understand well, that I could provide a custom rom_NGH_ID on the main C side correct?
I tried different things but I'm getting a linker error:
relocation truncated to fit: R_68K_16 against symbol rom_NGH_ID' defined in .data section in rom.elf`
Which, to my knowledge, means I'm trying to set fill a larger address than I should in an already defined space.
Do you have an idea?

from ngdevkit.

Oh yes, sorry I forgot to mention I got it working with defsym, not with the redefinition in the C code.
So it's not so important, I was just wondering the mechanism in the C side code.
Thanks

from ngdevkit.

Oh yes, sorry I forgot to mention I got it working with defsym, not with the redefinition in the C code.
So it's not so important, I was just wondering the mechanism in the C side code.

Right, most probably "defining a symbol" means "creating a variable" in C, which won't work because gcc will create a symbol for it in segment .data, while symbol rom_NGH_ID is used in the .text segment. So you'd need to define your symbol and use an attribute macro to tell gcc to store in it .text segment... But then that will consume some space for nothing...

So the trick in ngdevkit is to just assume you'll specify the value of rom_NGH_ID at link time, so ld considers it more or less like a constant. And as a fallback, the link script ngdevkit.ld uses a default value of 1337, so you don't need to care about the detail if you don't want to.

Thanks

from ngdevkit.

Alright understood!

from ngdevkit.