Car sprites do not show properly when F1 Spirit is loaded with TNCROM

[herraa1]

When running F1 Spirit via TNCROM.COM ver 0.03 (but it happens too in older versions) the car sprites can't be seen correctly (some are missing, some move erratically) when a race starts.

The test was done with F1SPIRIT.ROM with md5 603d4c819a51d0c20ff9fa9f902d3ffd, and the command used to load the ROM was TNCROM.COM /T KONAMI /R F1SPIRIT.ROM

It fails in the same way with new type KONAMI_SCC_I.

On the other hand the game works fine when loaded with SofaROM, but then the SCC is not detected as indicated in #11.

Any clues? Thanks.

[buppu3]

I have done the same experiment with tnCart cartridges, but could not reproduce the phenomenon.

I suspect that the MEGAROM emulator bus is unstable, since the SCC also has symptoms that cannot be detected. Was this symptom present in the first version of tnCartWonder?

[herraa1]

The sympton is present on all WonderTANG! revision boards when using the tnCart fpga code. This happened always since initial versions of the tnCartWonder modifications.

tnCartWonder modifications for V1.02d (and V1.01c) are minimal: just the little MSEL0 swap for MSEL1 (and inversion of the INT signal for V1.01c), the rest is exactly 100% as in the tnCart), and I can reproduce the problem always.

I tested it also with several MSX machines (Panasonic FS-A1WSX, Toshiba HX-10, Philips VG8235) and it always happens irrespective of the machine used.

Can you post the md5sum of your F1 Spirit ROM? Althought it works perfectly with SofaRun (and now with SCC working if I activate the SCC before loading SR) maybe my particular ROM has problems with TNCROM.

Thank you.

[buppu3]

I checked the TNCROM source files and found a bug that corrupts the transfer data. I don't know if this is the cause, but I have committed a new TNCROM for you to check out.

[herraa1]

I tested the new TNCROM 0.04 with a WonderTANG! V2.0b on my Panasonic FS-A1WSX (which is my most stable configuration).

First I used the tnCartWoder firmware with the mux sampling "workarounds" I added and got the same results.

I was going to post about it but decided to test again using the tnCartWonder code without the mux sampling "workarounds" (but with the code to set the rgb led to red on poweron) and, this time it worked!

The problem is that without the "workarounds" other MSX machines do not work at all or hang randomly.

The mux sampling code for the WonderTANG! boards seems to be a problem. It was a problem on the WonderTANG! fpga code (my Omega worked or not depending on the specific mux sampling code... and it stopped working with V2.0b) and seems to still be a source of problems.

I need to make more tests to confirm that the problem went away too on the other machines without the mux sampling code workarounds (if I manage to get to that point before they hang).

[herraa1]

I did one more quick test with my Toshiba HX-10 (which is also pretty stable).

I can confirm that (without mux sampling workarounds) the game works correctly with TNCROM v0.04 and fails (sprites show on the top of the screen) with TNCROM v0.03.

[buppu3]

Regarding the instability in V2.0, there are the following possibilities.

• The circuit scale has become larger, and more wiring is being rerouted in the FPGA, resulting in signal delays.
• Memory access timing is off because the MUX cycle has increased by one clock cycle.

If the first is the cause, the only solution is to modify the source code to reduce the size (Or adjust the entire system to run at a lower frequency)

If the second cause is the cause, adjusting the following timing may improve the situation.

• Length of delay put into RDn and WRn (Delay is intentionally put in because the RDn/WRn signals have no delay compared to the signal being MUXed)
• DELAY and MRAM_EXEC_DELAY parameters in uma.sv (Memory access timing is synchronized with the CPU clock, and RDn/WRn is checked at the timing of 6 operating clocks from the rising edge of 3.58 MHz clock)

Adjusting these two delays may help stabilize the operation.

[herraa1]

Thanks for your comments.

I think we can close this issue as the subject has been fixed with commit cfe66c51a5c41dbddce8ebf01cfbc06c9bc7952f.

If needed we can open a new specific issue focused on the detected instabilities. For now, the mux code tweaks were reverted. I'll keep an eye on possible instabilities once #14 is fixed.