[SOLVED] Maple activity causing system crash?

[DarkMorford]

Newbie Dreamcast dev here, only been playing around with it for 3 weeks or so. I'm running into a problem trying to exit my program. I'm using KOS commit 7d7aa89ca1d10a1bef20984a6a0120e616421f9e and version 1.0.4 of dc-load.

(Sample code at https://gist.github.com/DarkMorford/5ca ... 62aa6ca0ec)

This works as expected as long as I hit the START button on the first controller shortly after starting the application. However, if I let it run for even a couple of minutes, the system locks up as soon as I press the button. The program doesn't appear to escape the while loop, as the "Square demo finished" line is not printed. Since the problem only occurs when I press the START button, I'm assuming there's something wrong with my Maple code, but I can't find anything in the KOS samples to point me in the right direction.

Can any of you gurus help me out here?

[bogglez]

Have you tried testing the return values of the maple functions?

Code: Select all

    maple_device_t *cont;
    cont_state_t *state;

    cont = maple_enum_type(0, MAPLE_FUNC_CONTROLLER);

    while(1) {
        state = (cont_state_t *)maple_dev_status(cont);

        if(!state) {
            printf("Error reading controller\n");
            break;
        }

        if(state->buttons & CONT_START) {
           printf("start\n");
        }

[DarkMorford]

I've added return-value checks and updated the gist with the new code.

It looks like something in one of the Maple functions is causing the lockup, because I'm not getting any output at all—either from the return-value checks or the "Pressed START" message.

Also, I'm not able to get the ELF to run in nullDC r136. I've got a syscalls.bin and IP.bin in the data folder, but all I get in the output is a bunch of "[sh4]Read16 from 0xXXXXXXXX, not mapped [_vmem default handler]" errors with a number of different memory addresses.

[DarkMorford]

Problem solved. It turns out Windows Firewall doesn't like leaving UDP sockets open for more than a minute without any activity. This means that, when the Dreamcast application tried to send console output back to the PC, Windows blocked the packet and the program just hung. Adding an exception for dc-tool-ip.exe in the firewall lets it run without a problem.

(Thanks to the guys in #dreamcastdev and this thread for the help!)