Changes
/* Effort done */
== Effort done ==
=== VGA ===
Pixels and VRAM. Palette and rasters. CRTC0
==== 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.
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.
==== TODO : arnoldemu testbench - crtctest ====
Adding choice of CRTC 0 or 1 on OSD, and passing this test could be great.
==== 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
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.
==== TODO : a better border heuristic ====
=== bootloader ===
SDCARD and RAM.
(nothing to say here, really ???)
=== GA: interrupts, VSYNC ===
==== 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]]
In r005.8.16c29, arnoldemu testbench "cpctest" is OK (but it is a wip version :p)
=== GA: WAIT_n generator ===
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 : 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 : 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 : 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.
===== Instruction timing: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 : 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)
===== Instruction timing: 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)
|}
===== Instruction timing: plustest.asm =====
About 22 pages of source code using 3 columns per page.
.stdinst
[http://www.winape.net/download/plustest.zip WinAPE plustest.zip (including Instruction and Interrupt timing tests)]
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.
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]]
Based on [[https://cpcrulez.fr/applications_CPM-util-zexall.htm Zexall: Z80 instruction set exerciser]], running fine in JavaCPC.
Problem here : CPDR and CPIR has same implementation than CPD and CPI.
Since advanced FDC, dsk files have to be defragmented. Only ROMs are safe with a not defragemented sdcard...
ZX-Uno is using simple FDC, not impacted here.
==== DONE : arnoldemu's testbench fdctest ====
