The 16th sprite was not being shown, as the timing wasn't giving it time to read the it's contents during the horizontal blanking. It should work now. Other games with 16 sprites per line would have the same issue. I've only tested with the low res (ie 256 pixels).
Sorgelig wrote:Some games like R-Type and especially Dead Moon have flickering sprites. What causing it? Not enough bandwidth? MiSTer uses BRAM for system RAM, so if there any limiting mechanism is in core, then it can be removed. Even dual-port access can be added if required.
Some of this may have been the above issue, but the 16 sprites per scanline can still show up. It's certainly possible to get all 64 sprites on one scanline to show up with dual-port RAM, and not wasting cycles. The actual hardware only supported 16 per scanline, and some games require this limitation to display properly, so you'd want an OSD option to turn it on and off. For now, though, I'm more interested in getting the timing to match actual hardware, as this can cause many glitches.
Sorgelig wrote:Batman now works!
Atomic Robo-Kid Special: has many garbage on bottom of screen. And it seems should be blanked out. May be blanking problem.
I've improved this, but it's still not quite right. The status bar at the top of the screen was missing (life/score). It now shows up, but it's still cutting off part of it. Timing is not quite right. I made some adjustments and now the 256x240 test image in the 240p Test Suite now shows up completely (including a couple pixels of overscan on the left and right if you turn it on). The overscan test also shows no missing lines. I'm tempted to rewrite the X/Y handling in the 6270 file, as I think a state machine makes more sense than a bunch of if statements...
Also, I noticed the change you made to scandoubler causes issues for my monitor. It doesn't like having the vsync delayed by 3 lines. ie, I did this in my code to make monitor happy:
assign vs_out = vs_in;
//assign vs_out = vso;
Latest pull request in the usual place.