It's common to read that the tms requires 28 T-States between each output to vram in the active area.
In the tms manual however it's clearly stated that the VRAM address setup requires 2 delay of 2us. The window for another vdp access is however 6us. So after a first delay only 6us are needed. In this scenario, a OTIR should work fine, even in the active area. I cannot understand why people say that otir does not work outside vblk?

Can some one give me an explanation?

OTIR = 23 t-states = 6.4us that is greater than the access window....

Yes, it was explained in some document (I can find it if any are interested) that in screen 2 (and probably screen 1 but not sure about the others), the memory accesses are scheduled so that 1 out of every 16 are available for CPU reads or writes. 16 cycles on the 2.68MHz VRAM bus is less time than 23 cycles on the Z80's 3.58MHz clock. So it seems that OTIR should work then, but has anyone tried it? I don't have an MSX1. (I do have a TI99/4A but have never written machine code on it

OTIR doesn't work on MSX1 in screen 1 and 2 when sprites are used. Worst case delay between two consecutive outs is 29 T-states (although I have had no problem with 28 T-states between outs). See http://www.msx.org/forumtopic7755p60.html for more details.

Quote:

OTIR doesn't work on MSX1 in screen 1 and 2 when sprites are used. Worst case delay between two consecutive outs is 29 T-states (although I have had no problem with 28 T-states between outs). See http://www.msx.org/forumtopic7755p60.html for more details.

I've seen, however this appear strange to me, that otir could work without sprites and not with (i understand that sprites on screen means more vram fetch).
The vdp docs does not make any hint about sprites and i think the time i've seen on the tables IS the worst case. However i must trust your experience, so actually i'm guessing where is the trick.....

Confused.....

I thought that on MSX1 the sprites are always on, and there is no way to disable them.

Quote:

I thought that on MSX1 the sprites are always on, and there is no way to disable them.

Yes, it's true, i think dvik said 'when there are sprites' meaning :

"when the VDP has to process all the sprites on the screen or scanline".
Most probably as happen with the c64 the more sprites you have the more vram access you need.
However i still think the VDP is not so smart ( stupid TMS engineers ) to use the free sprites cycles to allow more bandwith to the cpu. I, instead think that the vdp uses a statically fixed amount of time to process the sprites, without regard if you have them on screen or not.

Sprites can be disabled by putting y=208 in the first position of the SAT
208 is a delimiter, so the SAT positions after the one marked are not processed at all.
(the TMS manual says so).

@PingPong: You can find a lot of interesting info about how the TMS distributes its processing time between tasks in this document

That posting is what I was referring to. It says clearly that the maximum time for a byte to get from CPU to VRAM (after the VDP delay, and waiting for a free VRAM cycle to come around) is 8us. What is not clear to me, is whether another byte can be written to $98 before the last one gets to VRAM... or in other words, can the "VDP delay" and "waiting for an access window" happen in parallel? If not then I can see that OTIR might result in bytes being lost whenever the VDP delay causes it to miss the access window... since the Z80's writes won't line up consistantly with the 1/16 access window

If the engineers were really smart they should have added a signal that could be used to halt the CPU whenever a read or write happened before the VDP was ready, so it could catch up. Having to use NOPs and such as a bandaid to the timing problem basically crippled the MSX standard until the end.

Quote:

@PingPong: You can find a lot of interesting info about how the TMS distributes its processing time between tasks in this document

thx, i already have read the doc. (The doc is the source of my question actually)

Quote:

Sprites can be disabled by putting y=208 in the first position of the SAT 208 is a delimiter, so the SAT positions after the one marked are not processed at all. (the TMS manual says so).

I know, but i do not believe that y=208 can stop the vdp from parsing the SAT (it would be toooo smart). For me it is only stopping the load of the sprites in the 4 internal buffers.
I think even with the first sprite = 208 the vdp continue to scan all the sat for the other 31 entries, it only stop to load the buffers when one sprite has a line that fall into the current scanline.
I will be surprised if anyone proves that:

The vdp stop effectively to read SAT
the available bandwith is used for the CPU ( tooooooo much smart for lazy TMS engineers)