for hw experts... (2)

Why do you need it - what is your objective? Your VDP works too slow or PC works too fast?
only as an help for msx1/2 computers.
Most games, usually insert sw delays when talking with vdp.
those, does not work very well, depends on cpu clock, hw, and are somewhat complex to optimize on the last drop.

so, programmers often choose the slowest interval, and does not get optimal performaces.

My idea is a simple circuitry, that can insert 0 to 4 wait states every access to vdp, selectable via sw.

A sw can auto-detect with probing the min number of delays that is needed, set it and does not worry about different timings between different cpu speed, or the type of out instruction used.

doing this via sw is possible but less flexible.

The final question is:
Can i pull down from a cartridge the logical wait signal to z80 to halt cpu when it's talking with vdp without causing short circuit?

about different timings between different cpu speed
MSX1 and MSX2 use 3.57MHz standard clocking frequency for CPU.

Agree, there's a good practice to insert NOP between out/in to VDP (single M1 cycle - 4 clocking periods), but insertion of /WAIT for every VDP read/write is not wise: there're much less situations when slowdown is really required than when they are just waste of CPU time.

But a hw wait is more reliable than sw delay
Prove it. Objectionable statement.

delays cannot be exactly achieved because of mismatch between the various z80 T-States needed to execute various instructions.
When programmers write programs, they know CPU commands they write. If they know commands, they can get to know timing of the commands. As soon as they know timing of the commands they can calculate delays. If they know delays, they can see if these delays satisfy VDP requirements.
Thus it is more about quality of programming on this platform.

The absence of a hw delay is clearly a flaw in the vdp design
I see it as a feature. CPU and VDP are working asynchronously to each other. Handshake like DMA/bus request takes some time and cycles slowing down machine as well as increasing cost of the PC.

Good or bad, it is made this way. If we would ever have MSX3 standard, I am sure developers would address this issue.

Now let's see what you can do. If you will use "delay cartridge" you have two options of using system clock for delay counting, or have separate clocking schematic in cartridge. Former method will have no difference with software NOP delay as it will use the same frequency as PC does (whateher MHz it is running on). Latter method is universal one, but will require some triggers and logic in your cartridge.

And finally, MSX redbook says the following "MSX1/2: Z80A or equivalent (clock 3.579545 MHz +- 1%)", thus running your MSX PC at 7 MHz is formally not supported configuration. At supported clock frequency MSX PC is expected to work without problems, and if you overclock it you introduce problems which you have now to solve, but MSX standard itself or designers are not liable for this.

@Eugeny: you are missing the point:

I'm NOT QUESTIONING about if it's better sw delay or hw arbitration, (for me the latter is better).
I'm only asking if i can pull down the Wait signal when i decode an i/o operation on some address. that's the original question.

About your discussion:

Prove it. Objectionable statement.

Easy to do:

when you output a byte to vdp you MUST take into consideration the *WORST* case, because you cannot really predict what the vdp is doing (horz. retrace, vert. retrace). Even in active area, on known situations, you cannot predict none.
You can only say: "at least the vdp will write my data in 8us, so i wait for this time". Pratically a access window can occur from 0 to 8us. By waiting the worst case, you assure that the byte will be stored, but you are missing the ability to use the real time needed to perform the operation.

If the vdp had a hw signal that say "ok, data trasferred", the time to wait is actually the time needed to write the data. It can be for example 8us, but can also be 2us.

Programs often cannot output at a constant rate for various reasons, and with hw sync one can use every bit of time.

When programmers write programs, they know CPU commands they write. If they know commands, they can get to know timing of the commands. As soon as they know timing of the commands they can calculate delays. If they know delays, they can see if these delays satisfy VDP requirements.

Programmers work on a machine, the outside world is made up of modified msx. Brazilian people often overclock their msx.
It's often unpredictable to know everything.
Plus the sw solution is the worst in terms of optimization. inserting whatever delay does not help to squeze every drop of the already slow vdp access.

For example, suppose you have a routine that output data to vdp. you are actually able to output 1 byte every 25 z80 t-states, but you discover that vdp requires at least 27 t-states between each out. So you are forced to insert the stupid NOP, that on msx const additional delay 5 t-states. Now, your routine takes 30t-states and you loose 3 t-states every out.
Please don't tell me that is a irrilevant time. On a limited machine such an 8 bit, often you need to gain all you can.

A clear example is found on fudeba (a msx user) words: when converting a zx speccy game for msx, he said it have FOUR different vdp write routines:
1) normal z80
2) 5/7mhz one
3) vblank
4) R800

And probably it's not addressing every possible configuration.
In its convertions, the gain in speed, i assure you, are noticeable if running at 7mhz. it's worth to use the 7mhz mode, if available, because improve the smoothness.

So fudeba IS forced to make this replication of routines because of the absence of hw support.
he could (off course) do only the first routine, but not taking advantage of additional speed.
With hw handshaking, none of this problems appears.

The absence of a hw delay is clearly a flaw in the vdp design
I see it as a feature. CPU and VDP are working asynchronously to each other. Handshake like DMA/bus request takes some time and cycles slowing down machine as well as increasing cost of the PC.

It's not true, in my mind the delay is introduced not every time you access, but only if THE LAST ACCESS is yet busy.
(like an S1990/ R800 does)

this approach allows much better use of cpu time, because the operations works asynchronously if possible, only stopping cpu when last access is not yet completed.

About the cost of the machine let me say two things:

- i'm not taking into account this, for obvious reasons. the logic needed is actually not expensive.
- only watching at cost is the primary reason of the crappy vdp implementation. without an extremely obsessive attention to cost the vdp could be another chip.

And i'm not speaking about super improvements in it's architechure. Only little changes could be made the difference.
But this is another story. Does not have nothing to do with the original question.

@PingPong: sorry if it got too hot here

Quote:
Prove it. Objectionable statement.
Easy to do:
Exmplanation accepted. And using VDP for clocking CPU is an attempt to synchronize the bus.

And probably it's not addressing every possible configuration.
Agree.

- only watching at cost is the primary reason of the crappy vdp implementation. without an extremely obsessive attention to cost the vdp could be another chip.
And the good example of it is that MSX is made of "standard" building blocks, invetnted in US - Z80, TMS9918 which seem to be not much modified from CPU side up to V9958. None just was thinking of overclocking that time. BTW, there are other places in MSX where slight problem with timing may make it inoperable...

asking if i can pull down the Wait signal
Dennis answered well - you will use chip with open collector output to get /WAIT line down. You should not short-circuit it to GND.

You seem to know subject very well. Why do you ask then?