Benchmarking - Revision history

Mizapf at 18:09, 14 January 2012

2012-01-14T18:09:44Z

← Older revision		Revision as of 18:09, 14 January 2012
Line 14:		Line 14:
	== Timer main program ==		== Timer main program ==

	For my benchmark experiments I use the same frame program which launches the tests that are included. I split the parts of the program in order to explain them one after another. The complete file can be downloaded as a TIFILES ~~file~~ or on a ~~sector dump~~ image.		For my benchmark experiments I use the same frame program which launches the tests that are included. I split the parts of the program in order to explain them one after another. The complete file can be downloaded as a file in [[TIFILES format]] or on a [[Sector Dump Format]] image.

			* [http://www.mizapf.de/ti99/benchmark.tfi benchmark.tfi]
			* [http://www.mizapf.de/ti99/benchmark.dsk benchmark.dsk]

	DEF START		DEF START

Mizapf at 16:49, 14 January 2012

2012-01-14T16:49:06Z

← Older revision		Revision as of 16:49, 14 January 2012
Line 1:		Line 1:
	Using the on-board real-time clock (RTC) we can do a lot of interesting tests on the Geneve, in its MDOS and GPL mode.		Using the on-board real-time clock (RTC) we can do a lot of interesting tests on the Geneve, in its MDOS and GPL mode. There are plenty of interesting things to be found out by benchmarking. For example, you can

			* determine the execution times of instructions
			* check the memory speed
			* find out about the usage of wait states in the system
			* find out when a certain bit in the system is set, and when it is reset.

			In the last case, for example, I wanted to find out whether the EO bit of the video processor's status register 2 is used in non-interlaced modes or not. The EO bit indicates which of the two screens is currently displayed (when using interlace). It was not clear, however, whether it is locked to a constant value when we do not use interlace or whether it still alternates between 0 and 1.

			How can we do this by measuring time? - The concept is to find out how long it takes until we have got 10000 times of this bit set to 1 when reading the status register. If the bit is locked to 0 it will take forever, so we need an upper bound for our iterations. If the bit is locked to 1 it will quickly terminate, so the number of iterations should not be too low.

			What I found was that it takes equal time for getting 10000 status reads with the bit set to 0 or to 1. This means that the bit indeed continuously changes between 0 and 1.

	== Timer main program ==		== Timer main program ==

Mizapf: /* Determining the video interrupt rate */

2012-01-14T16:40:22Z

Determining the video interrupt rate

← Older revision		Revision as of 16:40, 14 January 2012
Line 204:		Line 204:
	* interrupts have occured		* interrupts have occured

	~~START~~ LIMI 0		T01 LIMI 0
	CLR R12		CLR R12
	SBO 2 enable VDP interrupt propagation through 9901		SBO 2 enable VDP interrupt propagation through 9901

Mizapf: /* Timer main program */

2012-01-14T16:39:54Z

Timer main program

Show changes

Mizapf at 23:56, 30 December 2011

2011-12-30T23:56:45Z

← Older revision		Revision as of 23:56, 30 December 2011
Line 98:		Line 98:

	Accordingly, we get '''60 Hz''' for the NTSC and '''50 Hz''' for the PAL setting. The timing is not affected by the number of display lines (192 or 212) and not by interlace mode (on or off).		Accordingly, we get '''60 Hz''' for the NTSC and '''50 Hz''' for the PAL setting. The timing is not affected by the number of display lines (192 or 212) and not by interlace mode (on or off).


			[[Category:MDOS]]
			[[Category:Geneve]]
			[[Category:Programming]]

Mizapf at 23:55, 30 December 2011

2011-12-30T23:55:44Z

← Older revision		Revision as of 23:55, 30 December 2011
Line 89:		Line 89:

	(2) We must clear the flag which caused the interrupt. Unless cleared, the INT line from the VDP will stay low (active) and will re-trigger the interrupt. So the first thing to do in the interrupt handler is to clear the origin of the interrupt.		(2) We must clear the flag which caused the interrupt. Unless cleared, the INT line from the VDP will stay low (active) and will re-trigger the interrupt. So the first thing to do in the interrupt handler is to clear the origin of the interrupt.

			=== Result of the video benchmark ===

			Using the RTC we can determine the time which passed between the first and the 1000th interrupt:

			* NTSC set (video register 9): '''16.67 s'''
			* PAL set (also in reg 9): '''20.0 s'''

			Accordingly, we get '''60 Hz''' for the NTSC and '''50 Hz''' for the PAL setting. The timing is not affected by the number of display lines (192 or 212) and not by interlace mode (on or off).

Mizapf: Created page with "Using the on-board real-time clock (RTC) we can do a lot of interesting tests on the Geneve, in its MDOS and GPL mode. == Timer main program == TODO == Determining the video i..."

2011-12-30T23:50:49Z

Created page with "Using the on-board real-time clock (RTC) we can do a lot of interesting tests on the Geneve, in its MDOS and GPL mode. == Timer main program == TODO == Determining the video i..."

New page

Using the on-board real-time clock (RTC) we can do a lot of interesting tests on the Geneve, in its MDOS and GPL mode.

== Timer main program ==

TODO

== Determining the video interrupt rate ==

* Wait in a loop until the desired number of
* interrupts have occured

START LIMI 0
CLR R12
SBO 2 enable VDP interrupt propagation through 9901

LI R0,>8170 VReg 1 contains a flag to enable vertical sync interrupt
SWPB R0
MOVB R0,@>F102
SWPB R0
MOVB R0,@>F102

LI R0,>8980 VReg 9 contains flags to set 192/212 lines, NTSC/PAL, interlace/non-interlace
SWPB R0
MOVB R0,@>F102
SWPB R0
MOVB R0,@>F102

MOV @>0004,R6 Save INT2 vector to R6/R7
MOV @>0006,R7

LI R0,>F040 Set our own interrupt routine at INT2
MOV R0,@>0004
LI R0,INTR
MOV R0,@>0006

* We set our counter to 1000 interrupts
LI R3,1000
MOV R3,@ITER

* Arm the interrupts
LIMI 2

* ... and wait in a loop until the counter is zero
T012 MOV @ITER,R0
JNE T012

* Block the interrupts again
LIMI 0
MOV R6,@>0004 Restore the vector
MOV R7,@>0006

T01E RT

This is the interrupt routine which we have to install:

ITER DATA 0 Counter

* Start of the routine
INTR LIMI 0 Block all interrupts (see below, 1)

* Read the status registers. This will clear the flags. (2)
* One of the flags is in SREG1
BL @GETREG
DATA 1
BL @GETREG
DATA 0
SLA R0,1 Is the leftmost flag set (VSYNC)?
JNC SKIP If not, skip the DEC command
DEC @ITER Decrease our counter
SKIP RTWP

* Routine to read a given status register into R0
* Register number must be in data line (LSB)

GETREG MOV *R11+,R0
ORI R0,>8F00
SWPB R0
MOVB R0,@>F102
SWPB R0
MOVB R0,@>F102
CLR R0
NOP
MOVB @>F102,R0
RT

Comments:

(1) We have to disable the interrupts here. The routine above has set the mask to 0002, which enables interrupts from other sources as well. If we do not block the interrupts, another interrupt request may interrupt this handler, and we will lose the return vector. The RTWP command at the end will restore the interrupt mask.

(2) We must clear the flag which caused the interrupt. Unless cleared, the INT line from the VDP will stay low (active) and will re-trigger the interrupt. So the first thing to do in the interrupt handler is to clear the origin of the interrupt.