Originally Posted by Curt Coder
I suspect Megatouch is broken because the V9938 video chip signals an interrupt on each scanline instead of at vblank when it should. This comment can be found at line 601 in emu/video/v9938.c:

** Somehow the IRQ request is going down without cpu_irq_line () being
** called; because of this Mr. Ghost, Xevious and SD Snatcher don't
** run. As a patch it's called every scanline

I debugged this to death the last time I rewrote the Z80-PIO, and could not come up with a working solution. The V9938 code makes my eyes bleed every time I look at it.

Ok.. What are they actually using the PIO stuff for on the system?

Clearly that check_int code gets called every time either the irq related flags change, and for whatever reason, every scanline, and thus can potentially cause a pio write called due to the callback under certain conditions. I'm guessing you think it's spamming the pio with unwanted data due to the excessive calling?

Obviously checking the interrupt state and adjusting it if the register change is correct (although there could be a slight delay between write and effect) I really don't get the scanline kludge tho, I would have thought that it would only have to be rechecked if something related to the interrupt flags, or irq ack happened / the irq was taken.

It's the MSX VDP iirc, and I already question what's going on in the mode7 code that sexyboom etc. use, so I'd be curious to see which MSX games actually work. I wouldn't really want to change any code in there without a comprehensive test suite, hopefully again this is something the fixed software lists can bring. This is of interest to me because I was trying to get to the bottom of the 'missing black card symbols' issue with the mixing of the 2 VDPs, although I imagine that's going to be like Sega System E where the issue isn't obvious unless you have 2 vdps and have to handle transparency in a special way. Anyway that's got nothing to do with this issue, but it does make me question the quality of the vdp code.

It's possible the whole callback hookup with the PIO write in the actual driver is wrong too I guess...