Changes
/* Why I destroyed the PPL */
else b"1111" when RAMbank="111" and (A(15)='0' and A(14)='1')
else b"10" & A(15 downto 14); -- default value
* '''Ghouls'n'Ghost.dsk''': black screen during game. RAM is not relaxed enought to permit changing address just after knowing if Z80 does a read or a write (ROM written=> does write on RAM hidden behind)
== Effort done ==
A schematic developed in order to be comparable to original documentation schematic is nice. FPGAmstrad is composed of 3 schematics :
* amstrad_motherboard : comparable to original Amstrad schematic.
* amstrad_video : does manage a true VGA output, using a an internal VRAM.
* bootloader_sd : sdcard bootloader, in order to load ROM and dsk at boot, from sdcard.
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 lines 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 Time Constraints, no more problems around". 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 of hour to compile now ! and on a determinist way.
This formula does run also on bus (dsk_info bus wire coming from SDRAM_FAT32_LOADER to simple_DSK)
=== Internal FPGA RAM (VRAM) config ===
The internal dual RAM (written at 4MHz by Z80 and readden at 25MHz by VGA) are configured as "WRITE FIRST", "READ DOESN'T CARE".
aZRaEL_vram2vgaAmstradMiaow.vhd (the VRAM to VGA output part) has several manual counter offset calibrations, called "bug_*", it seems this component does not know counting right when reaching 25MHz (in fact it is, "mod" instruction does suffer a lot by here)
=== palette_D and aZRaEL's counters derailment ===
Compiler does detect when somes wires of a bus are not used, and when this bus is scanned by several counter derailing it results some data missing (this pixels normaly come from this offset, but is finaly calibred at this offset, so I plug it here and compiler does not thrust me, saying it's plug to an unused wire so does compile all that to GND... black screen)
Solution : using all wires of palette_D, taking care the compiler does not remove an "useless" wire from bus, and do calibrate manualy the derailing counters (all that "bug_*" constants inside aZRaEL_vram2vgaAmstradMiaow.vhd)
== Source code ==
