1 extra cycle added when OUTing to VDP (on some cases)

Hi again,

Since this morning, I found this: "waitstate generator".

http://www.msx.org/wiki/Compatibility_testing
V9958 has a built-in waitstate generator that can be enabled by software
bit 2 "WTE" of the V9958's R#25

doc V9958
When the CPU accesses the VRAM, accesses to all ports on V9958
is held in the WAIT state until access to the VRAM of V9958 is completed.

http://www.msx.org/forum/msx-talk/hardware/does-enabling-wai...
(...) so there is one cycle of cpu clk

Finally, I'm going to test this (z80 enabled, neither R800 nor overclocking z80):
VDP(25)=VDP(25)and251

Am I right? dunno!

I'm back!

What I'm talking about is explained there:
http://www.msx.org/forum/msx-talk/hardware/vdp-speed-curious...
Briefly: yes, on MSX2+ and MSX turbo R when z80 enabled at its original speed,
OUTs take "a bit" more time than on MSX1 or MSX2.
I did not write "a bit" but exactly one extra cycle on each OUT.
Measurement thru openMSX confirms 13 cycles for OUT(#99),A
See below, if needed, for détails.

That said, my remote friend was able to boot/configurate his Panasonic FS A1-WSX
to then behave like a standard MSX: getting 12 cycles on OUT(#99),A
My question: technically speaking, how? any idea?
I now understand that the V9958 wait state generator is not used there.
So? that extra wait cycle is generated by the MSX-engine, isn't it?
I still haven't found much about them (T9769B or T9769C),
I'm OK with port #40 and #41 to overclock the z80 on Panasonic msx2+,
but is there any other port (or any other mean) to enable/disable that extra-cycle on OUT?

----

I like to count cycle, so I count them thru openMSX.
I wrote my own command:
t0 to reset cycles counter,
dt to see how many cycles since the reset.

Prereq:
variable old_time 0

New commands:

proc t0 {} {
	set machineid [machine]
	set err [catch {set mtime [${machineid}::machine_info time]}]
	if {$err} {
		return ""
	}
	set cpu [get_active_cpu]
	set cycle_freq [expr {[machine_info ${cpu}_freq]}]
	set t [expr {$mtime * $cycle_freq}]
	set dt "t="
	append dt [format "%18s" [expr {$t -$::old_time}]]
	append dt "\n                              | "
	set ::old_time $t
	return $dt
}

proc dt {} {
	set machineid [machine]
	set err [catch {set mtime [${machineid}::machine_info time]}]
	if {$err} {
		return ""
	}
	set cpu [get_active_cpu]
	set cycle_period [expr {1.0 / [machine_info ${cpu}_freq]}]
	set t [expr {$mtime / $cycle_period}]
	set dt ""
	append dt "t=     "
	append dt [format "%20s" [expr {$t -$::old_time}]]
	append dt "\n                               | "
	return $dt
}

It isn't advisable for user software to change the V9958 built-in waitstate settings. From the wiki article:

One characteristic of the MSX standard is that you cant count on a given VDP I/O speed. Different machines will have different speeds, depending on their design. The MSX wasn't designed for "running against the raster" style of programming.

e.g. hblank is so late that I get the first effect on the left pixels of display area, horrors. Together with jitter it is 50 pixels into the screen.
Need timed cpu wait to ge to the right side to do something outside display area.
And every turbo is a new unknown thing asking special code for it...

I first sync on hblank and then afterwards check whether there actualy is a line interrupt. Then between interrupt and hblank fits quite some code, i.e. app code can have quite some DI zone without messing the line interrupt.
I got realtime OS things in mind

I added some IN 0x99 and the TR with slow VDP brake ends up taking roughly same time for the whole code as z80.
At that point I wondered whether VDP acess was made so slow that the average line interrupt code still works
And then one can set one VDP register and then one is back into display area.
It needs much ado but one can have tidy splits.

Could you point to the specific post? I’m curious.

Note btw that in my experiment I mentioned above, I was not outputting to the VDP.