si-spec.html 22.1 KB

Raw Blame History Permalink

<html>
<head>
<title>
	Project BB - SI Specification
</title>
</head>
<body bgcolor="#ffffff" text="#000000"
  link="#004868" vlink="#986424" alink="#00ffff">

<table width="100%" cellpadding=2 cellspacing=0 border=0>
<tr>
<td bgcolor="#e0e0e0">
	Project BB - SI Specification
</td>
<td align=right bgcolor="#f0c0c0" width="20%">
<font color=red>
	<b>Broad<i>On</i> confidential</b>
</font>
</td>
</tr>
</table>

<p>
<b><u> Overview </u></b>
<p>
	In N64, the SI (serial interface) implemented the PCH serial interface
	to the PIF (peripheral interface) chip. The PIF contained 2kbytes of
	boot ROM, 64 bytes of RAM, five Nintendo JoyChannel ports, the NMI and
	reset controller, and Nintendo proprietory security hardware. The security
	functions are very difficult to emulate and prompted the removal of the
	PIF chip from the BB design.
	The boot ROM has been replaced by the internal flash. The JoyChannel
	interface has been moved on-chip. The new SI implements three JoyChannel
	ports and one direct interface to the BB's buttons and joy stick. The SI
	logic implements a data structure similar to the PIF through which
	communication takes places.

<p>
<b><u> Related Documentation </u></b>
<p>
<a href="http://bird.routefree.com/N64OnlineManuals52"> N64 Online Manuals </a><br>
<a href="n64-ctrlspec.doc"> Specification of N64 Standard Controller </a><br>
<a href="n64-ctrlsch.gif"> Schematic of N64 Controller </a><br>
<a href="n64-ctrlbom.xls"> BOM of N64 Controller </a><br>
<a href="n64-motor.gif"> Schematic of Nintendo Rumble Pack </a><br>
<a href="n64-pifspec.doc"> N64 PIF Specification </a><br>
<a href="n64-pif-cic.email"> Email from Atsushi Watanabe about PIF/CIC interaction </a><br>

<p>
<b><u> SI Architecture </u></b>
<p>
	The core of the SI is a data structure through which communication
	takes place between the system side and the device side. The dma
	controller moves data between main memory and the SI RAM. The dma
	address must be 8-byte aligned and the size of the block is fixed at
	32 bytes (was 64 bytes in N64). Cpu ache effects have to be taken into
	account as well, such as cacheline alignment The pio controller manages
	access to the SI registers and buffers.
<p>
	The device side is comprised of three different controller types;
	one serial port controller, three JoyChannel controllers and one local
	button/stick controller. The serial port is intended for debug, modem
	extension and future low-speed extensions. The JoyChannel ports connect
	up to three standard Nintendo controllers for multi-player games. The
	local controller port transforms 16 bits of button samples from the
<a href="pi-spec.html">PI</a>
	into a controller data structure compatible with N64.
<p>
<img src="si-block.gif" width=640 height=450 border=0>

<p>
<b><u> Compatible SI Registers </u></b>
<p>
	The SI responds to cbus requests falling into the 0x048x_xxxx register
	space. Accesses to the original 0x1fc007c0 ... 0x1fc007ff PIF RAM space
	are trapped by the MI and are not passed to the cbus. There was a limitation
	in N64 which prohibited overlapping pio and dma operations. The SI set
	the DMA_ERR bit in the SI_STATUS register if the harzard was detected.
	No such limitation exists in the BB design. The controller and buffer
	structures can be accessed by dma or pio operations simultaneously. The
	dma size has been reduced from 64 to 32 bytes to allow software trap
	handlers to emulate functions beyond the four embedded controllers.
<p>
<table cellpadding=2 cellspacing=2 border=1>
<tr>
<td> Name </td>
<td> Address </td>
<td> Data </td>
<td> Read/Write </td>
<td> Reset </td>
<td> N64 </td>
<td> Description </td>
</tr>
<tr>
<td> SI_DRAM_ADDR </td>
<td> 0x0480_0000 </td>
<td> [25:3] </td>
<td> RW </td>
<td> x </td>
<td> y </td>
<td> DRAM dma address, lower 64MB region; <br>
	either x36 or x64 space, [2:0] are ignored; <br>
	must be 8-byte aligned, cannot cross page; <br>
	N64 used bits [23:2] with bit [2] = 0; </td>
</tr>
<tr>
<td> SI_DMA_READ </td>
<td> 0x0480_0004 </td>
<td> [31:0] </td>
<td> W </td>
<td> - </td>
<td> y </td>
<td> starts 32-byte dma from SI to memory; <br>
	write data is ignored; <br>
	N64 wrote 11 bits of PIF address; <br>
	N64 triggered 64-byte dma; </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [31:0] </td>
<td> R </td>
<td> X </td>
<td> n </td>
<td> read data is undefined,<br>
	N64 returned PIF address </td>
</tr>
<tr>
<td> SI_DMA_WRITE </td>
<td> 0x0480_0010 </td>
<td> [31:0] </td>
<td> W </td>
<td> - </td>
<td> y </td>
<td> starts 32-byte dma from memory to SI; <br>
	write data is ignored; <br>
	N64 wrote 11 bits of PIF address; <br>
	N64 triggered 64-byte dma; </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [31:0] </td>
<td> R </td>
<td> X </td>
<td> n </td>
<td> read data is undefined; <br>
	N64 returned PIF address </td>
</tr>
<tr>
<td> SI_STATUS </td>
<td> 0x0480_0018 </td>
<td> [31:0] </td>
<td> W </td>
<td> - </td>
<td> y </td>
<td> write clears SI interrupt; <br>
	write data is ignored </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [31:13] </td>
<td> R </td>
<td> 0 </td>
<td> y </td>
<td> reserved bits; <br>
	BB always returns 0; </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [12] </td>
<td> R INT </td>
<td> 0 </td>
<td> y </td>
<td> 1 = interrupt pending; <br>
	write to SI_STATUS clears interrupt </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [11:8]</td>
<td> R </td>
<td> 0000 </td>
<td> - </td>
<td> undocumented <br>
        BB always returns 0;  <br>
	N64 returned current dma state </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [7:4]</td>
<td> R </td>
<td> 0000 </td>
<td> - </td>
<td> undocumented <br>
        BB always returns 0;  <br>
	N64 returned current PCH state </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [3] </td>
<td> R DMA_ERR </td>
<td> old </td>
<td> y </td>
<td> 1 = dma error; <br>
	BB returns 1 for dma conflict only; <br>
	cleared on start of next dma; <br>
	N64 returned 1 for dma or dma/pio conflict </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [2] </td>
<td> R </td>
<td> 0 </td>
<td> - </td>
<td> undocumented <br>
	BB always returns 0; <br>
	N64 returned 1 for io read pending </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [1] </td>
<td> R IO_BUSY </td>
<td> 0 </td>
<td> y </td>
<td> always 0, no pio conflict in BB; <br>
	N64 returned 1 for pio busy </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [0] </td>
<td> R DMA_BUSY </td>
<td> 0 </td>
<td> y </td>
<td> 1 = dma busy </td>
</tr>
</tr>
<tr>
<td> SI_RAM </td>
<td> 0x1fc007c0 ...<br> 0x1fc007ff </td>
<td> [31:0] </td>
<td> RW </td>
<td> X </td>
<td> y </td>
<td> RAM space; <br>
	not seen by SI on cbus; <br>
	MI optionally traps accesses to this space; </td>
</tr>
</table>

<p>
<b><u> Notes on DMA Operation </u></b>
<p>
	Writes to the dma registers SI_DRAM_ADDR, SI_DMA_READ and SI_DMA_WRITE
	are ignored when a previous dma is still in progress. The current dma
	will complete and the DMA_ERR bit will be set in the SI_STATUS register.
	The bottleneck through the PCH serial channel no longer exists. The
	SI_DMA_WRITE will complete almost immediatedly, delayed only by other
	higher priority memory requestors. Spinning on the interrupt bit in
	the SI_STATUS register is an alternative to taking a costly SI interrupt.
	However, the SI_DMA_READ triggers the protocol engines of the local
	controller and JoyChannel controllers. The SI interrupt is raised when
	all controllers have finished their protocol (repsonse received, timeouts
	or errors) and the SI_DMA_READ has moved the data into main memory.

<p>
<b><u> RAM Data Structures </u></b>
<p>
	Communication with the devices takes place through data structures
	in the SI. The processor sets up a command structure in main memory
	and starts a SI read dma. The device side controllers listen on their
	corresponding 8-byte structure, issue the requested operations and
	update their structure upon completion. The processor then uses the
	SI dma again to move the results back to main memory. The intend of
	the BB SI design was to make the hardware backwards compatible. However,
	some PIF functions can not be emulated due to Nintendo's CIC security
	protocol. Only the basic controller commands are supported. It is
	assumed that all those differences will be handled by a new controller
	library (DevKit).
<pre>
	RAM offset	Device			SI_DMA_READ	SI_DMA_WRITE
	-----------------------------------------------------------------------
	 0 ..  7	local controller	    valid	used
	 8 .. 15	joyChannel port #1	    valid	used
	16 .. 23	joyChannel port #2	    valid	used
	24 .. 31	joyChannel port #3	    valid	used
	32 .. 63	no devices                not read    not written

	writes to unimplemented bits are ignored,
	reads from unimplemented bits return 0,
</pre>

<p>
<b><u> JoyChannel Controller </u></b>
<p>
	The JoyChannel controller translates the 8-byte protocol data into the
	bi-directional serial protocol. There is no JoyPort (socket on controller)
	support of any kind in the BB design. The main function of the JoyPort
	in N64 was the saving of game state, which is accomplished by different
	means in the BB design. Only the basic controller commands: Type/Status
	(0), Button Request (1), and Reset (255) are implemented. The local
	controller will return a no response error for all other commands, ie.
	emulating what a JoyChannel controller would have returned. The JoyChannel
	controllers return a request error for tx/rx sizes out of bounds. For
	valid sizes, the JoyChannel controllers send out the command and wait for
	a response. Up to five bytes can be transmitted and up to four bytes
	received. For sizes within bounds, but illegal for the issued command,
	the no response error is returned.
<p>
	XXX req_error on local controller
<p>
<dl>
<dd>
<table cellpadding=2 cellspacing=2 border=1>
<tr>
<td> Byte </td>
<td> Description </td>
<td> Transmit </td>
<td> Receive </td>
</tr>
<tr>
<td> 0 </td>
<td> block code <br>
	write data ignored <br>
	reads return 0xff, compatible with PIF block commands
</td>
<td> - </td>
<td> - </td>
</tr>
<tr>
<td> 1 </td>
<td> tx size in bytes, including cmd <br>
	value of 0 does not start the controller <br>
	values >= 64 cause request error <br>
	only bits[5:0] are returned on reads </td>
<td> - </td>
<td> - </td>
</tr>
<tr>
<td> 2 </td>
<td> rx size in bytes <br>
	values >= 64 cause request error <br>
	read data return error and bits[2:0] of rx size <br>
	[7:3] error code <br>
	10000 no response (timeout) <br>
	01000 overrun/request error (illegal tx or rx sizes) <br>
	00100 frame error (receive) <br>
	00010 collision error (transmit) <br>
	00001 controller reset <br>
	the tx/rx buffer (bytes 4..7) are undefined on errors <br>
<td> - </td>
<td> - </td>
</tr>
<tr>
<td> 3 </td>
<td> command byte </td>
<td> y </td>
<td> - </td>
</tr>
<tr>
<td> 4..7 </td>
<td> tx/rx buffer </td>
<td> y </td>
<td> y </td>
</tr>
</table>
</dl>

<dl>
<dt> Command 0: query type/status of controller
<dd>
<p>
<table cellpadding=2 cellspacing=2 border=1>
<tr>
<td> Byte </td>
<td> error </td>
<td> txsize </td>
<td> rxsize </td>
<td> command </td>
<td> byte[4] </td>
<td> byte[5] </td>
<td> byte[6] </td>
<td> byte[7] </td>
</tr>
<tr>
<td> Request </td>
<td> - </td>
<td> 1 </td>
<td> 3 </td>
<td> 0 </td>
<td> - </td>
<td> - </td>
<td> - </td>
<td> - </td>
</tr>
<tr>
<td> Reply </td>
<td> valid </td>
<td> 1 </td>
<td> 3 </td>
<td> 0 </td>
<td> type L </td>
<td> type H </td>
<td> status </td>
<td> - </td>
</tr>
</table>
<p>
<dl>
<dt> type L [7]
<dd> 1 = extended command support, 0 for standard NES controllers
<dt> type L [6:3]
<dd> undefined, 0 for standard NES controllers
<dt> type L [2]
<dd> 1 = has JoyPort
<dt> type L [1]
<dd> x counts are 0 = absolute, 1 = relative
<dt> type L [0]
<dd> y counts are 0 = absolute, 1 = relative
<dt> type H [7:6]
<dd> EEPROM size, 00 = NES, 01 = 64kbits, 10 = 4kbits, 11 = 16kbits
<dt> type H [5]
<dd> undefined, 0 for standard NES controllers
<dt> type H [4:0]
<dd> device ID, 0 for standard NES controllers
<dt> status [7]
<dd> 1 = EEPROM is in write mode
<dt> status [6:3]
<dd> undefined, 0 for standard NES controllers
<dt> status [2]
<dd> 1 = JoyPort address CRC error
<dt> status [1]
<dd> 1 = JoyPort card removed at least once after reset
<dt> status [0]
<dd> 1 = JoyPort card inserted
</dl>
<p>
	BB local controller returns type L = 0x00, type H = 0x00, status = 0x00.

<p>
<dt> Command 1: query buttons/stick values
<dd>
<p>
<table cellpadding=2 cellspacing=2 border=1>
<tr>
<td> Byte </td>
<td> error </td>
<td> txsize </td>
<td> rxsize </td>
<td> command </td>
<td> byte[4] </td>
<td> byte[5] </td>
<td> byte[6] </td>
<td> byte[7] </td>
</tr>
<tr>
<td> Request </td>
<td> - </td>
<td> 1 </td>
<td> 4 </td>
<td> 1 </td>
<td> - </td>
<td> - </td>
<td> - </td>
<td> - </td>
</tr>
<tr>
<td> Reply </td>
<td> valid </td>
<td> 1 </td>
<td> 4 </td>
<td> 1 </td>
<td> button status L </td>
<td> button status H </td>
<td> stick x counter </td>
<td> stick y counter </td>
</tr>
</table>
<p>
<dl>
<dt> button status L [7]
<dd> 1 = button B pressed
<dt> button status L [6]
<dd> 1 = button A pressed
<dt> button status L [5]
<dd> 1 = button G pressed
<dt> button status L [4]
<dd> 1 = button START pressed
<dt> button status L [3]
<dd> 1 = up arrow pressed
<dt> button status L [2]
<dd> 1 = down arrow pressed
<dt> button status L [1]
<dd> 1 = left arrow pressed
<dt> button status L [0]
<dd> 1 = right arrow pressed
<dt> button status H [7]
<dd> 1 = JSRST (L, R, START pressed at same time reset stick reference)
<dt> button status H [6]
<dd> always 0
<dt> button status H [5]
<dd> 1 = button L pressed
<dt> button status H [4]
<dd> 1 = button R pressed
<dt> button status H [3]
<dd> 1 = button E pressed
<dt> button status H [2]
<dd> 1 = button D pressed
<dt> button status H [1]
<dd> 1 = button C pressed
<dt> button status H [0]
<dd> 1 = button F pressed
</dl>

<p>
<dt> Command 2: read 32 bytes from joyport
<dd>
<p>
<table cellpadding=2 cellspacing=2 border=1>
<tr>
<td> Byte </td>
<td> error </td>
<td> txsize </td>
<td> rxsize </td>
<td> command </td>
<td> byte[4] </td>
<td> byte[5] </td>
<td> byte[6] </td>
<td> byte[7] </td>
</tr>
<tr>
<td> Request </td>
<td> - </td>
<td> 3 </td>
<td> 33 </td>
<td> 2 </td>
<td> addr H </td>
<td> addr L, addr crc </td>
<td> - </td>
<td> - </td>
</tr>
<tr>
<td> Reply </td>
<td> valid </td>
<td> 3 </td>
<td> 33 </td>
<td> 2 </td>
<td> data 0 </td>
<td> data 1 </td>
<td> data 2 </td>
<td> crc </td>
</tr>
</table>
<p>
	The local controller does not support this command.<br>
	Only data bytes 0..2 and the last byte as indicated by rxsize are captured.<br>
	Data bytes 3..rxsize-1 are discarded.
<p>
<dt> Command 3: write 32 bytes to joyport
<dd>
<p>
<table cellpadding=2 cellspacing=2 border=1>
<tr>
<td> Byte </td>
<td> error </td>
<td> txsize </td>
<td> rxsize </td>
<td> command </td>
<td> byte[4] </td>
<td> byte[5] </td>
<td> byte[6] </td>
<td> byte[7] </td>
</tr>
<tr>
<td> Request </td>
<td> - </td>
<td> 35 </td>
<td> 1 </td>
<td> 3 </td>
<td> addr H </td>
<td> addr L, addr crc </td>
<td> data 0 </td>
<td> data 1..31 </td>
</tr>
<tr>
<td> Reply </td>
<td> valid </td>
<td> 35 </td>
<td> 1 </td>
<td> 3 </td>
<td> crc </td>
<td> - </td>
<td> - </td>
<td> - </td>
</tr>
</table>
<p>
	The local controller does not support this command.<br>
	Byte[7] will be replicated into data bytes 1..txsize-1 and the crc.<br>
<p>
<dt> Command 255: reset JoyChannel, return type/status of controller
<dd>
<p>
<table cellpadding=2 cellspacing=2 border=1>
<tr>
<td> Byte </td>
<td> error </td>
<td> txsize </td>
<td> rxsize </td>
<td> command </td>
<td> byte[4] </td>
<td> byte[5] </td>
<td> byte[6] </td>
<td> byte[7] </td>
</tr>
<tr>
<td> Request </td>
<td> - </td>
<td> 1 </td>
<td> 3 </td>
<td> 255 </td>
<td> - </td>
<td> - </td>
<td> - </td>
<td> - </td>
</tr>
<tr>
<td> Reply </td>
<td> valid </td>
<td> 1 </td>
<td> 3 </td>
<td> 255 </td>
<td> type L </td>
<td> type H </td>
<td> status </td>
<td> - </td>
</tr>
</table>
</dl>

<p>
	All other commands can send up to five bytes and receive up to four bytes.
	These commands are actually sent to the JoyCchannel. The frame error bit
	will be set and no JoyChannel communication takes place when tx_size or
	rx_size are out of bounds.

<p>
<b><u> Local Controller </u></b>
<p>
	The local controller implements the button functions of a standard
	NES controller. There are 14 inputs from buttons and 2 digital inputs
	from the joy stick optical sensors. All 16 inputs are physically
	connected to the io bus through an external bus driver chip. The
<a href="pi-spec.html">PI</a>
	samples this port periodically and sends the sample data to the SI.
	The SI contains the logic that translates the samples into the same
	RAM data structure that the JoyChannel controllers use.
<p>
<img src="si-lctrl.gif" width=510 height=330 border=0>

<p>
<b><u> Input Sampling and Debouncing </u></b>
<p>
	Button presses can cause glitches due to contact bouncing in mechanical
	switches (metal-on-metal) or noise in resistive switches. The optical
	detectors in the joystick are resistive and can cause noise glitches
	as well. There are three levels of user input sampling.
<dl>
<dt> input buffer characteristics
<dd> Input buffers have specific input voltage behavior.
	Schmidt trigger inputs have the advantage of removing glitches that
	are smaller than the hysteresis.
<dt> button and stick sampling intervals
<dd> It was thought to be necessary to have programmable support for button
	and stick sampling. Mechanical limits (mass, spring force) impose
	an upper sampling frequency, response latency (frame to action) impose
	a lower bound. Response latency should be smaller than a video field
	time.
<dt> controller sampling
<dd> Controller sampling has different frequency bounds than the buttons,
	because motion of the x/y stick produces motion events at a higher
	rate than button events.
</dl>

	The SI requests a new button sample from the PI every BUT_RATE. The
	glitch and debouncing logic requires three consecutive samples to
	detect a button change.

<p>
<b><u> Single Command Detection </u></b>
<p>
	The hardware supports detection of single commands, ie. commands
	to the PIF chip targeting a single channel. The local controller will
	set error flags for all unsupported commands. Commands targeting
	controllers 1..N would prepend a byte of 0x00 to tell the PIF to
	skip a controller. The BB local controller checks byte 0 and causes
	a return of all 1s in the following read dma request. The existing
	software will take this as an error.

<p>
<b><u> New SI Registers </u></b>
<p>
	Two new SI registers control new features or functions that were previously
	handled by the PIF chip. The SI_CONFIG register contains a clock divider
	which divides down sysclk to create the JoyChannel time base. Another bit
	set the new slave mode. The SI_CTRL register is used for hardware reset of
	all JoyChannel ports and for control of the new slave mode. Reading of SI_CONFIG
	or SI_CTRL returns the contents of both registers.

<p>
<table cellpadding=2 cellspacing=2 border=1>
<tr>
<td> Name </td>
<td> Address </td>
<td> Data </td>
<td> Read/Write </td>
<td> Reset </td>
<td> N64 </td>
<td> Description </td>
</tr>
<tr>
<td> SI_CONFIG </td>
<td> 0x0480_001c </td>
<td> [31] </td>
<td> RW JC_SLAVE </td>
<td> 0 </td>
<td> n </td>
<td> JoyChannel 0=master, 1=slave </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [30:24] </td>
<td> RW JC_DIV </td>
<td> 31 </td>
<td> n </td>
<td> JoyChannel clock divider; <br>
	time base for JoyChannel interface; <br>
	jc_clk = sysclk / (SI_CONFIG[30:24] + 1)
</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [23] </td>
<td> RW SGL_ERR </td>
<td> 1 </td>
<td> n </td>
<td> cause single PIF commands to return error </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [22] </td>
<td> RW BUT_ENA </td>
<td> 0 </td>
<td> n </td>
<td> 1 = enable button sampling </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [21:16] </td>
<td> RW BUT_RATE </td>
<td> 2 </td>
<td> n </td>
<td> Button sample interval; <br>
	0 = sample every 1/jc_clk; <br>
	1..63 = sample every (n * 1024) / jc_clk;
</td>
<tr>
<td> </td>
<td> </td>
<td> [15:8] </td>
<td> RO </td>
<td> 0 </td>
<td> n </td>
<td> reserved </td>
</tr>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [7:0] </td>
<td> RO </td>
<td> - </td>
<td> n </td>
<td> same as SI_CTRL </td>
</tr>
<tr>
<td> SI_CTRL </td>
<td> 0x0480_000c </td>
<td> [31:8] </td>
<td> RO </td>
<td> - </td>
<td> n </td>
<td> same as SI_CONFIG </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [7:3] </td>
<td> RO </td>
<td> 0 </td>
<td> n </td>
<td> reserved </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [2] </td>
<td> W XMIT </td>
<td> 0 </td>
<td> n </td>
<td> 1 = start transmission of response </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [2] </td>
<td> R BUSY </td>
<td> 0 </td>
<td> n </td>
<td> 1 = transmitter busy </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [1] </td>
<td> RO REQ </td>
<td> 0 </td>
<td> n </td>
<td> 1 = received request </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> [0] </td>
<td> RW JCRST </td>
<td> 1 </td>
<td> n </td>
<td> 1 = drives JoyChannel L for bus reset; <br>
	software must ensure minimum duration of 800usec; </td>
</tr>
</table>

<p>
<b><u> BB Slave Mode </u></b>
<p>
	JoyChannel #1 supports a new mode which allows a BB to be used as a
	slave controller. A software driver listens on incoming requests on
	JoyChannel #1, transforms the local controller data into the appropriate
	response and sends it out. Control of the slave mode is accomplished
	entirely through register reads and writes. JoyChannels #2 and #3 are
	disabled in slave mode. The SI dma can be used to move the controller
	data structures.
<p>

<dl>
<dt> Slave Protocol Flow
<p>
<dd> cpu puts si into slave mode, ctrl #0 is still master, #1 is now slave;
<dd> cpu starts read dma to make ctrl #1 listen on JoyChannel;
<dd> request arrives, updates command, rxsize and bytes[4..7];
<dd> SI interrupt is issued with REQ bit set in SI_CTRL;
<dd> cpu processes request;
<dd> cpu writes txsize, command and bytes[4..7];
<dd> cpu writes XMIT bit in SI_CTRL;
<dd> SI_CTRL bit REQ is cleared, BUSY bit is set;
<dd> transmitter sends out response;
<dd> SI_CTRL bit XMIT is cleared and rxsize updated with completion code;
</dl>

<p>
<b><u> Serial Controller </u></b>
<p>
	There had been a plan to add a serial port to the SI block. The main
	purpose of the block was for bringup, debug and an external BlueTooth
	radio. The two USB ports now take care of BlueTooth. The software folks
	have pushed for higher I/O performance for debug, which pretty much
	obsoleted the serial port.

<hr>
<font size="-1">
	Problems and comments to
<a href="mailto:berndt@broadon.com">
	berndt@broadon.com
</a>
</font>
</body>
</html>