Okay this may be out of my league but isn’t the number of cycles between I/O in the second example 14 cycles?
After the 12th cycle of the in instruction rhe /IORQ will go high (meaning no I/O). It will remain high for cycles 1 upto and including 14 of the out instruction and will go low after that (before cycle 15 starts).
Actually it is also 14 cycles in example 1 if my logic is not flawed (which it may be of course)…
Depends on whether you count cycles between the end of the first /IORQ and the start of the next /IORQ, or cycles from the start of the first /IORQ to the start of the next /IORQ. The difference stemming from that the /IORQ signal lasts 3 cycles (2.5 actually).
I always count the time between the start of /IORQ signals. It’s easier and maps best to what happens in real hardware. The device you’re communicating with will sample the I/O at a fixed moment after /IORQ is signaled, so in practice you can count the time between the start of the /IORQ signals.
Really what matters most is that people count the same way when they specify wait times. In my experience people and documents always specify the time between the start of /IORQ signals. For example the 12-cycle wait that the YM2413 documentation requires after address writes, it means that on a standard MSX Z80 you can OUT address and data back-to-back.
most excellent explanation Grauw.
I'm super thankful for this. I never could have gotten this out of the z80.pdf handbook.
I will defenitely read the 2 articles you linked.
thank you !!!
@aineko thank you for thinking along with me !
@metalion an 'IN' instruction will increase the Vram pointer, just like an 'OUT', 'OUTI' and 'INI'. They all behave the same way.
@metalion an 'IN' instruction will increase the Vram pointer, just like an 'OUT', 'OUTI' and 'INI'. They all behave the same way.
It is very tempting to use IN in this way. I guess there aren't too many times you will see the need for it, but for SAT it makes sense, when only coordinates are updated. I'm currently doing outi on all data in the SAT even if the pattern and color remains the same all the time. cutting cycles from 18 to 12 on 50% of the commands is of course tempting.
Do we know that there are no artifacts or side effects by using IN when VRAM adressing is set to write?
Indeed good explanation! Still one thing I would like to know. Is it just the vram data that is corrupted when doing a to fast write and will the vram pointer be updated ok? Sometimes its an acceptable situation that vram gets (or could become) corrupted for just few bytes and have a routine speedup for 5-cycles (when doing animations its most of the time not even noticable).
out (c),r is 14 cycles. You would expect each 14/15 bytes a corrupted byte when the requirement is a wait of 15 cycles. But by experiment that does not happen. When doing a full page draw, most of the time all bytes are ok, sometimes only a few are incorrect... any thoughs about this?
code:
out (c),a
out (c),b
out (c),d
out (c),e
out (c),h
out (c),l
etc...
the msx should have required a hw wait driven from the VDP (which is the only device that REALLY knows if can or not accept data,) from the beginning in order to maximize the I/O speed.
Judging from the number of times of this kind of questions pops out on MRC i think there is a lot of confusion about this issue
out (c),r is 14 cycles. You would expect each 14/15 bytes a corrupted byte when the requirement is a wait of 15 cycles. But by experiment that does not happen. When doing a full page draw, most of the time all bytes are ok, sometimes only a few are incorrect... any thoughs about this?
code:
out (c),a
out (c),b
out (c),d
out (c),e
out (c),h
out (c),l
etc...
Please read the VRAM timing articles part 1 and part 2. These clarify how the VRAM access slot mechanism works, and have charts that show that the access slots are unevenly spaced which explains why the access time is variable.
