Now I can use my 16KB free RAM in VRAM double buffer. Reaching a full FGPAmstrad project deploy on MiST-board, unlocking others games : it is what is done in realise 002 of Amstrad core. I tested ChaseHQ does now run fine.
== ZX-Uno - Core Developer's Notes ==
=== Why I destroyed the PPL ===
NEXYS2's FPGAmstrad version is using a PPL (a DCM : Digital Clock Manager), just for half part of clocks generation.
Then comes the sequencer (the counter used to divise time) that does not respect "Timing Contraints good practice", forcing then adding a "I dislike good pratice" sentence on .ucf file like that :
IN "XLXI_512/XLXI_579/COUNT_1_BUFG.O" CLOCK_DEDICATED_ROUTE = FALSE;
Having half of clocks generated by a PPL results on a project running fine one time on both compilation : you add some normal line of code, and then you toss a coin.
Then I tryed, as on MiST-board version to manage all clocks from an unique PPL (good practice !), centering all clocks on one component, removing counter and also all logical "NOT" on clocks wires (good practice !), resulting then... in a electronic circuit that does not enter inside my FPGA chip. Damn.
So I go back to dark side, removing PPL. Recalibrating all clocks (this time "rising_edge against falling_edge" instead of "same edges" per component's process), and thinking "no more problems around Time Constraints". And you know what ? I got that :
WARNING:Route:464 - The router has detected a very dense, congested design. It is extremely unlikely the router will be able to finish the
design and meet your timing requirements. To prevent excessive run time the router will change strategy. The router will now work to
completely route this design but not to improve timing. This behavior will allow you to use the Static Timing Report and FPGA Editor to
isolate the paths with timing problems. The cause of this behavior is either overly difficult constraints, or issues with the
implementation or synthesis of logic in the critical timing path. If you are willing to accept a long run time, set the option "-xe c" to
override the present behavior.
Intermediate status: 929 unrouted; REAL time: 3 hrs 35 secs
Damn, 3 hrs 35 secs of compiling... Then I used my brain and think that it is trying to stupidly clocking my "reset_key" wired between my keyboard clock and my bootloader clock... so I had this set of instructions inside SDRAM_FAT32_LOADER.vhd :
attribute keep : string;
attribute keep of key_reset : signal is "TRUE";
attribute clock_signal : string;
attribute clock_signal of key_reset : signal is "NO";
And tadam, less than half a hour to compile now !
== Source code ==