boulder dash: music stops after a while

[jotego]

If you let the attract demo run for a while, the music will stop and not resume. Reported on Discord by breiztiger.

[jotego]

Ran a very long sim: jtsim -setname bouldash -video 50000. The output .wav file lasts for 14'31''. At 13'7", the music first starts running faster and from 13'9" the sound gets broken producing continuous noise for the rest of the simulation. The sim took 1989'27" to run, that's about 33 hours. The video output seems normal. The problems seems to happen only in the sound subsystem.

The starting frame for the problem is ~45178. It should be enough to simulate until 13'15" or 45637 frames to capture the glitch.

bouldash.mp3.zip

[jotego]

Gating the CPU clock in a different way does not fix it:

diff --git a/cores/slyspy/hdl/jtslyspy_snd.v b/cores/slyspy/hdl/jtslyspy_snd.v
index 71db77fa..b84ec054 100644
--- a/cores/slyspy/hdl/jtslyspy_snd.v
+++ b/cores/slyspy/hdl/jtslyspy_snd.v
@@ -74,7 +74,7 @@ always @(posedge clk) begin
 end

 always @(negedge clk) begin
-    hu_cen <= cencnt==0;
+    hu_cen <= cencnt==0 && rom_good;
 end

 assign irqn     = opn_irqn & opl_irqn;
@@ -186,7 +186,8 @@ jtframe_ram #(.AW(11)) u_ram( // only 2kB
 HUC6280 u_huc(
     .CLK        ( hu_clk    ),
     .RST_N      ( ~rst      ),
-    .WAIT_N     ( rom_good  ),
+    // .WAIT_N     ( rom_good  ),
+    .WAIT_N     ( 1'b1      ),
     .SX         ( SX        ),

     .A          ( A         ),

[jotego]

The OPL interruption stops happening right before the sound breaks

[jotego]

The last interrupt occurs write when the CPU is about to write to the OPL. It could be that the interruption affects the value or address to be written to the OPL.

[jotego]

Increasing the HuCPU speed solves the problem. Not sure whether the reason is the lack of clock recovery in this module or that the CPU speed was wrong to start with. Fixed in abd37000