All Codemasters' games have auto-detect region feature and so they can be played on both NTSC and PAL consoles. Also, most games are working on Dendy (Famiclones) too, except:*Bee 52*Quatro Sports: Pro Tennis*Quattro Arcade: CJ, Stunt BuggiesThose games, when run on Famiclone (Dendy) hangs momentally. Do you have any idea how to fix them?

Thank you, problem solved (CodeMasters' PAL/NTSC checking routine was counting CPU cycles between two VBLANKs and it was only prepared for two distinct values - one for PAL and one for NTSC. When it occured any other value, it was forced to count CPU cycles again. So for Dendy, it went into infinite loop.

Last edited by krzysiobal on Mon Jul 03, 2017 11:03 am, edited 1 time in total.

It looks like it'd fit size-wise. But what does their NMI handler look like when not much is going on? Because my detection code waits for the NMI handler to modify a variable in zero page and counts how long it takes for the variable to change again.

I personally prefer a console detection routine that doesn't rely on NMIs. It's less invasive, and counting the expected amount of cycles and then testing for vblank works just as well comparing the cycle count against expected values once vblank hits.

EDIT: One way to do it is: after waiting for vblank by polling $2002, wait enough cycles for the next NTSC vblank and test $2002. If the vblank flag is set, it's an NTSC console, if not, wait a little more for the PAL vblank and test $2002 again. If the flag is set, then it's a PAL console, if not, it must be Dendy, but you can wait a little longer to test the vblank flag again just to be sure.

I don't actually make this clear distinction between console types though, since Dendy has some things similar to PAL and others similar to NTSC, so I actually set 2 flags in my detection routine: one for the frame rate 50Hz vs. 60Hz) and another for vblank length (20 scanlines vs. 70 scanlines). The frame rate can be used to control the speed of the game and the music, while the vblank length can be used to control VRAM updates and music pitch, for example.

You have a point. I thought explicitly testing for a breakpoint between 29780 and 33247 cycles and another between 33247 and 35464 cycles would take more ROM space. But for poops and giggles, I tried writing a routine like what you recommend. It turns out that because the test takes long enough that the PPU stabilizes, the waiting code can be removed from the hardware init routine, making up the lost bytes.

I succeded in fixing most of those games just by forcing the check routine to return NTSC when in Dendy Mode.

One game that cause troubles is Fire Hawk. The title screen shakes in Dendy Mode (in PAL and NTSC is stable) and the game after starting crashes immediatelly due to sprite 0 hit fail.Anyone has idea why the shaking appears?

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum