@manuel. about tcl flexibility

Por PingPong

Prophet (3793)

Imagen del PingPong

07-06-2009, 13:10

@manuel: the flexibility that scripting adds to openMSX is not yet explored. One can do everything want (almost).
For example, expecially in msx2 development one thing is extremely usefull is to know the rate of use of the command engine, expressed in % and referred to 1 frame time.

For example if a command is executing for 5ms, assuming the frame is 20ms the percentage should be 25%.
I think could be done in similar way:
- at start of vblank set a counter = 0
- when a command start keep track of the time.
- when a command ends counter += (now-starttime).
- at the next vblank %usage = 100 * counter / frame time, then counter =0

Do you think could be done with tcl?

This helps a lot to identify situations where vdp is the bottleneck. And also can be useful to learn how vintage games use vdp.

Login sesión o register para postear comentarios

Por wouter_

Champion (469)

Imagen del wouter_

07-06-2009, 20:36

I already wrote such a script some time ago:

namespace eval vdp_busy {

variable curr_cnt 0
variable last_cnt 0
variable after_id

proc reset {} {
	# each frame copy current counter to last counter and reset current counter
	variable curr_cnt
	variable last_cnt
	variable after_id
	if [info exists after_id] {
		set last_cnt $curr_cnt
		set curr_cnt 0
		after frame vdp_busy::reset
	}
}

proc sample {} {
	# 100 times per frame, sample if VDP command engine is busy
	variable curr_cnt
	variable after_id
	if [info exists after_id] {
		incr curr_cnt [expr [debug read "VDP status regs" 2] & 1]
		set fps [expr ([vdpreg 9] & 2) ? 50 : 60]
		after time [expr 0.01 / $fps] vdp_busy::sample
	}
}

proc display {} {
	# a couple of times per second update the OSD
	variable last_cnt
	variable after_id
	osd configure "vdp_busy.text" -text "${last_cnt}%"
	set after_id [after time .25 vdp_busy::display]
}

proc toggle_vdp_busy {} {
	variable after_id
	if [info exists after_id] {
		after cancel $after_id
		osd destroy "vdp_busy"
		unset after_id
	} else {
		osd create rectangle "vdp_busy" \
			-x 5 -y 30 -w 42 -h 20 -alpha 0x80
		osd create text "vdp_busy.text" \
			-x 5 -y 3 -font skins/Vera.ttf.gz -rgb 0xffffff
		display
		reset
		sample
	}
	return ""
}

namespace export toggle_vdp_busy

} ;# namespace vdp_busy

namespace import vdp_busy::*

To use this script, either put it in your openmsx/share/scripts subdirectory or execute the command 'source <script-filename>' in the openMSX console. After that, use the 'toggle_vdp_busy' command to enable/disable an on-screen vdp-busy-percentage indicator.

This script is relatively big because it displays the result directly in the top left corner on the display. Together with the logic to enable/disable this display it takes up almost half of the script.

The core of the script should be easy enough to understand, so feel free to tweak it until it exactly matches your needs.

Por Manuel

Ascended (18252)

Imagen del Manuel

08-06-2009, 09:21

Note that this is a polling based script (it's not possible yet to get a trigger when the VDP status bit changed in openMSX), now polling at 100 times per frame.

Wouter, is this enough? What's the typical duration of a VDP command? If it's in the same order of time as 1/100 frame, then you might get awful aliasing and as a result a very unreliable measurement. If it's (much) larger, then it's probably OK. If it's much smaller, than the polling frequency is way too low.

I'm sure you've thought about this, but I'd like to see some numbers Smile

Por PingPong

Prophet (3793)

Imagen del PingPong

08-06-2009, 14:35

I already wrote such a script some time ago:

Sorry, wouter, i've completely forgot about this. Nice! i will try soon.

Por PingPong

Prophet (3793)

Imagen del PingPong

08-06-2009, 14:40

Note that this is a polling based script (it's not possible yet to get a trigger when the VDP status bit changed in openMSX), now polling at 100 times per frame.

Wouter, is this enough? What's the typical duration of a VDP command? If it's in the same order of time as 1/100 frame, then you might get awful aliasing and as a result a very unreliable measurement. If it's (much) larger, then it's probably OK. If it's much smaller, than the polling frequency is way too low.

I'm sure you've thought about this, but I'd like to see some numbers Smile
I think that considered the slowness of VDP, 100 times per frame is enough, expecially for block move command.
Would be nice to allow some form of callback tcl script to be called when a particular vdp or memory location change.

Por wouter_

Champion (469)

Imagen del wouter_

08-06-2009, 17:42

I think that considered the slowness of VDP, 100 times per frame is enough, expecially for block move command.
I also believe 100 is enough, block commands typically take much longer to complete. For very short commands (like PSET), the VDP will not be the bottleneck (the Z80 is), and thus this busy indicator is anyway not very useful.

Would be nice to allow some form of callback tcl script to be called when a particular vdp or memory location change.
It is already possible to set callbacks on memory and IO read/writes. On top of these primitives you can often build the functions you need (e.g. monitor IO port 0x98 to detect VRAM writes).
I agree it would be even more powerful to be able to set callbacks directly on any 'debuggable', but that would also mean a (possibly big) slowdown in emulation speed.
The current watchpoints could be implement without ANY slowdown for the case the callback does not trigger. For example writes to a memory region without any attached callbacks are not any slower than compared to an emulator without watchpoint functionality. So there is NO 'IF (watchpoint-on-this-location) THEN trigger-callback' code before every read/write. But for watchpoints on generic 'debuggables' I (currently) don't see a way to avoid this extra test (emulation speed is still important for embedded devices).

Por Manuel

Ascended (18252)

Imagen del Manuel

24-08-2013, 23:41

FYI: I now added this script to openMSX (if only to keep it easy to find ;-))