Changes
/* On MiST-board CoreAmstrad version */
Games that doesn't run are :
*'''ACPC_logon_system.dsk''': text scrolling lag. This demo will be used for horizontal ink calibration (when I’ll buy a luxurious FPGA platform... I need in fact 224KB of internal RAM to do it), and CRTC overcounts.
*'''commando.dsk''': pixels that should be deleted are not deleted (only VRAM &C000-FFFF seems used), on level 1, the moto is not displayed correctly inside the bridge... but after the bridge :/
*'''split ink demo.dsk''': (from cpcrulez) : may help about ink raster calibration.
*'''Sultan's Maze.dsk''': does need the right part of keyboard (F0-F9 are used for directions in this game)
*'''Pinball_Dreams__PREVIEW.DSK''': Does run in experimental/ versions r005.8.9.2 and r005.9.11e (experimental forked version of r005.9.11 using flag FPGAmstrad_amstrad_motherboard.vhdl.HACK_Z80=false). Does freeze in !experimental versions when background music is special (not long classic background music) and you press two buttons (left/right flipper keys) at the same time, ok in r005.8.14 (using default OSD value : MEM_WR=quick). Scrolling text is OK in r005.8.16c4 but still one garbage line at top of main game (CRTC1 offset ?)
*'''Fres Fighter II Turbo.dsk''': FDC problem, cannot be launched.
*'''Seascape.dsk''': Devilmarkus, using scandb50Hz and MEM_wr=slow, does display, but a flower petal at bottom is drawn in blue. A good raster test.
'''Arkanoid.dsk''' stars use rupture address (changing address several time during display of one image), it is now supported on "candidate 001" version of FPGAmstrad. Run better in r005.9.11e than in r005.9.11.
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)
* '''jdva6.dsk''': no keyboard... [https://github.com/renaudhelias/RubikCubePaletteCPC/tree/master/JDVA%236_test JDVA#6 test]
== Effort done ==
In r005.8.16c29, arnoldemu testbench "cpctest" is OK (but it is a wip version :p)
==== GA: TODO : MODE row buffer ====
MODE does change at each begin of lines, not at begin of pixel drawn.
Il ne faudrait pas penser que l'on puisse changer de mode plusieurs fois par ligne. En effet. c'est "impossible"! (jusqu'à preuve du contraire, le mode s'enclenche à chaque synchro horizontale (HBL).
https://cpcrulez.fr/coding_logon35-le_gate_array.htm
=== Z80 ===
In order to get a better external RAM performance, and getting more luck about porting my project into others FPGA platform, I do now use a "Mirror VRAM" : external is just used by Z80 read and write (no more clock sequence finally ^^'). And a write in video RAM zone (like "poke &C000,255") does just write also in another parallel RAM, a FPGA internal RAM, that I call VRAM, this VRAM can be written at a certain speed and read at another for VGA purpose (FPGA internal RAM can be used like that)
=== USB joystick Joystick ===
Before learning final platform and its embedded controlers (USB joystick with a controler, is just 7 wires : left right up down buttonX buttonY buttonZ), and after having destroyed 12 collector original joysticks during tests... I did some research about simply connecting a modern USB joystick into FPGA. It was a part of my Agile Method run, I worked about two months on it.
http://www.ulule.com/usb-paf (unfunded) => but MiST-board final platform does offer USB pro competition Joystick compatibility <3 <3 <3
==== A fork of USB Joystick by The EMARD ====
A fork of this minimalistic USB Joystick controler by The EMARD, going further :
http://github.com/emard/fpga-usbhid-host
----
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)
