Conversation
| .LHBL ( ~hs ), | ||
| // New line writting | ||
| .we ( buf_we ), | ||
| .we ( buf_we & ~hs ), |
There was a problem hiding this comment.
@jotego this is avoiding spilling sprites from line N to line N + 1 when there is a line time issue. Chuka taisen weas making 3 lines dirt because line 1 was spilling to line 2, and line 2 to line 3. Now with the rom patch this isn't an issue anymore but still fills like something that in general is correct. But i m also worried it could affect new sprites at the start of the line.
It depends when the code that executes the sprite drawing start drawing and when is the correct time for line N and line N + 1.
I would leave a note about this change but not chase it now, unless you think it makes sense.
|
This is a bit of a hack but it doesn't hide that fact so we can fix it better in the future. I think it is ok. @skutis did you RE'ed these chips? I am not sure if you had looked into this... |
|
I have not RE:d the chips yet. I have die pictures though. |
|
yes this is a rom patch waiting for full decap analysis. An avenue i didn't test, what if this game was default rotated by 180 and flipped? That would make it lik drtoppel and working fine no patches |
|
no sorry rotation + flip would make the game go on the left rather than on the right. |
|
i ll test this and then mark for review. |
|
Confirmed working good. |
|
Someone that tested the core compared the audio to mame and noticed this core sounds bad: // core // mame |
|
Ok i noticed that chuka taisen was getting the FM chip clocked to 1.5Mhz but also when switched to 3Mhz it sounds terrible. I tried remove lumping, that was something that was causing issues also on double dribble and the sound fixed. fpga_nolump_fm3.wav |
|
without lumping it sounds good. But for now that is a different topic, since all the other games needs to be tested or lumped manually with an header bit. |
|
this is the game with audio NOT LUMPED. testgood.mp4 |
The problem is well descripted in the issue #1509 i won't replicate here.
The fix i propose is a patch, not a large hdl improvement on fetch speed that could be hard to chase.
I decided to propose a patch to the program rom that work around the issue because the issue is really a combination of factors that make our sdram access a problem.
We can try to implement a better approach too with hdl that makes the issue less problematic and leave the grey bar there, but this seems reasonable to me.
closes #1509