Changes
/* RET cc and WAIT_n timing analysis */
[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]
So 2A is really during 5 NOPs... perhaps MEM_rd has to be slow down with one WAIT_n like for MEM_wr. Perhaps in this case 5T's instruction has not to be slow down. I have to fork r005.8.16c3 to test that. - update : in schematic GateArray does not has "MEM_wr wire" (but MEM_req and RD, so can deduce WR, but in an evil brain's way) - update 2 : all tests failed except one in testbench using this way, perhaps because RFSH_n does also use MREQ_n during M1 cycle. Perhaps WAIT_n generator can detect the current OP Code fetched (this is conform to [http://www.google.com/patents/US5313621 Patent US5313621 : Programmable wait states generator for a microprocessor and computer system utilizing it ]). - update : principe of concept validated for one instruction (2A), I can slow down instructions one per one, I don't know why I had to insert two WAIT_n instead of one here, but I result its results a plustest.dsk testbench with 2A instruction validated, that's done on r005.8.16c5f5 (candidate 5 fork 5), but I have to revert it to r005.8.16c3f5 I think before going further.
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.
Even prefixed and double prefixed instructions are taken into account by my WAIT_n generator.
WAIT_n generator is finally juste inserting a certain number of WAIT_n following executed instruction + a mod 4. In forum if I remembered, you don't do the next mod 4 alignement after a recepted IO_ACK (have to check that)
I try on this version to get 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.
I have regressions on this version, Still Rising's scroll, and Trail Blazer palette offset at left.
"RET cc" instruction seems not respecting original timing in T80. I had 2 clocks in last TStates of it.
I don't understand why I have to add 2 WAIT_n when 1 WAIT_n seems suffisant, I think there is some problem around my "PLEASE_WAIT" component (hack of T80's WAIT_n entry), perhaps finally T80's WAIT_n entry is fine, as finally I just insert a certain number of WAIT_n during second clock of M1, MEM_wr slow is unvalidated : Gatearray of Amstrad doesn't have the needed "WR" wire, so.
Next step shall be destroying "PLEASE_WAIT" component I think, in order to add 1 WAIT_n and not 2 with my WAIT_n generator.
T80 WAIT_n has also to be checked, I know that inserting a WAIT_n seems generating a seconde IO_ACK edge during an IO_ACK.
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)
===== 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.
In r005.6, cpctest.dsk did pass. Removing MEM_wr:slow both tests does still run fine (NOP/HALT (x00 x76)). Removing full mod4 WAIT_n generator, cpctest.dsk and plustest.dsk does fail. So NOP has to be synchronized (plustest.dsk is full of NOPs)
=== Test of a real Zilog 80 ===
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.
==== TODO : RAM 4MB extension ====
Why not ?
=== Sound output ===
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 : A SCART output with border ====
Asked by KLNHOMEALONE.
=== TODO UNDONE : pause Z80 while OSD is displayed ===
Cause playing Double Dragon II without "pause", is quite difficult.
Bryce.
=== TODO 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.
So you put the two last schematics together and tadam... got a problem.
The problem is that two components are accessing RAM in at the same time: the Z80 and the VGA, so you had to make a sequencer. A sequencer is simply a counter fed by a clock: 00, 01, 10, 11. And you manage work task like this:
*00 RAM WRITE start from Z80
You plug sequencer(1) on z80 clock and not(sequencer(1)) on VGA...but another problem appears: VGA uses 25MHz speed for scanning RAM. So Z80 has to use same speed xD
To solve this problem you can use a special RAM done for this problem, a RAM that you can WRITE at a certain speed, and READ at another speed, this magic component is called '''ramb16_s16_s16'''. Note that they have no problem to write simultaneously on two RAM components, so that you can dump video RAM content using starter kit 's external RAM, and you can display VGA using FPGA 'z internal '''ramb16_s16_s16''' RAM.
[[File:build_your_own_z80_amstrad_computer.jpg]]
===== State machine =====
Both component components of Bootloader, it is to say SPI_MASTER and SDRAM_FAT32_LOADER components, does use several state-machines, one state-machine per process, each process communicating with another one using "MASTER/SLAVE" : the master state-machine does ask a slave to do something, and slave does notify master when its task is finished. Using VHDL, I implement state-machine using a simple "switch case" on an '''integer'''. and before break I just change (increment...) this integer variable value, changing line of "switch case" this way.This "switch case" is encapsulated on a "if do/done do/done do/done" instruction. "do" being a boolean from MASTER, and "done" being a boolean from SLAVE. Each MASTER against SLAVE component has a "do" (input if SLAVE component, output if MASTER component) and a "done" (input if MASTER component, output if SLAVE component) wire.That's all. Like this you can run several sequential instructions, like reading and interpreting severals FAT32 variables using a SPI slaved component solving "read one byte at this address" instruction writen under a really low-level SDCARD protocol language.
Theses state-machines does use led debug : an '''integer ''' contains the state of state machine, and this '''integer ''' is displayed on 8 leds so you know where you are, it's for that I add several crash states in order to understand why and where component does crash. In On MiST-board, this is displayed on using the five 7-segment I just added in OSD, I add added also an input personalized "OSD menu entry" in order to select one or another state machine.during first phases of MiST-board's version of this project (that's why you can still see a mysterious 7-segment still displayed at bottom of OSD, it's used sometime for debug purpose)
==== FPGAmstrad_amstrad_video schematic ====
==== go further with USB sniffer ====
A better way to snif USB could be generation of TCP/IP packets encapsuling encapsulating USB packets, and to record them directly on PC from a RJ45 plug, using this way I could save more than 10 seconds of information transmission (RAM size is limited on FPGA platfoms)
[[File:Usb-paf.png|thumbnail]]
