You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How feasible would it to be to update a region of memory accessible from the HPS every time a core generates vblank?
It could be implemented as a simple counter that is incremented with every vblank and rolls over if it overflows. This would provide the HPS side with a timer that self adjusts to the core's speed.
As an example: autofire could be rewritten to simply trigger every x frames. The input loop would check the assigned memory address and if the value changes, it knows it's a new frame and acts accordingly. The need to check the system clock would be removed and the resulting code would be more maintainable.
I am willing to rewrite the existing autofire code in input.cpp to take advantage of this if it was implemented. I've mocked up a version that tries to calculate frame counts based on video timings from video.cpp but I know that's probably not a good way to do it.
I can't personally think of other uses but any HPS code that would benefit from synchronizing with the core's video output would have a much easier pathway to do it.
I've not touched vhdl/verilog since college or I'd submit a sample implementation myself. If this is a reasonable feature but out prioritized by other issues I may take a stab at it myself as a learning exercise.
The text was updated successfully, but these errors were encountered:
Writing to memory from FPGA is very costly operation. It's impossible to write like in normal computer. You have to reserve a time on memory bus and then write it my some module.
So, I don't see a reason to waste so much resources for autofire which is already working fine.
Since the hdmi_config stuff was moved to Main_MiSTer isn't the vblank already captured on the ARM/HPS side, or is that just an approximation based on the pixel clock and other factors?
How feasible would it to be to update a region of memory accessible from the HPS every time a core generates vblank?
It could be implemented as a simple counter that is incremented with every vblank and rolls over if it overflows. This would provide the HPS side with a timer that self adjusts to the core's speed.
As an example: autofire could be rewritten to simply trigger every x frames. The input loop would check the assigned memory address and if the value changes, it knows it's a new frame and acts accordingly. The need to check the system clock would be removed and the resulting code would be more maintainable.
I am willing to rewrite the existing autofire code in input.cpp to take advantage of this if it was implemented. I've mocked up a version that tries to calculate frame counts based on video timings from video.cpp but I know that's probably not a good way to do it.
I can't personally think of other uses but any HPS code that would benefit from synchronizing with the core's video output would have a much easier pathway to do it.
I've not touched vhdl/verilog since college or I'd submit a sample implementation myself. If this is a reasonable feature but out prioritized by other issues I may take a stab at it myself as a learning exercise.
The text was updated successfully, but these errors were encountered: