SP0256 Measured Timings - Revision history

Arnoldemu at 10:56, 11 March 2018

2018-03-11T10:56:41Z

← Older revision		Revision as of 10:56, 11 March 2018
Line 100:		Line 100:
	3E /EL/ 190.0 136.5 138.22 139.21 140.52		3E /EL/ 190.0 136.5 138.22 139.21 140.52
	3F /BB2/ 50.0 50.2 51.92 53.17 54.10		3F /BB2/ 50.0 50.2 51.92 53.17 54.10

			[[Category:Hardware]]

Nocash: /* LRQ / SBY Timings */

2010-01-23T13:31:48Z

LRQ / SBY Timings

← Older revision		Revision as of 13:31, 23 January 2010
Line 22:		Line 22:

	* From the Z80 perspective, the stuff with 180..210ns timings reacts immediately.		* From the Z80 perspective, the stuff with 180..210ns timings reacts immediately.
	* However, the LRQ high duration of 15..41us is visible to the Z80 (though ~~any existing and~~ any well programmed Z80 software should not RELY on the presence of this delay) (it should of course be able DEAL with it, ie. it should not send new allophones while LRQ is high).		* However, the LRQ high duration of 15..41us is visible to the Z80 (though any well programmed Z80 software should not RELY on the presence of this delay) (it should of course be able DEAL with it, ie. it should not send new allophones while LRQ is high) (caution: The SSA-1 detection in "Roland in Space" DOES rely on the presence of that delay).
	* Theoretically, in standby state, the chip could process incoming data immediately, so LRQ wouldn't need to go HIGH at all. The fact that it does go HIGH may have two reasons: First, the chip may be unable to react immediately. Second, it may be done intentionally, for use with edge-triggered IRQ or DMA hardware.		* Theoretically, in standby state, the chip could process incoming data immediately, so LRQ wouldn't need to go HIGH at all. The fact that it does go HIGH may have two reasons: First, the chip may be unable to react immediately. Second, it may be done intentionally, for use with edge-triggered IRQ or DMA hardware.

Nocash: /* Allophone Lengths */

2010-01-16T16:29:47Z

Allophone Lengths

← Older revision		Revision as of 16:29, 16 January 2010
Line 32:		Line 32:
	* min/avg/max = Timings measured on real hardware (Amstrad SSA-1)		* min/avg/max = Timings measured on real hardware (Amstrad SSA-1)
	The min/avg/max values are slightly higher than the calculated values. This is probably because the SP0256 executes "NOPs" (with repeat=1 and pitch=unchanged) while in standby mode, and refuses to start a new allophone until it has finished the "NOP".		The min/avg/max values are slightly higher than the calculated values. This is probably because the SP0256 executes "NOPs" (with repeat=1 and pitch=unchanged) while in standby mode, and refuses to start a new allophone until it has finished the "NOP".

			[[File:SP0256 SBY Duration.png]]

	num name spec calc min avg max		num name spec calc min avg max

Nocash: /* LRQ / SBY Timings */

2010-01-16T16:19:46Z

LRQ / SBY Timings

← Older revision		Revision as of 16:19, 16 January 2010
Line 22:		Line 22:

	* From the Z80 perspective, the stuff with 180..210ns timings reacts immediately.		* From the Z80 perspective, the stuff with 180..210ns timings reacts immediately.
	* However, the LRQ high duration of 15..41us is visible to the Z80 (though well programmed ~~/ existing~~ Z80 software should not ~~rely~~ on the presence of this delay).		* However, the LRQ high duration of 15..41us is visible to the Z80 (though any existing and any well programmed Z80 software should not RELY on the presence of this delay) (it should of course be able DEAL with it, ie. it should not send new allophones while LRQ is high).
	* Theoretically, in standby state, the chip could process incoming data immediately, so LRQ wouldn't need to go HIGH at all. The fact that it does go HIGH may have two reasons: First, the chip may be unable to react immediately. Second, it may be done intentionally, for use with edge-triggered IRQ or DMA hardware.		* Theoretically, in standby state, the chip could process incoming data immediately, so LRQ wouldn't need to go HIGH at all. The fact that it does go HIGH may have two reasons: First, the chip may be unable to react immediately. Second, it may be done intentionally, for use with edge-triggered IRQ or DMA hardware.

Nocash: /* LRQ / SBY Timings */

2010-01-16T16:17:18Z

LRQ / SBY Timings

← Older revision		Revision as of 16:17, 16 January 2010
Line 18:		Line 18:
	LRQn high duration 15940ns 24203ns 41600ns		LRQn high duration 15940ns 24203ns 41600ns
	SBY low duration (....allophone length....)		SBY low duration (....allophone length....)

			[[File:SP0256 ALD Detail.png]]

	* From the Z80 perspective, the stuff with 180..210ns timings reacts immediately.		* From the Z80 perspective, the stuff with 180..210ns timings reacts immediately.
	* However, the LRQ high duration of 15..41us is visible to the Z80 (though well programmed / existing Z80 software should not rely on the presence of this delay).		* However, the LRQ high duration of 15..41us is visible to the Z80 (though well programmed / existing Z80 software should not rely on the presence of this delay).

Nocash: /* Allophone Lengths */

2010-01-16T16:06:37Z

Allophone Lengths

← Older revision		Revision as of 16:06, 16 January 2010
Line 9:		Line 9:

	[[File:SP0256 PWM Output.png]]		[[File:SP0256 PWM Output.png]]

			== LRQ / SBY Timings ==

			This table shows timings when sending an allophone number to the chip (by sending ALD=LOW) while the chip was in standby mode:
			Timing min avg max
			ALDn falling to LDQn rising 180ns 187ns 190ns
			ALDn falling to SBY falling 200ns 204ns 210ns
			LRQn high duration 15940ns 24203ns 41600ns
			SBY low duration (....allophone length....)
			* From the Z80 perspective, the stuff with 180..210ns timings reacts immediately.
			* However, the LRQ high duration of 15..41us is visible to the Z80 (though well programmed / existing Z80 software should not rely on the presence of this delay).
			* Theoretically, in standby state, the chip could process incoming data immediately, so LRQ wouldn't need to go HIGH at all. The fact that it does go HIGH may have two reasons: First, the chip may be unable to react immediately. Second, it may be done intentionally, for use with edge-triggered IRQ or DMA hardware.

	== Allophone Lengths ==		== Allophone Lengths ==

Nocash: /* Allophone Lengths */

2010-01-16T15:38:28Z

Allophone Lengths

← Older revision		Revision as of 15:38, 16 January 2010
Line 16:		Line 16:
	* calc = Timings calculated from 10kHz sample rate and the pitch/repeat values in the -AL2 ROM		* calc = Timings calculated from 10kHz sample rate and the pitch/repeat values in the -AL2 ROM
	* min/avg/max = Timings measured on real hardware (Amstrad SSA-1)		* min/avg/max = Timings measured on real hardware (Amstrad SSA-1)
	The min/avg/max values are slightly higher than the calculated values. This is probably because the SP0256 executes "NOPs" with repeat=1 while in standby mode, and refuses to start a new allophone until it has finished the "NOP".		The min/avg/max values are slightly higher than the calculated values. This is probably because the SP0256 executes "NOPs" (with repeat=1 and pitch=unchanged) while in standby mode, and refuses to start a new allophone until it has finished the "NOP".

	num name spec calc min avg max		num name spec calc min avg max

Nocash: /* PWM Output */

2010-01-16T15:14:02Z

PWM Output

← Older revision		Revision as of 15:14, 16 January 2010
Line 6:		Line 6:
	* Normally, 7bit PWM should consist of one "packet" with 128 steps. However, this seems to be broken down to four "quarter-packets" with 32 steps. This technique reduces the PWM noise from 10kHz to in-audible 40kHz.		* Normally, 7bit PWM should consist of one "packet" with 128 steps. However, this seems to be broken down to four "quarter-packets" with 32 steps. This technique reduces the PWM noise from 10kHz to in-audible 40kHz.
	* The image shows one such "quarter-packet" with 32 steps (actually 33 steps, not sure why, so let's ignore that). Additionally, there are some dummy steps with constant LOW level inserted between each quarter-packet, making each quarter 39 steps long. This is done to achieve a sample rate of 10kHz (a full packet is 156 = 4*39 steps, so sample rate is 3.12MHz/2/156 = 10kHz).		* The image shows one such "quarter-packet" with 32 steps (actually 33 steps, not sure why, so let's ignore that). Additionally, there are some dummy steps with constant LOW level inserted between each quarter-packet, making each quarter 39 steps long. This is done to achieve a sample rate of 10kHz (a full packet is 156 = 4*39 steps, so sample rate is 3.12MHz/2/156 = 10kHz).
	* For whatever reason, the quarter ~~packers~~ aren't always 39 steps long, ~~and~~ instead they vary from 38 to 40 steps. Anyways, better let's ignore that, too.		* For whatever reason, the quarter packets aren't always 39 steps long, instead, they vary from 38 to 40 steps. Anyways, better let's ignore that, too.

	[[File:SP0256 PWM Output.png]]		[[File:SP0256 PWM Output.png]]

Nocash: /* Allophone Lengths */

2010-01-16T15:11:47Z

Allophone Lengths

← Older revision		Revision as of 15:11, 16 January 2010
Line 14:		Line 14:
	This table shows the allophone lengths in milliseconds.		This table shows the allophone lengths in milliseconds.
	* spec = Timings from original datasheets (these values are totally wrong)		* spec = Timings from original datasheets (these values are totally wrong)
	* calc = Timings calculated from pitch/repeat values in the -AL2 ROM		* calc = Timings calculated from 10kHz sample rate and the pitch/repeat values in the -AL2 ROM
	* min/avg/max = Timings measured on real hardware (Amstrad SSA-1)		* min/avg/max = Timings measured on real hardware (Amstrad SSA-1)
	The min/avg/max values are slightly higher than the calculated values. This is probably because the SP0256 executes "NOPs" with repeat=1 while in standby mode, and refuses to start a new allophone until it has finished the "NOP".		The min/avg/max values are slightly higher than the calculated values. This is probably because the SP0256 executes "NOPs" with repeat=1 while in standby mode, and refuses to start a new allophone until it has finished the "NOP".

Nocash: /* PWM Output */

2010-01-16T15:00:41Z

PWM Output

← Older revision		Revision as of 15:00, 16 January 2010
Line 2:		Line 2:

	== PWM Output ==		== PWM Output ==

			This image shows the PWM output. The PWM is clocked at 3.12MHz/2 (so one step is circa 630..640 µs).
			* Normally, 7bit PWM should consist of one "packet" with 128 steps. However, this seems to be broken down to four "quarter-packets" with 32 steps. This technique reduces the PWM noise from 10kHz to in-audible 40kHz.
			* The image shows one such "quarter-packet" with 32 steps (actually 33 steps, not sure why, so let's ignore that). Additionally, there are some dummy steps with constant LOW level inserted between each quarter-packet, making each quarter 39 steps long. This is done to achieve a sample rate of 10kHz (a full packet is 156 = 4*39 steps, so sample rate is 3.12MHz/2/156 = 10kHz).
			* For whatever reason, the quarter packers aren't always 39 steps long, and instead they vary from 38 to 40 steps. Anyways, better let's ignore that, too.

	[[File:SP0256 PWM Output.png]]		[[File:SP0256 PWM Output.png]]