CPS1: Street Fighter 2 Hyper Fighting runs too fast

[icypottle586]

Hi,

Street Fighter 2 Hyper Fighting runs way too fast. References videos:

https://www.youtube.com/watch?v=UUTSosokEDk
https://www.youtube.com/watch?v=2nJiMnxXYVA (indicates 210131 build was basically perfect)

jtcps1.rbf of 3/17/2024 takes roughly 47s range to finish (like the MAME-rr in one of those 2 videos). That's way too fast.

I grabbed a random older version from last year:
https://github.com/jotego/jtbin/blob/b1f9fe2f0f5269e7106aca49eea67364fbc2e1b2/mister/cps1/releases/jtcps1.rbf

This takes roughly 51s or so, still seems a bit too fast compared to what those 2 videos indicate.

[HabbleFox]

If it helps as an additional reference, 2 years ago I made a comparison video for the speedrun community based on the core versions we had on MiSTer at the time. https://youtu.be/DvIe35lBntU

[icypottle586]

Hi @jotego , I see you tagged it as question, do you need more information from me about this?

[jotego]

Thank you but it is a question for me. I do not mark items as bugs until I have checked them.

[real-amano]

I think that SF2 Turbo was always a conversion of other SF2 boards. Might the speed possibly vary depending on the board hardware that was converted?

[jotego]

Using the test Grego2d built a long time ago (sf2eb_dma_tests_no_b3.mra), the speed we are getting is:

Commit	speed (hex)	Date
4f7da4b	3596	May '24
ea01437	3596	Nov '23

The result should be 2C00, as measured in the PCB.

The whole core, not just SF2HF, has been running ~20% too fast for the last six months. This is probably related to changes in the jtframe_68kdtack module.

[jotego]

This patch restores the speed:

--- a/modules/jtframe/hdl/cpu/jtframe_68kdtack_cen.v
+++ b/modules/jtframe/hdl/cpu/jtframe_68kdtack_cen.v
@@ -77,12 +77,12 @@ module jtframe_68kdtack_cen
 localparam CW=W+WD;
 
 reg [CW-1:0] cencnt=0;
-reg  [1:0]   waitsh;
+reg  [2:0]   waitsh;
 wire         halt;
 wire [W-1:0] num2 = { num, 1'b0 }; // num x 2
 wire over = cencnt>den-num2;
 reg  [CW:0] cencnt_nx=0;
-reg         risefall=0, wait1;
+reg         risefall=0;
 
 `ifdef SIMULATION
     // This is needed to prevent X's at the start of simulation
@@ -93,25 +93,22 @@ reg         risefall=0, wait1;
     wire rstl=0;
 `endif
 
-assign halt = !rstl && RECOVERY==1 && !ASn && {waitsh,wait1}==0 && (bus_cs && bus_busy && !bus_legit);
+assign halt = !rstl && RECOVERY==1 && !ASn && waitsh==0 && (bus_cs && bus_busy && !bus_legit);
 
 
 always @(posedge clk) begin : dtack_gen
     if( rst ) begin
         DTACKn <= 1;
         waitsh <= 0;
-        wait1  <= 0;
     end else begin
         if( ASn | &DSn ) begin // DSn is needed for read-modify-write cycles
                // performed on the SDRAM. Just checking the DSn rising edge
                // is not enough on Rastan
             DTACKn <= 1;
-            wait1  <= 1; // gives a clock cycle to bus_busy to toggle
-            waitsh <= {wait3,wait2};
-        end else if( !ASn ) begin
-            wait1 <= 0;
-            if( cpu_cen ) waitsh <= waitsh>>1;
-            if( waitsh==0 && !wait1 ) begin
+            waitsh <= {wait3,wait2,1'b1};
+        end else if( !ASn && cpu_cen ) begin
+            waitsh <= waitsh>>1;
+            if( waitsh==0 ) begin
                 DTACKn <= DTACKn && bus_cs && bus_busy;
             end
         end

Needs to check that it does not break Dynamite Dux, Shinobi or Chelnov

[jotego]

Fixed without altering other M68000 cores. CPS1 needs to always wait for a positive CPU cen, whereas System 16 does not. Schematics are always a bit tricky to follow around the DTACK signal and because the dtack module is common to all M68000 cores, it requires a lot of attention to configuring it correctly.

The files will get out on the next JTFRIDAY.

[icypottle586]

awesome news! thank you so much @jotego !!!