Geneve wait state generation - Revision history

Stephen Shaw: /* Architecture */ replace missing page link with expansion of abbreviation

2014-11-15T15:55:30Z

Architecture: replace missing page link with expansion of abbreviation

← Older revision		Revision as of 15:55, 15 November 2014
Line 9:		Line 9:
	[[File:Waitstates_arch.png \| 500px \| left ]]		[[File:Waitstates_arch.png \| 500px \| left ]]

	The CPU, the TMS 9995, contains an own set of memory locations at addresses >F000 to >F0FB and the remaining 4 bytes at the end of the address space, that is, >FFFC to >FFFF (which are the [[NMI]] [[branch vector]]). The internal memory locations are directly connected to the 16 bit data bus, so we should say these are 128 words of 16 bit each.		The CPU, the TMS 9995, contains an own set of memory locations at addresses >F000 to >F0FB and the remaining 4 bytes at the end of the address space, that is, >FFFC to >FFFF (which are the NMI (None Maskable Interrupt) [[branch vector]]). The internal memory locations are directly connected to the 16 bit data bus, so we should say these are 128 words of 16 bit each.

	All other memory locations are outside of the CPU, and the 16 bit data transfers are converted to a sequence of two 8 bit data transfers. This is quite similar to the mechanism used in the TI-99/4A, with the exception that the TI send the odd address byte first, then the even address, and the TMS 9995 starts with the even address, followed by the odd address.		All other memory locations are outside of the CPU, and the 16 bit data transfers are converted to a sequence of two 8 bit data transfers. This is quite similar to the mechanism used in the TI-99/4A, with the exception that the TI send the odd address byte first, then the even address, and the TMS 9995 starts with the even address, followed by the odd address.

Mizapf at 15:51, 20 October 2011

2011-10-20T15:51:26Z

@@ Line 1: / Line 1: @@
 == Architecture ==
@@ Line 10: / Line 14: @@
 Wait states can only be created outside of the CPU; there is no way of creating wait states within the CPU (possibly also no need). There is a special PIN called READY which is used for wait state creation.
 Instead, we have an external wait state generation. The gate array circuit is used to create wait states in certain situations. When a wait state shall appear, the READY line of the CPU must be pulled down (cleared).
@@ Line 81: / Line 84: @@
 which makes '''4 cycles''' or 1.332 µs execution time.
 If the workspace is located in '''DRAM''' instead, we get more cycles:
@@ Line 89: / Line 104: @@
 * read the target argument (F080): 1 cycle
 * write the contents to the target address: 1 cycle
 together '''7 cycles''' or 2.331 µs.
@@ Line 96: / Line 124: @@
 : MOV @>3800,@>3802
-* read the instruction MOV @,@ (first byte): 2 cycles
+{| class="waitstate"
-* read the instruction MOV @,@ (second byte): 2 cycles
+|-
-* read the source operand (first byte): 2 cycles
+! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10
-* read the source operand (second byte): 2 cycles
+|-
-* read the byte at 3800: 2 cycles
+| class="wait" | wait
-* read the byte at 3801: 2 cycles
+| MOV R1,@ (HB)
-* read the target operand (first byte): 2 cycles
+| class="wait" | wait
-* read the target operand (second byte): 2 cycles
+| MOV R1,@ (LB)
-* write the byte at 3802: 2 cycles
+| class="wait" | wait
-* write the byte at 3803: 2 cycles
+| 38
 together '''20 cycles''' (6.66 µs).

Mizapf at 15:34, 20 October 2011

2011-10-20T15:34:13Z

← Older revision		Revision as of 15:34, 20 October 2011
Line 147:		Line 147:
	* the clock chip		* the clock chip
	* the sound chip (also see below)		* the sound chip (also see below)
	* the [[GROM simulator]] in the Gate Array ~~(since the GROMs are stored in DRAM)~~		* the [[GROM simulator]] in the Gate Array
	* the cards in the [[Peripheral Expansion Box]].		* the cards in the [[Peripheral Expansion Box]].

Line 171:		Line 171:

	Within the [[MESS]] emulator we decided to go for an average number of 24 wait states for the sake of simplicity. When the mechanisms behind these wait states are clarified this may be realized in MESS in a similar way.		Within the [[MESS]] emulator we decided to go for an average number of 24 wait states for the sake of simplicity. When the mechanisms behind these wait states are clarified this may be realized in MESS in a similar way.

			=== GROM simulator ===

			The Geneve features a [[GROM simulator]] within the [[TI mode]]. GROMs are considered to be "slow" devices, driven by a clock at 400-500 MHz; in the TI-99/4A console the clock signal is delivered by the VDP (video processor).

			Somewhat surprisingly, the GROM simulator in the Geneve does not apply special wait states for GROM access. One or two wait states are inserted, according to the extra wait state settings, as seen with DRAM. This is clear, since DRAM pages are used to store the GROM contents. The lack of specific GROM wait states implies that GROM access should be much faster on the Geneve than on the TI.

	== Automatic wait state generation ==		== Automatic wait state generation ==

Mizapf: /* Sound chip */

2011-10-20T15:25:35Z

Sound chip

← Older revision		Revision as of 15:25, 20 October 2011
Line 166:		Line 166:
	=== Sound chip ===		=== Sound chip ===

	'~~''TODO'''~~		Wait state generation for the sound access seems to be confusing at first. Unlike all previous experiments, the ones with sound access did not yield exact delay times. For instance, with different numbers of intermediate lines, the line with the sound access seems to change its number of wait states. Measurements show that we have discrete execution times (e.g. 32, 40, or 53 cycles) although we add instructions that use 3 cycles, so we should be able to get 35 cycles, for instance, yet we don't.

			The reason may be easier than expected: The sound chip has an own clock, and it offers a SNDRDY line which is connected to the Gate array. The number of wait states that are inserted obviously depends on the current state of the SNDRDY line. In that sense, execution is synchronized to the sound clock.

			Within the [[MESS]] emulator we decided to go for an average number of 24 wait states for the sake of simplicity. When the mechanisms behind these wait states are clarified this may be realized in MESS in a similar way.

	== Automatic wait state generation ==		== Automatic wait state generation ==

Mizapf: /* Video operation */

2011-10-20T15:05:21Z

Video operation

← Older revision		Revision as of 15:05, 20 October 2011
Line 162:		Line 162:
	The Geneve generates two "kinds" of wait states when accessing the VDP. The first kind has been explained above; the VDP is an external device and therefore gets one wait state per default, and two when extra wait states are selected. After the access, however, the Gate Array pulls down the READY line for another 14 cycles when the [[Geneve_CRU_definitions\|CRU bit]] for video wait states is set (address 0x0032 or bit 25 when the base address is 0x0000).		The Geneve generates two "kinds" of wait states when accessing the VDP. The first kind has been explained above; the VDP is an external device and therefore gets one wait state per default, and two when extra wait states are selected. After the access, however, the Gate Array pulls down the READY line for another 14 cycles when the [[Geneve_CRU_definitions\|CRU bit]] for video wait states is set (address 0x0032 or bit 25 when the base address is 0x0000).

	There are some interesting ~~pointa~~ about video wait states, which we discuss in a [[Geneve video wait states\|separate section]].		There are some interesting points about video wait states, which we discuss in a [[Geneve video wait states\|separate section]].

	=== Sound chip ===		=== Sound chip ===

Mizapf at 15:04, 20 October 2011

2011-10-20T15:04:37Z

← Older revision		Revision as of 15:04, 20 October 2011
Line 20:		Line 20:
	== Timing diagrams ==		== Timing diagrams ==

	Some diagrams may help to understand the concept of wait states on the Geneve. I picked some of the lines, but there are some more, also important ones. If you are interested in the exact set of signal lines please see the TMS9995 specification. For now, we only discuss ~~waitstate~~ generation.		Some diagrams may help to understand the concept of wait states on the Geneve. I picked some of the lines, but there are some more, also important ones. If you are interested in the exact set of signal lines please see the TMS9995 specification. For now, we only discuss wait state generation.

	Cycles are defined as starting from halfway of the low level, containing the whole high level, and ending at half of the time of the next down level. If we use one letter as one quarter of a cycle, it would read as LHHL. In the diagrams, each cycle has an own backdrop which differs from the next.		Cycles are defined as starting from halfway of the low level, containing the whole high level, and ending at half of the time of the next down level. If we use one letter as one quarter of a cycle, it would read as LHHL. In the diagrams, each cycle has an own backdrop which differs from the next.
Line 123:		Line 123:
	If the workspace were in SRAM, we would need 5 cycles (two cycles each for reading and writing to R1). If the command were in SRAM also, we get 6 cycles.		If the workspace were in SRAM, we would need 5 cycles (two cycles each for reading and writing to R1). If the command were in SRAM also, we get 6 cycles.

	When the CRU bit at address 1EFE is set to 0, the Gate array produces '''extra ~~waitstates~~'''. In the case of SRAM accesses, '''two ~~waitstates~~''' are inserted before the read access. For write accesses, two ~~waitstates~~ are included, starting with the access. This means that the above command when running in SRAM and with workspace in SRAM requires 18 cycles instead of 6.		When the CRU bit at address 1EFE is set to 0, the Gate array produces '''extra wait states'''. In the case of SRAM accesses, '''two wait states''' are inserted before the read access. For write accesses, two wait
			states are included, starting with the access. This means that the above command when running in SRAM and with workspace in SRAM requires 18 cycles instead of 6.

	=== DRAM access ===		=== DRAM access ===
Line 133:		Line 134:
	running in DRAM with R1 in DRAM as well, we get 6 memory accesses with 2 cycles each, that is, 12 cycles.		running in DRAM with R1 in DRAM as well, we get 6 memory accesses with 2 cycles each, that is, 12 cycles.

	With '''extra ~~waitstates~~''', the Gate array adds another ~~waitstate~~ for reading and writing. This means that SRAM and DRAM accesses operate at exactly the '''same speed'''.		With '''extra wait states''', the Gate array adds another wait state for reading and writing. This means that SRAM and DRAM accesses operate at exactly the '''same speed'''.

	=== Devices ===		=== Devices ===

	For external bus accesses (to the peripheral box), ~~waitstates~~ are used just as if accessing DRAM. That is, in the normal case, one WS is inserted for reading and writing. With extra ~~waitstates~~, two WS are inserted.		For external bus accesses (to the peripheral box), wait states are used just as if accessing DRAM. That is, in the normal case, one WS is inserted for reading and writing. With extra wait states, two WS are inserted.

	These ~~waitstates~~ apply to		These wait states apply to

	* the video processor (apart from the "background" ~~waitstates~~; see below)		* the video processor (apart from the "background" wait states; see below)
	* the memory map registers		* the memory map registers
	* the keyboard interface		* the keyboard interface

Mizapf: /* Video operation */

2011-10-20T14:57:00Z

Video operation

← Older revision		Revision as of 14:57, 20 October 2011
Line 161:		Line 161:
	The Geneve generates two "kinds" of wait states when accessing the VDP. The first kind has been explained above; the VDP is an external device and therefore gets one wait state per default, and two when extra wait states are selected. After the access, however, the Gate Array pulls down the READY line for another 14 cycles when the [[Geneve_CRU_definitions\|CRU bit]] for video wait states is set (address 0x0032 or bit 25 when the base address is 0x0000).		The Geneve generates two "kinds" of wait states when accessing the VDP. The first kind has been explained above; the VDP is an external device and therefore gets one wait state per default, and two when extra wait states are selected. After the access, however, the Gate Array pulls down the READY line for another 14 cycles when the [[Geneve_CRU_definitions\|CRU bit]] for video wait states is set (address 0x0032 or bit 25 when the base address is 0x0000).

	There are some interesting pointa about video wait states, which we discuss on a [[~~separate page\|~~Geneve video wait states]].		There are some interesting pointa about video wait states, which we discuss in a [[Geneve video wait states\|separate section]].

	=== Sound chip ===		=== Sound chip ===

Mizapf: /* Video operation */

2011-10-20T14:56:22Z

Video operation

Show changes

Mizapf: /* Video operation */

2011-10-20T14:52:21Z

Video operation

Show changes

Mizapf: /* Video operation */

2011-10-20T13:56:36Z

Video operation

@@ Line 178: / Line 178: @@
    F040    MOVB @VDPRD,R3     *  5 cycles
    F044    MOVB @SRAM,R4      * 15 cycles (4 cycles + 11 WS)
-   F046    DEC  R1            *  3 cycles
+   F048    DEC  R1            *  3 cycles
-   F048    JNE  F040          *  3 cycles
+   F04A    JNE  F040          *  3 cycles
 But we only get 11 WS, not 14. This is reasonable if we remember that the access to SRAM does not occur immediately after the VDP access but after writing to R3 and getting the next command. This can be shown more easily in the following way:
 {| class="waitstate"
-! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15 !! 16 !! 17 !! 18 !! 19 !! 20
+! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15
 |-
 | MOVB @,R3
@@ Line 205: / Line 205: @@
 | class="wait1" | wait
 | class="wait1" | wait
 | < *SRAM
 | > R3