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 ==
You can power Amstrad CPC using extension port, applying 5v. By doing it, power down button of Amstrad doesn’t run. Using this way you reach a common 5v power between starter-kit and Amstrad. I connected wires from extension port directly to FPGA, as they are used just for listening.
==== GA: WAIT_n generator (WIP...) ====
Instruction timing.
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
----
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 ==
== Appendix ==
=== MiST-board special features ===
Bulk of effort done/TODO-list, especially for the MiST-board's CoreAmstrad implementation.
==== ROM and /RAM ======== ROM/RAM : extension ====
In r004, you have more RAM +512KB, and you can add ROMs.
In r005.4, I add another UpperROM set : .f00 to .fFF file extension (hexa). If you press "space" during a reset_key ("page up" key), upperROM files used range from .f00 to .fFF instead of ranging from .e00 to .eFF. LowerROM .eZZ file extension is still used in both case.
==== ROM/RAM: TODO : RAM 4MB extension ====
Why not ?
==== DONE : A advanced dsk drive VIDEO ====
In order to plug FPGAmstrad on TV, and help debugging. And also to test a simple scan-doubler.
r005 : VGA 60H/TV 50Hz.
==== DONE = VIDEO: an An OSD option to enable scan-doubler =====
scan-doubler (simple TV to VGA converter) doesn't run ok in mode 2, but there is some many recent demo effect that doesn't pass using current VGA 72Hz implementation. Have to try to insert both VGA implementations.
core_r005c18 seems having a scan-doubler output, have to merge it.
==== DONE = VIDEO: A SCART output with border =====
Original output signal has no border, I have to implement the original border in TV mode.
Done in r005.8.14.2
==== DONE = VIDEO: move SCART parameter into mist.ini =====
Doing like in other cores : do use the global "scandoubler" option in mist.ini to switch between VGA and TV mode.
==== DONE = VIDEO: mix SCART H and V sync into HV sync (sort of C sync) =====
[http://github.com/mist-devel/mist-binaries/issues/35 Amstrad CPC core · Issue #35 · mist-devel-mist-binaries · GitHub] :
SCART TVs expect a composite sync. The VGAs vsync is connected the SCART pin used to detect a RGB signal and is constantly driven high. A TV will not cope with a video signal with separate H and V sync.
Done in r005.8.14.1
==== DONE = VIDEO: refactor of Parrot PAL signal =====
I found a running 15kHz TV, with [http://github.com/mist-devel/mist-board/blob/master/tutorials/soc/lesson11/lesson11.png mist-board tutorial lesson11 Parrot PAL] running fine, but not with CoreAmstrad r005.8.14.1. It's the same TV I used some years ago at festival with original CPC. I have to refactor Parrot tutorial and adapt it on CoreAmstrad in order to generate a better TV signal quality.
Test about centering screen are done using "BORDER 0", this way border is ignored and does interact with HSYNC/VSYNC screen synchronisation.
==== DONE = VIDEO: CRTC1 =====
r004.8 : a better CRTC/Gateway implementation, following better JEmu (JavaCPC) one... but it is a CRTC1 (but a better ONE)
Some bugs came from PPI also (keyboard bugs in particular), solved in r004.8
==== DONE = VIDEO: CRTC1 detection =====
I don't remember exactly, but in r005.8.4, one of "Midline Process"/"From Scratch"/"Pheelone" demo does crash due to a "CRTC1 needed" message : my CRTC1 seems not detected as a true CRTC1... If's "From Scratch" that does display this message in fact.
[http://quasar.cpcscene.net/doku.php?id=coding:test_crtc Test CRTC - Quasar Net]
==== = VIDEO: TODO : Interlaced scanlines =====
Interlaced scanline is an effect existing in CRTC (register R8) used by Wolfenstrad demo
L'écran passe en 100Hz, les registres 4 et 7 doivent être doublés pour retomber sur 50Hz
==== DONE = VIDEO: Scanlines =====
Here effect is about simulating CRT (not CRTC.R8) original screen. There is several way to implement it.
Here, truly one line out of two is 1/2 darker. By visual effect this result in "a thin full black horizontal line".
[[File:FGPAmstrad cc withScanlines.png|thumbnail]]
==== DONE = VIDEO: Monochrome option =====
Add an option to turn screen into green monochrome mode (in mode TV and in mode VGA)
[http://cpc.sylvestre.org/technique/technique_coul1.html Les Sucres en Morceaux - Couleurs - 1 - Les couleurs du CPC]
==== DONE = VIDEO: Monochrome OSD =====
Could be great having the OSD in monochrome when monochrome is selected and scanlined when scanline is selected
Done in r005.8.14.4
==== = VIDEO: TODO : Scanline during monochrome + scandb50Hz modes =====
soleil vert demo display result is best using scandb50Hz mode (r005.8.16c29) because it does alternate two pictures at 25Hz, seeming then like a fixed image for humans.
But my scandb50Hz option does not enable yet the scanline effect that could improve her agains this demo. To do.
==== TODO : Ethernet ====Integration of "ethernec.v". Several multiplayer games using several CPC does already exists VIDEO: [[Virtual_Net_96]]. ==== TODO : AMX mouse support ====Asked by KLNHOMEALONE. ==== TODO : tapes ====Do read .CDT files also. I think @ralferoo had already written FPGA code for tape reading for his FPGA CPC. Maybe you can borrow some code from him? Bryce. ==== DONE BUT SEEMS USELESS : welcome VGA signal =====
While bootloader is not fully started, do display a lighter screen output (not darker pixels as original screen color CPC depth using more resistors), as it VGA should be nicely centered at each boot. And then after come back to original CPC pixel depth.
This solution does not fix the problem of "stupid screen", but reveals something interesting about the defect (next chapter)
==== = VIDEO: TODO : SAMSUNG 16/9 tests =====
Using lighter pixels full white screen during bootload show me that screen doubts between two positions : a perfect centered 4/3 with 6.5 centimeters horizontal border each; and a starting 16/9 at left, crop at 6.5 centimeters left.
* a second time image does move perfectly (completely/totally) left and right without crop, and if centered has 6.5 black border left and right. This time image seems complete but crushed.
During ZX-Uno merged, I found two bug on VGA implementations (true ones ?), first being horizontal and vertical counter not reaching VTot/HTot (one clock tic missing), and second the horizontal counter limited to 1024 not reaching HTot that seems more than 1024. Perhaps, if this bugs are valided as it, do go back on original 800x600@72Hz modeline formula. ==== DSK ==== ===== DSK: A advanced dsk drive ===== Done on r004, I added also a second Drive in order to copy easily files from one disk to another. Irregular sector size ok. You just have to select Drive A or B from OSD before selecting another dsk file. Write is done directly on sdcard dsk file, so you can save games, and write texts... You can now change disk without reset. And then play games using several disks. [http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/fdc-floppy-t80ds-detection/ CPCWiki forum - Amstrad CPC hardware - FDC floppy t80ds detection] : talk about FDC in MiST-board CoreAmstrad. Since r004 "mecashark", the FDC implementation has write access ! ===== DSK: TODO : SNAP DSK =====Add an option in OSD MENU : "SNAP DSK". Does create a copy of current disk in current drive into "SNAP[number].DSK". Heuristic for number : file count (at boot, incremented at each snap dsk done) ===== DSK: TODO : fix message "This program will not run in this environment. Press any key" =====HartOz The core does not support the bundled CP/M+ software. With a valid working CP/M+ Disc1 image mounted, the systems returns with the following message after issuing the |cpm command. "This program will not run in this environment. Press any key"Due to using wrong language version of CP/M+ disc (cpmpluf1.dsk is french version of CP/M+)[[File:Cpmpluf1.dsk.png|thumbnail|CP/M+ fr disk inserted (cpmpluf1.dsk)]] "Wrong disk for your configuration" message seen in one-disk version of "Batman Forever" demo (two separate disk version runs fine), in forum they say that dsk image is using "bad track numbers", in fact when looking at a Track-Info with side 1 (instead of 0), track and side are correct in Track-Info but side is not ok in Sector-Info, normaly track/side are ignored in Sector-Info (Track-Info is used for that)... but still having the message, something else seems also wrong. Do fix also message "Bad Command" while running a not existing file on disk. Certainly linked to ''Orion Primes.dsk'' loading problem. ===== DSK: TODO : tapes =====Do read .CDT files also. I think @ralferoo had already written FPGA code for tape reading for his FPGA CPC. Maybe you can borrow some code from him? Bryce. ===== DSK: TODO : snapshoot purpose =====
Like in emulators, do something to go back in time while running a game.
==== Transmit ====
Could be nice around cross-dev.
===== Transmit: TODO : Ethernet =====
Integration of "ethernec.v".
Several multiplayer games using several CPC does already exists : [[Virtual_Net_96]].
==== X/Y ====
===== X/Y: TODO : A X/Y input =====
I want to work also on screen-pen entry, is there a manner to detect an analog X/Y as pen or gun ? YES : [http://java.cpc-live.com/gx4000.php Markus Hohmann] does it, he implements the lightgun on JavaCPC-GX4000 using mouse :)
http://cpcrulez.fr/hardware-pistolet-magnum_light_phaser_ACPC.htm
register 11,12 and 13 ?
==== X/Y: TODO : AMX mouse support ====
Asked by KLNHOMEALONE.
=== Others tricks ===
