I found this code (3E 3F ED 79) and replaced it by 3E 1F ED 79 at 1CC2Ah in the original ROM and the version Nandemo SCC, but it's not found in the Enhanced version. This bug may have already been fixed in this version.
I found this code (3E 3F ED 79) and replaced it by 3E 1F ED 79 at 1CC2Ah in the original ROM and the version Nandemo SCC, but it's not found in the Enhanced version.
I do not think that changing it just like that is the correct fix. Because 3Fh required in the game to show top 16 pixels with score / weapons / etc.
I am not sure about Enhanced version, I do not have it. But I assume somebody changed some code there to make it "Enhanced" and it is not the same as in original. Is it confirmed that Enchanced version also have this bug?
Yes, this is looks like the right code. For some reason they using direct register access that not really a good practice... (but I am guilty to do it myself sometimes :) ).
This saves time and space. Zanac EX uses also bad practice when it read the 0007h address to read a VDP register. (Even if it have no importance in fact because read ports are always at the same location as write ports.)
I tried on BlueMSX, it seems works but on OpenMSX the score panel is not displayed.
I will check he patch shortly.
But this is why before I was mentioning that just changing to 1Fh would not help, because it would affect the score panel.
I will look more later on today and try to make a patch. But, I would really want to understand WHY this is happening, because then we can have the real fix.
This saves time and space. Zanac EX uses also bad practice when it read the 0007h address to read a VDP register. (Even if it have no importance in fact because read ports are always at the same location as write ports.)
The code causing the glitch only triggers when the FH status bit (horizontal line interrupt) is flagged. However, during the title screen line interrupts are disabled (IE1 is 0).
Disabling the line interrupts does not keep FH low at all times though. When the VDP hits the interrupt line, FH goes high for a brief moment (openMSX says: “FH goes up at the start of the right border of IL and goes down at the start of the next left border.”), even though it does not stay latched like it would when IE1 is enabled.
Because of unlucky timing on the turboR GT (or maybe rather, lucky timing on other systems) it sometimes polls FH exactly in this moment. To fix the issue, the interrupt routine should skip the FH check when line interrupts are disabled.
The code causing the glitch only triggers when the FH status bit (horizontal line interrupt) is flagged. However, during the title screen line interrupts are disabled (IE1 is 0).
Disabling the line interrupts does not keep FH low at all times though. When the VDP hits the interrupt line, FH goes high for a brief moment (openMSX says: “FH goes up at the start of the right border of IL and goes down at the start of the next left border.”), even though it does not stay latched like it would when IE1 is enabled.
Because of unlucky timing on the turboR GT (or maybe rather, lucky timing on other systems) it sometimes polls FH exactly in this moment. To fix the issue, the interrupt routine should skip the FH check when line interrupts are disabled.
