[outrun] frame buffer

[jotego]

Add frame buffer to sprites to match the 1-frame delay in the original board and to reduce MiSTer's clock to 50MHz. Work in progress in https://github.com/jotego/jtframe/tree/frame_buffer

• [x] Design buffer logic
• [x] Simulation test in game module
• [x] Adapt to Pocket
• [x] Test in Pocket
• [x] Adapt to MiSTer
• [x] Test in MiSTer
• [x] Modify core to operate at 50MHz and use the buffer in Pocket & MiSTer

[jotego]

Both the MiSTer and the Pocket are not behaving as expected.

MiSTer

The DDR never seems to reply to the read and write commands. The busy signal seems dead. At one point, I saw activity when I changed the DDR base address. But I wasn't able to replicate it.

Pocket The PSRAM does not toggle the wait pin.

[jotego]

Pocket frame buffer works in dccca509. The wait pin didn't toggle because the PSRAM configuration must be done in asynchronous mode first

[jotego]

In MiSTer the DDR memory seems to be delivering data at half the clock rate. When the burst is set to 8'h40, it runs for 8'h80 clock cycles:

[jotego]

Requesting a read (ddr_rd=1) may not toggle the DDR busy signal, taking ddr_rd down after 1-2 cycles seem to result in the DDR not getting the command as data never gets to the core:

[jotego]

mister: The lfbuf_ddr_ctrl module set to perform only DDR writes never enters a dead lock situation. The DDR busy signal is always low and there is no other signal which could lock the system.

The write signal must be held high during the whole read transaction as long as data is valid

So write must be high for the clock cycles set by the burst count.

Setting the module to perform only reads will eventually lock it.

[jotego]

Experimenting with the ddrtest module shows that the DDR is responsive and data transfer works ok. So there is something else in the frame-buffer control logic that hangs up the system.

Other findings:

• A lot of the memory space is used by Linux. Not clear where but writting in many places will hang up MiSTer badly
• According to ddram.sv in the NeoGeo repo, the address range with 4-MSBs set to 4'd3 is safe to use. Testing in ddrtest did not crash MiSTer
• The bus range addr[28:0] is actually addr[31:3] if read in byte addressing
• If the DDR controller gets stuck, it is necessary to power cycle the MiSTer before the next trial
• Reloading the core will hang up the DDR controller

[jotego]

mister timings from DDR controller to the frame-buffer module are completely broken if clk_rom != 48MHz

[jotego]

MiSTer data through the DDR seems fine in 6454f20 but the game does not show any objects. Testing the pocket version again, it does not show objects either. Going back to version dccca5093, pocket works ok. It isn't clear what changed for both Pocket and MiSTer to not show objects. It could be

• the change in the line buffers to enable BRAM synthesis
• a change in the jtframe command
• JTFRAME_CLK48 missing in macros.def

It's likely that the MiSTer version will work once the Pocket version is restored.

[jotego]

Setting jtcores to dccca50 and moving JTFRAME to https://github.com/jotego/jtframe/commit/5167b54e3179deaba387f30e781bd68101b60ffa breaks it. That's just three commits on top of the working one for JTFRAME

[jotego]

The changes between the different JTFRAME commits don't justify that the objects stopped being displayed on the Pocket. It looks like the problem is that the PSRAM may not be starting up correctly every time so depending on compilation nuances the start up timing is different. Or may be it is a PSRAM clock phase issue.

[jotego]

The time constraints were wrong for the CRAM in the Pocket. Fixing this brings the objects back to life, even in https://github.com/jotego/jtframe/commit/5167b54e3179deaba387f30e781bd68101b60ffa

set_output_delay -clock cram0_clk -max 3 \
    [get_ports {cram0_a[*] cram0_dq[*] cram0_adv_n cram0_cre \
                cram0_oe_n cram0_we_n \
                cram0_ub_n cram0_lb_n }]

set_output_delay -clock cram0_clk -max 4 \
    [get_ports {cram0_ce0_n cram0_ce1_n  }]

set_output_delay -clock cram0_clk -min -2 \
    [get_ports {cram0_a[*] cram0_dq[*] cram0_adv_n cram0_cre \
                cram0_ce0_n cram0_ce1_n cram0_oe_n cram0_we_n \
                cram0_ub_n cram0_lb_n }]

[jotego]

The constraints don't fix the timing completely. Compiling afb08e35 without sound has sprites, compiling it with sound results in no sprites. So timing doesn't seem right and is not well captured with the constraints above.

[jotego]

Tighter constraints made it work with sound in the Pocket b0f01d5a

# CRAM0
set_output_delay -clock cram0_clk -max 4 \
    [get_ports {cram0_a[*] cram0_dq[*] cram0_adv_n cram0_cre \
                cram0_oe_n cram0_we_n \
                cram0_ub_n cram0_lb_n }]

set_output_delay -clock cram0_clk -max 4 \
    [get_ports {cram0_ce0_n cram0_ce1_n  }]

set_output_delay -clock cram0_clk -min -4 \
    [get_ports {cram0_a[*] cram0_dq[*] cram0_adv_n cram0_cre \
                cram0_ce0_n cram0_ce1_n cram0_oe_n cram0_we_n \
                cram0_ub_n cram0_lb_n }]

[jotego]

Works in MiSTer in 05e60dd8 if compiled without JTFRAME_PLL=jtframe_pll6293

[jotego]

Works even with the SEGA PLL after some adjustments in jotego/jtframe@421346b