Rondo of blood missing flickering pixels in the water

[TruREALigion]

Interesting (minor) issue. The pirate ship stage 5 It doesn’t do the pixel flickering in the water. Videohere

[dshadoff]

I think I understand what that is.

The Hu6260 Video Color Encoder chip has a video interface and a computer-side interface for reading-writing palette entries. But it is not exactly dual-ported memory.

If the computer side accesses the VCE palette during active display, it receives priority; the display interface will display the last-successfully-fetched value, which is still held in a latch. This can create horizontal streaks, where the previous value appears to be extended beyond its normal boundary.

This is basically comparable to "CRAM dots" on Sega hardware. It's a limitation of the original hardware, and is generally considered a bad side effect. I was not aware of an example that it was ever used intentionally.

[TruREALigion]

Using CRAM “intentionally”. If true, these artists really thought ahead!

So it sounds like the TG16 core is optimally reading/writing compared to what original hardware did, which is why these “CRAM dots” are not appearing from the FPGA?

Nevertheless, I believe the CoreGrafx2 had slight differences in hardware so I’m going to see if my DUO and white PCE exhibit the same thing. But it requires a trip back home to my parents house…. Stay tuned!

[dshadoff]

I'm working with github.com/turboxray to see if we are able to make a test ROM to quantify this VCE/CPU conflict behavior. This may take some time.

The other possibility - since your example seems to shift the whole scanline - is that there may be a raster interrupt, adjusting the X offset for one line only. This is difficult, because the next scanline is not affected, but RCR interrupts are usually a bit too slow to set up for consecutive scanlines. If this is the case, the x_offset is set immediately before being latched on that one scanline, and then reset soon afterward (to take effect on the next scanline). If this is the behaviour, then the x_offset latch point may need to be adjusted slightly.

[TruREALigion]

Glad I could contribute.

Here is a video of my DUO-R showing the same behaviour. This time (not that it matters) on a consumer CRT. https://twitter.com/lnitial_d/status/1467236409513811971?s=21

[M-Walrus]

it seems behavior on original hardware without the SSDS3 flash cart is even different from what you show in this video @TruREALigion
If you observe here, the large pillar is constantly flashing which is not the behavior in your video either:
https://youtu.be/7o1NuDusUic?t=1652

here is my 100% save file for testing purposes, to be able to access the level directly from the title screen (Stage 5):
Akumajou Dracula X - Chi no Rondo (Japan) (FABT, FACT).zip

[dshadoff]

It doesn't seem to be related to a raster interrupt.
At the very beginning of that level, BXR is written at lines 0x11, 0x40, and 0xF4 ... but the write at 0xF4 doesn't change the value (before and after are both 0x0000).

However, there are quite a few palette updates occurring between lines 0xE1 to 0xE3 (specific code is in bank $69, address $47E2 through $4814. This seems to be the area in question (initiated by raster counter interrupt).

[dshadoff]

I made a change and submitted a PR.

The flicker shows up in the correct position, but seems a little smaller on my PR than the real hardware; this may take some fine-tuning or better equipment for test.

[dshadoff]

Reviewing against actual hardware, the effect is correct but roughly half as much as expected.
This is true even if I simplify the latch criteria from:
elsif (CE_N = '0' and (WR_N = '0' or RD_N = '0') and (A = "010" or A = "011" or A = "100" or A = "101")) then
to
elsif (CE_N = '0') then

I think either:

1. Maybe 6280's CEK_N is being held low for a shorter period than expected, or
2. Perhaps the latch needs to be held one cycle beyond CE's removal (i.e. perhaps the 6260 remains sensitive beyond the assertion of CE)

[dshadoff]

Here is a test build of the core, holding the latch one more cycle (at the output stage, by waiting 1 cycle after release of CE_N):
TurboGrafx16.zip
It is closer to what can be seen on real hardware, but hard to say whether it's exact.

[dshadoff]

I took videos of:
a) original hardware
b) the implementation I previously checked in
c) the "additional cycle of hold" version described above, and
d) a version with 2 additional cycles of hold.

The results are:

• b) is too little effect.
• c) is a similar effect to original hardware, but appears slightly shorter than original, and slightly less volatile
• d) is approximately the right length (or possibly slightly too long), but it is too deterministic-looking.

The original seems to be between 1 and 2 cycles more than the current CE hold - between c) and d) implementations - and the volatility probably results from a clock-domain-crossing effect between the 7.16MHz CPU and (what seems to be) a 5MHz video clock.

I will check in the 1-additional cycle version as an improvement, but I think it can still be improved more (but may be beyond my current skill to implement).

[dshadoff]

The version with the fix is now in the public release.

In terms of how games operate (including simulating real hardware for games under development), I believe that this is now "close enough" that the core displays games as intended, and is a very good representation of real hardware (certainly better than any current software emulator).

In terms of "nth-degree cycle-accuracy" on this issue, there may still be something to learn on this issue, but I would recommend closing this issue until such "nth degree accuracy" is noticeable or can be measured.

[thehughhefner]

This ticket can be closed since @dshadoff solved this.