Hi all,
it's rare that I even read the threads in this section, so it's even rarer for me to start a thread here... (I'm trying to get back into Z80 programming :)).
Is there a file anywhere that lists all the Z80 commands and how how long each one takes on a CPC in real time (ie: in µs not in Cycles or whatever)?
Bryce.
http://www.cpcwiki.eu/forum/programming/craving-for-speed-a-visual-cheat-sheet-to-help-optimizing-your-code-to-death/?action=dlattach;attach=10666 (http://www.cpcwiki.eu/forum/programming/craving-for-speed-a-visual-cheat-sheet-to-help-optimizing-your-code-to-death/?action=dlattach;attach=10666)
1 NOP = 1 us
Take in account that those are the valid timings for and only for the CPC, you might find other generic timings for the Z80 widespread all over the Internet, but they are not valid for the CPC as the GA uses the WAIT pin of the Z80 in a regular basis and alters the duration of the instructions.
Yes, I already have the standard Z80 timings, it was the CPC specific ones that I was after (due to the GA etc), thanks.
Bryce.
Not at all, if only you had for software half the talent you have for hardware then we can expect great things within the next few months. :D
Quote from: Bryce on 11:13, 07 January 15
Yes, I already have the standard Z80 timings, it was the CPC specific ones that I was after (due to the GA etc), thanks.
Bryce.
http://quasar.cpcscene.net/doku.php?id=iassem:timings (http://quasar.cpcscene.net/doku.php?id=iassem:timings)
The timings alter slightly for some instructions if an interrupt request is performed at the end of them (e.g. INC BC).
But for general coding use the table above.
EDIT: I see opqa has added a link to an equally good document.
Quote from: opqa on 13:48, 07 January 15
Not at all, if only you had for software half the talent you have for hardware then we can expect great things within the next few months. :D
I can assure you that I have absolutely no talent in software :)
@Arnoldemu: Thanks. I'm working on very basic stuff at the moment, a loooong way away from experimenting with interrupts.
Bryce.
Quote from: Bryce on 14:13, 07 January 15
I can assure you that I have absolutely no talent in software :)
Well, if you need help, just PM me. IMHO it's good to work on things we're best in, that's the most efficient way. But of course it's always great to learn something new. :)
opqa : i enjoy your pdf document. Have. You other thing like that ?
For example, ppi, fdc, ay....etc
Quote from: TFM on 18:35, 07 January 15
Well, if you need help, just PM me. IMHO it's good to work on things we're best in, that's the most efficient way. But of course it's always great to learn something new. :)
I don't intend dropping hardware for software. But understanding the possibilities (and limits) of the software can help when developing hardware.
Bryce.
Definitely and vice versa. :)
Quote from: Ast on 19:17, 07 January 15
opqa : i enjoy your pdf document. Have. You other thing like that ?
For example, ppi, fdc, ay....etc
:o No, it isn't mine! Please don't give me merit for other's work. I also enjoy this document a lot but I found it searching on the internet. Credits are inside the pdf, the authors are two members of this forum, they made it based on data posted in the wonderful web cpctech, which in turn is based on real measures someone else made long time ago...
To get information on the CPC I use to search over different sources, the cpcwiki, cpctech, grimware, cantrell.org... depending on what I'm looking for. Some things are better explained in some sites and some else in others.
For a quick reference on the z80 instructions and flag affection I also like to check this table:
Z80 instruction set - ClrHome (http://clrhome.org/table/)
And for more detailed explanation of the instructions there are many other sites like the z80heaven wiki for instance.
Quote from: Bryce on 14:13, 07 January 15
I can assure you that I have absolutely no talent in software :)
Is this for your little hardware device that tells you how long each Z80 Command takes. 8)
No, but I am writing (trying to write) a piece of software that is time critical (at least in the 1ms region). So I want to calculate how much time my routines/loops take.
I regularaly write PIC machine code, so the code isn't all that different, I just need to understand the registers a bit better now. In University we "only" learnt 6800, not Z80 :(
Bryce.
Quote from: Bryce on 09:48, 08 January 15I can assure you that I have absolutely no talent in software (http://www.cpcwiki.eu/forum/Smileys/SoLoSMiLeYS1/smiley.gif)
QuoteI regularaly write PIC machine code, so the code isn't all that different, I just need to understand the registers a bit better now.
I'm beginning to wonder how you define talent. When you regularly write PIC machine code, you can obviously program. Writing time critical software implies a certain talent.
Writing code and writing good code are two completely different things :D
Quote from my professor on one of my assignments:
"Very well documented, it's such a pity that the code doesn't do what the comments claim"
Bryce.
Well, I hope he tried to give you suggestions where your code fails, otherwise he'd be a lousy teacher (but TBH all of them were, and my nephew claims that all of them still are. ;) )
Quote from: MaV on 14:01, 08 January 15
Well, I hope he tried to give you suggestions where your code fails, otherwise he'd be a lousy teacher (but TBH all of them were, and my nephew claims that all of them still are. ;) )
As a friend of mine says: "If they were good they'd have a proper job" :D
Bryce.
Well, that PDF is great!
I used to have another list in my HD, that I can't find on the internet.
But the PDF has better table to see overview.
Quote from: Bryce on 10:52, 08 January 15
Writing code and writing good code are two completely different things :D
What is good code? How do you define that?
Quote from: Bryce on 14:03, 08 January 15
As a friend of mine says: "If they were good they'd have a proper job" :D
Bryce.
Hum... >:(
:D
Quote from: Bryce on 14:03, 08 January 15
As a friend of mine says: "If they were good they'd have a proper job" :D
Or alternatively, "Those who can, do; those who can't, teach."
Quote from: Nich on 22:19, 08 January 15
Or alternatively, "Those who can, do; those who can't, teach."
Best saying of 2015 - you get the CPC literature nobel price! :)
Quote from: TFM on 22:31, 08 January 15
Best saying of 2015 - you get the CPC literature nobel price! :)
It's not 'my' quote, though! ;) Actually, I don't know who originally said it, even after a fairly thorough search on DuckDuckGo (although there are several variations of this quote that can be attributed to various people).
Well, probably most of the "Doing folks" throw something like that at the "talking folks". :laugh:
Never mind, you can keep the CPC nobel price for literature! :) :) :)
Quote from: TFM on 19:27, 08 January 15
What is good code? How do you define that?
Good code is neat, very efficient and well documented. My code manages 1 out of those 3 :D
Bryce.
Dirty code is for dirty minds :)
Quote from: Bryce on 23:32, 08 January 15
Good code is neat, very efficient and well documented. My code manages 1 out of those 3 :D
Bryce.
Ok, I like this discussion! :) I understand efficient! And I totally agree: that is for me 100% "good" code.[nb]Personally the only thing for me which is important for coding is efficiency. Stability is a prerequisite. Anything else ... I leave it to the teachers. :) [/nb]Documentation is taken strictly not part of the code, because it's not part of the compiled program itself. But it's good manners to document well. However, being able to write efficient code usually lowers the amount of documentation, because the better you get the more the code becomes self explaining. ;) Now what is "neat"?
Bryce,
I have PDF about the zilog chips CPU, DMA, PIO, etc.
Attached is the Z80 CPU timings PDF. The document shows number of cycles which is the clock cycles while the number of T states is the internal mechanism for execution.
The CPC affects these timings in that the VGA chips causes the CPU to WAIT periodically. I understand this to be due to the 6845 chip needing memory access and the management of the RST instructions.
rpalmer
Thanks. Now I have all the documents I need, I just need to find time to use them :)
@TFM (http://www.cpcwiki.eu/forum/index.php?action=profile;u=179): We learnt that writing good code is more than just the program that runs when it's finished:
Efficient: Speaks for itself as you said.
Neat: Means using proper indentation for labels, commands, loops etc so that the structure is easy to read.
Documentation: If documentation is done well, you should be able to hand code over to someone else and they can continue where you left off without having to decypher the code for hours.
Many very good programmers were lousy at documenting, so although the code is efficient, it takes hours to work out exactly how it works and making changes is a really hard job.
Bryce.
You are of course right in your last sentence for the reasons I suggested before. However I think IMHO the final result is all that counts.
Ok, for teaching purposes it may be interesting to show all that structured crap. But for the best solution all the stuff you learn will not help you that much.
An easy to read structure is usually not the quickest.
About Code reuse: Of course it makes sense from a business POV. But not that much from a efficiency POV.
I remember Odiesofts sources. He used like a lot of people MAXAM in ROM (I still prefer it that way) and his source was a collection of lines with dozens of Z80 instructions in every line. And of course no comments at all. Once he complained himself about it. :laugh:
I guess you already have an answer, but this is the reference I always used for CPU timings: Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/docs/instrtim.html)
Actually, all the information you need is usually in the Z80 manual anyway... Taking a random example: ADD IX,pp: T-states: 15 (4, 4, 4, 3)
Each of those logical groups fits neatly into the CPC's usual 4-cycle cadence, the last one will be stretched to 4, 4, 4, 4. So, 4us.
If you look at, e.g. INC ss: T-states: 6, this gets stretched to 8, so 2us.
Another: RLC (IX+d): 4,4,3,5,4,3. The 3, 5 and 3 all get stretched, so 4,4,4,8,4,4, so 7us.
One of the few exceptions to this rule is e.g. JR cc,e. This is 4,3,5 (taken), 4,3 (not taken). In this case, the 3 and the 5 of the taken aren't stretched when you'd expect. Why not? Well, this actually explains what is actually happening and why things gets stretched in the first case...
Every time the Z80 needs to do a memory access, it is delayed using the WAIT signal (which is asserted on 3 of the 4 cycles). In the usual case where one of the M-states gets extended it's because the next M cycle is a memory access (M cycle actually means memory cycle!). In the case of JR, the 3rd M cycle isn't actually a memory access, but a signed addition to adjust the program counter. As it's not accessing memory, the previous M state isn't stretched after all.
So, it's more correct to not think of it stretching the M cycle, but instead not starting the next one that requires a memory access until the 4th cycle.
If you think of it like this, it also explains the weird exception that happens for interrupt handling. Normally, responding to an interrupt adds 1us on the CPC. That's because it actually just adds 2 T states for the interrupt acknowledge before the next instruction fetch. However, in case where the last M cycle takes 6 T states, the interrupt acknowledge doesn't delay the instruction prefetch and so the usual 1us delay doesn't occur.
"Simples!" 8)
Not so simple I'm afraid, What happens with LD (nn),HL or OUT (c),r for instance?...
I still haven't found a 100% satisfactory explanation about how the GA 'drives' the Z80 without interfering its normal behaviour. The WAIT pin alone can't be the only mechanism for instance. This signal increases the duration of the read/write input/output cycles, but it doesn't prevent the z80 from driving the address bus neither the data bus (if is a write/output). So either the GA is multiplexing both buses to isolate them from the z80 when it needs them, or it is also issuing BUSRQ signals toghether with the WAITs at the appropiate moments. Does anybody know what's really going on?
Very interesting reading.
I didn't know about the exception when interrupting some instructions,
and I never got so deep into M-cycles and T-cycles to try to understand.
Tonight, I had to find such detail doc about z80 (http://www.phy.davidson.edu/FacHome/dmb/py310/Z80.Instruction%20set.pdf) to see your numbers.
To have last numbers there so that other guys can get onboard :
LD (nn),HL is (4, 3, 3, 3) -> so why 5 nop-cycles?
LD (nn),HL is (4, 3, 3, 3, 3) -> it's fine
OUT (C),r is (4, 4, 4) -> so why 4 nop-cycles?
EDIT: fixed LD (nn),HL thanks to opqa, a missing 3
some of the messages below refers to this error (striketrough)
Mmm, sorry, it seems that I made a mistake with LD (nn),HL. It is really, (4,3,3,3,3) So it fits into the pattern. It seems that OUT (c),r is the only "anomaly". I've my own theory about the reason, but I'm not sure its the right one. Still thinking about it...
The M-Cycles are the clock's fed to the CPU, while the T-States are simply key points into the Z80 CPU micro-code to execute an instruction.
So for LD (nn),HL the micro-code would be something like:
a. Read the Z80 instruction from memory.
b. Read the address to save HL to (i.e nn).
c. Write the address (nn) to the address bus and write a byte of data.
d. Increment the address nn, write the new address to the bus and write the next byte of data
and for OUT (C),r would be something like:
a. Read the Z80 instruction from memory.
b. Write the I/O address in BC to the address bus
c. Write the data onto the data lines and execute the I/O command sequences.
So you can see that the LD (nn),HL has 4 main executions while the OUT (c),r has 3.
The WAIT line can only affect the CPU when the address/data bus has yet to have valid data, since if it could occur then bus conflict would result and the CPC would not likely function properly. The state of M1 line is also used to know when the CPU can be paused.
The GA does use the WAIT line to "PAUSE" the CPU to allow for other functions like 6845 and RST instructions to work and it makes use of the M1 line to ensure that there are no conflicts.
With this information you can see that the Z80 CPU can be "PAUSED" on ANY instruction by the GA and it is this that makes it difficult get timing's for the CPU execution and why the Z80 DMA is almost impossible to get working on the classic CPC.
rpalmer
i also forgot that the IORQ and MREQ lines also assist to determine when the GA can PAUSE the Z80 CPU.
Attached is the Classic CPC 6128 schematic to show which lines the GA is using.
Quote from: opqa on 19:32, 10 January 15
I still haven't found a 100% satisfactory explanation about how the GA 'drives' the Z80 without interfering its normal behaviour. The WAIT pin alone can't be the only mechanism for instance.
Actually, the WAIT signal alone is the only signal that stretches the instructions, The /WAIT signal is held low for 3 out of every 4 clock cycles. The Z80 ignores the WAIT signal for most of it's internal processing, but checks it at the point where it needs to do a memory or IO read or write. My latest Z80 core implementation for JEMU doesn't have any CPC specific timing, but the CPC holds the wait line for 3 out of every 4 cycles, and the emulation passes all timing tests, including interrupt timing tests (without any special interrupt timing handling like what was there before).
@rpalmer (http://www.cpcwiki.eu/forum/index.php?action=profile;u=379)
I've found this document where it specifies what you're talking about, it breaks down what the z80 is doing on each Machine cycle.
http://z80.info/z80ins.txt (http://z80.info/z80ins.txt)
Forget about LD (nn),HL it was a mistake thinking it was an anomaly. It isn't. It's actually 5 machine cycles that get stretched to 5 nops as usual:
1) Fetch opcode (4 t-states)
2) Fetch parameter (high byte) (3 t-states)
3) Fetch parameter (low byte) (3 t-states)
4) Write memory (high byte in H register) (3 t-states)
5) Write memory (low byte in L register) (3 t-states)
OUT (C),r to the contrary, is made of 3 4 t-states machine cycles but it gets stretched to 4 nops:
1) Fetch prefix (it's an extended instruction) (4 t-states)
2) Fetch opcode (4 t-states)
3) Port Write (4 t-states)
The mechanism that explains this anomaly is much simpler than what you think, as Executioner points , the GA always asserts the WAIT pin 3 cycles out of every 4, and I believe that they are always the same 3 cycles. To understand why OUT (C),r doesn't fit in just 3 nops we must look a little bit deeper, into the t-state level.
@Executioner (http://www.cpcwiki.eu/forum/index.php?action=profile;u=17)
Yes, you're right about the use of the WAIT pin. I think that now I understand what's going on. But in my comment I was talking about something else. The GA needs to access memory 2 out of every 4 cycles, and while doing so the Z80 might be in wait state, this doesn't mean is inactive, ehilr in this state it's always trying to drive the address bus, and if it is a write/output op. what's being held, it will also be driving the data bus with the output value.
What I say is that there must be a parallell mechanism to isolate both buses from the memory when the GA is accessing them. And looking at the 6128 schematic it seems that there is. As I suspected, the address bus is multiplexed with the CRTC, and the GA controls those multiplexers, so it decides when the memory sees the z80 addres and when it sees the CRTC address trough them. Also, the data bus is latched/buffered between the z80 and the memory/GA, and again is the GA who controls those, so it decides when to isolate thee z80 bus from the memory for its own operations.
I will explain in a more detailed way how I think it works in a later post. But to advance, I think that the WAIT pin is held active 3 out every 4 cycles. But the z80 is allowed to read/write to memory 2 out of those 4 cycles.
On every microsecond (nop) the Gate Array has to either do two reads from memory (2 bytes for 16 bits of screen data) or a single 16 bit read. I don't know, but I suspect it only reads 8 bits at a time. The /WAIT signal is held low for 3 out of 4 cycles, and this causes each memory or IO read/write to be aligned to occur just after WAIT goes high. The document you refer to (z80ins.txt) doesn't actually show exactly what happens during each of those cycles, but the official Zilog Z80 user manual does in the TIMING section starting on page 11. It shows exactly when during each cycle the Z80 tests the /WAIT signal (usually T2 of each cycle, or TW in the case of I/O). The stretching of each cycle is actually more of an alignment of T2/TW with the single 1 of 4 clock cycles where /WAIT is high.
I know that, but this isn't incompatible with what I'm saying. I'll explain my theory now. First, I'm going to establish a terminology.
Based on the documens avalible about the Z80 (including the Zilog manual itself), or like this one:
http://www.piclist.com/techref/mem/dram/slide4.htm (http://www.piclist.com/techref/mem/dram/slide4.htm)
we know that the timings for opcode fetches, memory accesses and I/O operations are different. Let's show how:
For opcode fetches:
The complete M-cycle last 4 t-states (4 clocks). But the actual opcode fetch takes place during the first 2, which I'll call T1, T2, the other two are used to refresh memory in machines that use this feature of the Z80, the CPC doesn't. I'll call them R1, R2.
As you say, the wait line is sampled only during T2, and if active, the Z80 adds a wait state after it. The actual opcode fetch (the memory access itself) only takes place at the end of the last wait state, or at the end of T2 if none. Note that even after some inserted wait states R1 and R2 must take place for the machine cycle to complete.
So the cycle without wait states would be:
T-State T1 T2 R1 R2
Read |
And with two inserted wait states (for instance):
T-State T1 T2 Tw Tw R1 R2
Wait | |
Read |
For memory accesses:
The complete M-cycle of a memory access lasts only 3 t-states, T1, T2, and T3.
But this is because there is no RAM refreshing states. So really, in case it is a slower memory acces. As before, the wait line is sampled at T2, and if active it adds a Wait state just after it. More than one wait state can be added, but the actual memory read is not performed until the end of T3.
For write operations, where the actual memory write takes place depends upon the hardware, it can happen earlier in T2 because the address, the data bus, and all the signals are set and stable during the middle of T1, but they are kept until ~ the middle of T3. Probably the CPC sample the bus during T2.
So the cycle with no wait states would be:
T-State T1 T2 T3
Read |
Write |?
And with inserted wait states:
T-State T1 T2 Tw Tw T3
Wait | |
Read |
Write |?
For I/O operations:
Last but not least, the port I/O operations are the slower of them all. They last 4 full t-states without RAM refreshing. Documents avaliable talk about one "automatically inserted" wait state after T2, and so they call this states T1, T2, Tw, T3. Let's follow this terminology.
Now the WAIT line is sampled during Tw (it might be also sampled during T2 but it would have no effect as the processor is going to insert Tw' anyway).
As before, reads are sampled at the end of T3, and as before writes will be sampled whenever the hardware is ready. Signals are present from the middle of T1 on.
So without inserted "extra" wait states we have:
T-state T1 T2 Tw T3
Read |
Write |? |?
And with a couple of extra wait states:
T-state T1 T2 Tw Tw Tw T3
Wait | |
Read |
Write |? |?
Well, all this about how the Z80 works, in a second post I will explain how this "engages" with the WAIT states inserted by the GA, this will explain the "irregular" timing of OUT (c),r.
Well now, the second part, how I think all the above "engages" with the GA. In this part some of the things I'm going to tell are just hypothesis and assumptions.
The GA helds the wait signal 3 out of every 4 cycles. I'm going to call G1 to the only state where the Wait signal is inactive, and G2, G3, G4 to the other three.
I strongly suspect that the GA accesses memory during G3 and G4, and that it isolates the Z80 from the memory during G2, G3 and G4. At least partially, but it might be the case that complete isolation is not performed until G3.
The key point in the schematic of the CPC6128 is that the DATA bus is latched in the direction memory -> z80, and that this latch is controlled by the same READY signal that is connected to the WAIT pin of the z80. So if a read is performed in G2, it's going to read the value that was latched in G1. This way the actual value being held by the memory during this cycle might be different.
Anyway, none of the above affects timing, with my notation, the basic timing would be the following:
GA-state G1 G2 G3 G4
Wait | | |
Let's see how this engages naturally with an opcode fetch for instance.
GA-state G1 G2 G3 G4
T-state T2 R1 R2 T1
Wait | | |
Read |
Note that none of the above wait signals take real effect on the z80, as none is produced during T2, any other is simply ignored. Also note that this is the natural synchronization schema, and if we try any other we we'll end up with this one. For instance, let's guess we begin with T1 in G1:
GA-state G1 G2 G3 G4 G1 G2 G3 G4
T-state T1 T2 Tw Tw Tw R1 R2 T1
Wait | | | | | |
Read |
If we start with T1 in G3:
GA-state G3 G4 G1 G2 G3 G4
T-state T1 T2 Tw R1 R2 T1
Wait | | | | |
Read |
And so on...
In all cases the memory access is taken place during G1. But, let's see what happens when we have an opcode fetch followed by a memory read operation (a typical case):
GA-state G4 G1 G2 G3 G4 G1 G2 ...
T-state T1 T2 R1 R2 T1 T2 T3 ...
Wait | | | | |
Read | |
Now the memory read operation is performed during G2! That's why I said before that the z80 is "allowed" to access memory during 2 out of 4 cycles. It can be either G1 or G2 depending on the current and previous operation.
But, to be honest, and as I said before, what the z80 is really sampling during this clock is the latched sample of the bus that took place in the previous one during G1. So we can really consider that the real memory read takes place always at G1.
In the third and last part, why OUT (c),r doesn't fit in just 3 nops...
As stated in soft968 both memory and io have wait applied so this stretches out operation.
I believe out (c) has a single t state where wait can be applied for slow devices, I think this is where the delay happens.
In pcw docs it says io doesn't have wait so on pcw up should not take as long.
@arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122)
If you mean that the CPC hardware is inserting addional wait states (apart from the ones from the GA). I'm almost sure that this is not the case. It isn't needed at all to explain the timings. Take a moment to read my posts and maybe you'll agree with me.
So let's analyse what happens with out (c),r (or with in r,(c)). This instruction consist of two opcode fetches followed by a I/O port write. As stated before. The I/O port write takes 4 cycles: T1, T2, Tw (automatically inserted), and T3.
So the timings, starting from the second opcode fetch are:
GA-state G4 G1 G2 G3 G4 G1 G2 G3 G4 G1 ...
T-state T1 T2 R1 R2 T1 T2 Tw Tw Tw T3 ...
Wait | | | | | | |
Here we have a first wait state after T2 that is introduced automatically by the Z80, not by the CPC hardware, and a second and third ones that are inserted by the GA because of its fixed timing. So this is where the extra NOP comes from.
Now let's analyse why this doesn't happen with out (n),A. This operation consists of an opcode fetch, a parameter fetch, and an i/o port write.
Parameter fetches have the same timing as regular memory accesses, so just 3 t-states T1, T2 and T3. The complete sequence including all machine cycles is:
GA-state G4 G1 G2 G3 G4 G1 G2 G3 G4 G1 G2 ...
T-state T1 T2 R1 R2 T1 T2 T3 T1 T2 Tw T3 ...
Wait | | | | | | | |
So this instruction fits within just 3 NOPs, because the shorter timing of the parameter fetch gives enough space to the i/o operation to complete within the next NOP.
And that's all. What do you think?
It too took me ages until I believed that the WAIT generation was as simple as it was. I was convinced it used the M1 and IORQ signals to do something more complicated, but no, it really is that simple... Hopefully I'll show you why now... :) This is largely the same as opqa's explanation but explained slightly differently...
For reference, this is what I mean by the Z80 user manual: http://tlienhard.com/zx81/z80um.pdf (http://tlienhard.com/zx81/z80um.pdf) and the important pages start at page 29 (11 in the official numbering).
Instruction Fetch: T1 T2 (checks WAIT) T3 T4 (4+)
Read or Write: T1 T2 (checks WAIT) T3 (3+)
IO: T1 T2 TW (checks WAIT) T3 (4+) - later I'll refer to this as just T1 T2 T3 (checks WAIT) T4
For now, forget the labels T1, T2 etc and just consider the states that check the WAIT signal. So, we now have:
IF: -*--
RW: -*-
IO: --*-
OUT (c),r is described on page 298 (280 official numbering): 4,4,4 (IF, IF, IO)
Writing this out in terms of WAIT states, we have: -*-- -*-- --*-
Aligning this up with the CPC's wait states (I'll add a NOP also, -*--, but any instruction is the same):
vv the NOP's fetch T state is stretched by 1 T-state until the next gap
-*-- -*-- --__ _*-- _*--
1234 1234 12__ _341 _234
W.WW W.WW W.WW W.WW W.WW
^^ ^^ this T state is stretched by 3 T-states until the next gap
As you can see, 4 extra cycles have been inserted, but it's not as simple as just adding 1us to the IO cycle (even though that is the visible effect, it's actually 2 separate stalls)...
We can also see the difference to OUT (n), A which you might expect to take 4us not 3us...
Page 297 (279 official), shows OUT (n),A as: 4,3,4 (IF, RW, IO) - note the shorter 2nd M cycle... ;)
Writing this out in terms of WAIT states, we have: -*-- -*- --*-
Aligning this up with the CPC's wait states (I'll add a NOP also, -*--, but any instruction is the same):
vv the NOP's fetch T state is stretched by 1 T-state until the next gap
-*-- -*-- -*-- _*--
1234 1231 2341 _234
W.WW W.WW W.WW W.WW
^ note that this T state does align perfectly
So, even though the wait check check occurs 1 T state later in the IO M-cycle compared to the others, because it follows an M cycle, it starts 1 T state earlier and so it aligns perfectly.
Hopefully, that makes things clearer. If I've confused you more, I can try to explain it differently... :)
I think that's almost exactly what I was saying. It really is as simple in the CPC as EVERY memory or I/O read/write operation is aligned with cycle n (0..3) of every 4 cycles. The latest JEMU source code proves that a Z80 implementation designed using only the fetch, mem read, mem write, I/O read and I/O write operations with timing exactly as per the Zilog user manual can be made to have exactly the same timing as a real CPC by aligning the /WAIT to one the 4 cycles (I'm not sure which one it's actually high on, you'd have to either test with a CRO from reset or read the GA logic. It could also be determined by the exact position of palette changes etc).
If you look at the way it actually works, it is possible for a NOP (or any other 4 T-State instruction) to actually take 7 T-States to complete. If the previous instruction had been 5, 9, 13, 17 or 21 T-States.
Although I asked the question, I stopped understanding the posts in this thread back on page one :D
Bryce.
Quote from: Executioner on 02:37, 12 January 15
It really is as simple in the CPC as EVERY memory or I/O read/write operation is aligned with cycle n (0..3) of every 4 cycles.
Well, I disagree a little bit about this, as I explain at the end of this post (http://www.cpcwiki.eu/forum/programming/cpc-z80-commands-and-how-long-they-take/msg92352/#msg92352), from the z80 point of view, the read operations can take place either on first or second cycle out of every 4. Opcode fetches will take place always on first cycle, but memory reads and i/o inputs will take place one cycle later. Anyhow this small detail doesn't change the overall timing.
Quote from: opqa on 10:07, 12 January 15
Well, I disagree a little bit about this, as I explain at the end of this post (http://www.cpcwiki.eu/forum/programming/cpc-z80-commands-and-how-long-they-take/msg92352/#msg92352), from the z80 point of view, the read operations can take place either on first or second cycle out of every 4. Opcode fetches will take place always on first cycle, but memory reads and i/o inputs will take place one cycle later. Anyhow this small detail doesn't change the overall timing.
Actually op-code fecthes occur in the same cycle as /WAIT goes high, whereas memory reads and IO occur on the next cycle after /WAIT goes high, so the data has to be available 1 T-State after /WAIT goes high. This does suggest that the GA doesn't do memory reads during those two cycles and the Z80 can, but the /WAIT signal still only goes high for 1 cycle. It's only an assumption, but I'd think the internal operation is something like (using your terminology):
G1: /WAIT high, address and data bus multiplexed for Z80 use
G2: /WAIT low, address and data bus still for Z80 use
G3: /WAIT low, CRTC address on address bus, memory read into GA shift register
G4: /WAIT low, CRTC address + 1 on address bus, memory read into GA shift register
Quote from: Nich on 22:19, 08 January 15
Or alternatively, "Those who can, do; those who can't, teach."
I recently heard the same quote from a greek friend. Too many teachers and professors here. But few who know how to code or do/did something practical in their career.
Quote from: TFM on 23:02, 09 January 15
I remember Odiesofts sources. He used like a lot of people MAXAM in ROM (I still prefer it that way) and his source was a collection of lines with dozens of Z80 instructions in every line.
Strange. I am doing that too. I even hate it when an assembler doesn't support this with semicolon.
It's kinda like grouping many opcodes that do one thing in my mind.
Else, you have those listings with one opcode below the other (and with TABs), but then one single routine could be five pages long, instead of summarized in a single page.
Or when I unroll loops manually, it's one line with many opcodes separated by semicolon. So I copy this line many times. Imagine if every next line of this was a new opcode..
As for the discussion, it reminds me of that little joke that says: Pick any of two: Elegant, Fast and Small.
Well, that clearly shows that you can code! :)
Maybe they will not ever call it 'good code', but your's will always be faster. :laugh:
Quote from: Executioner on 10:45, 12 January 15
It's only an assumption, but I'd think the internal operation is something like (using your terminology):
G1: /WAIT high, address and data bus multiplexed for Z80 use
G2: /WAIT low, address and data bus still for Z80 use
G3: /WAIT low, CRTC address on address bus, memory read into GA shift register
G4: /WAIT low, CRTC address + 1 on address bus, memory read into GA shift register
It makes the design of the GA a lot simpler to use alternate cycles for the video memory accesses, but you're right it could be that way too.
However, the reason I think my way is more likely is this:
On the original 464 gate array, pin 1 is ¬CPUADDR, pin 40 is MA0/CCLK. Not only is MA0/CCLK used for A0 during a video access, it's also the clock for the AY chip. This is 2MHz into the the AY, rather than 4MHz, so it's either 50:50 duty cycle and the video memory is accessed every 2nd cycle or it's a 75:25 duty cycle and the video memory is accessed the way you describe. It's also possible that ¬CPUADDR and CCLK are both 2MHz and out of phase though... BTW, the CPU clock is output on pin 39.
Again more clues that it's my way is that there's a 74LS373 which latches the data from RAM output/GA data bus during the memory read cycle and holds it on the CPU side data bus. This shouldn't be needed if there's a long CPU side ownership of the RAM chips. (The 74LS244 isn't part of this process - it's so that the GA can peek at the CPU side data bus during the RAS latch period when the RAM isn't outputting anything so that the GA can read data sent to its IO port).
There is, of course, a simple way to answer this - attaching a scope to pins 1 and 40 of the gate array and watching what happens to those signals... :)
Quote from: ralferoo on 22:25, 13 January 15
There is, of course, a simple way to answer this - attaching a scope to pins 1 and 40 of the gate array and watching what happens to those signals... :)
Only simple if you have a scope of course :)
Isn't the clock frequency of the AY 1 mhz rather than 2 mhz?
Quote from: robcfg on 12:08, 14 January 15
Isn't the clock frequency of the AY 1 mhz rather than 2 mhz?
Yes, the AY runs at 1Mhz.
Bryce.
True this. Therefore the CPC has a cool bass. Now for other frequencies use the PlayCity.
I love that discussion and clarification on the interrelation of the GA and the Z80.
Another thing that bothers me a bit here is how the Z80 and the GA synchronise themselves at startup, or if they need to at all. The Z80 does a 2 cycle delay before it commences work, but there is no info about the GA in this case. (But I'm sure an oscilloscope can make that procedure a simple task. ;) )
That bit seems a bit esoteric for all practical purposes, but it would still be nice to know it.
Quote from: MaV on 15:03, 15 January 15
I love that discussion and clarification on the interrelation of the GA and the Z80.
Another thing that bothers me a bit here is how the Z80 and the GA synchronise themselves at startup, or if they need to at all. The Z80 does a 2 cycle delay before it commences work, but there is no info about the GA in this case. (But I'm sure an oscilloscope can make that procedure a simple task. ;) )
That bit seems a bit esoteric for all practical purposes, but it would still be nice to know it.
I would like to know this so I can emulate it. :)
Quote from: MaV on 15:03, 15 January 15
Another thing that bothers me a bit here is how the Z80 and the GA synchronise themselves at startup, or if they need to at all. The Z80 does a 2 cycle delay before it commences work, but there is no info about the GA in this case.
I'm not sure it matters, actually...
Normally the latches in the 2-bit counter the GA uses for the 4-cycle counter would have random values (or even indeterminate values) on reset unless the hardware makes a particular effort to clear them on reset. However, on the first clock cycle, the adder would interpret these bits as either 0 or 1 and so on the next clock cycle they would have a defined value. So, the GA could have a random number of cycles between 0 and 4 before ¬WAIT becomes high and the Z80 can proceed.
However, if I remember rightly the colour palette is reset to black (but not the border colour), so in that case the GA would have reset circuitry and so they might have forced the 2-bit counter to an initial value. That's considered good practice, but not always necessary.
Quote from: ralferoo on 10:07, 16 January 15I'm not sure it matters, actually...
That's what I implied with "esoteric". It probably has no practical impact, if it is left out. (But wouldn't you just love it to call your emulator or FPGA implemenation 100% correct? ;) )
However, I can see the necessity of knowing this for replacement gate arrays (in CPLD, FPGA or whatever other form) once those chips begin to fail in bulk (which is a long way away if Bryce is correct).
QuoteHowever, if I remember rightly the colour palette is reset to black (but not the border colour), so in that case the GA would have reset circuitry and so they might have forced the 2-bit counter to an initial value. That's considered good practice, but not always necessary.
That's an interesting observation. I know what I'm going to do, once I receive my scope. :D
The GA is running well within it's specs and runs relatively cool at all times. So it very unlikely that a GA would fail unless you powered the CPC with 12V or reversed the poles.
Bryce.
In JavaCPC, you have an array of instructions chrono for Z80 and another for Amstrad's Z80. You can compare them (this way is better for emulation)
It is modulo 4 in order to alternate the 2 RAM access purpose : VRAM=>CRTC (pixels) and RAM<=>Z80 interactions. CRTC is truly linked to WAIT_n of Z80 (this way is better for FPGA)
An exception is just done on MEM_WR that takes 1 more modulo-4-times cycle than it's own modulo 4 cycle.
In FPGA I used a hacked WAITn Z80 entry (original WAITn of FPGA Z80 has problems due to delta time between under hidden 8080 recycled code source (8080 is encapsulated in Z80, in Z80 FPGA version (called T80, opencores.org))
The pdf posted in the first page has some errors...
1.PUSH IX/IY and POP IX/IY cant take 5 nops.. POP is always faster 1 nop
2. A command DEX HIX is a mistake
Please fix if you agree..
Fascinating thread, it's answered a lot of questions I've had about how the Gate Array interfaces with the CPU. I'm on the lookout for a little more information and I'm hoping one of you might be able to help me out. I'm currently trying to figure out the exact Z80 instruction timings from the Z80 Users Manual, which I found at: http://www.phy.davidson.edu/FacHome/dmb/py310/Z80.Instruction%20set.pdf (http://www.phy.davidson.edu/FacHome/dmb/py310/Z80.Instruction%20set.pdf)
I have a question on the grouping of the T-states. For example, DJNZ if 0 takes 8 T-states. What I'm interested in is how the T-states are broken down, in this case it's two groups of T-states, (5,3). What do these groups of T-states represent? 5 and 3 represent? I'm hoping they show how many T-states the CPU spends in a particular a cycle of execution e.g. 5 T-states spent in the fetch cycle and 3 T-states spent in the decode and execution cycle. Is this correct? If so, is there any documentation on which CPU cycle of execution is represented by the numbers for each instruction? For example, RLC (IX+d) has 23 T-states which are separated into 6 groups of T-states. What are the 6 different states that the CPU is in for each group of T-states? I've looked through the manual and I can't seem to find this info, though I may have just missed it!
The reason I'd like to know this is that I'm attempting to implement Wait on my Z80 emulation so that I can emulate how the Gate Array uses it in order to arbitrate between the CPU and CRTC access of memory. If I can emulate this timing correctly, time critical effects such as rasters should finally look correct.
From what I understand, the CPU needs to be in a particular type of machine cycle in order to honour the request to wait. I've read that it will honour a wait request if it's in the fetch, memory read, IO or interrupt acknowledge cycles, so I need to emulate the different states in order to get Wait to work correctly.
I'm after a complete version of what's on the Wikipedia page for the Z80: https://en.wikipedia.org/wiki/Zilog_Z80 (https://en.wikipedia.org/wiki/Zilog_Z80), the table under the "Instruction execution" section which shows what the machine cycles are for a few instructions. Is there a version of this for all Z80 instructions including undocumented ones?
The official Zilog docs are a pretty good place to start, they include details of how many M-Cycles an instruction is broken down into and how many T-states each of those M-Cycles take. Unfortunately no details of the exact breakdown of what each M-Cycle is doing, but you can usually have an educated guess.
http://z80.info/zip/z80cpu_um.pdf
Thanks Andy, I think that's what I'm going to have to do. From what I understand, it only matters when the CPU is in a cycle that accesses memory. In those scenarios, it has to wait so that the Gate Array can access memory first. I can debug through the existing code and see where the memory read and writes are occurring which will allow me to build up an idea of how it all goes together. Fortunately the Z80 class is broken down nicely into a series of sub methods which I can hopefully use to determine the type of machine cycle that's in progress.
Thanks again for the heads up.
Cheers,
Damien
In order to understand the Z80's wait input pin, you have to understand why it was provided. The wait input does not actually stop the Z80 if the Z80 is not accessing the address and data busses.
The idea behind the wait input is very simple. It allows slow devices to be directly connected to the data bus. When wait is asserted and a transaction is taking place on the data bus, the Z80 will continue to hold the address lines steady, if writing, it will continue to hold the data bus lines steady. It will continue to do this until the wait line is de-asserted. At which point, the Z80 will complete the bus transaction. This then enables hardware to signal the Z80 that it is accessing slow memory or slow I/O devices. As detailed above, the bus transaction is synchronised to the Z80 clock.
Amstrad very cleverly made use of this feature (as have other designers previously) to use it to synchronise the Z80 CPU to a video system that requires regular memory read accesses. This is why there are chips that isolate the Z80 address and data bus from the RAM address and data bus lines.
Mark
Yes, that's my understanding too and it makes perfect sense, there's no need to do anything on a wait signal if the CPU is only working internally.
It is a clever way to arbitrate the sharing of memory access between the CPU and CRTC - simple yet elegant!
I'm attempting to figure out how DJNZ = 0 takes 3us to execute. So here's my theory:
The Z80 user's manual states that it takes 8 T-states to execute the instruction using 2 machine cycles, one lasting for 5 clock cycles, the other lasting for 3. Timings of the instruction on the CPC are 3us. I believe the cycles are:
Machine Cycle 1 - Decrement B (5 T-states)
Machine Cycle 2 - Check if B is 0 or not 0 (3 T-states)
I'm assuming the CRTC 1Mhz clock is derived from the 4Mhz CPU clock by sending a clock pulse to the CRTC every 4th CPU clock cycle. The only way I can see that DJNA = 0 could take 3us is if, when the execution of the instruction ends, as it coincides with the 4th Clock cycle - the Gate Array is looking to read 2 screen bytes from memory to draw the next line for a column. On the 4th Clock Cycle, the DJNZ instruction has finished executing and the Z80 is about read from memory to retrieve the next instruction. At the same time, the Gate Array sets WAIT to low and holds it there for 2 cycles as it retrieves 2 bytes from memory in order to draw the next line of the next character. This causes the CPU to wait for 2 cycles and therefore extends the number of T-states for machine cycle 2 for the DJNZ instruction from 3 to 5. The timing for DJNZ = 0 therefore ends up as:
Machine Cycle 1 - Decrement B (5 T-states)
Machine Cycle 2 - Check if B is 0 or not 0 (3 T-states) + 2 T-states held by Gate Array reading 2 bytes from memory (5 T-states)
The timing for DJNZ = 0 becomes (5,5) or 3us.
Does this sound plausible? Since DJNZ = 0 does not require the Z80 to access memory I cannot see how else the instruction timing could be stretched to 3us.
The current version of JEMU has all the instruction break-downs, it doesn't have a table of times. https://sourceforge.net/p/jemu/code/HEAD/tree/JEMU/src/jemu/core/cpu/Z80.java (https://sourceforge.net/p/jemu/code/HEAD/tree/JEMU/src/jemu/core/cpu/Z80.java)
The only thing it doesn't currently emulate properly is the SCF/CCF flag bit 5/3 handling. The CPC implementation holds the /WAIT signal high for 3 of every 4 T-States so all reads and writes get aligned to the same (of each 4) clock cycles.
Richard, thank you for the source code, I think it's going to be very useful - though I do feel a bit guilty that I'm effectively plagiarising your hard work!
I see from your implementation of DJNZ that you're reading the jump address upfront which completely changes my theory on the operation of that instruction. In your sequence of events there is a memory read of 1 byte during the instruction, to get the address of the label we need to jump to (I'd forgotten for a moment that this is a relative jump so it can only be a signed byte in size thus representing a jump of 128 bytes backwards or forwards).
It looks like I can figure out the times by counting up the calls to the cycle() method.
Thanks for the info, I shall use it to rethink my theory.
Cheers,
Damien
Weird changing font there. It was so small I couldn't read it, now it's larger than normal. The JEMU Z80 core is based on the original Java core I wrote but completely re-worked based on a combination of http://z80.info/z80ins.txt (http://z80.info/z80ins.txt) and the original Z80 User Manual (http://z80.info/zip/z80cpu_um.pdf) which also has a break-down of cycles (and many errors, but that's ok if you use common sense).
Yes the html editor is (as all I've come across) a little unpredictable, I try make sure I paste text in from Notepad to avoid additional formatting, but occasionally it sets the font size to tiny when I press the reply button. There's probably some devious logic at work somewhere just to keep us on our toes. Mind you I think anyone willing to write code in Javascript deserves a medal, it really is one of the worst languages. Anyway, hopefully my previous reply is now at a more expected font size!
One thing I am beginning to realise is that when it comes to emulation, new information causes a constant reworking of code - still if it makes it more accurate then it's all worth it. I'm very impressed with both WinAPE and Kev's Arnold emulator. I can't promise to ever reach your heights, but that won't stop me from trying!
Thanks for the additional info, it will be very useful. I'm still relatively new to emulation but I do feel like I'm genuinely getting a grip on it - but the wish to perfect is something that's difficult to resist!
Sorry about the random post earlier - it seems that you can't delete posts on this forum - or I just can't work out how!
So I've been through DJNZ in your Java CPC Z80 class, and I believe the timings can be derived as follows:
DJNZ = 0
======
- 5 T-states. 4 T-states to fetch the opcode including 1 T-state to check wait, 1 T-state in the DJNZ method - for the decrement
- 3 T-states for Fetchbyte including 1 T-state for checking wait
DJNZ != 0
======
- 5 T-states. 4 T-states to fetch the opcode including 1 T-state to check wait, 1 T-state in the DJNZ method - for the decrement
- 3 T-states for Fetchbyte including 1 T-state for checking wait
- 5 T-states for the relative jump (jre)
It's interesting that the processor fetches the relative jump address before checking whether b is 0. You could potentially save 3 T-states by not doing this until the value of b has been determined. In this scenario, if b were 0, 3 less T-states would be required.
Quote from: endangermice on 23:00, 27 October 16
It's interesting that the processor fetches the relative jump address before checking whether b is 0. You could potentially save 3 T-states by not doing this until the value of b has been determined. In this scenario, if b were 0, 3 less T-states would be required.
That would not quite work. You would still need to increment the PC, so the next instruction read is actually the next instruction, and not the jump address.
So, you could skip the actual memory read, but you would still need to increment the PC, which would still use some T-States.
In the end it is simpler to use the same "fetch from PC and increment PC" as everywhere else, instead of wasting some space for a dedicated "increment PC without fetching" operation.
Yes, you're quite right - thanks for pointing that out. Hmmm I guess my career as a CPU designer has been cut tragically short!
Quote from: endangermice on 23:00, 27 October 16
Sorry about the random post earlier - it seems that you can't delete posts on this forum - or I just can't work out how!
So I've been through DJNZ in your Java CPC Z80 class, and I believe the timings can be derived as follows:
DJNZ = 0
======
- 5 T-states. 4 T-states to fetch the opcode including 1 T-state to check wait, 1 T-state in the DJNZ method - for the decrement
- 3 T-states for Fetchbyte including 1 T-state for checking wait
DJNZ != 0
======
- 5 T-states. 4 T-states to fetch the opcode including 1 T-state to check wait, 1 T-state in the DJNZ method - for the decrement
- 3 T-states for Fetchbyte including 1 T-state for checking wait
- 5 T-states for the relative jump (jre)
Checking for wait doesn't take any tstates. Let me explain whats going on here:
Standard z80 instructions execution cycle consists of up to 3 machine cycles. Each machine cycle can contain up to 6 clock cycles (tstates) for M1 cycle and 3-5 tstates for other Mx cycles.
First machine cycle (M1) fetches the opcode and it can take up to 6 tstates:
t1 - pc to address bus,
t2 - reading memory addressed by address bus, pc is incremented.
t3 - transfer opcode read in t2 into instruction register, refresh memory
t4 - decode, execute, refresh memory
t5 (optional) - execute
After fetch opcode optionally there are memory read machine cycles - depending on instruction size it can be 1-3 such cycles (M2, M3, M4).
M2,M3,M4 cycle usually takes 3 tstates:
t1 - pc to address bus,
t2 - reading memory addressed by address bus, pc is incremented.
t3 - transfer byte read in t2 into temporary internal register
The difference between M1 and M2,M3 machine cycles is the timing of MREQ signal - in case of M1, it goes inactive at the beginning of t3 tstate and in case of M2,M3 it goes inactive during t3 tstate.
The important part is that checking for wait doesn't take any tstates - if external device applies wait on the cpu pin during the cpu memory reads/writes or i/o, the execution of the next tstate is held until the device stops signaling.
In case of cpc, the gate array sets wait on cpu to read the screen memory. As it was mentioned earlier in this thread, GA generates waits during 3 of 4 tstates.
The number of wait states impacts all instruction machine cycles that require memory access.
So, in case of djnz, you got:
for b=0
clk 1234567890123456
Z80 12345123
GA -___-___-___
CPC 1222234512ww3
for b<>0
clk 1234567890123456
Z80 1234512312345
GA -___-___-___-___
CPC 1222234512ww312ww345
To fit to the well known timings of cpc, it seems that GA waitstates are applied differently ie. _-__ and not -___, so the real timing will look a bit differently:
clk 1234567890123456
Z80 12345123
GA _-___-___-__
CPC 1234512www3
for b<>0
clk 1234567890123456
Z80 1234512312345
GA _-___-___-___-__
CPC 1234512www312345
Why single 1 machine cycle instructions (like di, xor a etc) are not affected by the wait states generated by GA? Their execution timing consists of only M1 cycle, where the address bus is used during t1 and t2 states - if GA wait state is applied starting from t2 state, the cpu doesn't need to wait for memory in t3 and continues execution until next memory access (next opcode or M2)
T 1234
GA _-__
CPC 1234
Quote from: endangermice on 23:00, 27 October 16
It's interesting that the processor fetches the relative jump address before checking whether b is 0. You could potentially save 3 T-states by not doing this until the value of b has been determined. In this scenario, if b were 0, 3 less T-states would be required.
The timing for djnz suggests otherwise - b is checked before fetching the jump offset. And you will not save 3 tstates by skipping the offset fetch - if b=0, you'll still need to increment pc which will take at least 1 tstate.
I believe that approach you suggested could complicate the cpu pipeline design.
Hi Docent,
Firstly, thank you for a very detailed explanation of how the cycle timing works - I think it will help me to under the process a lot more. However I don't quite understand how your diagrams relate to your explanation.
From your explanation of MREQ for M1 and M2,M3,M4 cycles etc. I understand MREQ to work in the following way
M1
==
t1 = MREQ (Memory request)
t2 = MREQ (Memory request)
t3
t4
M2
==
t1 = MREQ (Memory request)
t2 = MREQ (Memory request)
t3 = MREQ (Memory request)
Am I right in assuming that when MREQ is active the CPU intends to read memory during those t-states? I.e. in the case of M1 - t1 and t2 are memory read cycles which could be affected by wait? In the case of M2 - t1, t2 and t3 are all t-states where the CPU expects to read memory and again they could be affected by wait?
If this is the case, I am confused by the CPC part of the diagrams you've drawn for me. If you refer to the b=0 diagram. I believe I understand the part for M1. When the wait is applied, it isn't responded to by the CPU until the t-state that follows. So if wait is applied in t2, the CPU won't respond until t3 and only if t3 is a memory read which for M1 is it not. That explains why M1 in your diagram executes the 5 t-states without any wait being applied.
I am confused the diagram of M2 in the CPC part of the diagram. It appears that in the case of M2, t3 doesn't require memory access. If that is the case, why is there a wait inserted between t2 and t3 (2w3)? I can understand t2 running when wait is applied because the wait was applied during t2 but why is there a single wait before t3 (described as the transfer of the byte read in t2 into a temporary internal register) if t3 is not accessing memory? Should the CPC section be 123451www23 rather than 123451www2w3, similarly for b!=0 should it be 123451www2312345 rather than 123451www2w312345 which would also coincide with the instruction taking 16 cycles rather than 17, bringing it inline with the 4us of execution time expected by the WinAPE timing tests.
I hope this makes sense - I just can't see how the CPU is responding the Gate Array wait signal, it doesn't seem to be stopping at the right time. I think I may not be understanding your diagram properly so if you could explain a bit more I would be very grateful.
Thank you for all your help so far,
Damien
Quote from: endangermice on 13:19, 01 November 16
Hi Docent,
Firstly, thank you for a very detailed explanation of how the cycle timing works - I think it will help me to under the process a lot more. However I don't quite understand how your diagrams relate to your explanation.
From you explanation of MREQ for M1 and M2,M3,M4 cycles etc. I understand MREQ to work in the following way
M1
==
t1 = MREQ (Memory request)
t2 = MREQ (Memory request)
t3
t4
M2
==
t1 = MREQ (Memory request)
t2 = MREQ (Memory request)
t3 = MREQ (Memory request)
It is generally ok - in M1 cycle MREQ goes off at the beginning of t3, while in M2, M3 it goes off in the middle of t3
Quote from: endangermice on 13:19, 01 November 16
Am I right in assuming that when MREQ is active the CPU intends to read memory during those t-states? I.e. in the case of M1 - t1 and t2 are memory read cycles which could be affected by wait? In the case of M2 - t1, t2 and t3 are all t-states where the CPU expects to read memory and again they could be affected by wait?
If this is the case, I am confused by the CPC part of the diagrams you've drawn for me. If you refer to the b=0 diagram. If MREQ is active for t1 and t2 of M1, why doesn't your diagram show a wait between t1 and t2 of M1? By the time M1 reaches the start of t2, wait is being held low by the Gate Array. t2 is a memory read so the CPU should be waiting, but your diagram shows it reading memory? Why is this?
Similarly, t1 for M2 should be a memory read, yet in your diagram, the CPU is not waiting for the read despite wait being held low by the gate array. Also, you show t2 and t3 for M2 executing during a period where the wait signal is also being held low. How is this happening and why is there a wait between t2 and t3?
I hope this makes sense - I just can't see how the CPU is responding the Gate Array wait signal, it doesn't seem to be stopping at the right time. I think I may not be understanding your diagram properly so if you could explain a bit more I would be very grateful.
Everything will become clear if you take into consideration that:
a. z80 did not test wait signal during t1 state
b. wait states are accounted for in the following cycles
So, when GA signals cpu to wait in t2 state, cpu detects it during t2 and holds execution of next t3 state until wait is not active.
Hi Docent,
Thank you for the further explanation, it really helps. I read back through this thread again and after reading ralferoo's post a few times it suddenly clicked and I realised that adding the wait states is actually very simple. Simply put as Richard (Executioner) has said many times, all that's happening is that memory / io accesses are aligned with the wait states imposed by the Gate Array. this has the effect of stretching the instruction lengths in some circumstances (if the instruction's execution involves the access of memory or io.)
I was struggling because my impression was that the Gate Array holds the 1st cycle of every 4 high for io / memory access. I think as ralferoo states, it's actually the 2nd cycle in every 4 that is held high. If you work on that assumption, DJNZ b<>0 becomes 16 cycles not 17 which fits the 4us instruction timing perfectly. The wait state timing is therefore w.ww w.ww w.ww w.ww w.ww (wait low, wait high, wait low, wait low).
I have begun to implement this in my Z80 emulation and most of the timing tests are now passing. The ones the aren't are likely due to coding errors on my part and it's also possible I still have a few issues with the interrupt timing.
If I can at least get the instruction lengths correct and the Gate Array wait states working then I only have to work on the interrupt timing and it should all come good!
I'm sure I will have some further updates and likely more questions.
Thanks for all the help!
Damien.
So a bit of an update. After reworking my Z80 emualtion, I now have most timings passing the test - hooray! However, I'm having trouble with the DD codes. Seeing as DD is a prefix instruction, two fetches have to be made which is where the 2us timing is derived for instructions such as nop (1us per fetch). Say we're looking at a prefixed nop so 0xDD followed by 0x00. If we go by ralferoo's description from the Z80 user's guide that a fetch can be represented as -*-- where cycle 1 is the memory read, this is only going to take the expected 2us when the first fetch is exactly aligned to the first cycle, cycle 0 in the 4. e.g.
-*-- -*--
w.ww w.ww
0123 0123
if the first fetch starts on say cycle 3 (due to the previous instructions ending before cycle 3), we get a situation like the following:
- _*-- -*--
w w.ww w.ww
3 0123 0123
The first fetch has been stretched by 1 cycle so now the whole instruction takes 9 cycles to complete, which rounds up to 3us. This is exactly what is happening when I run the DD codes through my emulator. This also means that for instructions with tight timings like this i.e. anything that's an exact multiple of 4 cycles, it's not possible to predict the instruction timing. If 0xDD was 3us I think this would fit no matter what the starting cycle.
I obviously have something wrong here, but I'm just trying to apply ralferoo's workings to this situation and in practice, during the PlusTest on my emulator, the DD codes seem to start execution on cycle 3. To get consistent readings the start cycle shouldn't matter so what's going on here?
Quote from: endangermice on 21:08, 02 November 16
Hi Docent,
Thank you for the further explanation, it really helps. I read back through this thread again and after reading ralferoo's post a few times it suddenly clicked and I realised that adding the wait states is actually very simple. Simply put as Richard (Executioner) has said many times, all that's happening is that memory / io accesses are aligned with the wait states imposed by the Gate Array. this has the effect of stretching the instruction lengths in some circumstances (if the instruction's execution involves the access of memory or io.)
I was struggling because my impression was that the Gate Array holds the 1st cycle of every 4 high for io / memory access. I think as ralferoo states, it's actually the 2nd cycle in every 4 that is held high. If you work on that assumption, DJNZ b<>0 becomes 16 cycles not 17 which fits the 4us instruction timing perfectly. The wait state timing is therefore w.ww w.ww w.ww w.ww w.ww (wait low, wait high, wait low, wait low).
Hi Damien,
Good catch! The timing example I described earlier was indeed based on assumption that the GA sets wait states starting from the second cycle but only _-__ GA wait state cycle seems to work for all timings.
btw: I also made a mistake in applying waitstates to M2, M3 cycles - somehow I assumed wait states are checked from t1 state and not from t2 like they are in reality. and I even wrote that later :( Anyway, it seems that you got this working.
Quote from: endangermice on 20:05, 03 November 16
So a bit of an update. After reworking my Z80 emualtion, I now have most timings passing the test - hooray! However, I'm having trouble with the DD codes. Seeing as DD is a prefix instruction, two fetches have to be made which is where the 2us timing is derived for instructions such as nop (1us per fetch). Say we're looking at a prefixed nop so 0xDD followed by 0x00. If we go by ralferoo's description from the Z80 user's guide that a fetch can be represented as -*-- where cycle 1 is the memory read, this is only going to take the expected 2us when the first fetch is exactly aligned to the first cycle, cycle 0 in the 4. e.g.
-*-- -*--
w.ww w.ww
0123 0123
if the first fetch starts on say cycle 3 (due to the previous instructions ending before cycle 3), we get a situation like the following:
- _*-- -*--
w w.ww w.ww
3 0123 0123
The first fetch has been stretched by 1 cycle so now the whole instruction takes 9 cycles to complete, which rounds up to 3us. This is exactly what is happening when I run the DD codes through my emulator. This also means that for instructions with tight timings like this i.e. anything that's an exact multiple of 4 cycles, it's not possible to predict the instruction timing. If 0xDD was 3us I think this would fit no matter what the starting cycle.
I obviously have something wrong here, but I'm just trying to apply ralferoo's workings to this situation and in practice, during the PlusTest on my emulator, the DD codes seem to start execution on cycle 3. To get consistent readings the start cycle shouldn't matter so what's going on here?
You need to account for the remaining t states from tha last machine cycle of a previous instruction. Lets see what will happen in such case:
clk 1234567890123456
GA _-___-___-___-__
T 12341234
T+1 12www341234
T+2 12ww341234
T+3 12w341234
T is the time to execute an instruction like DD00 (8 tstates), when total tstates, taken by the previous instruction is 4 aligned ie 4, 8 etc tstates (generally tstates mod 4=0).
When there is a remainder from previous instruction timing, the first opcode fetch is stretched by waitstates it the way, that it correctly aligns to the beginning of next machine cycle.
Please notice, that no matter how many unused tstates have left from previous instruction, it will start execution of the following instruction correctly aligned to GA waitstates.
Hey, thanks for the replies - I think we're getting closer, a lot of very useful info. The only problem I have with
clk 1234567890123456
GA _-___-___-___-__
T 12341234
T+1 12www341234
T+2 12ww341234
T+3 12w341234
Is that in all but T, the instruction is taking more than 8 clock cycles to complete (T + 1 = 11 cycles, T + 2 = 10 cycles, T + 3 = 9 cycles). Therefore, for T+1, T+2 and T+3, the time of execution is going to round up to 3us. When I run the DD code tests through Richard's utility, it always expects DD:00 to be 2us in length. I can't see how this can be possible unless DD is perfectly aligned each time which with previous instructions of different lengths is in my mind far from certain. This is why I'm sure there's something else happening here that I'm not appreciating.
It may be that this is expected behaviour and my problem lies elsewhere e.g. timing with the interrupts. It would be useful to know whether DD:00 for example should have a different time of execution depending on the starting cycle. It is interesting that it is both the DD, FD and FD CB tests that are mostly failing. All of the normal instructions, the ED and CB prefixes are passing so I feel that I'm very close. I'm not passing many of the interrupt timing instruction tests which suggests my interrupt timing is out (I've been trying to fix but need to study the mechanism in more detail). This might be having a knock-on effect for the DD tests.
This is all because I want to make the Z80 cycle exact. I could probably get away with us timing, but I really want to get the cycle level emulation right!
Sorry I haven't been around for quite a while. Busy moving and other stuff. It really doesn't matter which cycle the WAIT signal is released (0, 1, 2 or 3) as the Z80 will adjust itself to be aligned so that T3 on each fetch, mem and IO request is aligned to the point where /WAIT goes high, so it actually doesn't matter if you use -___, _-__, __-_ or ___-.
The current (and it hasn't changed in at least 12 months) JEMU code passes all the timing tests, but doesn't currently have the SCF/CCF flag test implemented properly. WinAPE doesn't use the same T-State level emulation and instead has a flag to determine which T-State the previous instruction would have ended on which affects the timing for Interrupt requests (they have a 2 T-State time window before a fetch).
The unreleased WinAPE 2.0B3 passes all the tests, including ZEXALL and SCF/CCF tests. I'll try and release the current 2.0B3 version of WinAPE this next week or so as I need to get on with implementing new features that I don't have time to put in this release.
can't wait to read the whatsnew.txt file ;D
Regarding the CPC timing of Z80 instructions, all the documents linked here (and all others I've seen) contain errors.
I've made a doc (as an Orgams source Z80.O) free of those errors. You can download it here (http://orgams.wikidot.com/working).
It also comes with Z80tests.O, which allow to visually check the timing of any instructions, and demonstrates some undocumented flag behaviours.
Sorry, link doesn't work
EDIT: Works again! Must have accessed at the wrong moment in time twice. :laugh:
Hum?!? Works for me! What do you get?
You can try this instead: RC2 DSK (http://orgams.wdfiles.com/local--files/working/orgams-210111-EE-RC2.dsk)
The link Gunhed complains about doesn't work indeed: it points on the late push'n'pop website.
Thanks for the feedback! I don't understand, though.
http://orgams.wikidot.com/working
The forum is mixing up links again; for me it's currently pointing to a linkedin post. ???
@Gryzor (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1), your assistance is needed :)
Maybe the link in my signature works, and then go to working section.
Anyway, this link should already be in the bookmarks and the hearts of everyone!
...now it appears to be fixed?
It's pointing to www.z88dk.org for me now :picard2:
What is pointing there though.
Sorry, it's the "here" link on https://www.cpcwiki.eu/forum/programming/cpc-z80-commands-and-how-long-they-take/msg196635/#msg196635 (https://www.cpcwiki.eu/forum/programming/cpc-z80-commands-and-how-long-they-take/msg196635/#msg196635).
Which periodically changes it's address, not with every page load but maybe when a new comment forces the cache to be updated? And just now it was pointing to the right place again - maybe it only screws around when it knows you're not looking at it :D
Oh damn it seems I forgot the Heisenberg option set to "on"!
Ok, let me force a cache cleaning...
Quote from: m_dr_m on 04:58, 13 January 21
Maybe the link in my signature works, and then go to working section.
Anyway, this link should already be in the bookmarks and the hearts of everyone!
Indeed and indeed. My problem was probably a mixing up of links, since your post didn't show the link in detail I couldn't see where it was intended to go. It was a forum problem indeed. Please keep you signature though. :laugh: :laugh: :laugh:
Thanks Gryzor for fixing this!
Thanks Toms for this superb layout. (https://64nops.wordpress.com/2021/01/13/perfectly-accurate-z80-flags-and-cpc-timing/)
Quote from: m_dr_m on 16:12, 14 January 21
Thanks Gryzor for fixing this!
Thanks Toms for this superb layout.
This link works, but the link from there is broken, you need to change into:
http://memoryfull.net/articles/64nops/z80.o-v1.0.5.txt
(the current unworking link is: http://memoryfull.net/articles/64nops/z80.o-v1.0.4.txt)