[?] investigate the CPU/VDP9958 /WAIT interface behaviour
[?] clean documentation (blog)
Thesis:
as described in the datasheet (V9958-Technical-manual_v1.0.pdf) of the 9958 there are different timings given for different kind of writes. as far as we understand there are the following timings
first 2 bytes send to vdp during a write are always register writes which require a short delay of just 2µs
the write of the 3rd byte (after the 2nd) requires a delay of 8µs. any further "single byte transfer" - during a vram write - also requires the 8µs delay. the same is true if we want to initiate a register write direclty after a vram write.
the 3rd and n-th byte write to port #3 (index register port) during a bulk register write requires only the 2µs between each byte
Therefore we can optimize a little bit by using different "nop slides" for address setup and vram writes.
Another interesting thing is, "how does the /WAIT" behave in this situation? the assumption here is, that the /WAIT will behave in the way specified so it will be low at least after 130ns from CSW. so to handover the /RDY handling to the vdp via the /WAIT pin, we have to apply only 1 wait state from our WS-Gen. after one wait state, we can release the /RDY low from our WS so that the vdp /WAIT can drive /RDY as needed.
this requires
[Issue created by mlauke: 2018-06-13]
[Last updated on bitbucket: 2018-10-22]
[Comment created by mlauke: 2018-10-19]
ref #40
+fix api
→ <<cset 14b0516d95c9>>
[Comment created by mlauke: 2018-10-19]
ref #40
+fix wrong value handling
+fix gfx7 samples
→ <<cset 231963b98e0b>>
[Comment created by mlauke: 2018-10-19]
ref #40
+revision timings
+test TMS9929 compliance
+test TMS9958 compliance
→ <>
[Comment created by mlauke: 2018-10-19]
ref #40
+finally - 1 cycle accuracy
→ <<cset 06e8a05a21a1>>
[Comment created by mlauke: 2018-10-18]
ref #40
+timings, improved nopslide
→ <<cset 46499135d3ab>>
[Comment created by mlauke: 2018-10-18]
ref #40
+refactoring gfx lib, nopslides, waits, macros, api
→ <>
[Comment created by mlauke: 2018-10-14]
ref #40
+try vdp with only one wait state
twoinke
commented
12 months ago
v9958 should be evaluated...
Thesis: as described in the datasheet (V9958-Technical-manual_v1.0.pdf) of the 9958 there are different timings given for different kind of writes. as far as we understand there are the following timings
Therefore we can optimize a little bit by using different "nop slides" for address setup and vram writes. Another interesting thing is, "how does the /WAIT" behave in this situation? the assumption here is, that the /WAIT will behave in the way specified so it will be low at least after 130ns from CSW. so to handover the /RDY handling to the vdp via the /WAIT pin, we have to apply only 1 wait state from our WS-Gen. after one wait state, we can release the /RDY low from our WS so that the vdp /WAIT can drive /RDY as needed. this requires
[Issue created by mlauke: 2018-06-13] [Last updated on bitbucket: 2018-10-22]
[Comment created by mlauke: 2018-10-19] ref #40 +fix api
→ <<cset 14b0516d95c9>>
[Comment created by mlauke: 2018-10-19] ref #40 +fix wrong value handling +fix gfx7 samples
→ <<cset 231963b98e0b>>
[Comment created by mlauke: 2018-10-19] ref #40 +revision timings +test TMS9929 compliance +test TMS9958 compliance
→ <>
[Comment created by mlauke: 2018-10-19] ref #40 +finally - 1 cycle accuracy
→ <<cset 06e8a05a21a1>>
[Comment created by mlauke: 2018-10-18] ref #40 +timings, improved nopslide
→ <<cset 46499135d3ab>>
[Comment created by mlauke: 2018-10-18] ref #40 +refactoring gfx lib, nopslides, waits, macros, api
→ <>
[Comment created by mlauke: 2018-10-14] ref #40 +try vdp with only one wait state
→ <<cset 8afde736e1ee>>