RESMP0 and RESMP1 Register Testing

[Omegamatrix]

Here are some flexible test roms to cover many scenarios. Please read the source code for program usage. These roms are meant to be used on real hardware while looking at the same result on Stella to get an idea of what is not emulated correctly (Hint, there is some work to do...).

testRESMPx.zip

[Omegamatrix]

I did some real hardware testing today on a 4 switch woody. I put the results into the excel file below.

RESMP0_Results_1.zip

This was a very simple test. I kept P0 at one copy, and the M0 size at 8 clocks. In the excel sheet you will see some individual sheets for different "GAP" settings. The sheets show P0 Position vs STA RESMP0 instruction start cycle with the color tiles representing where M0 successfully repositioned to the center of P0. There is also a legend for the colors at the top of each sheet.

Of note P0 Position 159 has quite different results than positions 0-158. Pos 159 is the final position before HSYNC begins.

Can someone please take a look at the TIA schematics to see how RESMP0 and RESMP1 works, and share their findings?

[sa666666]

I've tried these ROMs in all emulators, and none of them are working like real hardware. @Omegamatrix, are you doing anything strange in the code, or is it just that this feature has been improperly emulated (or not at all) for all this time??

[Omegamatrix]

It has been improperly emulated all this time.

The reason is very few roms actually use RESMP0 or RESMP1, so no one has paid much attention to it. For the ones that do (like Combat) the emulation is probably accurate enough.

As a side note for the GAP value, I should have defined it as the amount of cycles between writes instead of the amount of cycles between instructions. There are 3 cycles extra on the excel sheet because of the cycles needed for STX RESMP0 to execute. I think everyone can figure it out.

[DirtyHairy]

@Omegamatrix thanks a ton for the test code. I have to find time to sit down and compare the emulation to real hardware myself, but that might well take until next weekend.

Until then, some general remarks (with a grain of salt, I have taken just a very superficial look at the code and the excel):

• The new core models the TIA in terms of interacting counters and is modelled tightly after the findings in Andrew Towers' canonical document. As such, many effects come naturally to the simulation, but some have to be accounted for separately (this is particularily true for the interaction between RESx, NUSIZx, HBLANK and rendering). I am very sure that the details of RESMPx falls into this domain, just as #68 , #63 , and friends.

• I think the issues uncovered by the code are, unsuprisingly, related to the interaction between RESMPx, decode / draw and HBLANK (there are special rules for a lot of things during HBLANK, and I have only a vague idea what is going on in actual hardware in those cases).

• @sa666666 I think that the code is fine, but it is exploring edge cases that are not correctly emulated anywhere atm. Again, this is the same category as e.g. my previous adjustments to NUSIZ changes during player draw

• Unfortunately, I am lousy at electronics (always was) and, as such, reading the schematics is not a viable option for me.

• I will look at these efects asap, and I am pretty sure they are fixable (and will be fixed). However, I should add that, after getting the core to where we currently are, I have arrived at the conviction that 100% accuracy in TIA emulation is impossible without a gate level simulation. With anything else, there will always be the odd edge cases that fails in emulation (to me, this is not a shortcoming per se, rather a compromise between accuracy, simplicity and performance).

[sa666666]

Thanks @DirtyHairy for looking into this, and of course for getting the TIA emulation to where it is now. I agree that the only way for guaranteed 100% emulation is a gate-level simulation, but I also think it can be mostly achieved if we take care of all the corner cases. There can't be an infinite number of them, can there??

[DirtyHairy]

:smile: I am pretty sure that the core is flexible enough to support all edge cases, but, as you say, we'll never be sure that we caught all of them. However, for the purpose of playing, analyzing, developing and debugging games, that's more than enough I guess :smirk: