Changes

(nothing to say here, really ???)

==== GA: alignment of HSYNC Interrupt ====

In r005.8.16c29, arnoldemu testbench "cpctest" is OK (but it is a wip version :p)

[[File: cpc_plus_m1.jpg]]

Code name: Raptor

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.

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.

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.

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...]

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.

[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 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)

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.

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.

|}

About 22 pages of source code using 3 columns per page.

.stdinst

[[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.

[http://www.cpc-power.com/index.php?page=detail&num=12883 CPC-Power Z80 FULL TEST (UK) (2012) - UTILITAIRE]

[http://www.winape.net/download/plustest.zip WinAPE plustest.zip (including Instruction and Interrupt timing tests)]

===== a) T80.vhdl =====

17 pages of source codes to read.

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.

It's data, insertion of disk.

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.

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.

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"

Keyboard detection versus VSYNC signal versus interrupt cycle.

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.

Update : arnoldemu's testbench PPI passed.

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...

PPI in original schematic does not have clock ! So I have to overclock this one to simulate the original behaviour...

PWM.

Using a simple [[PWM]], data is entered at a certain speed, the [[PWM]] clock speed.

This result a high quality sound output (in addition to this nice [http://www.fpgaarcade.com/library.htm Yamaha sound chip from fpgaarcade])

[[File:STarKos1 21 FPGAmstrad_800x600.png|none|STarKos 1.21 running on FPGAmstrad]]