Changes
/* Why I destroyed the PPL */
===On ZX-Uno FPGAmstrad version===
Games that doesn't run are :
* '''adios_a_la_casta.dsk''': bad sound. Does pass hacking memory banks this way :
else b"1100" when RAMbank="100" and (A(15)='0' and A(14)='1')
else b"1101" when RAMbank="101" and (A(15)='0' and A(14)='1')
else b"1111" when RAMbank="111" and (A(15)='0' and A(14)='1')
else b"10" & A(15 downto 14); -- default value
== Effort done ==
=== VGA ===
Pixels and VRAM. Palette and rasters. CRTC0
==== VGA: CRTC0 ====
CRTC0 seems the best one, some demo does cry when detecting a poor CRTC1 (CRTC1 seem a low cost version of CRTC0). I have to implement a CRTC0 instead of my current CRTC1...
In fact CRTC1 is the best one. CRTC2 is the low cost version. CRTC0 did appears before CRTC1.
Some demos are running only on CRTC0 and others CRTC1.
Done in r005.8.14. Detected as CRTC0 by WakeUp! - "Enjoy the show" message displayed.
In r005.8.15. WakeUp! (CRTC0/MEM_wr quick) detected as Emu first time, and after a quick reset, does say detected as CRTC0.
In ZX-Uno FPGAmstrad, I implemented CRTC0.
==== VGA: VRAM ====
ram_palette.
VRAM contains 800x300 amstrad pixels (VZoom x2), displayed VGA 800x600@72Hz with fix regular border at 768×576 and fix inside border at 768×544.
In ZX-Uno, VRAM contains 800x300 amstrad pixels (VZoom x2), displayed 640x480@60Hz, with vertical only border.
* simple_GateArrayInterrupt.vhd (GA to VRAM) parameters : VRAM_Hoffset/VRAM_Voffset
* aZRaEL_vram2vgaAmstradMiaow.vhd (VRAM to VGA) parameters : H_BEGIN/H_END/V_BEGIN/V_END (theorical fixed values)
To calibrate : VRAM_Hoffset++ does offset one char left. VRAM_Voffset++ does offset one line up. On display H_BEGIN does begin to scan lines of VRAM. But V_BEGIN does not enter in consideration here : vertical=0 does begin to scan columns of VRAM.
In original CPC, top border has 1/2 char more than bottom border. I used Batman Forever default welcome/calibration screen to calibrate VRAM offsets. On ZX-Uno I used Arkanoid to calibrate VRAM offsets.
RAM_palette contains the ink list and the mode for each line of VRAM, sampled at horizontal middle of 800x600 screen, and used at begin of each line.
==== VGA: TODO : arnoldemu testbench ====
'''arnoldemu testbench: crtctest'''
Adding choice of CRTC 0 or 1 on OSD, and passing this test could be great.
==== VGA: TODO : winape testbench ====
'''winape testbench: plustest'''
a better border heuristic
Using winape testbench (plustest), test 2 does show somes problems while border does go out of screen, negative border does hide line itself.
=== bootloader ===
SDCARD and RAM.
(nothing to say here, really ???)
=== GA ===
==== GA: alignment of HSYNC Interrupt ====
Interrupt are respected since version "candidate 001" of FPGAmstrad, Markus does help me a lot about it.
[[File:JavaCPC_running_norecess.jpg]]
JavaCPC running norecess's "using-interrupts" code [[http://norecess.cpcscene.net/using-interrupts.html]]
It could be interesting to test this asm code on next version of FPGAmstrad.
==== GA: Sniffing of a real Amstrad ====
[[File: cpc_plus_m1.jpg]]
Code name: Raptor
I listen to some wires of my Amstrad CPC 6128 plus, but I can't access VSYNC/HSYNC output of CRTC, so I have to buy another model in order to do this test. In fact you can listen at clock of Amstrad and transmit it to FPGA DCM component, resulting a accelerated clock sequence, that's it, with FPGA DCM you can overclock output Amstrad clock signal in order to insert more operations, I use this tip for listening signals and save them inside starter kit asynchronous RAM (write, stop write, write, stop write... I’m a perfectionist paranoid...)
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.
I tested instruction timing of [[T80]] compare to instruction timing of JavaCPC emulator. I deduce synchronization of Z80 with CRTC on M1 signal by WAIT_n insertion in order to have a multiple of 4 Tstates per instruction. I deduce also one WAIT_n inserted during MEM_WR operation (yes I log testbench [[T80]], I’m crazy)
I just made a test bench log of [[T80]] (log of instruction's M1, and first M1 coming after knowing that I send a lot of NOP after my instruction), and compare it to a JavaCPC timing array. Some instructions was not tested (interrupt wait, and special timing (instructions with change timing)), but all others passed correctly.
==== Instruction timing GA: WAIT_n generator - currently in r008.5.14 ====
In GA, I do use begin of edge for IO_ACK instead of state.
MEM_WR has an OSD menu choice to switch between "quick" and "slow", "slow" mode does insert ONE WAIT_n during detection of MEM_WR. This switch exists because somes games are running in "slow" mode and others in "quick" mode.
==== Instruction timing GA: WAIT_n generator - talk about r008.5.14 ====
In fact it exists several instruction making MEM_wr, and adding each one ONE WAIT_n does result in different case of synchronization.
[http://www.cpcwiki.eu/forum/programming/cpc-z80-commands-and-how-long-they-take/40/ CPC Z80 Commands and how long they take...]
==== Instruction timing GA: WAIT_n generator - talk about r005.8.16c4 ====
In r005.8.16c3, I remark that WAIT_n are badly introduced following plustest.dsk testbench (WinAPE). I corrected a T80 parameter firing the WRITE action 1 clock before. That unlocks 32 instructions timing in plustest.dsk testbench .
During this work, I remark an instruction that seems badly classified on plustest.dsk : 2A LD HL, (nn). This instruction does not use MEM_WR and is not a 5T M1 instruction. So it shall be using 4 NOPs instead of 5 NOPs. LD (nn), HL does take 5 NOPs (because it does use MEM_WR instruction), as in plustest.dsk testbench here for this instruction.
===== GA: WAIT_n generator - Tests on real CPC (by DanyPPC) =====
[http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/need-plustest-dsk-testbench-5-output-on-original-cpc-6128/ CPCWiki's forum : Need plustest.dsk testbench 5 output on original CPC 6128]
About testbench border effects, I think that IO_ACKed instructions has to be under same rules (MEM_wr, modulo 4 etc) - update : same result in testbench using this way.
==== Instruction timing GA: WAIT_n generator - talk about r005.8.16c20 ====
Instruction timing seems all respected following plustest.dsk, but I think it isn't enough, so it's still a candidate version.
Have to check also the moment IO_ACK is taken into account during M1 signal (I think it's at begin of it, but have to re-check that)
===== GA: WAIT_n generator - RET cc and WAIT_n timing analysis =====
Normaly, without WAIT_n generator (even modulo 4), NOP should take 1 M-cycles and 4 T-states, so this instruction should pass using plustest.dsk at 0x00. Does fail here (my approach is incorrect)
ralferro explains also that stretching instruction timing depends of memory used or not by instruction. I know that Amstrad schematics does not use the MEM_WR wire. So it could be hard to deduce if they added 1 or more WAIT_n for certain instructions. But I'm more about 1 WAIT_n inserted at maximum each time (it's more easy to hard implements), and the modulo 4 synchro, let's see results of my current experiment (comparing time instruction of Z80 and plustest.dsk testbench, deducing diff table of "slowing down instructions") wip.
==== Instruction timing GA: WAIT_n generator - talk about r005.8.16c29 ====
This version does implements correctly a theorical WAIT_n generator : I used a script comparing Z80 doc timings to plustest.dsk testbench result on real CPC, I deduce that inserting each time 2 WAIT_n does the stuff (that will my first approach), I saw also that first set of instruction timing is fully covered by Z80 doc, so plustest.dsk testbench failing on this part is not due to table slowing down instruction timing (WAIT_n generator's table of slowing down instruction timing), this isntructioon have to be slowed somewhere else : perhaps a bug inside Z80 itself or else the equation NOP/HALT/ACK to review, instructions concerned here seems all about "JUMP" except two instruction (a LD and an EX), in past I did already tested Z80 instruction timing themself and found no problem this way.
|}
===== GA: WAIT_n generator - plustest.asm =====
About 22 pages of source code using 3 columns per page.
.stdinst
(CPC Timing array (first instruction set))
=== Test = GA: TODO : arnoldemu testbench ===='''arnoldemu testbench: cpctest''' [http://www.cpcwiki.eu/forum/emulators/amstrad-cpc-%27acid%27-test/ forum : amstrad cpc "acid" test] => ''I have uploaded updated tests : [http://cpctech.cpc-live.com/test.zip http://cpctech.cpc-live.com/test.zip]'' Tests done here : ppi/psg/cpctest. [[File:arnoldemu_testbench_CPCTEST-r005-6.png]] In r005.6, I reach successfully some arnoldemu tests to calibrate more efficiently HSYNC interrupt : ppi.bin, psg.bin, cpctest.bin. Games unlocked by r005.6 : Sigma7, Pac-land, Golden Tail. In r005.8, Prehistorik is running fine. In r005.8.4, arnoldemu testbench "cpctest" does fail :/ In r005.8.7, arnoldemu testbench "cpctest" is OK In r005.8.14 version, using default mode "MEM_wr:quick", is OK. And Prehistorik II is running fine. In r005.8.16c29, arnoldemu testbench "cpctest" is OK (but it is a wip version :p) === Z80 ===Architecture of Z80. ==== Z80: test of a real Zilog 80 ====
[[File:Z80fx2bb.jpg]]
Code name : Z80fx2bb, real Z80@2MHz (instead of 4MHz) on fx2bb extension card.
In fact the only difference between [[T80]] of opencore and real Z80 is that [[T80]] runs on rising_edge, and Z80 runs during low state. Test past with little modification of sequencer forcing it to do nothing during low state of z80, resulting a downclock (memory is too overclocked with this sequencer modification), perhaps using buffer on address bus and data bus could solve this detail... but as it runs for me it is not a problem.
==== TODO : Z80 testbench ==== [http://www.cpc-power.com/index.php?page=detail&num=12883 CPC-Power Z80 FULL TEST (UK) (2012) - UTILITAIRE] Some errors detected in r005.8.4 (test done by Philippe D.) [http://www.winape.net/download/plustest.zip WinAPE plustest.zip (including Instruction and Interrupt timing tests)] ===== Z80 architecture =========== a) T80.vhdl ======
17 pages of source codes to read.
Contains T80_ALU.vhdl and T80_MCode.vhdl components.
6 pages of source codes to read.
[[http://www.z80.info/decoding.htm § Disassembly tables]] shall make a cool ALU_Op quick reference card, doesn't it ?
First 5 pages, and last 2 pages of source codes to read. Others pages are "always the same" architectually speaking.
Inc_WZ register : take a look at [[http://www.righto.com/2014/10/how-z80s-registers-are-implemented-down.html § The WZ temporary registers]. It's a tmp internal register in fact.
===== Z80: Some bad instruction timing analysis =====
Based on [[http://www.winape.net/ WinAPE>download>Plus test>plustest.dsk]] testbench, mapped using [[http://clrhome.org/table/ Z80 instruction set - ClrHome]], instruction described then in [[http://www.zilog.com/docs/z80/um0080.pdf Z80 doc]], against [[http://www.winape.net/ WinAPE]] passing testbench timing.
{| class="wikitable"
[[File:FPGAmstrad plustest5 r005.8.16c6 part2.png|thumbnail|FPGAmstrad_plustest5_r005.8.16c6_part2]]
===== Z80: Some bad instruction analysis =====
Based on [[https://cpcrulez.fr/applications_CPM-util-zexall.htm Zexall: Z80 instruction set exerciser]], running fine in JavaCPC.
====== Z80: ED A9 cpd(r) / ED A1 cpi(r) ======
Problem here : CPDR and CPIR has same implementation than CPD and CPI.
=== Alignment of HSYNC Interrupt = Z80: TODO : cpc-power testbench ====Interrupt are respected since version "candidate 001" of FPGAmstrad.
[[Filehttp:JavaCPC_running_norecess//www.jpg]cpc-power.com/index.php?page=detail&num=12883 CPC-Power Z80 FULL TEST (UK) (2012) - UTILITAIRE]
In first version of FPGAmstrad (NEXYS2) I used switches for disk selection. As final FPGA platform doesn't have any switches set, I have to add an BASIC instruction for it, something like "OUT &CAFE,disk_number" could be fine.
"PRINT INP(&CAFE)" does print current disk selected number.
Since advanced FDC, dsk files have to be defragmented. Only ROMs are safe with a not defragemented sdcard...
==== TODO DSK: 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. === TODO : A X/Y input arnoldemu testbench === 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 ? === DONE: A SCART output === In order to plug FPGAmstrad on TV, and help debugging. And also to test a simple scan-doubler. r005c17 : experimental version, original signal TV output is running fine, with OSD menu. Have to add a flag in mist.ini instead of using OSD menu.scan-doubler doesn't run ok in mode 2, and has strange offset with Arkanoid (vertical display games), so it unvalidated : only original TV output will be added to r004 in r005. r005 : VGA 60H/TV 50Hz. ==== TODO : 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 arnoldemu testbench: A SCART output with border ==== Original output signal has no border, I have to implement the original border in TV mode. Priority: HIGH! (asked by Markus Hohmann) Done in r005.8.14.2 ==== DONE : 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 : 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. Bu titfdctest's usually sufficient to xor hsync and vsync to get a csync acceptable for many TVs.So something like this Vsync=1; Hsync=old_Vsync xor old_Hsync;Done in r005.8.14.1 ==== DONE : 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. Done in r005.8.14.2 In theory, simple_GateArrayInterrupt.vhd shall have : vsync_azrael<=etat_monitor_vhsync(2); hsync_azrael<=etat_monitor_hsync(2); if hSyncCount=2+4 thenIn practice - in r005.8.14.2 - here we have : vsync_azrael<=etat_monitor_vhsync(1); hsync_azrael<=etat_monitor_hsync(1); if hSyncCount=1+4 thenThis way screen is nicely centered but CPCWiki rule "The HSYNC is modified before being sent to the monitor. It happens 2us after the HSYNC from the CRTC and lasts 4us when HSYNC length is greater or equal to 6. If R2=46, and HSYNC width is 14 then monitor hsync starts at 48 and lasts until 51." is not respected. Test about centering screen are done using "BORDER 0", this way border is ignored and does interact with HSYNC/VSYNC screen synchronisation. === DONE : 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 : CRTC0 ====CRTC0 seems the best one, some demo does cry when detecting a poor CRTC1 (CRTC1 seem a low cost version of CRTC0). I have to implement a CRTC0 instead of my current CRTC1... In fact CRTC1 is the best one. CRTC2 is the low cost version. CRTC0 did appears before CRTC1. Done in r005.8.14. Detected as CRTC0 by WakeUp! - "Enjoy the show" message displayed. In r005.8.15. WakeUp! (CRTC0/MEM_wr quick) detected as Emu first time, and after a quick reset, does say detected as CRTC0. ==== DONE : 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. Done in r005.8.14 : Still Rising (Vanity) demo can be launched, better using "MEM_WR:slow" mode. [http://quasar.cpcscene.net/doku.php?id=coding:test_crtc Test CRTC - Quasar Net] === TODO : Interlaced scanlines === Interlaced scanline is an effect existing in CRTC (register R8) used by Wolfenstrad demoSeen also at begin of '''R-Typeee.dsk''' ("stereo soundtrack" message's picture), and seem also used in a lot of recent demos as "flipping lace" effect. Scanline is also used just at begin of '''Pinball_Dreams__PREVIEW.DSK''' (eagle draw) - in fact I've got a doubt here, it seems more about a problem of HSYNC edge choice of alignement here. [http://cpc.sylvestre.org/technique/technique_identifier_crtc.html Les Sucres en Morceaux - Amstrad CPC - Identifier les CRTC] OUT &BC00,8 OUT &BD00,3 [http://quasar.cpcscene.net/doku.php?id=coding:test_crtc Test CRTC - Quasar Net] L'écran passe en 100Hz, les registres 4 et 7 doivent être doublés pour retomber sur 50Hz === DONE : 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 withoutScanlines.png|thumbnail]][[File:FGPAmstrad cc withScanlines.png|thumbnail]] === DONE : Monochrome option ===Add an option to turn screen into green monochrome mode (in mode TV and in mode VGA) done in r005.8.9.2 (Soleil Vert demo)[[File:Soleil vert CoreAmstrad.png|thumbnail]][[File:Soleil vert CoreAmstrad scandb50Hz.png|thumbnail]] [http://cpc.sylvestre.org/technique/technique_coul1.html Les Sucres en Morceaux - Couleurs - 1 - Les couleurs du CPC] ==== DONE : Monochrome OSD ==== Could be great having the OSD in monochrome when monochrome is selected and scanlined when scanline is selected
arnoldemu's testbench to pass : test/fdctest/fdctest/fdctest.dsk
Have also to fix theses "Bad Command" responses from fdc (it seems that when you don't reach a track, you have to send back the current track instead of this "Bad Command" signal). Test : 30YMD demo, "disk change" message not running correctly, "another disk inserted" is not detected in this demo.
CoreAmstrad r005.8.15
* 27FAIL01/29FAIL01 : read_track6/read_track10 - very big sector size counter not implemented (more than 512B)
* 60FAIL01 : format2 - format command not implemented (this test is slow)
[http://www.cpctech.org.uk/test.zip http://www.cpctech.org.uk/test.zip] arnold test last update. Folder disc/, tests : "seek, recalibrate, sense interrupt status, sense drive status, write protect"
=== PPI ===
==== DONE PPI: A better PIO ====
I'm looking after a great implementation of PIO, in original schematic of Amstrad, keyboard (output, not input) is mapped behind Yahama chip behind PIO.
In original schematic, PIO is the only one component having a low state reset (0), I think that imply a 0 value as state init of internal components variable. Data bus of Z80 seems having a pull-up state (read 1 when nothing is plugged), for example a unplugged ROM does respond xFF in data-bus.
In r005.5 I build the Yamaha clock from GA. Unlocking "Saboteur 2" game.
Yamaha clock (YM2149_linmix_AmstradStereo.vhd) is used only for "sound algorithm", not for setting/getting registers (registers are set using "BDIR BC2 BC1" wires), so I have to overclock the setting/getting register clock to simulate the original behaviour...
==== DONE PPI: PPI clock ====
PPI in original schematic does not have clock ! So I have to overclock this one to simulate the original behaviour...
Overclocked at 16MHz.
=== TODO = PPI: a better border heuristic arnoldemu testbench ====Using winape arnoldemu's testbench (plustest), test 2 does show somes problems while border does go out of screen, negative border does hide line itselfPPI passed.
=== TODO : AMX mouse support SOUND ===Asked by KLNHOMEALONEPWM.
=== UNDONE = SOUND: pause Z80 while OSD is displayed PWM ====Cause playing Double Dragon II without "pause", is quite difficult.
----
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 ==
* [http://www.cpcmania.com CPCMANIA] ''plug Amstrad on TV''
* [http://bellaminettes.com Bellaminettes] fr ''Artist drawer -nice girls- from ACBM magazine - Les puces informatiques - Sasfepu''
== Appendix ==
=== MiST-board special features ===
Bulk of effort done/TODO-list, especially for the MiST-board's CoreAmstrad implementation.
==== ROM/RAM ====
==== ROM/RAM : extension ====
In r004, you have more RAM +512KB, and you can add ROMs.
* LowerROM has .eZZ file extension
* UpperROM has .e00 ot eFF file extension (hexa)
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 ?
==== VIDEO ====
===== VIDEO: A SCART output =====
In order to plug FPGAmstrad on TV, and help debugging. And also to test a simple scan-doubler.
r005c17 : experimental version, original signal TV output is running fine, with OSD menu. Have to add a flag in mist.ini instead of using OSD menu.
scan-doubler doesn't run ok in mode 2, and has strange offset with Arkanoid (vertical display games), so it unvalidated : only original TV output will be added to r004 in r005.
r005 : VGA 60H/TV 50Hz.
===== VIDEO: 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.
===== VIDEO: A SCART output with border =====
Original output signal has no border, I have to implement the original border in TV mode.
Priority: HIGH! (asked by Markus Hohmann)
Done in r005.8.14.2
===== 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.
===== 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.
Bu tit's usually sufficient to xor hsync and vsync to get a csync acceptable for many TVs.
So something like this
Vsync=1;
Hsync=old_Vsync xor old_Hsync;
Done in r005.8.14.1
===== 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.
Done in r005.8.14.2
In theory, simple_GateArrayInterrupt.vhd shall have :
vsync_azrael<=etat_monitor_vhsync(2);
hsync_azrael<=etat_monitor_hsync(2);
if hSyncCount=2+4 then
In practice - in r005.8.14.2 - here we have :
vsync_azrael<=etat_monitor_vhsync(1);
hsync_azrael<=etat_monitor_hsync(1);
if hSyncCount=1+4 then
This way screen is nicely centered but CPCWiki rule "The HSYNC is modified before being sent to the monitor. It happens 2us after the HSYNC from the CRTC and lasts 4us when HSYNC length is greater or equal to 6. If R2=46, and HSYNC width is 14 then monitor hsync starts at 48 and lasts until 51." is not respected.
Test about centering screen are done using "BORDER 0", this way border is ignored and does interact with HSYNC/VSYNC screen synchronisation.
===== 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
===== 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.
Done in r005.8.14 : Still Rising (Vanity) demo can be launched, better using "MEM_WR:slow" mode.
[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
Seen also at begin of '''R-Typeee.dsk''' ("stereo soundtrack" message's picture), and seem also used in a lot of recent demos as "flipping lace" effect.
Scanline is also used just at begin of '''Pinball_Dreams__PREVIEW.DSK''' (eagle draw) - in fact I've got a doubt here, it seems more about a problem of HSYNC edge choice of alignement here.
[http://cpc.sylvestre.org/technique/technique_identifier_crtc.html Les Sucres en Morceaux - Amstrad CPC - Identifier les CRTC]
OUT &BC00,8
OUT &BD00,3
[http://quasar.cpcscene.net/doku.php?id=coding:test_crtc Test CRTC - Quasar Net]
L'écran passe en 100Hz, les registres 4 et 7 doivent être doublés pour retomber sur 50Hz
===== 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 withoutScanlines.png|thumbnail]]
[[File:FGPAmstrad cc withScanlines.png|thumbnail]]
===== VIDEO: Monochrome option =====
Add an option to turn screen into green monochrome mode (in mode TV and in mode VGA)
done in r005.8.9.2 (Soleil Vert demo)
[[File:Soleil vert CoreAmstrad.png|thumbnail]]
[[File:Soleil vert CoreAmstrad scandb50Hz.png|thumbnail]]
[http://cpc.sylvestre.org/technique/technique_coul1.html Les Sucres en Morceaux - Couleurs - 1 - Les couleurs du CPC]
===== 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.
===== VIDEO: 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.
Some VGA does detect FPGAmstrad resolution just if pixels are ligther, so I turn them lighter during start of engine. Normaly a press into reset button (the one front the sdcard entry) does solve directly this problem (you can also turn on screen before MiST-board with this sort of screens)
I tryed also [http://github.com/mist-devel/mist-binaries/tree/master/cores/menu menu core project] with my stupid screen, as it normally I can power on MiST-board before screen for FPGAmstrad (switching core does the stuff here also)
Tryed in r005.8.14.4 : lighter pixels during bootload. Also with a full white screen.
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.
Without lighter pixels full white screen, the crop of image does change, moving into first displayed characters : in fact in SAMSUNG menu, the position of screen is not 50 50, if you put 50 50 you come back to "lighter pixels full white screen" defect. So here screen begining at first char displayed on screen is a second defect, but a small one, as you just have to set 50 50 in SAMSUNG menu.
So back to previous bug : screen doubt 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".
When displaying a game, in fact, in found two different case in "perfect centered 4/3" case , this case is not so perfect, it does also doubts between two positions :
* one time screen does crop at 6.5 left and right, changing the screen vertical position using menu does translate the image cropping left and right at fix position : 6.5 centimeters fix black border. About extra 1 centimeter pixels : image in middle of image does move, but not the borders at all.
* 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 ===
