wait 15 T-States between reading and writing to Vram

Página 2/6
1 | | 3 | 4 | 5 | 6

Por sdsnatcher73

Prophet (3007)

Imagen del sdsnatcher73

09-01-2022, 20:01

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

Por Grauw

Ascended (10561)

Imagen del Grauw

09-01-2022, 20:24

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.

Por norakomi

Paragon (1121)

Imagen del norakomi

09-01-2022, 20:18

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.

Por Bengalack

Hero (571)

Imagen del Bengalack

09-01-2022, 21:31

norakomi wrote:

@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?

Por inchl

Resident (59)

Imagen del inchl

09-01-2022, 21:44

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

Por Grauw

Ascended (10561)

Imagen del Grauw

09-01-2022, 21:40

I’m not certain but I expect that indeed only the data will corrupt.

Por inchl

Resident (59)

Imagen del inchl

09-01-2022, 21:57

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

Por PingPong

Prophet (3885)

Imagen del PingPong

09-01-2022, 22:21

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

Por Grauw

Ascended (10561)

Imagen del Grauw

09-01-2022, 23:12

inchl wrote:

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.

Por inchl

Resident (59)

Imagen del inchl

10-01-2022, 07:47

Already read! Excellent research!

Página 2/6
1 | | 3 | 4 | 5 | 6