furrtek / SiliconRE

Traces, schematics, and general infos about custom chips reverse-engineered from silicon
GNU General Public License v2.0
155 stars 12 forks source link

K051937 sprite buffers switch (PAIR) #20

Open paulb-nl opened 1 year ago

paulb-nl commented 1 year ago

I am looking into the sprite issues of TMNT and noticed that the line buffer switches much too late, after the first sprite has already started rendering.

The PAIR (AN106) signal is generated from the delayed nNEWLINE signal (NEWLINE_DELAY[6]) and then even more delayed to AN15_DELAY[4]. These delays causes PAIR to toggle on HCNT 43 while the first sprite starts rendering at HCNT 35.

IMO the PAIR signal should toggle immediately when nNEWLINE goes low so I don't understand these delays.

The HV counters and nNEWLINE signal are already delayed by 8 pixels compared to K051960 because of HVIN_DELAY. If this wasn't the case then I could understand why the PAIR signal is delayed.

I have looked at the schematics but they seem to match the Verilog for these signals.

furrtek commented 1 year ago

Thanks for the detailed insight. I'll have a look at the svg files asap to see if there are any wrong connections around the cells related to those signals.

paulb-nl commented 1 year ago

AN15_Q (NEWLINE_DELAY[6]) also resets AR4 which is part of the write signal for the buffers. AN15_Q signal must be asserted before the LACH signal is asserted otherwise it stops rendering the sprite.

So I tried to use an 8 pixel earlier NEWLINE signal for NEWLINE_DELAY. This matches the NEWLINE signal from 51960.

This works perfectly. AN15_Q is now asserted just before the first LACH and the buffers switch right before the first pixel of the line is written.

Here you can see the change I made. It is just a hack that generates the NEWLINE signal for the NEWLINE_DELAY shift register at pixel 407 instead of 415: https://github.com/paulb-nl/Arcade-TMNT_MiSTer/commit/af7c652faf91547d286ef684d2e60d1e56b61710

Not sure how the original chip does this. There must be two different NEWLINE signals or something.

Here is a SignalTap trace where you can see that it switches the buffers at address 57 right before it writes to 58 which is the first address for sprite 0 at the character select screen.

k51937_sprite_buffer_switch