Yeah, the Aoi game was a case of two wrongs making a right. Fixing the INT_MASK made the other error show up.Sorgelig wrote:I've also tried to fix it but unsuccessfully since i've tried to understand why INT_MASK reading prevented Aoi game to run.GreyRogue wrote:Fixed in latest pull request (Reading VDC register 0x1 should always read 0, not 0xFF).
By the way, i've added Q13 project files to this core. So, you can install Quartus 13 web edition and compile the Lite version twice faster!
I don't know if you use SignalTap or not, but In Q16+ versions it's kind of broken as Storage qualifier doesn't work reliably. So, Q13 version provides better SignalTap experience.
I haven't been able to download Quartus 13 yet. Actually, I downloaded Quartus 13.0 and then realized I needed 13.1, and I haven't been able to get it to download yet. I guess they decided the first couple GBs was enough for now...
Fixed the Sprite Width setting for "10", which is functionally equivalent to "01". The Japanese version uses "00", which reads the data twice as fast, but as long as the Sync width is long enough to get the data, it shouldn't matter which one is used ("11" is different and only reads two out of four planes, which is what is was doing for "10").Sorgelig wrote:There are 2 types of R-Type ROMs:
1) R-Type Japan comes as 2 separate parts with 256KB each - looks OK.
2) R-Type USA comes in a single 512KB ROM - it works OK, but sprites are dull.. like with missing bitplanes. Playfield looks OK.
What it can be? Different USA/Japan regions have some differences in HW? Or it's game protection to prevent it play correctly on foreigner HW?
I just tried each of vso through vso, and they all have the same issue with my monitor blanking out every couple of seconds. Only vs_in works for me. I'm building Lite builds and displaying through VGA. Using vso[1-3] also chops part of the image off for me (testing with the 240p Test Suite Overscan test). I'm not sure why. The code looks right to me, but I haven't dug into it.Sorgelig wrote:Scandoubler delays the data by 2 lines. Also, to make sure of correct work of HDMI scaler, one blanking line is required before VSync. Some cores don't provide enough blanking. Hence 3 lines delay.
Can you explain what's wrong with 3 lines delay? Did you try vso instead? Vertical blanking is delayed by 2 lines as well, so delay VSync by 2 lines should make correct sync.