Changes

In MaY 2020, I add Sorgelig formula for WAIT_n=quick, no more table of instruction time in code, just a simple WAIT_n formula. In MaY 2019, I add cassette feature. In August 2018, totally desperated -around time and level of efforts- about reaching next step focus around Z80 range, here came Sorgelig, he is working around port of FPGAmstrad into the MiSTer FPGA platform, and make during his step an intermediate jump step on MiST-board called "Amstrad_MiST" full of verilog as he seems to love. And, as a specialist of Z80 core, I just send him Z80 testbenches I collected since, he then corrected the Z80 fully this way, I merged, resulting this next current checkpoint. In May 2018, I programmed my first CPC game http://www.pouet.net/prod.php?which=75855 following JDVA youtube tutorial since january, they are based on CPCMania 2005's website knowledge about programing in CPC using SDCC. I think that if I do progress this way enough, I'll implement my own CPC testbenches, needed for reaching next realise of FPGAmstrad.(I did it : Moustache testbench)

*'''Orion Primes.dsk''': does display "secteurs entrelacés" - "vérifiez votre copie", a FDC problem, perhaps "sectorId++" is not the good way to reach next sector, or else two tracks in one track. Does pass on Sorgelig fork.*'''Batman_Forever.dsk''': some problem during flying chip demo part (one garbage line), and several rupture showing ghost lines around Vcc=0. Rupture solved in r005.8.16c4, but flying chip now show a half garbage of pixels. Batman seems CRTC1. '''BattroProblems with FDC in r005.dsk''' seems also CRTC1 and does fail completly8.16 (does slow animations, like if I missed some "not ready" signal ?)*'''30YMD.dsk''': in Benediction demo, at bottom some time you see some ghosts of central animation (too many HSync per screen ?), solved in r005.8.16c4 16 (CRTC0 seems perfectly implemented). 30YMD seems CRTC0, running fine except that changing disk feature does still fail.*'''arkanoid2.dsk''': don't run in r005.8.13, but fine in r005.8.13e (experimental fork), ok in r005.8.14 (using default OSD value : MEM_WR=quick)*'''trailblazer.dsk''': no more "raster" problem since r005.5, it's now perfect ! Palette heuristic offset (done for unlocking Batman Forever Demo) has a small effect in left (squares are inserted/not separated by a black line in first column) - same small defect in TV mode using r005.8.14.2... Thinking about a HSYNC offset of 2 (instead of 1 currently) then also delaying DATA+HDISP of 1 (charinserted/inserted signal ?)*'''imperial_mahjong.dsk''': modern EXA/EXA2 resolution not passing my color pallet heuristic :p- does pass on Sorgelig fork.

*'''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. Test on real 6128 [http://www.cpcwiki.eu/forum/demos/seascape-cpc-by-impact-on-original-cpc-6128/ forum: Seascape CPC by Impact - on original CPC 6128 ?] - by Emashzed : type 1 is perfect (no blue on bottom right flowers, no blue on middle triangle rock), type 2 has bright cyan squares (one on bottom right flowers, and one on middle triangle rock. Calibrated OK in r005.8.16.5 using OSD VGA:scandb50Hz. Does pass on Sorgelig fork.[[File:Seaspace-type1_MiST-board_CoreAmstrad-r005.8.16.5|thumbnail|Seascape (type 1) - r005.8.16.5]]*'''Megablasters[original].dsk''': has a 2 pixels glich border on left side. Certainly final HSYNC offset problem, as on Super Cauldron normaly the right (not left) border has to be selected to get a nice bottom bar in game (actually too centered)*'''Edge_Grinder.dsk''': screen not stable horizontally, music change speed during game ? Does pass on Sorgelig fork.

'''moktar.dsk''' / '''super_cauldron.dsk''' does run fine since r004.8.1.1. Morkar run fine in r005.8.16c4 using CRTC0 and MEM_wr=slow. Super Cauldron bottom bar is fine in r005.8.16.4 when we select "right border" (instead of default left one) during "screen synchro" menu welcome.

==== GA: WAIT_n generator (WIP- currently in r008.5..) 14 ====

==== GA: MEM_WR has an OSD menu choice to switch between "quick" and "slow", "slow" mode does insert ONE WAIT_n generator - currently during detection of MEM_WR. This switch exists because somes games are running in r008.5.14 ====In GA, I do use begin of edge for IO_ACK instead of state"slow" mode and others in "quick" mode.

M1 reached same time An elegant fork by Sorgelig, sum up nicely the "MEM_WR:slow" algorithm + the HACK_Z80 flag of IO_ACK are ignored r008.5.14 : T80pa CPU (not M1 (...) in .cen_p(ce_4p & (WAIT_n generator| no_wait)), .wait_n(1) // (cyc1MHz | (IORQ_n & MREQ_n) | no_wait) );MEM_WR has an OSD menu choice to switch between "quick" and "slow", "slow" mode does insert ONE // Current WAIT_n during detection of MEM_WR. This switch exists because somes games are running in "slow" mode and others in "quick" mode.generation is not correct! // It should use WAIT_n instead (see commented out code above ^^) reg WAIT_n; wire acc = (MREQ_n | ~RFSH_n) & IORQ_n; always @(posedge clk) begin reg old_acc; if(ce_4p) begin old_acc <= acc; if(old_acc & ~acc) WAIT_n <= 0; if(cyc1MHz) WAIT_n <= 1; end end

==== 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 . In r005.8.16c4, I remark that two WAIT_n are also needed by instructions using 5T during M1 cycle. But in fact the M1 signal is not outputing 4T while 4T, but cutted at 2T. So that I do here (experimental), I produce a M1 signal output of 3T while 5T. Detecting it that way in my WAIT_n generator, producing then needed 2 WAIT_n at this moment. But plustest.dsk testbench don't pass anymore in r005.8.16c4, testbench show border effect : a correct instruction is marked as bad timing, but in fact it the next one I did modify. I don't know if plustest.dsk does pass on real Amstrad, but it is a really great testbench to progress (without it, r005.8.16c4 could not be realized). 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) ====

==== GA: WAIT_n generator - talk about r005.8.16c20 plustest-9 - Tests on real CPC (by GUNHED and Kris) ====Instruction timing seems all respected following plustest[http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/need-plustest-dsk, but I think it isn't enough, so it-testbench-9-output-on-original-cpc-6128/ CPCWiki's still a candidate versionforum : Need plustest.dsk testbench 9 output on original CPC 6128]

Even prefixed and double prefixed instructions are taken into account by my WAIT_n generator.GUNHED results : WAIT_n generator is finally juste inserting a certain number of WAIT_n following executed instruction + a mod 4. In forum if I remembered System 1: CPC6128, you don't do the next mod 4 alignement after a recepted IO_ACK (have to check that)CRTC2: I try on this version to get Test 9 works normal until the &EC codes, there are two errors marked with an intelligent IO_ACK: in JavaCPC instructions just has a fixed time (array of instruction timing) and IO_ACK does not influence on them. So IO_ACK perhaps has to remove one WAIT_n inserted by GateArray"X". &ED, &46: 2I have regressions on this version &ED, Still Rising's scroll&4E: 2 After &ED, and Trail Blazer palette offset at left.&5D it suddenly stops working! "RET cc" instruction seems not respecting original timing in T80. I had System 2 clocks in last TStates of it.: 6128 Plus: I don't understand why I have to add &ED, &46: 2 WAIT_n when 1 WAIT_n seems suffisant &ED, I think there is some problem around my "PLEASE_WAIT" component (hack of T80's WAIT_n entry)&48 5 &ED, perhaps finally T80's WAIT_n entry is fine&49: 5 &ED, as finally I just insert a certain number of WAIT_n during second clock of M1&4E: 2 &ED, MEM_wr slow is unvalidated &50: Gatearray of Amstrad doesn't have the needed "WR" wire5 &ED, so.&51: 5 &ED, &58: 5Next step shall be destroying "PLEASE_WAIT" component I think &ED, in order to add 1 WAIT_n and not 2 with my WAIT_n generator.&59: 5 T80 WAIT_n has also to be checked After &ED, I know that inserting &5D it suddenly stops working! Probably a WAIT_n seems generating crash, since a seconde IO_ACK edge during an IO_ACKspot appears on screen.Kris results :Have to check also Here are my results (teste performed on CPC 6128 CRTC 1) Pictures of each screen attached in the moment IO_ACK is taken into account during M1 signal .rar file. (I think it's at begin ...)In pictures of itKris, but have to re-check thatafter ED5D, it does stop also. Only ED test part has some failings :* ED46:C* ED4E:CIn WinAPE (by default CPC 6128 CRTC1), ED test does finish its screeen result, with several fails :* ED46:2* ED4E:2* ED66:2* ED6E:2Others screens results after does pass. Relaunching once again in WinAPE, same results.

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.

==== GA: WAIT_n generator - talk about r005.8.16c29 16 ====This version does implements correctly a theorical OSD menu has now "WAIT_n generator : I used slow|quick", 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 generator is fully covered by Z80 docimplemented adding 0, so plustest.dsk testbench failing on this part is not due to table slowing down instruction timing (1 or 2 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 per instruction timing themself and found no problem this way.

I also revisited the edges of WAIT_n generator, to insert WAIT_n at 2T(like explain in Z80 doc), so normaly it is retro-compatible with official T80. Doing this way I can set HACK_Z80 flag at false (T80.WAIT_n is now used in r005.8.16)

Megablasters seems running fine on r005.8.16c29. Using 4 disk version of Megablasters (old one), sometimes bombs doesn't explode, it's normal : in this case you have to press the second fire button (gameplay...) plustest.dsk source code are available on winape websitetestbench 5 does pass, I have to explore them. {| class="wikitable"|except for two instruction : CPIR and CPDR -! Hex !! Inst !! CPC timing !! btw, in r005.8.16c29|-| 32 || LD (nn)16,A || 4|| 3|-| 3A || LD A,(nn) || 4 || 3|-| C0 || RET NZ || 2its instructions are using then same "WAIT_n generator" slower than CPI/4 || 2/3|-| C4 || CALL NZ,nn || 3/5 || 3/4|-| C5 || PUSH BC || 4 || 3|-| C7 || RST 0H || 4 || 3|-| C8 || RET Z || 4/2 || 3/2|-| CC || CALL Z,nn || 5/3 || 4/3|-| CD || CALL nn || 5 || 4|-| CF || RST 8H || 4 || 3|-| D0 || RET NC || 2/4 || 2/3|-| D4 || CALL NC,nn || 3/5 || 3/4|-| D5 || PUSH DE || 4 || 3|-| D7 || RST 10H || 4 || 3|-| D8 || RET C || 4/2 || 3/2|-| DC || CALL C,nn || 5/3 || 4/3|-| DF || RST 18H || 4 || 3|-| E0 || RET PO || 2/4 || 2/3|-| E3 || EX CPD : none (SPno WAIT_n added for theses instructions),HL || 6 || 5|-| E4 || CALL PO,nn || 3/5 || 3/4|-| E5 || PUSH HL || 4 || 3|-| E7 || RST 20H || 4 || 3|-| E8 || RET PE || 4/2 || 3/2|-| EC || CALL PE,nn || 5/3 || 4/3|-| EF || RST 28H || 4 || 3|-| F0 || RET P || 2/4 || 2/3|-| F4 || CALL P,nn || 3/5 || 3/4|-| F5 || PUSH AF || 4 || 3|-| F7 || RST 30H || 4 || 3|-| F8 || RET M || 4/2 || 3/2|-| FC || CALL M,nn || 5/3 || 4/3|-| FF || RST 38H || 4 || 3|}

r005.8.16c4 results ==== Z80:Some bad instruction analysis ====Based on [[Filehttps:FPGAmstrad plustest5 r005//cpcrulez.8fr/applications_CPM-util-zexall.16c4 part1.png|thumbnail|FPGAmstrad_plustest5_r005.8.16c4_part1htm Zexall: Z80 instruction set exerciser]][[File:FPGAmstrad plustest5 r005, running fine in JavaCPC.8.16c4 part2.png|thumbnail|FPGAmstrad_plustest5_r005.8.16c4_part2]]

Solved in r005.8.16c6 results :[[File:FPGAmstrad plustest5 r005.8.16c6 part1.png|thumbnail|FPGAmstrad_plustest5_r005.8.16c6_part1]][[File:FPGAmstrad plustest5 r005.8.16c6 part2.png|thumbnail|FPGAmstrad_plustest5_r005.816.16c6_part2]]3 by Sorgelig (T80 fixes) - valided

==== 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 B9 cpd(r) / ED A1 B1 cpi(r) ====<s>Problem here : CPDR and CPIR has same implementation than ED A9 CPD and ED A1 CPI.</s> Solved by Sorgelig (does not pass plustest.dsk testbench 5 in r005.8.16.2 but does pass it on Sorgelig MiSTer fork version) In fact it is a more difficult instruction that I was thinking, if you watch at it, it shall take only 4 NOPs maximum but in plustest.dsk it does take 6/4 NOPs. In fact C9 RET seem also used here, as sub instruction. I remark that CPD and CPI does take 4 NOPs, so here CPDR/CPIR does not has same implementation than CPD/CPI (so I was wrong : CPIR/CPIR is implemented in T80) Done in r005.8.16.4 : just added a TState (TStates <= "110";) on case 3, that way plustest.dsk tb 5 does succeed.

USB is just a state machine (welcome how are you today, show me your state, show me your state, show me your state....), encoding (have to read USB manual), you can use some usb sniffer softwares software to decode them (wireshark unix version does it fine). Sniffer software does not show low level messages (ack ko ok) but does show the high level messages (ones that show that a button is pressed or not)

On [[http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS2 Diligent NEXYS2 official page]], you can download a "Onboard Memory controller reference design" that contains explanation and VHDL source code about dumping on RAM/ROM of NEXYS2 directly from PC (usb port). I didn't tested this yet, but it is certainly a nicer approach :P

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(=> done in r005.8.15.2)

core_r005c18 seems having a scan-doubler outputOn Sorgelig fork, have to merge it.the scandoubler does run ok in mode 2 (but still not centered correctly on VGA 16/9)

===== DSK: TODO HOWTO: fix message "This program will not run in this environment. Press any key" =====

 ===== DSK: TODO : tapes =====

===== X/Y: TODO : AMX Kempston mouse support =====Asked by KLNHOMEALONEdid ask AMX mouse - sorry about this, finally I added the Kempston mouse model only :p Merge of Sorgelig kempston_mouse.v done in r005.8.16.6 [[File:Advanced art studio-kempston-mouse MiST.jpg|thumbnail|Advanced Art Studio - Kempston mouse]] Advanced Art Studio > Misc.> Input Devices> Kempston mouse Advanced Art Studio > Misc.> Input Devices> Fast cursor (if you want) I do not like the AMX mouse, because it can trick a beginner: in fact, in Advanced Art Studio, even if the mouse is already moving, you have to activate the "AMX mouse" on "Misc" menu or else the mouse stay very very slow, the time you understand that our mouse is slow and that it's abnormal, you are disgusted with Advanced Art Studio.