is there a direct way to detect VBLANK period on TMS VDP via hw?

i mean: it's possible to create a hw that allow via a in a,(someaddr) to get a byte that means: 'vblank' or 'not vblank' time?

i see only one solution: catching the int out from vdp then starting a countdown for vblk time to know if it's vblk or not.
Anyone could find a better solution?

thx

you want to detect 50/60hz ?
or measure how long vblank lasts ?
i mean it should last the same on every 50hz machine for instance

The idea was a small cart to allow a msx1 the following:

- being able to know if the vdp is active area or not via sw.
- being able to get a WAIT signal for z80 when one addresses the VDP without using sw timing that have a lot of problems, such cpu speed, differences in how long the delay should last depending on the active/blank area.

Having a proper hw timed WAIT allow the sw to not worry about timings and GET the maximum transfer speed in every situation.
Unfortunately delays also depend on screen mode, but this can be 'configured' by sending a configuration byte to the cart.

Will improve transfer speed
and is BETTER than the R800 wait because take into consideration also the active area

Maybe this could be added to this idea:
http://www.msx.org/forumtopicl10792.html

... for example in form of resetable drawline counter (= counter running at 15716.99 Hz speed)... Maybe even with interrupt support?

i dont understand ...

i really do not know if it's possible. maybe other devices trigger interrupts....

@Leo :what is unclear?
the reason of the hw cart?

It's simple:

this code writes 10 bytes to vram:

ld hl,someaddr
ld b,10
ld c,0x98
otir

however this code does not work always. If the vdp is in active area display data comes to fast from the z80 so vdp misses some bytes.

Instead if vdp is in vblank this code works well.

Programmers are forced to delay writes in active area, and to have two or more write routines one for active area (slow) and other for vblank (fast).

Sometimes, a fast transfer started in vblank ends when the vdp has already reached to draw the active area, dropping bytes.

Plus on a z80 @7Mhz the software delay must be trimmed to take in account the greater speed.



Having a WAIT signal from the vdp is the ideal solution. Unfortunately the vdp had not.


My idea is simple:

- Monitor when an interrupt is triggered (means that vdp has started vblank)
- Start a countdown.
- Until the countdown reaches zero we are in vblank so the normal outs from z80 are not affected by any wait signal, because we ARE IN VBLACK
- If the counter reaches zero, then outs from z80 to vdp should raise a WAIT signal of proper duration.
- The counter then restart at every interrupt to count-down the vblank duration.

Additionally having the ability to test if the counter has reached zero via a "in" instruction would be great.

@Leo: do you think is doable?

i really think i am missing something ....

interrupts are triggered when vdp start vblank ?
if you do :
halt
call transfer_highspeed_byte_with_otir

it works if your block size is not big enough.

lets put numbers even if they are not correct just to illutrate :
during vblank:
you can transfer 1000 byte in 60Hz with z80=3.5MHz
you can transfer 1200 byte in 50Hz with z80=3.5MHz
you can transfer 2000 byte in 60Hz with z80=2x3.5MHz
you can transfer 2400 byte in 50Hz with z80=2x3.5MHz
during display:
you can transfer 2x1000 byte in 60Hz with z80=3.5MHz
you can transfer 2x1200 byte in 50Hz with z80=3.5MHz
you can transfer 2x2000 byte in 60Hz with z80=2x3.5MHz
you can transfer 2x2400 byte in 50Hz with z80=2x3.5MHz


so if you have to tranfer N bytes
halt
call transfer_high_speed_for_the_max_num_of bytes
call transfer_the_rest_at_low_speed

See you sync on interrupts and start hi-speed for a while,
this duration is deterministic for a vdp+Z80 config , you can
take some margins , and if you have to transfer a large or
continious amout of bytes you do a wait for interrupt with
halt then transfer hi speed then when you now new screen
display will arive after some bytes you on low speed function
then when you know the next vblank is about to arrive you
take some margin and do a halt before and here you go again
for next loop

no need fo extra hardware ?

Quote:

.... no need fo extra hardware ? ....

of course, pratically most already do in this way, but is far better to have this controlled by hw. plus does not depend from cpu speed. this feature should have been there already on first msx1..

C64 had this. Amstrad had this. speccy had this.
on those machines there were not need to create strange tricks as the above mentioned to do vram access. hw took care of sync.

VDP 9958 has wait output , right ?

yes. getting an msx2+ to have a wait is a bit too much. i mean a feature to have in hw it on tms9928. this is the vdp that most have to gain to this feature. even the v9938 does not suffer at all from out speed, at least at normal 3.5Mhz.

plus it's unclear to me to what kind of situation apply the wait on v9958, maybe only to vdp command execution, not vram i/o transfers