Yeah, I think you're right there. Also I'm not sure if some of the sequential logic I've used is adding an extra cycle delay in some places (such as the edge detectors) where it makes a difference. Some of this code is still older implementations that work which I haven't got around to investigating whether it can be improved yet, due to a lack of time.ijor wrote:This is probably because you are missing some pipeline cycles between the shift array and the palette lookup. But note that there is no ideal model here. Some programs with Spectrum 512 effects don't work correctly on a real Shifter depending on the wakeup. Furthermore, there is some async behaviour that might even be non deterministic and affected by such things as the temperature.Smonson wrote:This is fairly stable now, so I'm sharing the verilog model that I'm using.
Spectrum 512 works as long as the pixel count initial value is changed from 4 to 2.
As you can tell from my long silence, I haven't been able to work on this for ages - that's because I unfortunately have a high-priority task that has been sucking up all my evenings for this whole calendar year. But for this week I'm on holidays from work and I've been indulging my hobbies a bit. Eventually the high-priority task will come to an end.
Thanks, I missed that one.ijor wrote:Ideally this should be cleared on RESET. Not sure if any program actually depends on this, but this is what SHIFTER does.
Code: Select all
resolution_register <= data;
Yeah, I've been ignoring that clock generation part due to a lack of knowledge. I will look into how to do this properly at some point. I've been hoping this message in the console means it's implementing the clocks the best possible way.ijor wrote: As we mentioned some time ago, it is not a very good idea to implement a clock mux like that. And it is not good practice to use the same signal as a clock and as data. The best method is to use the signal as clock enable, not directly as a clock. But if you insist, the FPGA has some dedicated hardware for clock muxing that you might be able to use.
I can infer from your code that you are not simulating the design. It is a bit of a PITA to perform simulations, but trust me, it is worth.
Code: Select all
Warning (19017): Found clock multiplexer shifter:shifter_model|pixel_clock
In place of simulations (another thing waiting on free time) I've been plotting the signals onscreen as the scanline proceeds, which looks like this:
It's a hack but it lets me see what's going on (light blue line is DE, next line is resolution register, then darkened video superimposed with LOAD (red bars) and reload (yellow bars), the red line under that is pixel_counter_enable I think, then lastly the pixel counter expressed as intensity). But you're right, I definitely need to learn how to do it properly.