ES2247692T3

ES2247692T3 - Metodo de transmision de datos y sistema de juego construido segun dicho metodo.

Info

Publication number: ES2247692T3
Application number: ES98919599T
Authority: ES
Inventors: Naoki Sega Enterprises Ltd. NIIZUMA; Atunori Sega Enterprises Ltd. HIMOTO
Original assignee: Sega Enterprises Ltd
Current assignee: Sega Corp
Priority date: 1997-05-14
Filing date: 1998-05-14
Publication date: 2006-03-01
Anticipated expiration: 2018-05-14
Also published as: WO1998052331A1; DE69831054T2; EP0932286B1; JP2870538B2; RU99102537A; KR20000023811A; AU7237798A; KR100384677B1; EP0932286A4; EP0932286A1; JPH11234362A; JPH1132097A; DE69831054D1

Abstract

PROPORCIONA UN NUEVO SISTEMA DE TRANSMISION DE DATOS ENTRE UN DISPOSITIVO DE JUEGO Y DISPOSITIVOS PERIFERICOS RELACIONADOS, Y UN DISPOSITIVO QUE LO UTILIZA. LA TRANSMISION EN SERIE DE DATOS SE DIVIDE EN UNA SECUENCIA DE BITS IMPARES Y UNA SECUENCIA DE BITS PARES. CADA BIT DE LA SECUENCIA DE BITS IMPARES SE DISTRIBUYE ENTRE PULSOS DE UNA PRIMERA SEÑAL DE SECUENCIA DE PULSOS CON UN INTERVALO CONSTANTE, FORMANDO ASI UNA PRIMERA SEÑAL DE SECUENCIA DE PULSOS (SDCKA). CADA BIT DE LA SECUENCIA DE BITS PARES SE DISTRIBUYE ENTRE PULSOS DE UNA SEGUNDA SEÑAL DE SECUENCIA DE PULSOS CON UN INTERVALO CONSTANTE, FORMANDO ASI UNA SEGUNDA SEÑAL DE SECUENCIA DE PULSOS (SDCKB). LOS EJES DE TIEMPO RESPECTIVOS SE AJUSTAN DE TAL FORMA QUE EL COMPONENTE DE RELOJ DE LA PRIMERA SEÑAL DE SECUENCIA DE PULSOS SE SITUA EN LA SECCION DE DATOS DE LA SEGUNDA SEÑAL DE SECUENCIA DE PULSOS, Y EL COMPONENTE DE RELOJ DE LA SEGUNDA SEÑAL DE SECUENCIA DE PULSOS SE SITUA EN LA SECCION DE DATOS DE LA PRIMERA SEÑAL DE SECUENCIA DEPULSOS. LOS DATOS SE TRANSMITEN UTILIZANDO ESTAS SEÑALES AJUSTADAS PRIMERA Y SEGUNDA DE SECUENCIA DE PULSOS.

Description

Método de transmisión de datos y sistema de juego construido según dicho método.

Campo y antecedentes de la invención

La presente invención se refiere a una tecnología de interfaz que proporciona una conexión mutua entre dispositivos de procesamiento de datos, los cuales procesan datos, y dispositivos periféricos, que conducen la entrada/salida de información, y similares; y, más en particular, se refiere a un nuevo estándar de tecnología de interfaz relacionado con las conexiones entre los dispositivos de juego y aquellos periféricos asociados.

Los métodos de transmisión de datos que se emplean en las comunicaciones de datos entre una unidad principal de un dispositivo de procesamiento de imágenes y los dispositivos periféricos asociados a la misma incluyen:

\bullet: Sistema bus I^{2}C de Philips

: En este sistema, dos cables transmiten datos en serie y un reloj en serie. Los datos y el reloj están físicamente separados y la transmisión/recepción de datos y su reproducción son posibles gracias al método más simple. El bus I^{2}C se describe, por ejemplo, en el manual de instrucciones del sistema bus I^{2}C de Philips (enero 1992).

\bullet: Sistema de enlace DS de SGS - Thomson

: En este sistema, dos cables transmiten una señal de datos y señales de muestreo. Se reproduce una señal de reloj por medio de la señal de datos y de la señal de muestreo. Cuando los datos transmitidos cambian a un valor diferente, sólo cambia la señal de datos. Cuando los datos transmitidos tienen el mismo valor, sólo cambia la señal de muestreo. Por ejemplo, si cambian los datos transmitidos en la señal de datos de "0" \rightarrow "1" ó de "1" \rightarrow "0", entonces la señal de muestreo no cambia. Si los datos transmitidos en la señal de datos no cambian, por ejemplo "0" \rightarrow "0" ó "1" \rightarrow "1", entonces sólo cambia la señal de muestreo. Por tanto, si se realiza una operación OR-exclusivo para la señal de datos y la señal de muestreo, es posible reproducir la señal de reloj. El sistema de enlace DS se presenta en Nikkei Electronics, vol. 675, (4 noviembre 1996, pp. 167 - 171). En aquellos dispositivos destinados al consumidor, por ejemplo dispositivos de juego, es necesario usar un sistema de transmisión de datos y de conexión de interfaz estándar que se pueda utilizar con un bajo coste. Sin embargo, en el sistema de bus I^{2} mencionado, debido a que el límite de transición de la señal de datos tiene la misma temporización que el límite de transición del reloj, no es posible utilizar la señal de reloj directamente en la parte de reproducción de datos (desmodulación). Además, en el sistema de enlace DS se aplica una lógica OR-exclusivo a la señal de datos y a la señal de muestreo para reproducir un reloj de sincronización. La señal de datos debe muestrearse usando este reloj. Por tanto, el nivel de simplicidad de la estructura de circuitos de la interfaz no satisface adecuadamente las condiciones de los dispositivos de juego domésticos, ya que es muy importante que los precios sean bajos.

En US 3.909.541 se describe una estructura "framing" de baja velocidad para un flujo de bits digital de alta velocidad. Un flujo de bits de alta velocidad que comprende información procedente de múltiples canales multiplexados y bits "framing" se divide sin ninguna restricción en varias flujos de bits de baja velocidad. Los flujos de bits de baja velocidad se dividen entonces de forma condicionada para formar un nuevo grupo de flujos de bits, y los nuevos flujos de bits son examinados en un detector de frames. Este detector varía la sincronización de la división condición según los flujos de bits hasta que aparece un patrón "framing" predeterminado entre los nuevos flujos de bits. La naturaleza de la coincidencia del patrón de framing identifica el modo de funcionamiento de la división no condicionada. Los nuevos flujos de bits se transfieren, de acuerdo con el modo de funcionamiento, para proporcionar múltiples salidas, donde cada salida corresponde a un canal multiplexado determinado independientemente del modo de funcionamiento de la división no condicionada.

Breve descripción de la invención

Por tanto, un objeto de la presente invención es proporcionar un sistema de transmisión de datos para una interfaz que tiene una composición de circuitos de bajo coste y que se puede aplicar a un dispositivo de procesamiento de imágenes, por ejemplo a un sistema de juego doméstico. Otro objeto de la presente invención es proporcionar un sistema de transmisión de datos para una interfaz, donde los datos se pueden separar de aquellos datos que portan señales mediante una composición de circuitos simple.

Es otro objeto de la presente invención proporcionar un dispositivo de juego y un dispositivo periférico asociado que comprenda interfaces, donde los datos se pueden separar de los datos que portan señales mediante una composición de circuitos simple.

Es otro objeto de la presente invención proporcionar una tecnología básica para desarrollar varios tipos de dispositivos periféricos, proponiendo una tecnología de interfaz novedosa entre un dispositivo de juego y un dispositivo periférico.

El objetivo se alcanza mediante un método de transmisión de datos según la reivindicación 1, un dispositivo de juego según la reivindicación 7 y un dispositivo periférico según la reivindicación 12. Otras novedades de la invención se indican en las reivindicaciones dependientes respectivas.

De este modo es posible crear una interfaz de comunicaciones en la que los circuitos de modulación y desmodulación se pueden formar de manera relativamente fácil con un pequeño número de líneas de transmisión de datos (a saber, dos líneas de transmisión de datos).

El dispositivo de juego relacionado con el método de transmisión de datos puede separar fácilmente los datos ya que una o las dos señales de datos comprenden un componente reloj de transmisión. El circuito de modulación y de desmodulación se puede construir de manera relativamente fácil.

Ya que el formato de señal para las comunicaciones de datos entre el dispositivo de juego y el dispositivo periférico está estandarizada mediante un formato de frame, se puede garantizar fácilmente la compatibilidad entre el dispositivo de juego y múltiples tipos de dispositivos periféricos.

Es posible aislar fácilmente los datos superpuestos en una señal de datos mediante el otro reloj.

El dispositivo de juego puede identificar, a partir de los datos de transmisión recibidos, la dirección del dispositivo periférico en la vía de transmisión de datos y las características de tal dispositivo periférico.

Las comunicaciones de datos directas se realizan entre el dispositivo de juego y los dispositivos periféricos de expansión.

Es posible evitar el uso de dispositivos de juego que sean incompatibles con los sistemas o aplicaciones denominados "plug and play".

El método de transmisión de datos según la presente invención se puede aplicar a un dispositivo de juego.

Conectando el dispositivo periférico a un dispositivo de juego que tiene múltiples puertos de entrada y salida, éste dirige las comunicaciones de datos con el dispositivo de juego y crea una dirección origen para si mismo en la vía de transmisión de datos con la información que se refiere a los puertos de entrada y salida tal como lo indica el dispositivo de juego, e información que representa el tipo de dispositivo periférico que incluye el mismo dispositivo.

El dispositivo periférico de expansión dirige las comunicaciones de datos con un dispositivo de juego que comprende múltiples puertos de entrada y salida mediante un dispositivo periférico (dispositivo periférico base) que tiene múltiples conectores de expansión conectados en paralelo a cualquiera de los puertos de entrada y salida. Éste crea una dirección fuente que se emplea en las comunicaciones de datos gracias a la información que se refiere al puerto de entrada/salida, tal como lo indica el dispositivo de juego, e información que se refiere al conector de expansión utilizado, tal como lo indica el dispositivo periférico. La dirección fuente no es simplemente una dirección, sino que también incluye información específica. Este tipo de función del dispositivo periférico es adecuada para sistemas "plug and play" y similares.

Breve descripción de las figuras

Figura 1: diagrama ilustrativo que muestra ejemplos de un servidor (dispositivo de juego) 1, un dispositivo periférico 2 y un dispositivo periférico de expansión 3.

Figura 2: organigrama que muestra un sistema de control del servidor.

Figura 3: organigrama que ilustra relaciones de conexión entre un servidor y los dispositivos.

Figura 4: organigrama que ilustra las relaciones entre un servidos, dispositivos superiores y dispositivo inferiores.

Figura 5: organigrama que ilustra la asignación de posiciones absolutas.

Figura 6: organigrama que ilustra que los dispositivos tienen permeabilidad posicional cuando se miran desde el servidor.

Figura 7: diagrama que ilustra la composición de un frame de datos transferidos.

Figura 8: organigrama que ilustra la composición de una interfaz a partir de la zona software.

Figura 9: organigrama que ilustra los niveles del protocolo de transmisión entre un servidor y un dispositivo.

Figura 10: diagrama que ilustra un sistema de transmisión de datos.

Figura 11: diagrama que ilustra un formato estándar de un frame de transmisión.

Figura 12: diagrama que ilustra un formato de frame de transmisión que comprende una opción CRC.

Figura 13: diagrama que ilustra (a) un modelo de puesta en marcha y (b) un modelo de fin de un patrón de sincronización.

Figura 14: diagrama que ilustra un modelo de puesta en marcha con opción CRC.

Figura 15: diagrama que ilustra un patrón de permiso de ocupación SDCKB.

Figura 16: diagrama que ilustra un modelo de reinicialización.

Figura 17: diagrama que ilustra un modo de comunicación entre un servidor y una función de dispositivo.

Figura 18(a): diagrama que ilustra un aspecto del bus M donde las comunicaciones de datos se realizan de manera intermitente de acuerdo con un formato según el cual las funciones del dispositivo responden a los comandos del servidor.

Figura 18 (b): diagrama que ilustra un ejemplo donde los datos que se van a transmitir son largos, y los datos se transmiten de manera intermitente mediante múltiples frames de transmisión.

Figura 19: diagrama que muestra una ilustración aproximada del funcionamiento de un dispositivo.

Figura 20: diagrama que ilustra un procedimiento de establecimiento de posición absoluta (AP).

Figura 21: diagrama de circuito en bloques que ilustra un MIE servidor.

Figura 22: diagrama de circuito en bloques que ilustra los principios de funcionamiento de un codificador de frame.

Figura 23: tabla de tiempos que ilustra el funcionamiento de un codificador frame.

Figura 24: diagrama de circuito en bloques que ilustra los principios de funcionamiento de un registro de desplazamientos alternos.

Figura 25: tabla de tiempos que ilustra el funcionamiento de un registro de desplazamientos alternos (conversión paralelo a serie).

Figura 26: diagrama de circuito en bloques que ilustra los principios de funcionamiento de un decodificador de frame.

Figura 27: tabla de tiempos que ilustra el funcionamiento de un decodificador de frame.

Figura 28: diagrama de circuito en bloques que ilustra los principios de funcionamiento de un registro de desplazamientos alternos (conversión serie a paralelo).

Figura 29: tabla de tiempos que ilustra el funcionamiento de un registro de desplazamientos alternos.

Figura 30: organigrama que ofrece una ilustración aproximada de la composición general de un controlador estándar.

Figura 31: organigrama que ilustra un MIE de controlador estándar.

Figura 32: organigrama que ilustra una sección de conexión de bus que es permeable a los datos (permeabilidad posicional).

Figura 33: diagrama de circuito en bloques que ilustra un MIE de dispositivo U.

Figura 34: diagrama de circuito en bloques que ilustra un MIE de dispositivo L.

Figura 35: organigrama que ilustra la identificación de un modelo de transmisión en un MIE.

Figura 36: organigrama que ilustra la formación de una señal de frame de formato estándar.

Figura 37: organigrama que ilustra la formación de una señal frame de un formato con opción CRC.

Figura 38: organigrama que ilustra el funcionamiento mediante un modelo de ocupación SDCKB.

Figura 39: organigrama que ilustra la transmisión de un modelo de reinicialización.

Figura 40: organigrama que ilustra la operación de recepción de un MIE.

Figura 41: organigrama que ilustra el procesamiento en un caso en el que se detecta un modelo de puesta en marcha.

Figura 42: organigrama que ilustra el procesamiento en un caso en el que se detecta un modelo de puesta en marcha que comprende CRC.

Figura 43: organigrama que ilustra un ejemplo en el que el servidor lee información inherente que incluye el dispositivo.

Figura 44: diagrama que ilustra múltiples modos para conectar un servidor, dispositivos base y dispositivos de expansión.

Figura 45: diagrama que ofrece una ilustración conceptual de la relación entre un servidor y las funciones (dispositivos base y dispositivos de expansión).

Figura 46: diagrama que ilustra la comunicación de datos entre un servidor, un dispositivo base y un dispositivo de expansión, mediante un modelo en capas.

Figura 47: diagrama que ilustra las relaciones de conexión entre un dispositivo base y dispositivos de expansión.

Figura 48: diagrama que ilustra la composición de los datos del frame.

Figura 49: diagrama que ilustra un Time Out (exceso de tiempo permitido).

Figura 50: diagrama que ilustra la transmisión de datos mediante una señal SDCKA y una señal SDCKB.

Figura 51: diagrama que ilustra un modelo de puesta en marcha y un modelo de terminación.

Figura 52: diagrama que ilustra un patrón de permiso de ocupación SDCKB.

Figura 53: diagrama que ilustra un modelo de reinicialización.

Figura 54: diagrama que ilustra un formato de frame.

Figura 55: diagrama que ofrece una ilustración aproximada de una transmisión de datos entre un servidor y un dispositivo periférico (dispositivo base o dispositivo de expansión).

Figura 56(a): diagrama que ilustra cómo se realizan comunicaciones de datos de manera intermitente mediante un formato donde los dispositivos responden a comandos transmitidos por el servidor a los dispositivos.

Figura 56(b): diagrama que ilustra un ejemplo en el que los datos que se van a transmitir se dividen en múltiples de datos y se transmiten de manera intermitente mediante múltiples frames de transmisión, cuando los datos que se van a transmitir sobrepasan el volumen que se puede transmitir mediante un único frame de transmisión.

Figura 57: diagrama que ilustra todos los valores AP para un servidor, dispositivos base y dispositivos de expansión.

Figura 58: diagrama que ilustra un procedimiento de selección AP (dirección absoluta) para un dispositivo base.

Figura 59: diagrama que ilustra un procedimiento de selección AP (dirección absoluta) para un dispositivo de expansión.

Figura 60: diagrama que ilustra una transferencia de datos de frame entre un servidor, un dispositivo base y un dispositivo de expansión.

Figura 61: diagrama que ilustra un procedimiento de comunicación normal entre un servidor y un dispositivo base (o dispositivo de expansión).

Figura 62: diagrama que ilustra un procedimiento de ocupación SDCKB entre un servidor y un dispositivo base.

Figura 63: organigrama que ilustra un MIE servidor.

Figura 64: organigrama que ilustra la composición de un dispositivo base.

Figura 65: organigrama que ilustra la composición de un MIE de dispositivo base.

Figura 66: organigrama que ilustra una conexión entre un dispositivo base y un dispositivo de expansión.

Figura 67: diagrama que ilustra un procedimiento en un caso en el que un dispositivo base recibe datos de un servidor.

Figura 68: diagrama que ilustra un procedimiento en un caso en el que un dispositivo base recibe datos del servidor que se refieren a un volumen superior al búfer de transmisión y recepción.

Figura 69: diagrama que ilustra un procedimiento en un caso en el que se transmiten datos desde un dispositivo base al servidor.

Figura 70: diagrama que ilustra un procedimiento en un caso en el que datos con un volumen superior al búfer de transmisión y recepción del MIE se transmiten de un dispositivo base a un servidor.

Figura 71: diagrama que ilustra un comando "Device Request".

Figura 72: diagrama que ilustra un comando "All Status Request".

Figura 73: diagrama que ilustra un comando "Device Reset".

Figura 74: diagrama que ilustra un comando "Device Kill".

Figura 75: diagrama que ilustra un comando "Data Transfer".

Figura 76: diagrama que ilustra un comando "Get Condition".

Figura 77: diagrama que ilustra un comando "Get Media Info".

Figura 78: diagrama que ilustra un comando "Block Read".

Figura 79: diagrama que ilustra un comando "Block Write".

Figura 80: diagrama que ilustra un comando "Get Last Error".

Figura 81: organigrama que muestra un ejemplo de un dispositivo base (controlador de juego) que tiene una dirección relativa.

Figura 82: organigrama que muestra un ejemplo de un dispositivo base (controlador de juego) que tiene una dirección absoluta.

Figura 83: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho LCD) que tiene una dirección relativa.

Figura 84: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho LCD) que tiene una dirección absoluta.

Figura 85: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho de memoria) que tiene una dirección relativa.

Figura 86: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho de memoria) que tiene una dirección absoluta.

Figura 87: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho vibratorio) que tiene una dirección relativa.

Figura 88: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho vibratorio) que tiene una dirección absoluta.

Figura 89: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho de arma luminosa) que tiene una dirección relativa.

Figura 90: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho de arma luminosa) que tiene una dirección absoluta.

Figura 91: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho de entrada de sonido) que tiene una dirección relativa.

Figura 92: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho de entrada de sonido) que tiene una dirección absoluta.

Figura 93: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho de salida de sonido) que tiene una dirección relativa.

Figura 94: organigrama que muestra un ejemplo de un dispositivo de expansión (cartucho de salida de sonido) que tiene una dirección absoluta.

Figura 95: diagrama que muestra un ejemplo en el que un bus M está formado por un sistema inalámbrico (radio).

Figura 96: diagrama que muestra otro ejemplo en el que un bus M está formado por un sistema inalámbrico (transmisión óptica).

Figura 97(a): diagrama que muestra un conector de bus M de un controlador de juego.

Figura 97(b): diagrama que ilustra un conector de bus M de un controlador de juego.

Figura 98: diagrama que muestra otro ejemplo de un controlador de juego.

Figura 99: vista lateral que ilustra un ejemplo de socket de un conector bus M.

Figura 100(a): vista lateral que ilustra una clavija de conector de bus M.

Figura 100(b): vista superior de esa clavija.

Figura 100(c): una vista frontal de esa clavija.

Figura 101: diagrama de un conector situado en un lateral del dispositivo periférico (dispositivo base) de un cable de bus M.

Figura 102(a): vista superior de una socket de conector bus LM.

Figura 102(b): vista frontal de esa clavija.

Figura 103(a): vista superior de una clavija de conector de bus LM.

Figura 103(b): vista frontal de esa clavija.

Descripción detallada de la invención Resumen de la composición

En primer lugar, y con referencia a las Figuras 1 y 2, se describe un resumen de la composición del sistema. La Figura 1 es un diagrama ilustrativo para describir un dispositivo de juego que comprende un sistema informático. La Figura 2 es un organigrama para describir un sistema de control para este dispositivo de juego.

El dispositivo de juego (servidor) 1 comprende: una CPU 1a para ejecutar programas de juego y similares; una ROM 1b para almacenar programas de control, datos, OS y similares, para el dispositivo de juego; un dispositivo CD-ROM 1c para almacenar programas de aplicación y datos de juegos; un controlador de bus 1d para controlar la transferencia de datos entre la CPU y otras secciones; una RAM 1e para almacenar programas y datos para la CPU 1a, que se usan en el procesamiento de datos; un procesador de dibujo 1f para generar señales de imagen a partir de datos del dibujo; un procesador de sonido 1g para formar señales de sonido a partir de datos de sonido; una interfaz periférica 1h para transferir datos entre la CPU 1a y los dispositivos periféricos externos; y similares. Una parte de la RAM 1e se utiliza como RAM de trabajo para procesar datos periféricos, facilitando así una operación denominada DMA. Una señal de imagen y una señal de sonido se suministran a un monitor 4 (por ejemplo un monitor de televisión) y se general salidas de imágenes de vídeo y sonido. Los dispositivos periféricos comprenden dispositivos periféricos básicos 2 y dispositivos periféricos de expansión 3. Los dispositivos periféricos básicos 2 se conectan a la interfaz periférica 1h mediante un conector 1i y los dispositivos periféricos de expansión 3 se conectan a los dispositivos periféricos básicos 2. Los dispositivos periféricos básicos 2 y los dispositivos periféricos de expansión 3 se conectan eléctricamente (o mediante una estructura lógica) al servidor en paralelo. Los dispositivos periféricos básicos 2 son, por ejemplo, controladores de juego, y los dispositivos periféricos de expansión 3 son, por ejemplo, dispositivos de entrada de sonido, de salida de sonido, módulos de armas de rayos luminosos, dispositivos vibrantes, dispositivos de memoria o similares.

Aquí, en el primer modo de ejecución descrito (primer modelo de interfaz), los dispositivos periféricos se investigan en lo que se refiere a la función que realizan y éstos se dividen en dispositivos de función U y de función L. Esta clasificación tiene en cuenta el hecho de que, además de los casos en los que un único dispositivo periférico realiza una sola función, también existen casos en los que un único dispositivo periférico realiza múltiples funciones, y casos en los que múltiples dispositivos periféricos realizan una única función.

Por otro lado, en el segundo modo de ejecución descrito posteriormente (segundo modelo de interfaz), los dispositivos periféricos se dividen en dispositivos periféricos básicos y dispositivos periféricos de expansión dependiendo de las relaciones entre los dispositivos.

En líneas generales, los modos de llevar a cabo la presente invención se clasifican en un primer modo de ejecución y en un segundo modo de ejecución.

Primer modo de ejecución

Inicialmente, el significado de la terminología que se usa en el primer modelo de interfaz según la presente invención se describe haciendo referencia a las figuras.

En primer lugar, los datos que se han obtenido expandiendo datos en una serie de tiempos se denominan "datos en serie". Una línea de señal que intercambia datos como de datos en serie se denomina "bus en serie". Un bus en serie que conecta un dispositivo de juego y dispositivos periféricos mediante el modelo de interfaz según la presente invención se denomina bus M (bus-M).

El número de identificación del sistema de registro asignado inicialmente a la función del dispositivo de cada dispositivo periférico se denomina "ID del dispositivo". Se pueden preparar múltiples tipos de dispositivos, por ejemplo 256 tipos de dispositivos ID. También es posible tener varios de los múltiples los dispositivos en un único puerto.

La sección mediante la cual se puede conectar un dispositivo periférico a un dispositivo controlador periférico de juego a través del bus M se denomina "puerto". El bus M permite la conexión activa de múltiples puertos. Es posible, por ejemplo, incluir 16 puertos, aunque este modo de ejecución se refiere a un ejemplo en el que se incluyen cuatro puertos (puerto A, puerto B, puerto C, puerto D).

Como se muestra en la Figura 3, el dispositivo de juego se denomina "servidor" y una función del dispositivo periférico conectada al mismo se denomina "función de dispositivo". Ya que la "función de dispositivo" indica una función de un dispositivo más que al dispositivo en su mismo (producto), además de los casos en los que un único dispositivo realiza una única función, es posible también dividir la función de un único dispositivo en múltiples funciones, cada una de las cuales es aceptada como una función de dispositivo. En el bus M hay un dispositivo servidor que se conecta a las funciones de dispositivo en una configuración en árbol. Cada función de dispositivo aparece como si estuviera presente en el mismo bus M. Se pueden conectar múltiples funciones de dispositivo, por ejemplo 14 funciones de dispositivo, a un único puerto. Las funciones de dispositivo permiten a los dispositivos periféricos del dispositivo de juego funcionar, por ejemplo, como un controlador de juego, un bloque de juegos, un joystick, un teclado, un dispositivo de control de imitación, un arma de imitación, un dispositivo de grabación, un dispositivo de sonido y similares.

Como se muestra en la Figura 4, las funciones de dispositivo se dividen en dos tipos: "función de dispositivo superior (U)" y "función de dispositivo inferior (L)". Las funciones de dispositivo U se pueden conectar al servidor. Las funciones de dispositivo U tienen capacidad para controlar las funciones de dispositivo L. Las funciones de dispositivo L están basadas en la premisa de que están conectadas (o pueden conectarse) con una función de dispositivo U. Un bus M que conecta una función de dispositivo-L a una función de dispositivo-U se denomina "bus LM".

Si no se proporciona al menos una función de dispositivo U en un puerto, ese puerto no se puede utilizar. Principalmente, los controladores del dispositivo de juego forman funciones de dispositivo U y los dispositivos de expansión (conectados periféricamente) forman funciones de dispositivo L. El bus M se puede conectar, por ejemplo, a un máximo de 14 funciones de dispositivo-L.

Además, es posible conectar una función de dispositivo-U a una función de dispositivo-U. En este caso, la función de dispositivo-U conectada se convierte en una función de dispositivo-L. No es necesario separar físicamente las funciones de dispositivo-U y las funciones de dispositivo-L y otra función del dispositivo que está separado de manera lógica dentro de la función de dispositivo-U puede formar una función de dispositivo-L.

Por ejemplo, dentro del IC de control de función del dispositivo (por ejemplo un microordenador o microcontrolador) del dispositivo periférico, las secciones de control digital y analógico se pueden ajustar mediante función como funciones de dispositivo-U y funciones de dispositivo-L, respectivamente, y cuando no se emplea una sección de control analógico, es decir una función de dispositivo-L, es posible inutilizar esa sección.

Según muestra la Figura 5, se asignan números en orden a cada función de dispositivo desde un puerto A, de manera que se puede acceder directamente a cada una de las múltiples funciones de dispositivo a través del servidor en cada puerto del mismo. El número de identificación (o símbolo) de acceso asignado a cada función de dispositivo se denomina "posición absoluta (AP)".

En el bus M, se asignan múltiples funciones de dispositivo a un único puerto del servidor. La relación entre el número de puertos en el bus M y el número de APs se expresa con la siguiente ecuación:

(máximo número de puertos) x (máximo número de APs asignados a un puerto) = constante

En el bus M según el modo de ejecución, la "constante" se toma para representar un byte. En este caso, (4 puertos (máximo 16 puertos)) x (APs para un máximo número de puertos) = 1 byte.

De los 16 APs, un AP se reserva para el puerto de servidor, con lo cual hay un máximo de 15 APs asignados a cada uno de los puertos. Por tanto, se puede usar un máximo de 15 funciones de dispositivo en un puerto. Además, ya que una función de dispositivo U está conectada a un puerto, el máximo número de funciones de dispositivo L en cada puerto es de 14.

El rando de números que se pueden emplear en un puerto se designa para cada puerto mediante los APs asignados a las funciones de dispositivo. Por ejemplo, el AP se compone de la siguiente manera:

Bit: 76543210

AP: pppp\Box\Box\Box\Box

Aquí "pppp" es el número de puerto (puerto A = "0000", puerto B = "0001", C = "0010", puerto D = "0011"), y "\Box\Box\Box\Box" es el número de serie ("0000" (decimal de "0") - "1111" (decimal de "15")). En consecuencia, los APs para un máximo de funciones de dispositivo es quince, y se pueden ajustar quince funciones de dispositivo en un puerto.

Si se indica en valores binarios, el valor AP de la función de dispositivo es "00000001" - "00001111" en el puerto A, "000100001" - "00011111" en el puerto B, "00100001" - "00101111" en el puerto C y "00110001" - "00111111" en el puerto D.

Si se indica en valores decimales, los valores anteriores son 1-15, 17-31, 33-47, 49-63, y en valores hexadecimales, #01 - #0F, #11 - #1F, #21 - #2F y #31 - #3F.

El AP de cada puerto del servidor visto desde la función de dispositivo es siempre el menor valor AP que se puede utilizar en ese puerto, y en el puerto A, es #00, en el puerto B, es #10 (16), en el puerto C, es #20 (32) y en el puerto D es #30 (48). La función de dispositivo y el servidor pueden identificar el puerto al que está conectado mediante los primeros cuatro bits del AP. El acceso a la función de dispositivo especifica una función de dispositivo a la que accede este AP.

Si la designación de un AP relacionado a cada función de dispositivo es al mismo tiempo la designación de una función de dispositivo, el servidor puede acceder directamente a cada función de dispositivo del dispositivo periférico. Por tanto, como se muestra en la Figura 6, vista desde el servidor, el servidor aparece conectado directamente a cada función de dispositivo. Dicho de otro modo, cada dispositivo aparece conectado al mismo bus.

El intercambio de datos entre el servidor y la función de dispositivo no se realiza mediante comunicaciones unidireccionales convencionales, sino que se hace utilizando determinadas instrucciones específicas, por ejemplo se pueden transmitir y recibir datos adecuados de ese momento y lugar. Estas instrucciones se denominan "comandos". Los datos de comando se denominan "parámetros".

Un ciclo de datos de transmisión se compone de un frame (por ejemplo 256 bytes) que comprende un comando + un parámetro, como se muestra en la Figura 7. El parámetro puede incluir datos de AP, tamaño de los datos, y datos, o se pueden omitir los datos.

En principio, el servidor accede a una función de dispositivo mandando un comando. Cuando la función de dispositivo ha preparado los datos correspondientes, manda un comando al servidor y envía los datos. En el bus M se puede preparar, por ejemplo, un máximo de 254 comandos y se puede transmitir un máximo de 253 bytes de datos.

Un lugar para conectar un dispositivo de expansión para expandir las funciones del dispositivo periférico, por ejemplo un controlador de juego que funciona como un dispositivo de entrada de ejecución de juegos, se denomina "socket de expansión". En principio, los dispositivos L están conectados a sockets de expansión. Un controlador de juego estándar puede comprender, por ejemplo, dos sockets de expansión. El bus M puede estar provisto de un número de sockets de expansión igual al número de funciones de dispositivo L, por ejemplo 14 en el caso de este modo de ejecución.

Un circuito que transforma datos determinados en datos en serie para el bus M, de manera que se pueden comunicar a través del bus M, se denomina "motor I/E del bus M" (MIE). Todos los dispositivos estándar de bus M comprenden MIEs de este tipo. El servidor incorpora un MIE de servidor, las funciones de dispositivo U, un MIE de función de dispositivo U, las funciones de dispositivo L y un MIE de función de dispositivo L.

Como se muestra en la Figura 8, para que el servidor tenga acceso a una función del dispositivo, siempre es necesario operar a través de un software (driver de bus M) que ejerza un control general sobre las funciones del dispositivo. El driver de bus M controla y gestiona las funciones del dispositivo. Este driver de bus M gestiona el ID del dispositivo (número de identificación de función), el AP (posición absoluta), el puerto, etc, y controla y gestiona la recepción y transmisión de comandos, el formato de los datos y similares. Los comandos se pueden aumentar mejorando (modernizando) y aumentando el driver de bus M.

En el bus M, todas las funciones de dispositivo tienen obligación de contener información particular de si mismas (información inherente) grabada según un formato prescrito. Esta función de dispositivo se denomina "Estado de dispositivo".

El estado de dispositivo graba el nombre del producto, la ID del dispositivo, el número de modelo, el destino, el número de buses LM, y similares, como datos de gestión, y el consumo de energía en estado de espera y el consumo de energía máximo, etc, como datos eléctricos (información hardware). El driver de bus y la interfaz del programa de aplicación (API) gestionan y utilizan el estado del dispositivo; por ejemplo, permite identificar el nombre del producto y la capacidad de conexión del dispositivo periférico, y permite que se pueda controlar la energía de todos los puertos en base al máximo consumo de energía, y similares.

La Figura 9 ofrece una ilustración aproximada del objeto propuesto del presente modelo de interfaz. El software de aplicación que se realiza en el servidor controla la comunicación de datos con las funciones de dispositivo en los dispositivos periféricos vía el software llamado API, o directamente dando instrucciones al driver de bus M. Los comandos que forman el driver de bus M según las instrucciones se suministran vía el MIE del servidor, el cable, el MIE del dispositivo periférico y el controlador de MIE, al software de control, que forma el núcleo de las funciones de dispositivo del dispositivo periférico. Este software de control envía una respuesta correspondiente al comando en cuestión al software de aplicación que se realiza en el servidor vía el controlador de MIE, el MIE de dispositivo periférico, el cable, el MIE del servidor y el driver de bus. Es posible proporcionar generar múltiples funciones de dispositivo en un dispositivo periférico y, en este caso, es posible que cada función de dispositivo comparta el uso de un MIE. Aquí, los MIEs, los cables de conexión, etc, representan niveles físicos, y el driver de bus M y el controlador de MIE representan niveles lógicos.

A continuación se describe la transmisión de datos al bus M. En el bus M, la transmisión de datos se realiza mediante un sistema en serie sincronizado. Los cables de conexión comprenden un total de cuatro líneas: un par de líneas de corriente (Vcc, GND) y un par de líneas de transmisión de datos (SDCKA, SDCKB: bidireccionales). Si es necesario, se añade un cable protector para proteger el cable de conexión con miras a evitar ruidos. La transmisión y recepción de datos utiliza un sistema semiduplex de comunicaciones bidireccional que se ajusta a una velocidad de transferencia de datos adecuada, por ejemplo 2 Mbps.

A continuación se describen los principios de transmisión de datos con referencia a la Figura 10. Los datos se transmiten mediante un reloj de transmisión de datos en serie (SDCK) A y un reloj de transmisión de datos en serie (SDCK) B, que propagan una línea de datos. Cuando transmiten los datos, los relojes de transmisión de datos en serie A y B comprenden un componente de reloj y forman alternativamente un borde negativo (borde descendente), como se muestra en la Figura 10. Dicho de otro modo, como se muestra en la sección de modelos de datos de la Figura 11, los bits de datos se introducen entre cada impulso de la secuencia de impulsos del reloj de transmisión y los relojes de transmisión de datos en serie A y B se desplazan relativamente entre si una distancia adecuada por el eje del tiempo (un salto de tiempo por el cual el borde de impulso de una señal se coloca en la sección de datos de la otra señal). En el lado de recepción, la sección de datos de una señal se bloquea de acuerdo con la sincronización del borde negativo de la ondulación de la otra señal, y esta sección de datos se lee para producir datos (reproducción de datos). Los datos se transfieren comenzando por el bit más significativo (MSB). Un circuito para llevar a cabo la transmisión de datos de este modo se puede construir de manera relativamente simple. Además, la sincronización del bloqueo de datos puede basarse también en el borde positivo (borde ascendente) de la señal.

De acuerdo con este sistema, es posible reducir la frecuencia de transmisión en una ruta de transmisión de datos, si se compara con un sistema de enlace BUS I^{2} o DS. Por ejemplo, para transmitir a una velocidad de transferencia de datos de 10 Mbit/s utilizando un sistema de enlace BUS I^{2} o DS, es necesario hacer funcionar el medio de transferencia de datos a 10 MHz. Sin embargo, si se aplica el presente sistema, ya que 10 Mbit de datos se trasmiten particionándolos en dos líneas de transmisión de datos que portan, en teoría, 5 Mbit cada una, es posible obtener una velocidad de transferencia de datos de 10 Mbit/s usando un reloj de transferencia de datos de 5 MHz en las líneas de datos. Además, ya que la duración del impulso se prolonga insertando datos entre los impulsos del reloj, en las secciones correspondientes, la frecuencia de transmisión desciende en una cantidad equivalente. Ya que una menor velocidad de transmisión es satisfactoria, el diseño del circuito se simplifica.

Las Figuras 11 y 12 muestran ejemplos de formatos de transmisión de señales. Un formato de transmisión comprende un modelo de puesta en marcha, un modelo de transmisión de datos y un modelo de fin, y si es necesario, se añaden bits CRC (control cíclico por redundancia).

La Figura 11 muestra un formato de transmisión estándar. La transmisión de datos se controla en unidades frame (unidad más pequeña). La composición de una frame en el formato estándar comienza con un modelo de puesta en marcha (START), que indica el comienzo de la transmisión de datos, y después comprende un modelo de datos de 256 bytes de longitud (DATA), y un modelo de fin (END). Los símbolos "D" que se muestran en el modelo de datos representan secciones que contienen información de los bits "0" y "1" de los datos.

La Figura 12 muestra un ejemplo de un formato que incorpora la opción CRC, donde se añade una función de corrección de errores al formato de datos estándar. Por ejemplo, se puede emplear un control cíclico por redundancia (CRC) como método para la corrección de errores. En la transmisión de datos con la opción CRC, se añade un patrón código CRC después de los datos que son objeto del CRC, como se ilustra en el modelo de datos de la Figura 12.

Las partes que están fuera del modelo de datos con el formato de transmisión descrito anteriormente forman patrones de información que contienen información específica. Los patrones de información se definen mediante el número de impulsos de señal (relojes de transmisión) para los cuales cada una de las líneas de datos SDCKA o SDCKB propaga la otra línea de señales mientras está en un nivel "L". Los patrones de información pueden incluir, por ejemplo, modelos de sincronización, modelos de permiso de ocupación de líneas de datos, modelos de reinicialización y similares. Los patrones de sincronización incluyen: patrones de comienzo como los que se ilustran en la Figura 13(a),
patrones de fin como los que se ilustran en la Figura 13(b) y patrones de comienzo con opción CRC como los que se ilustran en la Figura 14.

Un patrón de puesta en marcha es un modelo de sincronización que se ha transmitido antes del modelo de datos mencionado antes. Si el MIE del lado receptor detecta cuatro bordes negativos de la línea de datos SDKB mientras la línea de datos SDCKA está en el nivel "L", el siguiente patrón se lee como un patrón de datos y se almacena en el búfer usando una memoria. El patrón de fin indica el fin del patrón de datos. Si el MIE del lado receptor detecta dos bordes negativos de la línea de datos SDCKA mientras la línea de datos SDCKB está en el nivel "L", esto confirma que el patrón de datos ha terminado e indica que el proceso ha finalizado de manera adecuada.

El patrón de puesta en marcha con la opción CRC representa el patrón START cuando se añade la opción CRC. Si el MIE del lado receptor detecta seis bordes negativos de la línea SDKB mientras la línea SDCKA está en el nivel "L", esto se identifica como una transmisión de datos que comprende una opción CRC. Se realiza una revisión de errores con respecto a la sección de datos empleando los 16 bits anteriores al patrón END como datos CRC.

La Figura 15 muestra un ejemplo de modelo de permiso de ocupación de una línea de datos por el cual el servidor permite al lado receptor ocupar una de las líneas de datos. En un modelo de permiso de ocupación que se refiere a la ocupación de la línea de datos SDCKB, la línea SDCKB tiene ocho bordes negativos cuando SDCKA está en el nivel "L". Cuando el MIE del lado receptor detecta un modelo de permiso de ocupación SDCKB, es posible ocupar SDCKB cuando SDCKA está en el nivel "L", comenzando por el siguiente borde negativo de SDCKA. El siguiente borde positivo de SDCKA, cancela la ocupación de SDCKB.

Por ejemplo, es posible enviar datos de salida desde un arma luminosa de un dispositivo de juego de tiro al dispositivo de juego ocupando la línea de datos SDCKB. Los datos se transfieren usando únicamente la línea de datos SDCKB, y la línea de datos SDCKA indica el tiempo de ocupación (periodo).

La Figura 16 muestra un patrón de reinicialización. El patrón de reinicialización comprende 14 bordes negativos de la línea datos SDCKB cuando la línea de datos SDCKA está en el nivel "L". Cuando el MIE del lado receptor detecta el patrón de reinicialización, éste lo identifica como una petición de reinicialización procedente del servidor. El dispositivo inicializa entonces el MIE y borra el AP. Ningún dato más aparte de estos se inicializa.

A continuación, y con referencia a la Figura 17, se describe el protocolo de transmisión en la comunicación de datos entre el servidor y el dispositivo.

En primer lugar, el servidor tiene, en principio, el derecho de prioridad para transmitir comandos. Las comunicaciones se realizan en un modo en el que la función de dispositivo correspondiente responde a un comando procedente del servidor. Por tanto, todos los protocolos de transmisión empiezan con la transmisión de un comando procedente del servidor. La Figura 18(a) ilustra esto. Los datos se transmiten desde el servidor a la función de dispositivo cuando surge la necesidad. Por tanto, en el bus M y el bus LM se sucede una comunicación de datos intermitente entre el servidor y múltiples funciones de dispositivo. Si los datos a transmitir sobrepasan la longitud estipulada para una frame de transmisión, los datos se particionan en múltiples secciones, como se muestra en la Figura 18(b), y cada una de las secciones de datos ya divididas se transmite mediante múltiples frames de transmisión (ver Figura
70).

El programa de aplicación del servidor accede al driver del bus para obtener datos de la función de dispositivo de un dispositivo periférico determinado. El driver crea un AP, formando una dirección y un comando, y el MIE envía datos frame llevando el AP y el comando al bus M. En un estado normal, las funciones de dispositivo conectadas al bus están en espera de un comando del servidor. El MIE del dispositivo periférico recibe los datos frame y transfiere el comando al programa de control de la función de dispositivo vía el controlador del MIE.

Si el programa de control detecta su propio AP, devuelve una respuesta al comando pertinente vía el controlador del MIE. El MIE crea datos frame que contienen el comando de retorno y el AP del servidor, y envía de salida éstos al bus. El servidor recibe estos datos frame obteniendo así una respuesta al comando transmitido. La función de dispositivo vuelve a un estado de espera de comandos.

De este modo, el servidor puede obtener la información requerida de una función de dispositivo.

A continuación, y con referencia a la Figura 19, se muestra una vista general del procesamiento realizado en las funciones de dispositivo. Cuando una línea eléctrica se conecta al dispositivo periférico y se suministra energía, la función de dispositivo ejecuta un proceso de inicialización para asignar valores iniciales de hardware y similares. Acto seguido, se realiza un proceso de asignación de AP para asignar el valor AP de la función de dispositivo. En el proceso de asignación de AP, se identifican las funciones de dispositivo conectadas, y se asignan los AP a las funciones de dispositivo, etc. Dando a la función de dispositivo un AP, es posible controlar las comunicaciones entre el servidor y la función de dispositivo usando el AP, produciéndose así un estado operativo normal.

En un estado operativo normal, cuando una función de dispositivo recibe un comando de reinicialización desde el servidor, se reinicializa el AP (reinicialización del software). Cuando se recibe un comando de reinicialización de bus, se inicializan todas las funciones de dispositivo conectadas al bus en el puerto correspondiente, y los AP se reinicializan (reinicialización del hardware). El servidor también puede ordenar que se prohiba o suspenda una operación, transmitiendo un comando a cada función de dispositivo.

A continuación, y con referencia a la Figura 20, se describe el proceso de asignación de AP en las funciones de dispositivo.

(1): Después de completarse la incialización, el servidor transmite un Device Request (Petición de Dispositivo) en secuencia, empezando por el puerto A, para confirmar si alguna función de dispositivo está conectada a los puertos. El comando Device Request es un comando que requiere cualquier función de dispositivo a la que no se le haya asignado un AP para devolverle su Device Status (Estado de Dispositivo), lo que proporciona información inherente al dispositivo. Ésta se transmite en secuencia empezando por el puerto A y terminando por el puerto D.

(2): Después de completarse la incialización, una función de dispositivo-U desconecta el bus LM del bus M y espera un Device Request (Petición de Dispositivo) procedente del servidor. Si recibe una Device Request del servidor, como respuesta devuelve un Device Status (Estado de Dispositivo) al servidor. En esta fase, sólo hay una función de dispositivo en un puerto que recibe una petición de dispositivo en cualquier momento. Las funciones de dispositivo no responden si no se les ha asignado un AP.

(3): Cuando el servidor recibe un Device Status procedente de una función de servidor, éste determina la relación de conexión y los atributos del dispositivo en base a estos datos y asigna un AP a la función de dispositivo y transmite una asignación de AP que incluye el valor AP asignado a la función de dispositivo. Los APs se asignan de manera consecutiva dentro de un rango asignado a cada puerto, y el servidor detecta la relación entre el AP y la función de dispositivo. Si los atributos de la función de dispositivo no son los que espera el software de aplicación (fuera del rango de uso), entonces la operación de esa función de dispositivo puede terminarse enviando un comando Device Kill. Si la función de dispositivo es una función de dispositivo-U, también terminan las funciones de dispositivo-L conectadas al mismo, permitiendo así inutilizar todo el puerto.

(4): La función de dispositivo lee la asignación de AP procedente del servidor, almacena su AP asignado y después transmite una Device Replay (Respuesta de Dispositivo) al servidor como respuesta desde la función de dispositivo. A continuación, el servidor accede a la función de dispositivo usando el ID del dispositivo y el AP.

(5): Ya que el servidor detecta el número de buses LM de la función de dispositivo que se ha fijado desde el Device Status (Estado de Dispositivo), si hay un bus LM, el servidor transmite Connect Lm-Bus (Conectar bus LM) de manera que uno de los buses LM conecte con una función de dispositivo. Si no se produce conexión de bus LM, se realiza el procesamiento (10) posterior.

(6): Cuando la función de dispositivo-U recibe Connect LM-Bus, ésta conecta un bus LM al bus M. Después envía una Device Replay al servidor.

(7): Cuando el servidor recibe Device Replay, éste transmite una Device Request. En este caso, ya que a la función de dispositivo-U ya se le ha asignado un AP, ésta no responde.

(8): Cuando una función de dispositivo-L recibe Device Request procedente del servidor, ésta envía un Device Status al servidor como respuesta.

(9): El proceso desde (3) a (8) se repite hasta que se conectan todos los buses LM (se han asignado APs a todas las funciones de dispositivo).

(10): El servidor envía Function Start (Comienzo de Función) para que comience la operación de cada función de dispositivo.

(11): Cuando la función de dispositivo recibe Function Start, ésta cambia desde la operación de asignación de AP a la operación normal. Después del cambio, la función de dispositivo envía Device Replay al servidor.

(12): Al recibir Device Replay, el servidor envía Function Start al siguiente AP.

(13): Cada función de dispositivo se activa en secuencia repitiéndose el proceso (11) y (12), hasta que la función de dispositivo que está en el AP final transmite Device Replay, después de lo cual termina el proceso de asignación de AP.

(14): Una vez que las funciones de dispositivo se han transferido a la operación normal, el servidor continúa con la asignación de AP para el siguiente puerto.

De este modo, se selecciona un AP para cada función de dispositivo conectada a un puerto determinado.

A continuación, se describe el proceso necesario para conectar o desconectar un cable mientras el servidor esta operativo (conexión/desconexión de una línea activa).

(1): El servidor transmite Device Request a cada puerto a intervalos determinados. Los puertos que no están en uso se pueden excluir de la operación de acceso.

(2): Si se transmite Device Status desde un puerto que no se ha conectado previamente, el servidor reconoce que se ha conectado una función de dispositivo. Al reconocer esto, envía un patrón de reinicialización a ese puerto y borra los APs para todas funciones de dispositivo. Después realiza un proceso de asignación de APs para restaurar los APs y volver a crear las conexiones.

(3): Si el servidor transmite un comando a una función de dispositivo y no hay respuesta desde ésta, el servidor reconoce que la función de dispositivo se ha desconectado. Si la función de dispositivo se desconecta, el servidor borra los APs y vuelve a crear las conexiones.

A continuación, se describe el proceso de transmisión y recepción de datos durante una operación normal.

(1) Derecho de prioridad de transmisión de comandos

El servidor siempre transmite inicialmente un comando y las funciones de dispositivo responden a éste. Si una función de dispositivo transmite primero un comando al servidor, éste no se reconoce. El servidor no retransmite comandos a menos que haya una petición desde el lado de la función de dispositivo.

(2) Formato de los datos

La transmisión y recepción de datos está formada por comandos y parámetros (datos AP, tamaño de los datos, datos). Cuando se transmite exactamente una señal por una línea de datos, el MIE le añade un patrón de puesta en marcha y de fin, antes del comando y al final de los parámetros, respectivamente. Por tanto, se forma y se transmite un frame en el orden: "patrón puesta en marcha" + "patrón comando" + "datos AP" + "tamaño de datos" + "patrón de fin".

El MIE del lado receptor analiza el frame, confirmando así el patrón de puesta en marcha y de fin. Posteriormente se describirán en detalle los comandos y parámetros.

(3) Servidor

El MIE empleado por el servidor es controlado por el driver del bus M. La lectura de los datos de la función de dispositivo no la realiza el MIE de forma automática, sino que la realiza el software correspondiente vía el driver del bus M. El software correspondiente aquí quiere decir un sowftare de un nivel superior si se compara al del driver del bus M, por ejemplo un software de librerías o un software de juego. En una única operación de acceso, es posible comunicar con una función de dispositivo que tenga un AP específico. Con miras a leer los datos procedentes de múltiples funciones de dispositivo en 1 INT, se accede al número correspondiente de funciones de dispositivo. 1 INT (interrupción) es una unidad de sincronización de la reescritura en pantalla TV, en concreto de aproximadamente 1/60 segundos. El control de conexión del puerto transmite un Device Request a los puertos no conectados, y si hay una respuesta, ese puerto se establece como "conectado". Cuando no hay transmisión, un puerto siempre se establece al modo entrada (recepción). El tipo de comando a utilizar difiere según la función de dispositivo y del tiempo y las circunstancias, ajustándose según la especificación de la función de dispositivo.

(4) Funciones de Dispositivo

La CPU o equivalente, controla los MIE para los dispositivos periféricos vía un controlador MIE, ejecutando la CPU los programas de función de dispositivo. Las funciones de dispositivo mantienen un estado de recepción hasta que el servidor transmite un comando. Las funciones de dispositivo generan entonces sus propios datos necesarios para las comunicaciones. Además, de manera asíncrona al acceso desde el servidor, las funciones de dispositivo crean datos para ser transmitidos como función de ese dispositivo determinado (por ejemplo, dispositivo de entrada de operación como un mando de control o joystick). Si hay una petición del servidor, los datos se transmiten dentro de un periodo de tiempo fijado. El servidor transmite el mismo comando a todas las funciones de dispositivo conectadas al mismo puerto. Las funciones de dispositivo analizan el comando y los parámetros recibidos, y devuelven un comando sólo si se corresponde a sus propios AP. Si no se corresponde a sus propios AP, no tienen que responder al servidor. El tipo de comando utilizado varía dependiendo de la función de dispositivo y del tiempo y las circunstancias, con lo cual los detalles del mismo se determinan dependiendo de la especificación de la función de dispositivo.

(5) Operaciones prohibidas

El acceso directo desde una función de dispositivo a otra función de dispositivo conectada al mismo puerto está prohibido. Las comunicaciones entre funciones de dispositivo se deben hacer vía el servidor. Además, no de deben usar comandos que sólo puede transmitir el servidor.

A continuación se describe un proceso excepcional. Se trata de un proceso especial preparado para aquellos dispositivos en los que la transmisión y recepción de datos no puede controlarse mediante comandos. Un ejemplo de tal dispositivo es un arma luminosa de un juego de tiro.

(1): Si el servidor reconoce que la función de dispositivo tiene un ID de dispositivo de arma luminosa, entonces éste cambia el bus M de modo normal a modo de ocupación SDCKB. El cambio de modo no es posible desde el lado de la función de dispositivo. Antes de cambiar, el servidor transmite un cambio de modo, y después de confirmar que se ha conectado un arma luminosa, cambia el modo del bus M a un patrón de ocupación SDCKB.

: Al entrar en el modo de ocupación SDCKB, todos los dispositivos de ese puerto asumen el modo de ocupación SDCKB y las funciones de dispositivo que no operan en modo de ocupación SDCKB no reciben comandos. Por ejemplo, si un arma luminosa, una tarjeta de memoria y una unidad vibrante se conectan a un puerto A, la función de dispositivo que opera en el modo de ocupación SDCKB es únicamente el arma luminosa. Durante el modo de ocupación, el servidor sólo controla el arma luminosa, y las otras funciones de dispositivo, a saber, la tarjeta de memoria y la unidad vibrante, no operan (no las puede controlar el servidor).

(2): Para volver desde el modo de ocupación SDCKB, el servidor cancela el proceso. Cuando se termina el modo de ocupación SDCKB, el sistema vuelve inmediatamente al modo normal.

(3): En el caso de un arma luminosa, el periodo de tiempo para reescribir la pantalla en 1 INT omitiendo el periodo de borrado vertical, en otras palabras el periodo de tiempo para dibujar la pantalla de TV, forma el modo de ocupación SDCKB.

: Cuando termina el periodo de dibujar la pantalla y ha comenzado el periodo de borrado, el sistema cambia directamente a modo normal, y la transmisión y recepción de datos para las funciones de dispositivo se realizan en otros puertos.

(4): Para conseguir una función de arma luminosa, una sección que contiene un elemento fotorreceptor se toma como una función de dispositivo, y las secciones que contienen el gatillo y las teclas direccionales, teclas analógicas y similares se toman como otra función de dispositivo. De este modo, es posible evitar problemas convencionales tales como la inutilización de teclas direccionales cuando se usa el arma luminosa. Además, ya que el arma luminosa forma una única unidad de función de dispositivo, ésta se puede conectar a otros dispositivos de expansión. Con estos medios, es posible proporcionar aplicaciones de juego con nuevas funciones.

A continuación se describen ejemplos de comandos. En líneas generales, los comandos se pueden dividir en comandos de control y comandos de error. Los comandos de control comprenden los comandos básicos de: Device Request, Status Request, All Status Request, AP Assign, LM-Bus Connect, Function Start, Host DAta Transmit, Data Request, All Data Request, Mode Change, Device Sleep, Device Request, Device Kill, Device Status, Device Reply, DEvice Data Transmit y similares. Además, existen comandos de expansión que no pertenecen a estos comandos básicos. Los comandos de expansión varían dependiendo de la función de dispositivo y del driver del bus M.

Device Rquest es un comando desde el servidor pidiendo una función de dispositivo que no tenga un AP asignado para devolver un Device Status.

Status Request es un comando desde el servidor pidiendo una función de dispositivo especificada por un AP para devolver un DEvice Status (estos datos constituyen una información inherente de dispositivo (Fixed Device Status)).

All Status Request es un comando desde el servidor pidiendo que un AP especifique todos los estados de dispositivo (en concreto, el Fixed Device Status y el Free Device Status) de una función de dispositivo. La función de dispositivo devuelve el Fixed Device Status y después el Free Device Status mediante una Device Data Transmit.

AP Assign es un comando mediante el cual el servidor asigna un AP a una función de dispositivo. Esto sólo se puede ejecutar durante el proceso de asignación de AP. Si la función de dispositivo es una operación normal, no procesa el comando sino que devuelve un Command Refusal.

LM-Bus Connect es un comando desde el servidor pidiendo una función de dispositivo para conectar un Bus LM al Bus M. Al recibir la LM-Bus Connect, las funciones de dispositivo conectan el Bus LM que les corresponde, un bus para cada función. Si una función de dispositivo es una operación normal, ésta no procesa el comando sino que devuelve un Command Refusal.

Function Start es un comando del servidor que hace que una función de dispositivo especificada por su AP comience una operación normal. Si la función de dispositivo recibe este comando y comienza una operación normal, devuelve Device Reply. No se produce incialización. Si la función de dispositivo está en operación normal, no procesa el comando sino que devuelve un Command Refusal.

Host Data Transmit es un comando mediante el cual el servidor transmite datos a una función de dispositivo. El contenido de los datos varía dependiendo de la función de dispositivo. Los detalles de estos datos los determina la especificación de función de dispositivo. Si el tamaño de los datos es 0, la función de dispositivo no recibe y devuelve un Command Refusal. Durante la asignación de AP, la función de dispositivo tampoco recibe y devuelve un Command Refusal.

Data Request es un comando del servidor pidiendo una función de dispositivo para transmitir datos especificados. En la región de datos se pueden especificar múltiples números de datos pedidos. Si el tamaño de los datos es 00h, entonces la función de dispositivo no procesa el comando y devuelve un Command Refusal. También durante la asignación de AP, la función de dispositivo no procesa el comando y devuelve un Command Refusal.

All Data Request es un comando del servidor pidiendo una función de dispositivo para transmitir todos sus datos. Durante el proceso de asignación de AP, la función de dispositivo no recibe el comando y devuelve un Command Refusal.

Mode Change es un comando mediante el cual el servidor cambia el modo de puerto del bus M. Cuando se cambia al modo de ocupación SDCKB, después de emitirse un comando Mode Change se confirma un Device Reply y el puerto especificado se cambia al modo de ocupación SDCKB. Si la función de dispositivo no corresponde a las operaciones del modo de ocupación SDCKB, entonces no procesa el Mode Change y devuelve un Command Refusal. También durante el proceso de asignación de AP, la función de dispositivo no procesa el Mode Change, sino que devuelve un Command Refusal.

Device Sleep es un comando mediante el cual el servidor suspende temporalmente un dispositivo especificado. Cuando se suspende una función de dispositivo, ésta devuelve un Device Reply y después de esto sólo puede recibir un Function Start. Durante el proceso de asignación de AP, la función de dispositivo no procesa el Device Sleep sino que devuelve un Command Refusal.

Device Reset es un comando mediante el cual el servidor aplica una reinicialización de software a una función de dispositivo especificada para inicializarla. La reinicialización de software no es una reinicialización (inicialización) que use funciones hardware como por ejemplo terminales de reinicialización IC, sino que es, por ejemplo, la inicialización de RAMs internos o de registros de programas (software). Ya que la reinicialización del software permite que se puedan seleccionar partes que se van a reinicializar en el programa, es posible retener partes, por ejemplo el estado fijado del terminal IC, para las que no se desea la inicialización. Los valores AP que se han asignado ya no se inicializan. Después de la inicialización, la función de dispositivo devuelve un Device Reply y empieza una operación normal. Durante la asignación de AP, la función de dispositivo no procesa el Device Request sino que devuelve un Command Refusal.

Device Kill es un comando mediante el cual el servidor prohibe la operación de una función de dispositivo. La función de dispositivo sólo puede procesar este comando antes del AP Assign en la secuencia de asignación de AP. La función de dispositivo espera en un consumo de energía en reserva y no puede recibir comandos. Para activar la función de dispositivo, tiene que reinicializarse el hardware o desconectarse la corriente. La reinicialización del hardware se realiza mediante reinicialización (inicialización) utilizando funciones hardware como por ejemplo terminales de reinicialización IC. También es posible realizar un procesamiento de inicialización igual en el programa. Este procesamiento es igual a la reincialización de conexión al comienzo del suministro de energía que lleva a cabo la inicialización de IC al mismo tiempo. Al contrario que en la reinicialización de software, no se puede seleccionar la parte que se va a inicializar. Si la función de dispositivo es una operación normal, ésta no procesa este comando, sino que devuelve un Command Refusal. Para suspender una función de dispositivo temporalmente durante la operación normal, se emplea el comando Device Sleep.

Device Status es un comando por el cual una función de dispositivo envía un Fixed Device Status al servidor. Este Fixed Device Status se describe después.

Device Reply tiene una amplia variedad de usos como respuesta de función de dispositivo transmitida por una función de dispositivo. El AP en el contenido de los datos indica el propio AP de la función del dispositivo, especificando así la procedencia de Device Reply.

Device Data Transmit es un comando mediante el cual una función de dispositivo transmite datos según la petición del servidor. El contenido de los datos varía dependiendo de la función de dispositivo. Si el tamaño de los datos es de 00h (h indica notación hexadecimal), el servidor no procesa el comando sino que devuelve un Command Refusal. Dependiendo de las circunstancias, se pueden emitir comandos tales como retransmisión, Device Status o similares.

A continuación se describen los comandos de error. Los comandos de error comprenden comandos básicos tales como command Refusal, Command Unknown, Transmit Again, LM-Bus Error, Device Error y similares. Además de esto, también existen comandos de expansión, que son intrínsecos a la función de dispositivo y al driver de bus M. Comandos intrínsecos aquí no quiere decir comandos estándar contenidos en el driver sino comandos preparados para funciones de dispositivo específicas.

Command Resfusal es un comando mediante el cual el servidor o la función de dispositivo rechaza recibir datos correspondientes a un comando de entrada. Este comando también se transmite si se recibe un comando incompatible con el servidor o con la operación de la función. Este comando prohibe un acceso indebido.

Command Unknown es un comando que se transmite desde una función de dispositivo al servidor cuando la función de dispositivo recibe un comando del servidor que no reconoce.

Transmit Again es un comando enviado por el servidor o por una función de dispositivo solicitando los mismos datos que se van a transmitir de nuevo cuando ha habido un error de algún tipo en los datos recibidos.

LM-Bus Error es un comando de una función de dispositivo al servidor notificando que se ha producido un error en el bus LM. Este comando se envía al servidor en aquellos casos donde, por ejemplo, se recibe LM-Bus Connect desde el servidor pero no existe bus LM que conectar.

Device Error es un comando de una función de dispositivo notificando al servidor que se ha producido un error de algún tipo en la función de dispositivo y que la función de dispositivo está en proceso de reinicialización.

A continuación se describe la información sobre Device Status mencionada. El Device Status almacena datos directamente de manera que no se pueden reescribir o borrar. Por ejemplo, no está permitido calcular un cierto valor para proporcionar un valor o texto de estado.

Device Status comprende: Fixed Device Status y Free Device Status.

Fixed Device Status se refiere a un estado permanente de dispositivo que es una descripción fundamental del dispositivo, por ejemplo formato total de 108 bytes. A menos que se describan todos los datos, no se pueden garantizar la operación y conexión del dispositivo.

Free Device Status se refiere a un estado de dispositivo que se puede usar libremente dependiendo de la función individual de dispositivo. Por ejemplo, la capacidad debe ser de 148 bytes o inferior.

Fixed Device Status comprende los siguientes:

(1) Device ID (ID del dispositivo)

Describe el ID y los atributos de la función de dispositivo. Si se registra y asigna previamente un ID a cada función de dispositivo, el servidor puede identificar qué tipo de función de dispositivo está conectada leyendo su ID. Por tanto, aquellos empleados por el bus M se registran como producto por adelantado para aquellos que tengan licencia de bus M.

(2) Maximum data size (Máximo tamaño de datos)

Describe el máximo tamaño de los datos que emite la función de dispositivo.

(3) Número de buses LM

Esto describe el número de buses LM que contiene la función de dispositivo.

(4) Nombre del producto

El nombre del producto se describe en inglés o romaji usando el código ASCII. Este puede ser diferente del nombre comercial actual. El nombre del producto también está sujeto a un registro previo.

(5) Código de destino

Describe la zona de venta del producto. Por ejemplo, Norte de América, Europa, Japón, etc. Este código hace posible determinar la compatibilidad entre los dispositivos periféricos y las aplicaciones de juego para zonas de destino determinadas.

(6) Licencia

Muestra la licencia del producto en inglés o romaji usando el código ASCII.

(7) Consumo de energía en reserva

Esto describe la energía consumida durante una suspensión temporal, en unidades de 0,1 mA.

(8) Consumo máximo de energía

Esto describe la máxima energía consumida, en unidades de 0,1 mA.

Por otra parte, el Free Device Status se refiere a áreas de información que los planificadores de producto, promotores, diseñadores, programadores o similares pueden asignar libremente. El servidor puede obtener esta información desde la función de dispositivo mediante el comando de All Device Request. Cuando se emplea esta zona de información en el software de aplicación y similares, es necesario asegurar de antemano la compatibilidad de las secuencias de datos, etc.

Al MIE del servidor se le denomina específicamente controlador periférico. La Figura 21 muestra un ejemplo de un diagrama de circuito en bloques para un controlador periférico (MIE) provisto en el servidor.

En este diagrama, un divisor de reloj 51 crea un reloj para alimentar cada bloque de procesamiento del controlador desde un reloj de sistema y, variando el ratio de frecuencias del reloj suplementado, es posible alterar la velocidad de transmisión (de transferencia), y similares.

Un registro de instrucciones 52 es un registro de 32 bits en el que las instrucciones enviadas desde la aplicación, etc, a los dispositivos periféricos se escriben vía el bus principal. Los contenidos escritos en este registro se transfieren a un controlador de puerto 57 y a un controlador de unidad de información 58.

El búfer de escritura 53 consiste en una RAM de 256 bytes en la que se copian datos de transferencia.

Un controlador de interrupción 54 controla las interrupciones que se producen debido a las transmisiones, recepciones o errores de diferentes tipos.

Un registro de estado 55 es un registro de 32 bits que indica el estado del controlador principal.

El búfer de lectura 56 consiste en una RAM de 256 bytes para guardar los datos recibidos.

El controlador de puerto 57 controla los puertos implicados en la transmisión y recepción de datos. Si se controla un búfer de tres estados 68 de un puerto de transmisión seleccionado mediante un comando, las salidas SDCKA y SDCKB de un primer y un segundo selector 64 y 65 se dirigen al puerto seleccionado. Un puerto de recepción se selecciona controlando un tercer y un cuarto selector 66 y 67.

El controlador de frame 58 controla la composición del frame en lo que se refiere al modelo de salida, la longitud de los datos y similares.

El codificador de frame 59 se controla mediante el controlador frame 58 y éste genera y emite modelos de información.

El registro de desplazamientos alternos 60 se controla mediante el controlador de frame, y es un registro para trasformar (P/S) datos paralelos del búfer de escritura en datos en serie, y de manera alternativa transmitir datos y un reloj a SDCKA y SDCKB. Se proporciona una sección de cálculo de CRC dentro del registro de desplazamientos alternos, y se aplica el procesamiento CRC a los datos según los comandos procedentes del controlador de frames.

El primer selector 64 se controla mediante el controlador de frames 58, y emite SDCKA seleccionando las salidas del codificador de frame 59 o la salida del registro de desplazamientos alternos 60.

El segundo selector 65 se controla mediante el controlador de frames 58, y emite SDCKB seleccionando la salida del registro de desplazamientos alternos 60 o la salida del codificador de frames 59.

El tercer selector 66 selecciona un puerto de recepción según los comandos procedentes del controlador de puerto 57, y suministra SDCKA recibido vía un búfer amplificador 69 a un descodificador de frames 61 y a un registro de desplazamientos alternos 62.

El cuarto selector 67 selecciona un puerto de recepción según los comandos del controlador de puerto 57, y suministra SDCKB recibido vía un búfer amplificador 69 a un descodificador de frames 61 y a un registro de desplazamientos alternos 62.

El descodificador de frames 61 analiza la composición de los frames recibidos, la refleja en el Statis Register (Registro de Estado) 55, y controla el registro de desplazamientos alternos 62.

El registro de desplazamientos alternos 62 se controla mediante el descodificador de frames 61, y es un registro (S/P) para transformar datos en serie recibidos en datos paralelos. El registro de desplazamientos alternos 62 también comprende un circuito de cálculo de CRC para realizar una inspección de errores de la señal recibida.

\newpage

El controlador de frame 58 activa el controlador de señal de bloqueo HV. Por ejemplo, cuando el controlador de frame 58 ha transmitido un patrón de permiso de ocupación SDCKB, el descodificador de frames se desactiva y se activa el controlador de señal de bloqueo HV. Cuando el controlador de señal de bloqueo HV recibe un SDCKB después de que se ha transmitido un patrón de permiso de ocupación SDCKB, se suministra una señal de bloqueo HV a un contador (se ha omitido del dibujo). El contador HV comprende un contador de posición horizontal y un contador de posición vertical, que generan los valores correspondientes a una posición en una pantalla. Por ejemplo, en un juego de tiro, cuando se aprieta el gatillo de un arma que apunta hacia una pantalla de TV, el arma emite SDCKB. Este SDCKB se emplea para identificar la posición de la mira (disparo) del arma en la pantalla mediante el contador HV.

La Figura 22 es un diagrama de circuitos que ilustra los principios operacionales del codificador de frames 59. En este diagrama, 591 es un circuito flip-flop (basculante), 592 es un contador, 593 es un comparador y 594 es una puerta lógica.

La Figura 23 es un organigrama de tiempos para describir la operación del codificador de frames 59.

Cuando se suministra un pulso de escritura al codificador de frames 59, este circuito adopta un estado activo. El SDCKA que está en la salida Q del circuito flip-flop (basculante) 591 se ajusta al nivel "L" mediante el borde ascendente del pulso de escritura. El SDCKA crea una entrada habilitada al contador 592, el cual empieza el recuento del reloj CLK que se suministra al mismo. El contador 592 adelanta un valor de conteo CNT OUT a través de "0", "1", "2", ..., "7", "8". Este valor de cuente se suministra a la entrada de comparación A del comparador 593. Un valor asignado de patrón de salida n se suministra a la entrada de referencia de comparación B del comparador 593. Por ejemplo, si se genera un "patrón de puesta en marcha", el codificador de frames 59 descodifica este comando y suministra "9" como un valor asignado n. Si las dos entradas concuerdan, el comparador 593 emite CMP OUT desde el terminal de salida EQ, que se suministra al terminal preseleccionado /PR del circuito flip-flop (basculante) 591. Por tanto, la SDCKA en la salida Q del circuito flip-flop 591 se fija al nivel "H". El SDCKB se obtiene sintetizando el SDCKA y una señal CLKB que tiene la mitad de la frecuencia de la señal del reloj CLK en la puerta OR 594.

De este modo, se suministran valores asignados al patrón de salida que corresponden a un patrón de puesta en marcha, de reinicialización y de fin, etc, y cuando se introduce un pulso de escritura, el SDCKA se ajusta al nivel "L", y para SDCKB se puede obtener una señal patrón que tenga un número predeterminado de bordes descendentes.

La Figura 24 es un diagrama de circuitos que ilustra los principios operacionales del registro de desplazamientos alternos 60. En este diagrama, 601 es un registro de desplazamientos para transformar datos paralelos en datos en serie; 602 es un selector de entrada dual; 603 es un registro de desplazamiento para transformar datos paralelos en datos en serie; 604 es un selector de entrada dual.

La Figura 25 es un organigrama de tiempos que describe la operación del registro de desplazamientos alternos 60.

Se suministran múltiples bits pares D6, D4, D2, D0 para la transmisión de datos a múltiples terminales de entrada D del registro de desplazamientos 601, y los datos se desplazan con la ayuda de un reloj de desplazamiento SHIFT CLKA cuya sincronización se ilustra en el diagrama, y se suministran desde el terminal de salida Q al de entrada A del selector 602 como datos en serie. Un reloj CLKA como el que se muestra en el diagrama se introduce en el terminal de entrada B del selector 602. El selector 602 selecciona los datos en serie procedentes del terminal de salida Q según el nivel "H" del reloj de desplazamiento SHIFT CLKA, y selecciona el reloj CLKA según el nivel "L" del SHIFT CLKA.

Por tanto, en el terminal de salida Y del selector 602 se obtiene una señal SDCKA, en la que los datos D6, D4, D2, D0 se superponen en el reloj CLKA a intervalos predeterminados.

De manera similar, múltiples bits impares D7, D5, D3, D1 para la transmisión se suministran respectivamente a múltiples terminales de entrada D del registro de desplazamientos 603, y los datos se desplazan con ayuda de un reloj de desplazamiento SHIFT CLKB cuya sincronización se muestra en el diagrama y se suministran desde el terminal de salida Q al de entrada A del selector 604 como datos en serie. Un reloj CLKB como el que se muestra en el diagrama se introduce en el terminal de entrada B del selector 604. El selector 604 selecciona los datos en serie procedentes del terminal de salida Q según el nivel "H" del reloj de desplazamiento SHIFT CLKB, y selecciona el reloj CLKB según el nivel "L" del SHIFT CLKA. Por tanto, en el terminal de salida Y del selector 604 se obtiene una señal SDCKB en la que los datos D7, D5, D3, D1 se superponen con el reloj CLKB a intervalos predeterminados. Las secciones "D0" a "D7" que se muestran en las señales SDCKA y SDCKB tienen un nivel "H" o un nivel "L" dependiendo del valor de sus datos.

La Figura 26 es un diagrama de circuitos que muestra un ejemplo de composición de un descodificador de frames 61. En este diagrama, 611 es un contador, 612 es un flip-flop compuesto por múltiples conjuntos flip-flop, 613 es un contador y 614 es un flip-flop compuesto consistente en múltiples flip-flop.

La Figura 27 es un organigrama de tiempos que describe el funcionamiento del descodificador de frames 61.

De los elementos del diagrama, el contador 611 y el flip-flop 612 operan para detectar un patrón de puesta en marcha. Cuando el SDCKA está en el nivel "H", se deshabilita el contador. Cuando SDCKA está en el nivel "L", se habilita el contador y se cuentan los bordes descendentes del SDCKB. Al contar el número de bordes descendentes del SDCKB mientras que el SDCKA está en el nivel "L" , se suministra un salida de recuento al flip-flop 612 que está en el borde ascendente de SDCKA.

Como se muestra en la Figura 27, si el número de bordes descendentes del SDCKB es cuatro durante el periodo en el que el SDCKA está en el nivel "L" (patrón de puesta en marcha, cf. Figura 13), el circuito flip-flop genera la salida de detección del patrón puesta en marcha.

Para detectar el patrón fin, se cuenta el número de bordes descendentes del SDCKA cuando el SDCKB está en el nivel "L" con el contador 613 y el flip-flop 614. La salida de recuento 613 se incorpora al contador 613 a través del borde ascendente del SDCKB. Como se muestra en la Figura 27, cuando se cuentan dos bordes descendentes del SDCKA mientras que el SDCKB está en el nivel "L", el flip-flop 612 emite la detección del patrón fin. Cuando no se especifica el número de bordes descendentes del SDCKA durante el periodo en el que el SDCKB está en el nivel "L", el flip-flop 614 emite una detección de error de frame. En el modo de operación normal, el patrón de datos y el de fin con dos bordes descendentes de SDCKA siguen al primer patrón de puesta en marcha con cuatro bordes descendentes del SDCKB (cf. Figura 11).

Además, aunque no se ilustra en la Figura 27, después de comenzar la recepción, cuando el contador 611 detecta seis bordes descendentes del SDCKB mientras que el SDCKB está en el nivel "L", el flip-flop 612 emite la detección de un patrón de puesta en marcha con CRC (Figura 14). En el modo de operación que usa CRC, el patrón de datos, los datos CRC y el patrón de fin vienen a continuación del patrón de puesta en marcha CRC con seis bordes descendentes del SDCKB (cf. Figura 12).

Además, si el contador 611 detecta ocho veces los bordes descendentes del SDCKB mientras que el SDCKA está en el nivel "L", entonces el flip-flop 612 emite el patrón de permiso de ocupación SDCKB (cf. Figura 15). Cuando se detecta el patrón, el modo de operación cambia al modo de operación de permiso de ocupación SDCKB. En el modo de operación de permiso de ocupación SDCKB, se puede usar un arma luminosa. El modo de permiso de ocupación SDCKB se restablece mediante el modelo de reinicialización del modo de operación de permiso de ocupación SDCKB (borde ascendente del SDCKA).

Si el contador 611 detecta catorce veces los bordes descendentes del SDCKB mientras que SDCKA está en el nivel "L", el flip-flop 612 emite la detección del patrón de reinicialización (cf. Figura 16). La detección permite la operación de reinicialización.

Si no se especifica el número de bordes descendentes del SDCKB, el flip-flop 612 emite la detección de error de frame. Las salidas de detección de patrones desde los flip-flop 612 y 614 se mantienen en el registro de estado 55.

La Figura 28 muestra un ejemplo de la composición del registro de desplazamientos alternos 62. En este diagrama, los datos en serie SDCKB se suministran al terminal de entrada de datos D de un registro de desplazamientos 621, y SDCKA se suministra a la entrada de reloj de desplazamiento del mismo. El registro de desplazamientos 621 lee las secciones de datos de SDCKB sucesivamente en los bordes descendentes de SDCKA, como se ilustra en la Figura 29. Los datos transformados de serie a paralelo se colocan en los terminales de salida paralelos D7, D5, D3, D1 del registro de desplazamientos 621 mediante cuatro bordes del reloj de SDCKA.

De manera similar, los datos en serie SDCKA mostrados en la Figura 29 se suministran a los terminales de entrada de datos D del registro de desplazamientos 622 que se muestran en la Figura 28, y SDCKB se suministra a la entrada de reloj de desplazamiento del mismo. El registro de desplazamientos 622 lee las secciones de datos de SDCKA sucesivamente en los bordes descendentes de SDCKB. Los datos transformados de serie a paralelo se colocan en los terminales de salida paralelos D6, D4, D2, D0 del registro de desplazamientos 622 mediante cuatro bordes del reloj de SDCKB.

La Figura 30 es un diagrama de bloques similar de un dispositivo periférico a conectar a un dispositivo de juego, denominado normalmente controlador de juego, un controlador de operación de entrada o un dispositivo de entrada de operación, etc. Después se describe un controlador de juego. Es posible añadir (acoplar) además otros dispositivos periféricos (funciones de dispositivo-L) proporcionando dos sockets de expansión en el controlador de juego. El controlador de juego contiene un microcontrolador de un sólo chip. También comprende 11 switches para generar una salida digital, y teclas analógicas para generar una salida de cuatro ejes. La salida de estos switches, etc, se procesa mediante el microcontrolador, y se emite al servidor vía una sección MIE y un bus M.

La Figura 31 es un diagrama de bloques que ofrece una aproximación a la composición de un MIE que está en el lado de la función de dispositivo, donde las funciones de un dispositivo periférico son admitidas como funciones de dispositivo.

En este diagrama, el controlador de juego se conecta a un servidor (se omite del dibujo) vía un bus M. El controlador de juego comprende una función de dispositivo-U que se conecta al servidor vía el bus M, y dos funciones de dispositivo-L que se conectan a la función de dispositivo-U vía los buses LM.

\newpage

La Figura 32 es un diagrama de circuitos en bloques que muestra la sección de conexión de bus (selector) de la Figura 31. Hay dos buses que derivan de la función de dispositivo-U, y se les denomina bus LM 1 y bus LM 2, respectivamente. La operación de conexión para conectar y desconectar los buses LM y el bus M se realiza con ayuda del selector MIE en la función de dispositivo-U.

La Figura 33 es un diagrama de bloques similar de una sección hardware de la función de dispositivo-U. La sección de procesamiento de transmisión, la sección de control socket, la sección CPU y la sección I/O están formadas por un microcontrolador de un solo chip. El bloque de procesamiento de transmisión forma una interfaz con el servidor. La sección CPU controla el procesamiento de la señal en el dispositivo periférico, por ejemplo un controlador de juego o similar. La sección I/O es una interfaz de entrada externa para botones digitales, teclas analógicas o similares. La sección de control del socket controla los sockets de expansión. En este ejemplo, se preparan sockets de expansión hardware (dos ranuras) para dos funciones de dispositivo L.

La Figura 34 es un diagrama de bloques similar de una función de dispositivo-L. Una sección de procesamiento de transmisión, una sección CPU y una sección de función de soporte están constituidas por un microordenador de un solo chip. La sección de procesamiento de transmisión forma una interfaz con la función de dispositivo-U (MIE para la función de dispositivo-L). La sección CPU lleva a cabo un proceso relacionado con la función de dispositivo-L. El bloque de la función de soporte opera la función del dispositivo-L, por ejemplo un circuito para realizar la función de gatillo de un arma luminosa, la función de memoria o la función vibración, etc.

A continuación, y con referencia a las Figuras 33 y 34, se describe la operación del MIE en el lado de la función de dispositivo. En el estado inicial donde no se han asignado APs, el controlador de socket que se muestra en la Figura 33 controla una búfer de tres estados, y se inhabilitan los SDCKA OUT y SDCKB OUT transmitidos a los sockets de expansión 1 y 2. Aquí, el controlador de socket realiza las funciones de controlador de bus LM 1 y LM 2.

Con SDCKA OUT en estado inhabilitado, cuando no se ha conectado ninguna función de dispositivo L al socket de expansión, DSCKA OUT asume el nivel "L" debido a la resistencia de empuje conectada al terminal de salida del búfer de tres estados. El controlador socket puede identificar que no hay ninguna función de dispositivo-L conectada a la función de dispositivo-U detectando el nivel "L" de esta terminal de salida.

Por otro lado, se conecta una fuente de alimentación al terminal de entrada de SDCKA OUT del hardware de la función de dispositivo-L mediante una resistencia de empuje, como se ilustra en la Figura 34. Por tanto, si se conecta el hardware de la función de dispositivo-L al socket de expansión, la terminal SDCKA OUT (búfer de tres estados en estado desconectado) se eleva al nivel "H" debido a la resistencia relativamente alta de la resistencia de empuje que se muestra en la Figura 33 y a la baja resistencia de dicha resistencia de empuje. Si se detecta el nivel "H" de esta salida, el controlador socket puede identificar que el hardware que contiene una función de dispositivo-L se ha conectado al hardware que comprende una función de dispositivo-U.

Se asigna un AP a la función de dispositivo-U mediante un comando AP Assign desde el servidor, y cuando se recibe un comando LM-Bus Connect, el SDCKA OUT y el SDCKB OUT del socket 1 asumen el estado habilitado. Por tanto, los comandos procedentes del servidor se transmiten a la función de dispositivo-U y a la función de dispositivo-L que están conectadas al socket de expansión 1.

Si el servidor asigna un AP a la función de dispositivo-L que está en socket de expansión 1 y transmite un comando LM-Bus Commect a la función de dispositivo-U, ésta habilita el SDCKA OUT y el SDCKB OUT que están en el socket de expansión 2. Después de que se ha completado el proceso de asignación de Aps a la función de dispositivo-L del socket de expansión 2, los comandos procedentes del servidor se transmiten a la función de dispositivo-U y a todas las funciones de dispositivo-L por igual. Las funciones de dispositivo U y L comparan el valor AP contenido en el comando, determinan si se les ha seleccionado a ellos mismos y responden adecuadamente.

Las Figuras 35 a 39 son organigramas que ilustran las operaciones de control que lleva a cabo el MIE durante la transmisión.

La aplicación de servidor genera una secuencia de comandos de proceso al software del driver del bus a través de un API. El driver del bus traduce estos comandos de proceso en instrucciones controladas por el MIE, y las registra en el registro de instrucciones 52 del MIE.

El controlador de frame 58 determina si los comandos (instrucciones) del registro de instrucciones ordenan la salida de la señal del patrón de formato de transmisión estándar (S12), la salida de una señal de formato con opción CRC (S14), la salida de un patrón de permiso de ocupación SDCKB (S16) o la salida de un patrón de reinicialización (S18).

Si se va a emitir un patrón de formato de transmisión estándar (S12; Yes), el controlador frame 58 selecciona la salida del codificador frames 59 mediante los selectores 64 y 65 y genera la salida de un patrón de puesta en marcha desde el codificador de frames 59 (S21) según la secuencia mostrada en la Figura 36. Acto seguido, selecciona la salida del registro de desplazamientos alternos 60 con la ayuda de los selectores 64 y 65, hace que se escriban los datos de transmisión en el registro de desplazamientos alternos 60 (S22) desde la búfer de escritura 53, y genera la salida de un patrón de datos desde el registro de desplazamientos alternos 60 (S23).

El controlador de frame 58 confirma que los datos transmitidos comprenden, por ejemplo, 256 bytes (S24). Si no comprenden 256 bytes (S24; No), se repite el proceso de lectura desde la búfer de escritura (S22) y la emisión de datos (S23). Si se han transmitido 256 bytes (S24; Yes), los selectores 64 y 65 seleccionan la salida del codificador de frames 59 y el codificador de frames 59 transmite un patrón de fin. De este modo, se transmiten datos según un patrón estándar.

Si el código que fijado en el registro de instrucciones 52 ordena la salida de un señal de formato con opción CRC (S14; Yes), el controlador de frame 58 selecciona la salida del codificador de frames 59 mediante los selectores 64 y 65 y hace que el codificador de frames 59 genere un patrón de puesta en marcha con CRC (S31), según la secuencia que se muestra en la Figura 37. Acto seguido, los selectores 64 y 65 seleccionan la salida del registro de desplazamientos alternos 60, y se leen los datos de transmisión entre el búfer de escritura 53 y el registro de desplazamientos alternos 60 (S32). Además, el controlador de frame 58 hace que la sección de cálculo de CRC en el registro de desplazamientos alternos realice cálculos de CRC sobre los datos leídos (S33). Esto genera un patrón de datos de salida desde el registro de desplazamientos alternos 60 (S34).

El controlador de frame 58 confirma la transmisión de datos de, por ejemplo, 256 bytes (S35). Si no encuentra 256 bytes (S35; No), se repiten los procesos de lectura desde el búfer de escritura (S32), el cálculo de CRC (S33) y la salida de datos (S34).

Si se han enviado 256 bytes (S35; Yes), el controlador de frame 58 provoca que el registro de desplazamientos alternos 60 transmita datos CRC después de los datos (S36). Entonces selecciona la salida del codificador de frames 59 mediante los switches 64 y 65 y hace que el codificador de frames 59 transmita un patrón de fin (S37).

De este modo, los datos se transmiten en un modelo que contiene CRC.

Si el controlador de unidad de frames 58 identifica un comando de salida para un patrón de permiso de ocupación SDCKB (S16; Yes), entonces selecciona la salida del codificador de frames 59 mediante los switches 64 y 65 y hace que el codificador de frames 59 emita el patrón de permiso de ocupación SDCKB (S41), según la secuencia que se muestra en la Figura 38. El búfer 68 se controla vía el controlador de puerto 57 y prohíbe la salida de SDCKB (S42). Acto seguido, el codificador de frames 59 genera el patrón de permiso de ocupación SDCKB, en donde SDCKA se fija en el nivel "L" (S43).

Después de esto, se habilita el controlador de bloqueo HV 63. El controlador de bloqueo HV 63 monitoriza la línea SDCKB (S44). Si hay una respuesta desde el lado del dispositivo (S44; Yes), entonces el controlador de bloqueo HV 63 genera una salida de bloqueo del contador HV (S45). Después de generar una salida de bloqueo (S45), o si no hay respuesta desde el lado del dispositivo (S44; No), entonces identifica si el comando que selecciona el modo de ocupación SDCKB está todavía presente en el registro 52 (S46). Si todavía está presente (S46; No), se repiten las fases S44 a S46, y se generan salidas de bloqueo sucesivamente según las respuestas procedentes del lado del dispositivo.

Si se ha cancelado el comando que selecciona el modo de ocupación SDCKB (S46; Yes), el SDCKA vuelve al nivel "H" y el sistema reanuda un estado en el que SDCKA y SDCKB se pueden usar para transmitir (S47).

De este modo, se aplica el modo de ocupación SDCKB.

Si el controlador de unidad de frame 58 identifica que el código seleccionado en el registro de comandos es un comando de emisión de un patrón de reinicialización (S18), entonces hace que el codificador de frame 59 genere un patrón de reinicialización (S51), como se muestra en la secuencia de la Figura 39.

De este modo, se pueden transmitir señales de diferentes formatos.

A continuación, se describe la operación del MIE durante la recepción.

Como se muestra en la secuencia de la Figura 40, el descodificador de frame 61 descodifica los SDCKA y SDCKB recibidos, e identifica si las señales recibidas comprenden un patrón de puesta en marcha (S62), de puesta en marcha con CRC (S64), o un error de frame que no corresponde a ninguno de estos patrones (S66).

Si se detecta un patrón de puesta en marcha (S62; Yes), se identifica si éste es indefinido (S71), como se muestra en la secuencia de la Figura 41. Si es un patrón de puesta en marcha indefinido (S71; Yes), la marca de error de frame se fija en el registro de estado, y el software del driver o equivalente realiza un proceso de detección de error de frame prescrito.

Si es un patrón de puesta en marcha previamente definido (S71; No), entonces la marca de detección de patrón de puesta en marcha se fija en el registro de estado. Por tanto, se activa el registro de desplazamientos alternos 62 y se extraen datos sucesivamente desde las señales SDCKA y SDCKB recibidas, desmodulándose los datos en serie extraídos en datos paralelos (S73). Esta desmodulación/transferencia de datos se repite hasta que el descodificador de frame 61 detecta un patrón de fin (S71 a S75). Cuando se ha detectado un patrón de fin (S75; Yes), se fija una marca de detección de patrón de fin en el registro de estado 55, y termina la recepción.

Por otro lado, si se detecta un patrón de puesta en marcha que contiene CRC, se identifica si éste es un patrón de puesta en marcha indefinido (S81). Si es un patrón de puesta en marcha indefinido (S81; Yes), se fija una marca de detección de error de frame en el registro de estado, y el software del driver o equivalente realiza el proceso de detección de error de frame prescrito (S82).

Si es un patrón de puesta en marcha previamente definido (S81; No), se fija una marca de detección para el patrón de puesta en marcha con CRC. De este modo, se activa el registro de desplazamientos alternos 62, se extraen datos sucesivamente de las señales SDCKA y SDCKB recibidas y los datos en serie extraídos se desmodulan en datos paralelos (S83). Después se realiza un cálculo de CRC para los datos desmodulados (S84), y los datos desmodulados se escriben en el búfer de lectura 56 (S85). Esta desmodulación y transferencia de datos se repite hasta que el descodificador de frame 61 detecta un patrón de fin (S81 a S86). Cuando se detecta un patrón de fin (S86, Yes), el cálculo de CRC para los datos recibidos se compara con los datos de CRC anexionados después de la sección de datos para determinar si hay un error de CRC (S87).

Si se detecta un error de CRC (S87, Yes), se fija una marca de detección de error de CRC en el registro de estado 55, y entonces es posible procesar la detección de error de CRC, por ejemplo una petición de retransmisión de datos (Transmit Again). Si no se detecta error de CRC, se completa el proceso de recepción de datos mediante un patrón de señal que contiene CRC (S87; No).

La Figura 43 es un organigrama que ilustra la obtención y el uso de la información inherente (Fixed Device Status) referido a un dispositivo periférico (función de dispositivo) mediante programas incorporados en las aplicaciones (software), por ejemplo programas de juego.

El programa de aplicación suministrado desde un medio de almacenamiento de datos, por ejemplo un CD-ROM, se almacena en la memoria y lo pone en práctica la CPU. El programa de aplicación hace que el comando de Device Request se transmita a la función de dispositivo (S102), y después espera una respuesta de la función de dispositivo. Si no se recibe un Fixed Device Status desde la función de dispositivo incluso después de que haya transcurrido un periodo de tiempo determinado, se determina que no hay ninguna función de dispositivo conectada al bus (S104; No), y se lleva a cabo un proceso de "no conexión" (S106).

Si se recibe un Fixed Device Status desde la función de dispositivo (S104; Yes), se compara la información de descripción de licencia (S108), la información de región de destino (S110) y el ID del dispositivo con la información que se encuentra en la aplicación del programa de juego, etc, que se suministra desde el medio de almacenamiento de datos, por ejemplo un CD-ROM (S112). Si esta comparación se corresponde (S112; Yes), se realiza el proceso para asignar un AP a esa función de dispositivo (S114).

Sin embargo, si la comparación no se corresponde, se lleva a cabo un proceso para informar al usuario de que las funciones de dispositivo conectadas (o los dispositivos periféricos conectados) no corresponden a la aplicación (S116). Acto seguido, se realiza el proceso de desconectar estas funciones de dispositivo desde servidor (S106), y termina la rutina.

Estas funciones se usan como contramedidas PL (responsabilidad civil de productos) para los dispositivos periféricos. En un juego de tiro, por ejemplo, se usa un arma de imitación, aunque existe el riesgo de que un dispositivo modelado exactamente como un arma se puede confundir con un arma real. En algunos países, por ejemplo, este tipo de uso puede no es causa de problemas, pero en otros países sí. En tales casos, en estos países donde sí pueden surgir problemas, sólo se puede usar un "arma" cuyo aspecto exterior indica claramente que es un arma de imitación.

Por tanto, en aplicaciones en las que se tienen que tener en cuenta las costumbres, circunstancias, etc., en particular en países o regiones, es deseable que se pueda restringir el tipo y el modelo de dispositivo que se puede emplear con esa aplicación mediante el Fixed Device Status que se ha descrito anteriormente.

De este modo, según el estándar de conexión para un dispositivo de juego y sus dispositivos periféricos correspondientes según la presente invención, es posible conectar un dispositivo de juego y múltiples dispositivos periféricos mediante un número reducido de líneas de bus.

Además, si un usuario conecta un dispositivo periférico de juego a un dispositivo de juego mediante un cable, ya que el dispositivo de juego identifica automáticamente el dispositivo conectado e inicializa y pone en marcha el dispositivo periférico conectado de manera que se corresponda con la aplicación, es posible eliminar procedimientos especiales y operaciones de ajuste que involucran al usuario, proporcionando así un tipo de conexión adecuada entre el dispositivo de juego y los dispositivos periféricos.

Además, en la ejecución descrita, ya que los dispositivos periféricos no tienen acceso a otros dispositivos conectados al bus, sino que las comunicaciones de datos se realizan en un formato mediante el cual los dispositivos periféricos responden para acceder desde el dispositivo de juego, la regulación de la sincronización de acceso entre el dispositivo de juego y los múltiples dispositivos periféricos se hace obsoleta. Ya que el acceso de un dispositivo periférico a otro dispositivo periférico está prohibido, la regulación de la sincronización de acceso entre dispositivos periféricos tampoco es necesaria. Por tanto, sólo se necesita una estructura relativamente simple para el hardware y el software I/O.

Además, se pueden conectar múltiples dispositivos periféricos y de varios tipos. Por ejemplo, es posible conectar un controlador de dispositivo de juego, un joystick, un teclado, una unidad CD-ROM, una unidad DVD, un dispositivo de entrada y salida de voz, un paquete de memoria, un dispositivo FDD, un MODEM, un terminal ISDN (red digital de servicios integrados), o similares.

Además, ya que la comunicación de datos se realiza según un formato de comando entre el dispositivo de juego y los dispositivos periféricos, es posible que una aplicación de juego obtenga los datos necesarios en un momento y en una situación que se correspondan con la evolución del juego desde un controlador de juego (dispositivo periférico), o equivalente.

Además, ya que se transmiten pequeños volúmenes de datos de manera intermitente, se reduce el ruido que producen los cables de conexión.

Ya que un driver de bus controla la transmisión de datos, se pueden añadir comandos o se pueden desarrollar fácilmente nuevos dispositivos periféricos, actualizando el driver.

Ya que se pueden transmitir datos entre un dispositivo de juego y dispositivos periféricos, es posible transferir datos multimedia, por ejemplo salida de sonido, entrada de sonido, pantallas fijas, pantallas animadas, etc., mediante un par de cables.

Ya que una unidad o aplicación principal de dispositivo de juego puede utilizar la información inherente de un dispositivo periférico, ésta puede distinguir entre los dispositivos periféricos que se pueden usar con una aplicación y aquellos que no se pueden usar con esa aplicación, desde múltiples dispositivos de juego conectados, y de manera deseable, puede suspender la operación de los dispositivos periféricos que no sean compatibles.

Segundo modo de ejecución

Resumen

A continuación, se describe un segundo estándar de interfaz periférica para un bus M. De todos los procesos que se han realizado en el bus M, este estándar determina las especificaciones de interfaz entre el servidor MIE y el driver del bus M, las especificaciones de interfaz entre la función y el controlador del MIE, las especificaciones de protocolo de comunicaciones, y el formato de datos.

En primer lugar, se describen las topologías física y lógica de la segunda interfaz después de un procedimiento similar a la explicación anterior del primer estándar de interfaz.

(1) Topología de conexión física

: La Figura 44 muestra una ilustración aproximada de la topología de conexión física según este segundo modo de ejecución. El modo de conexión física comprende una configuración servidor-dispositivo base (dispositivo periférico)-dispositivo de expansión (dispositivo periférico). Los dispositivos base representan el hardware (dispositivo periférico) conectado directamente al servidor. Los dispositivos de expansión representan el hardware (dispositivos periféricos) conectados al servidor vía un dispositivo base. En cualquier sistema, existe un único servidor (por ejemplo, una máquina de juego). El servidor puede tener un máximo de cuatro puertos para conectar a los dispositivos periféricos. Un dispositivo base se conecta a un puerto. Se puede conectar un máximo de cuatro dispositivos de expansión externos a cualquier dispositivo base. El servidor y los dispositivos base se conectan con cables asignados.

: Sin embargo, los siguientes tipos de conexiones no están permitidos: a) conexión directa servidor a dispositivo de expansión; b) conexión dispositivo base a dispositivo base; c) conexión dispositivo base a dispositivo de expansión; d) conexión dispositivo de expansión a dispositivo de expansión. Estas afirmaciones no pretenden limitar la presente invención a las realizaciones.

(2) Topología de conexión lógica

: La Figura 45 es un diagrama simbólico que ilustra la topología de conexión lógica según el segundo modo de ejecución. Según muestra este diagrama, la conexión lógica entre cada función (formada por el hardware del dispositivo de expansión y del dispositivo base) y el servidor forma una conexión denominada conexión en estrella con el servidor por su centro. El servidor controla la transmisión y recepción de señales.

Estructura en capas y flujo de comunicación

La Figura 46 es un diagrama simbólico que describe la estructura en capas entre un servidor y los dispositivos periféricos. Según muestra el diagrama, el servidor y los dispositivos periféricos forman una estructura en capas para las comunicaciones de datos entremedias.

\newpage

En la Figura 46, la capa de función utiliza cada función de un dispositivo periférico y controla la transmisión y recepción de datos según el formato de datos. Un dispositivo periférico tiene hasta un máximo de tres funciones. La capa de control I/O controla la transmisión y recepción de datos que están en los frames y también controla el MIE (Motor I/F del bus M) que se describe después. La capa interfaz del bus controla la conexión física y la transmisión y recepción de señales entre el servidor y los dispositivos base (o dispositivos de expansión). La obtención de datos (transmisión de datos) y el control entre la aplicación en el servidor y las funciones físicas de los dispositivos periféricos se realizan mediante una librería de funciones, una librería de bus, el MIE del servidor, líneas de conexión, MIEs de dispositivos base (o expansión), controlador MIE y funciones.

Tipo periférico

Los dispositivos periféricos (periféricos) se clasifican y diferencian de la siguiente manera. Primeramente, los dispositivos periféricos se clasifican en dos tipos: dispositivos base y dispositivos de expansión. A su vez los dispositivos base y los dispositivos de expansión se dividen en controladores de juego y en otros periféricos. Como ejemplos del tipo controlador de juego de dispositivo periférico se incluyen componentes estándar de dispositivos de juego, por ejemplo controladores de juego estándar, joysticks, volantes y similares, asociados a los dispositivos de juego. Ejemplos de "otros periféricos" incluyen: teclado, ratón, arma (arma de imitación) y similares. Un dispositivo de expansión es un periférico de un sistema de expansión controlador, ejemplos de éstos incluyen: una entrada de sonido, memoria back-up, un arma (arma de imitación) y similares. El sistema controlador tiene un formato de datos estándar fijo, con lo cual se puede usar con cualquier software de aplicación. Ya que los otros dispositivos base y de expansión tienen diferentes formatos de datos dependiendo del dispositivo, se prepara una librería de función para cada función respectiva.

Descripción de la terminología

A continuación se explica la terminología que se usa en la descripción del segundo modo de ejecución. Por razones de conveniencia, éste se solapa parcialmente con la descripción del primer modo de realización. Primeramente, a los datos que se expanden a lo largo de una serie de tiempos se les denomina "datos en serie". Una línea de señales (flujo) que controla el intercambio de datos en serie se denomina "bus serie". Un bus serie que conecta un dispositivo de juego con dispositivos periféricos según el estándar a que se refiere la presente invención se denomina "bus M". Un grupo de parámetros que indican la función de un dispositivo periférico y que se asigna a cada dispositivo periférico correspondiente se denomina "ID de dispositivo". Un ID de dispositivo contiene 16 bytes, incluidos los atributos del dispositivo periférico y las funciones (formato de datos y elementos funcionales) que comprende. El ID de dispositivo se puede obtener mediante un comando Device Status, como se describe posteriormente.

Un terminal de bus M al que se puede conectar un dispositivo periférico del dispositivo de juego se denomina "puerto". En un terminal de un puerto, hay cuatro clavijas estándar, que comprenden terminales de alimentación de energía (VVC, GND) y líneas de transmisión de datos (SDCKA, SDCKB), o cinco clavijas que comprenden una línea adicional protectora. En el "bus M" según el estándar del segundo modo de ejecución, se mantienen un máximo de cuatro puertos (puerto A; puerto B; puerto C; puerto D).

Al dispositivo de juego se le conoce como "servidor", y las funciones realizadas por los dispositivos periféricos conectados al mismo se denominan "función". Una función no se refiere a un producto en si mismo, sino a un elemento que constituye un producto, y por esta razón un producto puede comprender múltiples funciones. Un dispositivo periférico forma una colección de funciones, y el acceso desde el servidor se controla en las unidades de dispositivo periférico, especificándose el acceso a las funciones mediante el tipo de función. Se pueden emplear múltiples funciones en un único dispositivo periférico, aunque con el "bus M" según el segundo modo de ejecución, por ejemplo, se puede usar un máximo de tres funciones.

Según se muestra en la Figura 47, los dispositivos periféricos se dividen físicamente en dos tipos; "dispositivos base" y "dispositivos de expansión". Un dispositivo base es un dispositivo periférico que se conecta al servidor y tiene la función de controlar los dispositivos de expansión. Un dispositivo base identifica y conecta automáticamente un dispositivo de expansión unido al mismo. Un dispositivo de expansión es un dispositivo periférico conectado a un dispositivo base que no puede operar si no tiene dispositivo base. Un bus M que conecta un dispositivo base a un dispositivo de expansión se denomina bus "LM". Un bus LM es lo mismo que el bus M en términos lógicos (señal), aunque es diferente físicamente. De los dispositivos periféricos, los dispositivos base comprenden principalmente sistemas de control de juego y los dispositivos de expansión comprenden dispositivos de expansión de los sistemas de control de juego. Por ejemplo, sólo se puede conectar un dispositivo base a un puerto del servidor, aunque el dispositivo base puede gestionar hasta cinco dispositivos de expansión (hasta cinco buses LM).

En el caso de un dispositivo base y múltiples dispositivos de expansión en un único puerto, se asigna un número de identificación a cada dispositivo base y dispositivo de expansión según el punto donde esté conectado, con lo cual se puede acceder al mismo directamente. Este número asignado se denomina "posición absoluta AP". En el "bus M", el AP es un único byte fijo que tiene la siguiente estructura:

(Máximo 4 puertos (2 bit)) x (Máximo número de APs asignados a 1 puerto = 6 (6 bit)) = (1 byte (8 bit))

El AP asignado se determina según el modo de conexión y si el dispositivo es un dispositivo base o un dispositivo de expansión, como se describe después. Este AP se usa para acceder al dispositivo base o de expansión.

El intercambio de datos entre el servidor y las funciones no se controla usando un sistema de comunicación unilateral convencional, sino mediante el uso de instrucciones específicas determinadas, de manera que se pueden transmitir y recibir datos adecuados a la situación y al tiempo. Estas instrucciones se denominan "comandos" y los datos objeto del comando se denominan "parámetros". Un "parámetro" está formado por el AP del dispositivo de destino, el AP del dispositivo fuente, el tamaño de los datos, y los datos. En el bus M, se puede preparar un máximo de 254 comandos básicos y se puede transmitir o recibir un máximo de 1.020 bytes de datos en una sola operación de acceso.

La transmisión de datos a través de un puerto se realiza en unidades "frame". La Figura 48 muestra un ejemplo de la composición de un frame. Un frame está formado por un patrón de puesta en marcha, un código de comando, un parámetro (AP destino, AP fuente, tamaño de datos, datos y similares), bits de paridad, y un patrón de fin. Un frame se transmite en una única operación de acceso. Un acceso se hace a un dispositivo en un intervalo (INT). El patrón de puesta en marcha, los bits de paridad y el patrón de fin se añaden mediante el MIE (se describe posteriormente).

La Figura 49 es un diagrama simbólico que ilustra el proceso de respuesta y de "Time Out" ("exceso de tiempo permitido") en un bus M. La respuesta que se transmite cuando un servidor envía un comando a un dispositivo base o de expansión se denomina "respuesta". Después de transmitir un comando, el servidor espera una respuesta durante un determinado periodo de tiempo, y si no hay respuesta después de esperar, este estado se denomina "Time Out". El servidor considera que un dispositivo base (o de expansión) ha sobrepasado el tiempo permitido como que ha sido desconectado. Además, si un dispositivo base (o de expansión) sobrepasa el tiempo permitido cuando está recibiendo, se reinicializa el software. El periodo de tiempo hasta que se sobrepasa el tiempo permitido ("Time Out") puede ser por ejemplo de 1,0 ms.

En la Figura 49, en el caso (1), la respuesta del dispositivo base (o de expansión) está dentro del tiempo de respuesta y por tanto es normal. En el caso (2) no hay respuesta, con lo cual se sobrepasa el tiempo permitido. En el caso (3), no hay respuesta dentro del periodo de respuesta, con lo cual se sobrepasa el tiempo permitido. En el caso (4), el intervalo de tiempo que se produce durante la transmisión sobrepasa el tiempo de respuesta, con lo cual se sobrepasa el tiempo permitido. El puerto al que se conecta un dispositivo periférico que ha sobrepasado el tiempo permitido ejecuta una reinicialización del hardware.

Un lugar para conectar un dispositivo de expansión para expandir las funciones del controlador se denomina "socket de expansión". Un dispositivo de expansión se conecta a un socket de expansión. El bus M puede tener un máximo de cuatro sockets de expansión. Esto se debe a que la correspondencia entre los sockets de expansión y los buses LM se ejecuta según la lógica de las dos líneas ID, que se describirán después. El número de buses LM y el número de sockets de expansión no tiene que ser el mismo.

Un circuito que convierte los datos en datos en serie para el bus M de manera que se puedan transmitir y recibir vía el bus M se denomina ``MIE (Motor I/F del bus M). Todos los dispositivos estándar del bus M tienen este MIE. El servidor tiene un MIE servidor, los dispositivos base tienen un MIE de dispositivo base y los dispositivos de expansión tienen un MIE de dispositivo de expansión. Un MIE sólo convierte datos, con lo cual el proceso de extraer datos desde un frame lo realiza el driver del bus M (se describirá después) en el servidor, y el software (firmware) llamado driver del MIE en el dispositivo.

La operación de acceso del servidor a un dispositivo periférico se controla vía software "driver del bus M" y la "librería de función" que controlan los dispositivos periféricos (dispositivos base y dispositivos de expansión). El driver del bus M controla y gestiona los frames, mientras que las operaciones de control de cada dispositivo periférico (función) mediante comandos y parámetros de gestión (formato de datos) las lleva a cabo una librería de función. Sólo hay un tipo de driver de bus M para todos los dispositivos periféricos, mientras que las librerías de función se proporcionan de manera que correspondan a cada función respectiva. Se pueden usar hasta tres librerías de función por el ID del dispositivo para cada uno de los dispositivos periféricos.

En el "bus M", todos los dispositivos base y de expansión graban información específica de ellos mismos según un formato determinado.

La información que se refiere a un dispositivo base o a un dispositivo de expansión se denomina "Device Status". El Device Status graba datos de gestión, por ejemplo el nombre del producto, el ID del dispositivo, la licencia, el número de modelo, el lote de fabricación, la región de destino, etc., y datos eléctricos tales como el consumo de corriente de reserva, el máximo consumo de corriente y similares. El Device Status se gestiona y utiliza mediante una librería de dispositivo y el software de aplicación. Por ejemplo, es posible rechazar copias de un producto ilegal según el nombre del producto y la información de la licencia, y para controlar la corriente en todo el puerto según la información del máximo consumo de corriente.

Patrón de transferencia de datos

A continuación se describe la transmisión física de datos en el bus M. Para esta transmisión de datos se emplea el mismo formato que en el primer modo de ejecución. Dicho de otro modo, los datos se transmiten mediante un formato en serie sincronizado. Hay un total de cuatro líneas: Vcc para suministrar energía; una línea a tierra GND; una línea de datos SDCKA (bidireccional) para transmitir una señal SDCKA; y una de datos SDCKB (bidireccional) para transmitir una señal SDCKB. La comunicación de datos bidireccional emplea un sistema semidúplex y la velocidad de transferencia es, por ejemplo, de 2 Mbps como máximo. Si es necesario, se puede añadir un cable de protección de señal.

Principios de transmisión

La Figura 50 muestra patrones de datos para SDCKA y SDCKB. Las señales que transmite el reloj de datos en serie A (SDCKA) y el reloj de datos en serie B (SDCKB) se forman de manera que sus bordes descendentes siempre se presentan alternativamente cuando se están transmitiendo datos. En el lado de recepción, se bloquea una señal en el borde descendente (o borde ascendente) de la otra señal, y se desmodula el nivel de la señal bloqueada para ofrecer datos digitales. Los datos se transfieren comenzando desde el MBS, y en la posición de puesta en marcha, SDCKA proporciona información del reloj y SDCKB proporciona información de los datos.

Patrones de información según SDCKA y SDCKB

La Figura 51 muestra un ejemplo de un patrón de sincronización. El patrón de sincronización comprende un patrón de puesta en marcha (START) y un patrón de fin (END). El patrón de puesta en marcha es un patrón de sincronización que se transmite antes que el de datos. Cuando el lado de recepción detecta cuatro veces el borde descendente (o borde ascendente) de SDCKB (cuatro pulsos negativos) en un periodo que va desde el descenso de SDCKA hasta su siguiente borde ascendente, se decide que el siguiente patrón es un patrón de datos. Cuando el lado de recepción detecta dos veces el descenso (o ascenso) de SDCKA (dos pulsos negativos) en el periodo que va desde el descenso de SDCKB hasta su siguiente borde ascendente, se confirma que el patrón de datos ha terminado, y se decide que la operación ha terminado de forma normal.

Patrón de permiso de ocupación SDCKB (arma luminosa)

La Figura 52 muestra un ejemplo de un patrón de permiso de ocupación. Si el lado de recepción detecta ocho veces el borde descendente (8 pulsos negativos) en el periodo que va desde el descenso de SDCKA hasta su siguiente borde ascendente, se puede ocupar SDCKB desde el siguiente descenso de SDCKA hasta que ascienda. La ocupación de SDCKB se debe liberar mediante un borde ascendente de SDCKA. Este modelo se usa, por ejemplo, con un arma luminosa en un juego de tiro.

Patrón de reinicialización

La Figura 53 muestra un ejemplo de un patrón de reinicialización. Si el lado de recepción detecta 14 veces el borde descendente de SDCKB (14 pulsos negativos) en el periodo que va desde el descenso de SDCKA hasta su siguiente borde ascendente, se decide que hay una petición de reinicialización desde el lado de transmisión, y se realiza una reinicialización.

Formato de transmisión

La Figura 54 muestra un ejemplo de un formato de transmisión. La transmisión de datos se realiza en frames (unidad mínima). El contenido de un frame empieza con un patrón de puesta en marcha que indica el comienzo de la transmisión de datos, y comprende también un patrón de datos con una longitud máxima de 1.024 bytes, paridad, y un patrón de fin. La paridad comprende 8 bits en dirección horizontal, y se añade automáticamente mediante el hardware durante la transmisión y se borra durante la recepción.

Protocolo

A continuación se describe el protocolo de comunicaciones entre el servidor y los dispositivos periféricos. Los comandos se indican con "nombre de comando", y los detalles se describen después.

La Figura 55 es un diagrama simbólico que ofrece un esbozo del protocolo de comunicaciones. En primer lugar, el derecho de prioridad para transmitir comandos en una secuencia de procesamiento lo tiene el servidor. Por tanto, al principio, los dispositivos periféricos (dispositivos base o de expansión) asumen un estado "standby" de espera de comando. Todas las comunicaciones entre los dispositivos periféricos y el servidor se controlan en unidades frame, como se ha descrito antes. El servidor ejecuta un programa de aplicación y genera comandos a los dispositivos periféricos. Estos comandos se transmiten a los dispositivos periféricos vía el bus M como datos frame. Se da una orden a un dispositivo periférico a través del comando y los parámetros de un frame. Cuando un dispositivo periférico que corresponde al AP de destino en el frame recibe los datos frame, responde de manera acorde. En concreto, el dispositivo periférico genera un comando adecuado y crea datos frame que transmite al servidor vía el bus M. Acto seguido, el dispositivo periférico asume el estado standby esperando la siguiente transmisión de datos. El servidor recibe los datos frame procedentes del dispositivo periférico y extrae el comando reply (respuesta). Este comando se pasa después a la aplicación. La aplicación ejecuta la siguiente acción usando la información que transmite este comando. Las comunicaciones de datos entre el servidor y el dispositivo periférico se controlan repitiendo este procedimiento. La Figura 56(a) ilustra este tipo de comunicación de datos intermitente entre un servidor y múltiples dispositivos periféricos vía un bus M y buses LM. Además, la Figura 56(b) ilustra un ejemplo en el que no es posible enviar todos los datos a transmitir en una sola transmisión de frame, y por tanto los datos se reparten y transmiten de manera intermitente mediante múltiples frames de transmisión (ver Figura 70 posterior).

El proceso de comunicación de datos anterior tiene las siguientes características. El servidor puede acceder directamente a un dispositivo base y a un dispositivo de expansión usando el mismo protocolo, sin necesitar una conversión de datos, o similar, durante la operación. Los datos AP necesarios para el acceso se determinan según el puerto del servidor, el dispositivo base y el socket de expansión donde se conecta la función. Cuando se accede a un dispositivo base, se puede confirmar el estado de conexión de los dispositivos de expansión en ese dispositivo base. Los dispositivos periféricos se pueden conectar o desconectar incluso aunque el servidor esté funcionando. Con miras a obtener información que se refiere a un dispositivo periférico, el servidor pide un Device Status. Si no se pide un Device Status, un dispositivo periférico no comienza a funcionar, sino que permanece en standby (estado de espera). Hay dos tipos de operación de reinicialización de dispositivo periférico, a saber, una reinicialización de software (comando de reinicialización) y una reinicialización de hardware (patrón de reinicialización), que se describirán después. Una reinicialización de software sólo reinicializa dispositivos periféricos determinados que están conectados a un puerto. Una reinicialización de hardware reinicializa todos los dispositivos periféricos. La transferencia de datos se controla en unidades frame que contienen un máximo de 1.024 bytes. Un único dispositivo periférico puede usar hasta tres funciones y se accede a las funciones especificando los tipos de función correspondientes. Dentro de un intervalo (1 INT) es posible un máximo de una operación de acceso a una función, y mediante un acceso se puede comunicar un frame de datos. A un único puerto no se accede en un modo continuo. Después se describe el modo en el que se consiguen estas características.

Datos frame

Para una función, es posible un máximo de una operación de acceso durante un periodo INT interno, y la cantidad de datos que se pueden transferir en una operación de acceso es frame de transmisión de datos y un frame de recepción de datos. La Figura 54 antes descrita muestra ejemplos de datos frame, donde un frame comprende un patrón de puesta en marcha, un patrón de datos, bits de paridad y un patrón de fin.

El patrón de puesta en marcha, bits de paridad y el patrón de fin son designados por el patrón de transmisión de datos, y son procesados automáticamente por el MIE. El patrón de datos en el frame está formado por unidades de 4 bytes, y contiene un mínimo de cuatro bytes y un máximo de 1.024 bytes. Cuando tiene un mínimo de 4 bytes, comprende únicamente un código de comando, un AP destino, un AP fuente, y un tamaño de datos (=00 h). El código de comando indica el código del comando emitir al dispositivo destino. El AP destino indica el AP del dispositivo al que se transmite el frame. Dicho de otro modo, el servidor especifica el AP de un dispositivo base o de expansión, y un dispositivo base o de expansión especifica el AP de un puerto de servidor. El AP fuente indica el propio AP del dispositivo de transmisión. El tamaño de los datos indica el tamaño de los datos de transmisión en unidades de 4 bytes. Los datos son los datos para la transmisión (formato de datos, etc.) y se almacenan en unidades de 4 bytes.

Códigos de comando

Los códigos de comando comprenden 1 byte y almacenan los códigos para comandos.

TABLA 1 Composición del código de comando

Bit	7	6	5	4	3	2	1	0
Datos	COM_{7}	COM_{6}	COM_{5}	COM_{4}	COM_{3}	COM_{2}	COM_{1}	COM_{0}

Aquí, COM_{0} a COM_{7} son códigos de comando. Los códigos de comando se definen en un rango entre 01h y FEh. Los diferentes tipos de código de comando se describen después.

Los datos que se describen con referencia a esta tabla se almacenan en un emplazamiento adecuado en una memoria o registro interno, etc., que no se muestra en los dibujos.

Posición absoluta AP

A continuación se describe AP. Hay tres tipos de AP: el AP de un dispositivo básico o de expansión en si mismo; un AP que indica un destino para los datos (AP destino); y un AP que indica una fuente de datos (AP fuente). El AP de un dispositivo base o expansión es el AP del dispositivo en si mismo, y se compara con el AP destino de un frame transmitido desde el servidor y que se usa para identificar si los datos procedentes del servidor se dirigen o no a ese dispositivo. El AP fuente de un dispositivo son los datos que se escriben en el tercer byte de un frame cuando un dispositivo base o de expansión devuelve los datos al servidor (Figura 48). Esto indica al servidor qué datos transmitidos al dispositivo se han enviado. En el AP fuente del dispositivo, los cinco bits menos significativos indican el estado de conexión anterior del bus M. El servidor accede al dispositivo base y examina el AP fuente en el comando de respuesta (frame desde el dispositivo base) para ver qué buses LM del dispositivo base tienen dispositivos de expansión conectados. El valor de AP se determina según la configuración de conexión del puerto, al dispositivo base y al dispositivo de expansión (sistema de número de sockets fijos), como se ilustra en la Figura 57, que se describe después.

Composición de bits del AP

La Tabla 2 muestra una composición de bits del AP que se guardan en un registro interno. El AP comprende un byte (8 bits). Los bits séptimo y octavo del AP son los bits de selección de puerto PO_{1} y PO_{2}, que indican el puerto de entrada/salida del puerto al que está conectado el dispositivo base. El quinto bit del AP es un bit de selección de dispositivo base/dispositivo de expansión, que indica si el dispositivo es un dispositivo base o de expansión. Los bits cuarto a cero del AP son los bits LM_{4} a LM_{0} de selección de bus LM, que indican el número de un bus LM.

TABLA 2 Composición del AP

Bit	7	6	5	4	3	2	1	0
Datos	PO_{1}	PO_{0}	D/E	LM_{4}	LM_{3}	LM_{2}	LM_{1}	LM_{0}

En la tabla se muestran ejemplos del uso de los bits de puerto elegidos PO_{0} y PO_{1}. Cualquiera puerto desde el puerto A al puerto D se designa mediante los dos bits de selección de puerto PO_{0} y PO_{1}.

TABLA 3 Bits de selección de puerto

Puerto seleccionado	PO_{1}	PO_{2}
Puerto A	0	0
Puerto B	0	1
Puerto C	1	0
Puerto D	1	1

Como se muestra en la Tabla 4, el bit se selección dispositivo base/dispositivo de expansión es "1" cuando el AP se selecciona para un dispositivo base, "0" cuando se selecciona un dispositivo de expansión, y es "0" cuando se selecciona un puerto.

TABLA 4 Bits de Selección de Dispositivo de Base / Dispositivo de Expansión

Dispositivo seleccionado	D/E
Dispositivo base	1
Dispositivo de expansión	0
Puerto	0

Los bits LM_{4} a LM_{0} de selección de bus LM se muestran en la Tabla 5. Si el AP designa un dispositivo base o un puerto, LM_{4} a LM_{0} se fijan en "0". Si un dispositivo de expansión se conecta a un bus LM, o se accede a un dispositivo de expansión, el bit de selección LM_{n} para el bus correspondiente se fija en "1". Además, si no hay ningún dispositivo de expansión conectado, el bit de selección LM_{n} del bus LM correspondiente se fija en "0". Cuando se accede a un dispositivo de expansión, sólo el bit de selección del número de buses LM del dispositivo de expansión al que se accede se fija en "1".

TABLA 5 Bits de Selección de Número de bus LM

Destino transferencia	LM_{4}	LM_{3}	LM_{2}	LM_{1}	LM_{0}
Dispositivo base	0	0	0	0	0
Dispositivo expansión	La tabla que se muestra después
Puerto	0	0	0	0	0

\vskip1.000000\baselineskip

Número de bus LM	Bit de selección	Acceso o estado conectado	Estado desconectado
Nº 1	LM_{0}	1	0
Nº 2	LM_{1}	1	0
Nº 3	LM_{2}	1	0
Nº 4	LM_{3}	1	0
Nº 5	LM_{4}	1	0

Cuando hay una respuesta desde un dispositivo base, el AP fuente comprende el AP del dispositivo base automáticamente combinado mediante una puerta OR con los bits de selección de estado de conexión de dispositivo de expansión para los buses LM correspondientes.

Por ejemplo, si el servidor accede a un dispositivo base desde el puerto A (00 h), el AP fuente será "00100000" (20 h), y el AP destino será "00000000" (00 h). Aquí, h indica notación decimal. Si los dispositivos de expansión se conectan al dispositivo base por los buses LM números 1 y 3, la respuesta desde el dispositivo base al puerto A será: AP destino = "00000000" (00 h), AP fuente = "00100101" (25 h). El AP fuente añade (mediante una operación OR) el estado de conexión de los dispositivos de expansión (LM_{0} y LM_{2} = "1") al AP del dispositivo base ("00100000").

Después, cuando el servidor accede a un dispositivo de expansión conectado al bus LM nº 1 desde el puerto B, el AP destino es "01000001" (41 h), el AP fuente es "01000000" (40 h). La respuesta del dispositivo de expansión conectado al bus LM nº 1 es AP destino = "01000000" (40 h), AP fuente = "01000001" (41 h).

La Figura 57 muestra una tabla de Aps (notación hexadecimal) para dispositivos base y dispositivos de expansión cuando el servidor accede a los mismos. Cuando un dispositivo base responde, el AP receptor es la suma (todas las sumas OR) del AP del mismo dispositivo base, más los valores AP de los dispositivos de expansión conectados a él. Por tanto, el AP fuente desde un dispositivo base contiene información de la conexión de los dispositivos de expansión. El servidor puede saber por el AP fuente del dispositivo base si uno o varios dispositivos de expansión están conectados.

Procedimiento de selección inicial para Aps de dispositivo base

A continuación se describe un procedimiento para seleccionar inicialmente Aps. La persona que está jugando puede conectar dispositivos base a cualquier puerto del servidor, y puede también conectar dispositivos de expansión a cualquier bus LM del dispositivo base. Por tanto, antes de empezar el juego, el servidor tiene que descubrir si un dispositivo base o de expansión está conectado a alguno de los puertos del servidor, y tiene que identificar el AP de estos dispositivos. A continuación se describe un procedimiento para seleccionar en principio Aps de dispositivo base con referencia al organigrama de la Figura 58. La Figura 58 muestra un ejemplo de un caso en el que un dispositivo base está conectado al puerto A del servidor y hay dispositivos de expansión conectados a los buses LM nº 1 y nº 2 del dispositivo base. El diagrama ilustra la operación del servidor y del dispositivo base CPU.

Primeramente, el servidor, el dispositivo base y el dispositivo de expansión se conectan entre si mediante líneas de comunicación, y cuando se conecta la fuente de alimentación para los dispositivos, comienzan los programas de inicialización desde una ROM a la CPU en cada dispositivo. El MIE del dispositivo base se ilustra en la Figura 64 posterior, y el MIE del dispositivo de expansión se ilustra en la Figura 66. Según estos programas, el dispositivo base (CPU) inicializa el registro de interfaz y el puerto, que se describen después (S22, S24). Acto seguido, el dispositivo base genera un AP para si mismo. En este caso, ya que el AP se refiere al mismo dispositivo, sólo el bit 5 del AP se fija en "1", dando un AP de " - - 100000". Aquí, el símbolo "-" indica un valor indefinido (S26). A continuación, el dispositivo base investiga si se proporciona un bus LM nº 5. A diferencia de otros buses LM, el bus LM nº 5 es una conexión de bus o una conexión lógica. Esto se debe a que se prevén usos en donde las funciones del mismo dispositivo base se expanden, instalando un dispositivo de expansión dentro del dispositivo base, o usando un dispositivo base y un dispositivo de expansión en combinación. Por ejemplo, si se crea un controlador de juego que comprende una función vibrante, entonces el controlador de juego formará el dispositivo base y una sección vibrante se conectaría a éste vía el bus LM nº 5, formando así todo el dispositivo un controlador de juego que contiene una sección vibrante. La presencia o ausencia de este bus nº 5 ya se ha establecido en el dispositivo base CPU (esta información está escrita en una ROM, etc), y no necesita configurarse, o similares. En el ejemplo que se describe aquí, se supone que no hay bus LM nº 5 (S28).

A continuación, la CPU del dispositivo base selecciona los buses LM para los sockets externos. Como se muestra en la Figura 64, el dispositivo base genera una combinación de valores de voltaje que corresponden al número de buses LM significativos en terminales particulares, por ejemplo terminales ID_{0}, ID_{1}, de cada socket de bus LM, comenzando por la sección I/O. La Tabla 6 muestra ejemplos de la lógica de salida a los terminales ID_{0}, ID_{1} de cada bus LM que ha seleccionado el dispositivo base (S30).

TABLA 6

ID_{0}	ID_{1}	Nº de bus LM	Nº socket
0	0	1	1
1	0	2	2
0	1	3	3
1	1	4	4

El dispositivo base emite "0", "0" respectivamente a los terminales ID_{0}, ID_{1} del socket del bus LM nº 1 y emite "1", "0" respectivamente a los terminales ID_{0}, ID_{1} del socket del bus LM nº 2. Estos voltajes de salida lógicos se suministran a los dispositivos de expansión vía los buses LM y los puertos I/O. Un dispositivo de expansión examina los valores de salida lógicos del dispositivo base para identificar qué bus LM (socket de expansión) está conectado (S32).

El dispositivo base lee el nivel lógico desde un terminal especialmente reservado, por ejemplo el ID_{2} de cada socket de bus LM. El terminal ID_{2} se conecta a tierra vía una resistencia de empuje, y cuando se conecta un dispositivo de expansión a este socket, se aplica un voltaje Vcc desde el lado del dispositivo de expansión. El resultado es que cuando se conecta un dispositivo de expansión a ese socket, el nivel lógico del terminal ID_{2} se convierte en "1". Además, si no se conecta el dispositivo de expansión, el nivel lógico del terminal ID_{2} se convierte en "0". Si se examina el nivel lógico de ID_{2} con respecto a ID_{0} e ID_{1} emitidos al bus LM, el dispositivo base puede identificar si un dispositivo está o no conectado al nº de bus LM que indica la lógica emitida a los terminales mencionados ID_{0} y ID_{1}. Si se repite este proceso, el terminal ID_{2} sirve para confirmar la conexión de los dispositivos de expansión, y cuando ID_{2} es "0", esto indica que no hay ningún dispositivo de expansión conectado, y cuando ID_{2} es "1", esto indica que sí hay un dispositivo de expansión conectado. En este ejemplo, ID_{2} del bus LM nº 1 e ID_{2} del bus LM nº 2 son "1" (S34).

En determinadas condiciones, las salidas lógicas a los terminales socket ID_{0}, ID_{1} sirven como señal de reinicialización desde el dispositivo base a un dispositivo de expansión. Por ejemplo, si el dispositivo base cambia las salidas ID_{0}, ID_{1} que van al dispositivo de expansión, se forma una señal "detener funcionamiento" que va al dispositivo de expansión y el dispositivo de expansión detiene su funcionamiento. Por ejemplo, si ID_{0}, ID_{1} fueran "00" y se cambiaran a ID_{0}, ID_{1}= "11", el dispositivo de expansión detendría su funcionamiento. Además, si el dispositivo base cambiase las salidas ID_{0}, ID_{1} y después las devolviese a sus valores originales, se crearía una señal de reinicialización hacia el dispositivo de expansión y el dispositivo de expansión se reincializaría. Por ejemplo, si ID_{0}, ID_{1} fueran "00", y después se emitiera ID_{0}, ID_{1}= "11" (señal de detención) para detener el dispositivo de expansión, el dispositivo base se reinicializaría después. Después de reinicializar el dispositivo base, se reinicializa el dispositivo de expansión cambiando a ID_{0}, ID_{1}= "00" (señal de reinicialización) (volver a los valores originales). Después de la reinicialización, los dispositivos asumen el mismo estado que el que sigue al una reinicialización de software, el cual se describe después. A continuación, cuando el dispositivo base está transmitiendo, genera un AP fuente. El AP fuente tiene la forma
" - - 1xxxxx" dependiendo del AP del dispositivo base y del estado del terminal ID_{2}. Los símbolos "x" en bits de 0 a 4 son "0" ó "1", dependiendo de los estados de conexión de los buses LM. En este ejemplo, hay dispositivos conectados únicamente a los buses LM 1 y 2, con lo cual el AP fuente es " - - 100011" (S36).

El dispositivo base espera a recibir un Device Request, que es un tipo de comando que envía el servidor. Si el dispositivo base no recibe un Device Request, éste permanece en un estado de espera y repite el proceso desde la fase 34 (S38; No). En este ejemplo, el dispositivo base está conectado al puerto A del servidor. El AP destino para este dispositivo base desde el servidor es "00100000", que indica que el dispositivo base está en el puerto A. El "1" en el quinto bit indica un dispositivo base, y el "00" en el sexto y el séptimo indica puerto A.

Por otro lado, el servidor envía sucesivamente un comando (Device Request) a cada puerto y espera una respuesta desde un dispositivo base, de este modo puede identificar si los dispositivos base o los dispositivos de expansión (dispositivos periféricos) están conectados a los puertos A a D (H22). Cuando el dispositivo base en el puerto A recibe un comando (Device Request) del servidor (S38; Yes), éste lee el AP fuente en el frame recibido, y deduce el nº de puerto que se conecta desde los bits sexto y séptimo. En este ejemplo, es el puerto A, con lo cual estos bits son "00" (S40).

En la fase S26, el dispositivo base completa su propio AP (8 bits) usando los 6 bits menos significativos que se han creado antes y los dos bits más significativos que indican el puerto (S42). En concreto, combina el "00" (bits sexto y séptimo) deducido para el puerto A, y el AP que ya ha creado el dispositivo base (= " - - 100000") (bits cero a quinto), completando así el propio AP del dispositivo base "00100000" (20h en notación hexadecimal).

Acto seguido, el dispositivo base completa el AP fuente para el frame de transmisión. Los bits de puerto se añaden, en las posiciones más significativas, al AP fuente que ya se ha completado hasta únicamente los 6 bits menos significativos en la fase S36. En este ejemplo, los bits de puerto "00" se añaden al AP fuente = " - - 100011" para proporcionar un AP fuente "00100011" (S44). Si se mira el código de este AP fuente, se puede ver que el dispositivo base está conectado al puerto A, y que los dispositivos de expansión están conectados a los buses LM nº 1 y nº 2 de este dispositivo base.

Este dispositivo base crea un frame de transmisión para contestar al Device Reply (S46). El dispositivo base prepara un Device Status como comando de respuesta para el comando de Device Request. El AP destino es "00000000" que indica el puerto A, y el AP fuente es "00100011" como se ha descrito antes.

El dispositivo base envía un frame de transmisión que contiene el Device Status, devolviendo así un comando al servidor (S48). Después de esto, ya que el dispositivo base no está desconectado, su AP es "00100000". El dispositivo base monitoriza constantemente el estado del terminal ID_{2} de los sockets de los buses LM. Si cambia el estado de conexión de los dispositivos de expansión con los buses LM, también cambian los bits del AP fuente, manteniendo así un AP fuente que corresponde al estado de conexión de los dispositivos de expansión.

El servidor recibe frames de transmisión desde el dispositivo base e identifica que hay un dispositivo base conectado al puerto A y que los dispositivos de expansión están conectados a los buses LM nº 1 y nº 2 de este dispositivo base (H24). El servidor puede apreciar si existen dispositivos de expansión conectados al dispositivo base simplemente accediendo al dispositivo base. Como se describe después, mediante el comando de Device Status, el servidor puede identificar también los detalles del dispositivo base (tipo de dispositivo periférico, etc) conectado al puerto.

En el proceso de selección de AP mencionado antes, los sockets mediante los cuales los dispositivos de expansión se conectan al dispositivo base tienen números fijos y se comprueba si un dispositivo de expansión está o no conectado a cada uno de los sockets (sistema de número fijo de socket (número de bus LM)). Dicho de otro modo, (a) después de inicializarse el mismo dispositivo base, éste selecciona primeramente los ID_{0}, ID_{1} correspondientes al nº de bus LM (socket), y después (b) examina el nivel lógico del ID_{2} de cada socket para identificar la presencia o ausencia de una conexión de dispositivo de expansión en cada bus LM. Acto seguido, (c) determina qué número de dispositivos de expansión de buses LM se conectan desde la información de conexión ID_{2}, y por tanto crea los seis bits menos significativos del AP fuente para el frame de transmisión en base a esta información. (d) El dispositivo base obtiene información que indica el puerto del servidor que se conecta desde el AP fuente en el frame recibido desde el servidor, y añade los dos bits más significativos del AP fuente del dispositivo base, completándose así el AP fuente.

Por otro lado, también es posible que el dispositivo base ejecute un chequeo previo del ID_{2} para identificar los buses LM en uso, y después para asignar los números de bus LM a los buses LM usados (sistema de asignación de número de socket (número de bus LM)). En concreto, (a) después de inicializarse el mismo dispositivo base, éste examina la lógica ID2 para identificar si un dispositivo de expansión está conectado a un bus LM determinado. (b) Después asigna ID_{0}, ID_{1} a los buses LM que ha identificado el terminal ID_{2} como que tienen una conexión de dispositivo de expansión. Los números se asignan en orden ascendente con lo cual no se solapan entre ellos. La Tabla 7 muestra un ejemplo de ID_{0}, ID_{1} y números de bus LM. Un bus LM cuyo estado de conexión permanece inalterado mantiene el número de su estado anterior.

TABLA 7

ID_{0}	ID_{1}	Nº de Bus LM
0	0	1
0	1	2
1	0	3
1	1	4

Acto seguido, (c) el dispositivo base crea los 6 bits menos significativos de su AP fuente usado cuando transmite, en base a la información que hay en ID_{2} y ID_{0}, ID_{1}. (d) Después obtiene información que identifica el puerto del servidor al que se conecta desde el AP fuente que está en el frame recibido del servidor, y añade los dos bits más significativos del AP fuente del dispositivo base, completando así su AP fuente.

Una vez que el dispositivo base ha establecido su AP fuente, si recibe después una instrucción del servidor que pide que se actualice el AP, en el sistema de número fijo de socket, ya se han proporcionado los ID_{0}, ID_{1} correspondientes a cada socket, con lo cual el procesamiento que ejecuta el dispositivo base para actualizar el AP comienza en la fase (b) anterior. En el sistema de asignación de número de socket, los números de socket cambian, y por tanto el procesamiento en el dispositivo base para actualizar el AP comienza desde la fase (a) anterior.

Procedimiento de selección inicial de APs para dispositivos de expansión

A continuación se describe un procedimiento para la selección inicial de APs para dispositivos de expansión, haciendo referencia al organigrama de la Figura 59. En este diagrama, las operaciones del servidor, del dispositivo base y del dispositivo de expansión se muestran en paralelo. Además, se aplican los mismos números de fase a las secciones que corresponden a la Figura 58, y estas secciones no se describen aquí. En el ejemplo que se describe aquí, un dispositivo base está conectado al puerto B del servidor, y un dispositivo de expansión está conectado al bus LM nº 2 del dispositivo base.

Primeramente, el servidor, el dispositivo base y el dispositivo de expansión se conectan entre si, y se suministra energía a cada dispositivo (K22). El MIE del dispositivo de base y el MIE del dispositivo de expansión se describen después mediante las Figuras 64 y 66, respectivamente. El dispositivo de expansión se conecta al dispositivo base y cuando se ejecuta la denominada "power on reset" ("reinicialización de conexión"), se inicializa su registro interno y su puerto de bus LM (K24, K25).

El dispositivo de expansión (CPU) examina el bus LM según un programa de control. Como ya se ha descrito antes, los niveles lógicos que corresponden al número de bus LM se emiten mediante el dispositivo base (CPU) a terminales determinados, por ejemplo ID_{0}, ID_{1}, de cada conector de bus LM. El dispositivo de expansión lee la lógica de los terminales ID_{0}, ID_{1} del bus LM al que está conectado (K28). En este ejemplo, el dispositivo de expansión se conecta al socket 2, con lo cual la salida lógica de los terminales ID_{0}, ID_{1} se fija en "01". El dispositivo de expansión identifica el número de bus LM consultando la salida lógica de los terminales ID_{0}, ID_{1} y la Tabla 6. En este ejemplo, ID_{0}, ID_{1}= "01", con lo cual el número de bus LM se identifica como "2" (K30).

El dispositivo de expansión crea después su propio AP. El dispositivo de expansión sabe que es un dispositivo de expansión. Esto se consigue copiando previamente la información necesaria en una ROM, o copiándola directamente en el programa de control de dispositivo de expansión. El bit 5 (bit de selección dispositivo de expansión/dispositivo) del AP que está en el registro que se muestra en la Tabla 2 se fija en "0", y los bits 0 a 4 (bits de selección de número de bus LM) se fijan en "1" en correspondencia con el número de bus LM al que está conectado el dispositivo de expansión. En este ejemplo, el bus LM es el nº 2, con lo cual el bit 1 se fija en "1". Por tanto, el AP del mismo dispositivo de expansión es " - - 000010" (K32).

Acto seguido, el dispositivo de expansión crea un AP fuente de dispositivo de expansión. A diferencia del dispositivo base, el dispositivo de expansión no realiza un chequeo de conexión para el AP fuente, y por tanto el "AP fuente = AP de dispositivo de expansión". En este ejemplo, el AP fuente = AP de dispositivo de expansión = " - - 000010" (K34).

El dispositivo de expansión entonces espera un frame de entrada procedente del servidor que contiene un comando de Device Request que especifica su propio AP (" - - 000010") (K36). Si no recibe un comando Device Request continúa esperando en standby (reserva) (K36; No).

Como se ha descrito antes, ya que el dispositivo base ya ha informado al servidor del estado de conexión de los buses LM (S48), el servidor sabe qué buses LM tienen un dispositivo de expansión conectado a ellos (H26). Por tanto, los comandos de Device Request sólo se pueden transmitir al dispositivo de expansión para que se pueda usar el dispositivo de expansión, en aplicaciones que permitan el uso de dispositivos de expansión. En este ejemplo, el AP fuente en el frame de transmisión enviado por el servidor es "01000000" que indica el puerto B, y el AP destino es "010000010" que indica un dispositivo de expansión y un bus LM nº 2 (H28).

El dispositivo de expansión recibe el frame que contiene el comando Device Request (K36; Yes). Entonces lee el AP fuente de estos datos del frame ("01000000") para deducir el número de puerto significativo del servidor. Aquí, es el puerto B, con lo cual el número de puerto es "01". El dispositivo de expansión añade los bits que indican el puerto B a las posiciones más significativas del AP del dispositivo de expansión que ya se ha completado hasta únicamente los 6 bits menos significativos, completándose así su propio AP de dispositivo de expansión. En este ejemplo, se añaden los bits "01" para el puerto B al AP del dispositivo de expansión " - - 000010", produciéndose así un AP de dispositivo de expansión de "01000010".

Después, se completa el AP fuente del dispositivo de expansión. Los bits del puerto se añaden, en las posiciones más significativas, al AP fuente que ya se ha completado hasta únicamente los seis bits menos significativos. Aquí, los bits de puerto "01" se añaden al AP fuente "--000010" para ofrecer un AP fuente de "010000010" (K42). Este AP fuente del dispositivo de expansión es el mismo que el AP del dispositivo de expansión, con lo cual se puede suprimir este proceso (K42).

El dispositivo de expansión crea entonces un frame de transmisión para contestar al servidor (K44). Prepara un comando de respuesta Device Status en respuesta al comando Device Request. El AP destino es "01000000" que indica el puerto B del servidor, y el AP fuente es "010000010". El dispositivo de expansión envía el comando al servidor (K46). Este comando es un comando Device Status. Acto seguido, el dispositivo de expansión mantiene "010000010" como su propio AP y AP fuente, a menos que se desconecte el suministro de energía o los cables.

El servidor obtiene los detalles del dispositivo de expansión que está conectado (diferente información que se refiere al dispositivo periférico) al recibir el comando Device Status del dispositivo de expansión.

Tamaño de los datos

A continuación se describe la composición de la sección del tamaño de los datos que se encuentran en un frame de transmisión o recepción. La sección del tamaño de los datos comprende un único byte, como se muestra en la Tabla 8.

TABLA 8 Composición del Tamaño de los Datos

Bit	7	6	5	4	3	2	1	0
Datos	DS_{7}	DS_{6}	DS_{5}	DS_{4}	DS_{3}	DS_{2}	DS_{1}	DS_{0}

Aquí, los datos DS_{0} a DS_{7} en el bit 0 a bit 7 indican el tamaño de los datos. La sección del tamaño de los datos indica el tamaño de los datos que están en unidades de 4 bytes, desde un mínimo de 0 bytes a un máximo de 1.020 bytes. Esto se muestra en la Tabla 9.

TABLA 9 Formato de los Datos

Bit	7	6	5	4	3	2	1	0
Tamaño datos
esp.	DS_{7}	DS_{6}	DS_{5}	DS_{4}	DS_{3}	DS_{2}	DS_{1}	DS_{0}
0 bytes	0	0	0	0	0	0	0	0
4 bytes	0	0	0	0	0	0	0	1
8 bytes	0	0	0	0	0	0	1	0
:	:	:	:	:	:	:	:	:
508 bytes	0	1	1	1	1	1	1	1
512 bytes	1	0	0	0	0	0	0	0
516 bytes	1	0	0	0	0	0	0	1
:	:	:	:	:	:	:	:	:
1012 Bytes	1	1	1	1	1	1	0	1
1016 bytes	1	1	1	1	1	1	1	0
1020 bytes	1	1	1	1	1	1	1	1

\newpage

Datos

A continuación se describe la composición de la sección de datos que se encuentra en un frame de transmisión o recepción. La sección de datos almacena datos que se van a transferir a un tamaño indicado por el tamaño de los datos (unidades de 4 bytes). Por ejemplo, un sistema controlador contiene el tipo de función y el formato de los datos del controlador. La composición de la sección de datos se muestra en la Tabla 10.

\vskip1.000000\baselineskip

TABLA 10 Composición de los Datos

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	D1_{7}	D1_{6}	D1_{5}	D1_{4}	D1_{3}	D1_{2}	D1_{1}	D1_{0}
2^{os} Datos	D2_{7}	D2_{6}	D2_{5}	D2_{4}	D2_{3}	D2_{2}	D2_{1}	D2_{0}
3^{os} Datos	D3_{7}	D3_{6}	D3_{5}	D3_{4}	D3_{3}	D3_{2}	D3_{1}	D3_{0}
4^{os} Datos	D4_{7}	D4_{6}	D4_{5}	D4_{4}	D4_{3}	D4_{2}	D4_{1}	D4_{0}
:	:	:	:	:	:	:	:	:

\vskip1.000000\baselineskip

Transferencia de datos

A continuación se describe una visión general de la transmisión de datos entre el servidor y un dispositivo periférico (dispositivo base o dispositivo de expansión). En este proceso de transmisión de datos, se elaboran las reglas de manera que sean adecuadas para dispositivos de juego. Primeramente, las comunicaciones de datos se controlan básicamente según un formato por el cual el servidor hace peticiones y los dispositivos periféricos responden de manera acorde. Todas las instrucciones y las peticiones entre el servidor y un dispositivo periférico se ejecutan mediante comandos (frames). Si se transmite un comando (frame) a un dispositivo periférico, éste siempre devuelve un comando de cualquier tipo al servidor. Si se produce un error de transmisión, se usa un indicador de error y las funciones de hardware ejecutan un proceso de error.

Después de la conexión al servidor, se activa un dispositivo periférico al recibir un comando de Device Request desde el servidor con el fin de deducir los detalles del dispositivo periférico. El dispositivo periférico siempre devuelve un comando de cualquier tipo en respuesta al comando del servidor. El dispositivo periférico (o una función que proporciona este dispositivo periférico) puede, por ejemplo, recibir un comando durante un intervalo
INT.

La Figura 60 es un diagrama simbólico que ilustra la transmisión de datos entre un servidor y un dispositivo periférico. Como se ha afirmado antes, el servidor y el dispositivo periférico (dispositivo base o dispositivo de expansión) se interconectan, y cuando se conecta el suministro de energía, se establecen sus APs respectivos antes de que comience la transmisión de datos. Esto proporciona los AP de dispositivo inherente, AP fuente y AP destino correspondientes que se necesitan para la transmisión de datos.

Al ejecutarse una aplicación, la CPU del servidor pide acceso al dispositivo periférico. Los datos de transmisión y el comando de transmisión emitidos por la aplicación se copian respectivamente en un búfer de escritura y en un registro de comandos del MIE del servidor. Los datos de transmisión y el comando de transmisión se establecen en un frame, como se ha ilustrado antes en la Figura 48, y este frame se transmite al dispositivo periférico que está en un estado de espera de comando. Al recibir esta unidad de información, el MIE del dispositivo periférico lee el comando y los datos, y los suministra a la CPU del dispositivo periférico. La CPU del dispositivo periférico lee el comando y controla el proceso que corresponde al comando para obtener un comando de respuesta y, si es necesario, los datos que se van a devolver al servidor. Estos datos y el comando se establecen un frame mediante el MIE del dispositivo periférico, y después se envían al servidor.

Acto seguido, el dispositivo periférico asume un estado standby en espera del siguiente comando. Cuando el MIE del servidor recibe el frame de respuesta, copia el estado de las comunicaciones en el registro de estado y copia los datos recibidos en un búfer de lectura. La CPU del servidor lee después los datos de ambos registros y continúa la aplicación. Al repetirse estas operaciones, se controlan las comunicaciones de los datos entre el servidor y el dispositivo periférico (dispositivo base o dispositivo de expansión).

\newpage

Los detalles concretos de un proceso de comunicaciones entre el MIE del servidor y el MIE del dispositivo periférico se describen después. Si el hardware produce un indicador de error, entonces se ejecuta un proceso de error. Los detalles de la interfaz interna del servidor también se describen después.

Error de transferencia

Aquí se describe el error de transferencia que se produce durante la transmisión de datos. Los errores que puede detectar el hardware incluyen: errores de paridad, Time Outs (excesos de tiempo permitidos) y Overflows (desbordamientos). Un error de paridad es un error que se detecta cuando la paridad del frame de datos no corresponde. Un Time Out (exceso de tiempo permitido) es un error que se detecta cuando ha transcurrido más del tiempo permitido mientras que las líneas SDCKA y SDCKB permanecen en un estado de régimen permanente. Un overflow (desbordamiento) de datos es un error que se detecta cuando el volumen de los datos sobrepasa la capacidad del búfer de transmisión/recepción. Otros errores diferentes a estos (por ejemplo corrupción de datos) los detecta el software. Si se produce un error que puede detectar el hardware cuando se recibe un frame, esto lo indica un indicador de error, o equivalente.

Procesamiento de error en el servidor

Si se produce un error de recepción en el servidor, se emite un comando de retransmisión mediante el comando enviado al dispositivo periférico (dispositivo base o dispositivo de expansión). El comando de retransmisión se envía un máximo de tres veces. Si todavía se produce un error, se ejecuta un proceso de visualización de "no conexión" o de visualización de error. El número de transmisiones y el método de procesamiento varían según el software de aplicación y la librería. Un comando de transmisión enviado al dispositivo periférico se reconoce hasta tres veces para cada transmisión del servidor, y después de esto se ejecuta un proceso de visualización de "no conexión" o de error, o equivalente. En un procesamiento de "no conexión", se envía una reinicialización de hardware (patrón de reinicialización) al puerto donde se ha producido el error. Acto seguido, si es necesario, se ejecuta un Device Request.

Procesamiento de error en el dispositivo periférico

Si se produce un error de transmisión, el dispositivo periférico (dispositivo base o dispositivo de expansión) controla una operación de retransmisión en respuesta a las peticiones del servidor, aunque no lleva a cabo un proceso de error, tal como una retransmisión basada en la decisión del dispositivo periférico. Si se produce un error de recepción, el dispositivo periférico puede enviar un comando de retransmisión al servidor. Si se produce un Time out durante la recepción, el dispositivo periférico ejecuta una reinicialización de software. Los Time outs (excesos de tiempo permitidos) los detectan únicamente los dispositivos base, y se envían señales de reinicialización a los dispositivos de expansión desde un dispositivo base usando la línea ID.

Operaciones prohibidas En este estándar se aplican algunas prohibiciones

En concreto, (1) si se conectan múltiples dispositivos periféricos (dispositivos base y dispositivos de expansión) a un servidor, se prohibe el acceso directo desde un dispositivo periférico a otro. En principio, el acceso se debe hacer vía el servidor. (2) A un dispositivo periférico no se le permite usar comandos que sólo puede emitir el servidor. (3) No se puede acceder al mismo puerto en un modo continuo.

Sin embargo, estas prohibiciones sólo se dan como ejemplo en un modelo según una realización, y no se pretende con las mismas reducir el objeto de la presente invención o restringir la aplicación de la invención. Naturalmente, es posible controlar las comunicaciones de datos mediante un estándar diferente que permita estas operaciones prohibidas y otras similares.

Conexión y desconexión de dispositivos periféricos

Aquí se describe el proceso de juicio que ejecuta el servidor para conectar y desconectar dispositivos periféricos (dispositivos base y dispositivos de expansión). Para ejecutar este proceso de juicio, el servidor transmite un comando Device Request a los dispositivos periféricos de cada puerto. Como se ha explicado antes, cuando se conecta una fuente de alimentación después de conectar un servidor y los dispositivos periféricos, el servidor, los dispositivos base y los dispositivos de expansión ejecutan por separado procedimientos para establecer su propio AP. Por tanto, antes de este proceso de juicio, se determinan los APs de los dispositivos periféricos destino para cada puerto. El intervalo en el que se transmite un Device Request es, preferentemente, 1 intervalo INT. Si ha habido una respuesta desde el dispositivo periférico, entonces no es necesario transmitir un comando Device Request posterior. Naturalmente, no es necesario que el servidor transmita un comando Device Request a los puertos que no ha usado el software de aplicación.

Comprobación de conexión del dispositivo base

Ahora se describe la comprobación de conexión. Si el servidor transmite un comando de Device Request a un puerto determinado y el dispositivo de base devuelve el comando Device Status, el servidor identifica que un dispositivo base descrito por el Device Status (se explica después) está conectado a ese puerto. Si no hay ninguna respuesta del dispositivo base (Time out-exceso de tiempo permitido), se juzga que no hay ningún dispositivo base conectado a ese puerto. Un exceso de tiempo permitido se genera cuando no hay respuesta en 1,0 ms, por ejemplo, desde la transmisión del comando.

Comprobación de conexión del dispositivo de expansión

Al acceder únicamente a los dispositivos base que están conectados a sus puertos correspondientes, el servidor también recibe desde los dispositivos base información del estado de conexión de los dispositivos de expansión que están conectados a esos dispositivos base (mediante los APs fuente), y por tanto no es necesario realizar una comprobación de conexión de todos los dispositivos de expansión de la misma forma que para los dispositivos base. Además, si, cuando se accede a un dispositivo base, un bit de selección de conexión de dispositivo de expansión que antes indicaba que no había conexión en el AP fuente que se encontraba en la respuesta procedente del dispositivo base cambia ahora a "1", esto indica que un dispositivo de expansión indicado mediante ese bit de selección se acaba de conectar. Ya que el servidor puede identificar el estado de conexión de los dispositivos de expansión después de acceder a un dispositivo base, también transmite un Device Request a los dispositivos de expansión, y espera un comando de respuesta Device Status. Aquí, si no hay respuesta Device Status se genera un Time Out, y se juzga que no hay ningún dispositivo de expansión conectado.

Operación del dispositivo periférico con respecto a la comprobación de conexión

Todos los dispositivos periféricos (dispositivos base y dispositivos de expansión) asumen un estado de espera inmediatamente después de la conexión y en vez de comenzar su operación de dispositivo, obtienen los seis bits menos significativos de únicamente su propio AP. Un dispositivo periférico no responde a ningún comando del servidor hasta que recibe un Device Request. El dispositivo periférico recibe después un comando Device Request desde el servidor. Graba el puerto AP al que se conecta desde el AP fuente que está en el frame recibido, completa su propio AP y AP fuente y después comienza a funcionar para devolver un Device Request.

Comprobación de desconexión del dispositivo base

El servidor transmite un comando a un dispositivo base conectado (dispositivo base que se ha confirmado previamente que está conectado a un puerto), y si no hay respuesta del dispositivo base en un periodo de tiempo predeterminado (Time Out), el servidor decide que el dispositivo base se ha desconectado. Esta desconexión se confirma tres veces, y si aún está desconectado, se transmite un patrón de reinicialización después de un intervalo (1 INT).

Comprobación de desconexión del dispositivo de expansión

Si el servidor no recibe respuesta a un comando que ha transmitido a un dispositivo de expansión, que se ha confirmado previamente que está conectado a un puerto, Time Out, el servidor decide que el dispositivo de expansión se ha retirado y ha asumido un estado desconectado. Esta desconexión se confirma tres veces, y si aún está desconectado, se transmite un patrón de reinicialización después de un intervalo (1 INT).

Además, el servidor accede al dispositivo base y recibe un frame de respuesta desde el dispositivo base. Acto seguido, si el servidor identifica que un bit de selección de conexión de dispositivo de expansión en el AP fuente del frame recibido ha cambiado a "0", decide que el dispositivo de expansión que se indica mediante ese bit de selección de conexión LM_{n} se ha eliminado y ha entrado en un estado desconectado.

Operación de un dispositivo periférico con respecto a la desconexión

Si un dispositivo base se retira de un puerto del servidor, se interrumpe la fuente de alimentación que va del servidor al dispositivo base conectado a ese puerto. Por tanto, se pierde la información que se refiere al puerto de conexión almacenado en el dispositivo base. En consecuencia, incluso aunque un dispositivo base cuyo conector se ha retirado se vuelva a conectar al puerto del servidor (reincicialización hardware), el dispositivo base no comienza a funcionar en este estado. De manera similar, si un dispositivo de expansión se separa de un socket de dispositivo base, se interrumpe la fuente de alimentación al dispositivo de expansión y por tanto se pierde la información almacenada que se refiere al puerto de conexión. En consecuencia, aunque el dispositivo de expansión separado se vuelva a conectar al dispositivo base, no empieza a funcionar.

Reinicialización

Existen dos tipos de reinicialización: reinicialización hardware (patrón de reinicialización) y reinicialización software (comando de reinicialización). Las reinicializaciones sólo las puede ejecutar el servidor. Una reinicialización hardware es aquella que se realiza mediante un patrón de reinicialización, y permite que todos los dispositivos periféricos (dispositivos base y dispositivos de expansión) conectados a un puerto determinado se inicialicen. Los dispositivos periféricos no envían ninguna respuesta. Una reinicialización software es aquella que se realiza mediante un comando Device Reset, y puede inicializar un dispositivo periférico determinado. En este caso, el dispositivo periférico en cuestión devuelve un comando DEvice Reply, después de lo cual el dispositivo periférico ejecuta un proceso de autoinicialización.

El dispositivo periférico reinicializado (dispositivo base o dispositivo de expansión) inicializa sus datos almacenados, por ejemplo variables y contenidos RAM, etc, al estado que viene inmediatamente después del encendido, a excepción de algunas funciones. Ya que el AP del dispositivo periférico se inicializa cuando se va a volver a usar, el servidor tiene que transmitir un Device Request.

ID de dispositivo

Como ya se ha descrito antes, en una comprobación de conexión, un dispositivo periférico (dispositivo base o dispositivo de expansión) que recibe un Device Request desde el servidor transmite un Device Status en respuesta al servidor. Diversa información referente al dispositivo está almacenada en esta zona de datos de Device Status, que forma información de dispositivo fija. Uno de estos es el ID de dispositivo. El ID del dispositivo registra si el dispositivo es un dispositivo base o un dispositivo de expansión, el tipo de función, y texto del bloque de definición de función. Todos los dispositivos periféricos tienen al menos un ID de dispositivo y una o más funciones. De ese modo, el servidor puede identificar los detalles del dispositivo periférico que está conectado al mismo (tipo, función, formato de señal, etc.). Los diferentes tipos de comando se describen después.

Composición del ID del dispositivo

El ID del dispositivo comprende 16 bytes /128 bit), como se muestra en la Tabla 11.

\vskip1.000000\baselineskip

TABLA 11 Composición del ID del dispositivo

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	FT_{31}	FT_{30}	FT_{29}	FT_{28}	FT_{27}	FT_{26}	FT_{25}	FT_{24}
2^{os} Datos	FT_{23}	FT_{22}	FT_{21}	FT_{20}	FT_{19}	FT_{18}	FT_{17}	FT_{16}
3^{os} Datos	FT_{15}	FT_{14}	FT_{13}	FT_{12}	FT_{11}	FT_{10}	FT_{9}	FT_{8}
4^{os} Datos	FT_{7}	FT_{6}	FT_{5}	FT_{4}	FT_{3}	FT_{2}	FT_{1}	FT_{0}
5^{os} Datos	FD1_{31}	FD1_{30}	FD1_{29}	FD1_{28}	FD1_{27}	FD1_{26}	FD1_{25}	FD1_{24}
6^{os} Datos	FD1_{23}	FD1_{22}	FD1_{21}	FD1_{20}	FD1_{19}	FD1_{18}	FD1_{17}	FD1_{18}
7^{os} Datos	FD1_{15}	FD1_{14}	FD1_{13}	FD1_{12}	FD1_{11}	FD1_{10}	FD1_{9}	FD1_{8}
8^{os} Datos	FD1_{7}	FD1_{6}	FD1_{5}	FD1_{4}	FD1_{3}	FD1_{2}	FD1_{1}	FD1_{0}
9^{os} Datos	FD2_{31}	FD2_{30}	FD2_{29}	FD2_{28}	FD2_{27}	FD2_{26}	FD2_{25}	FD2_{24}
10^{o} Datos	FD2_{23}	FD2_{22}	FD2_{21}	FD2_{20}	FD2_{19}	FD2_{18}	FD2_{17}	FD2_{16}
11^{o} Datos	FD2_{15}	FD2_{14}	FD2_{13}	FD2_{12}	FD2_{11}	FD2_{10}	FD2_{9}	FD2_{8}
12^{o} Datos	FD2_{7}	FD2_{6}	FD2_{5}	FD2_{4}	FD2_{3}	FD2_{2}	FD2_{1}	FD2_{0}
13^{o} Datos	FD3_{31}	FD3_{30}	FD3_{29}	FD3_{28}	FD3_{27}	FD3_{26}	FD3_{25}	FD3_{24}
14^{o} Datos	FD3_{23}	FD3_{22}	FD3_{21}	FD3_{20}	FD3_{19}	FD3_{18}	FD3_{17}	FD3_{16}
15^{o} Datos	FD3_{15}	FD3_{14}	FD3_{13}	FD3_{12}	FD3_{11}	FD3_{10}	FD3_{9}	FD3_{8}
16^{o} Datos	FD3_{7}	FD3_{6}	FD3_{5}	FD3_{4}	FD3_{3}	FD3_{2}	FD3_{1}	FD3_{0}

\vskip1.000000\baselineskip

Aquí, FT indica el tipo de función que proporciona el periférico. FD1 indica un bloque de definición de función de una primera función. FD2 indica un bloque de definición de función de una segunda función. FD3 indica un bloque de definición de función de una tercera función. FD1, FD2 y FD3 tienen un significado de contenido que difiere dependiendo de la función indicada por FT.

\newpage

La Tabla 12 ilustra los contenidos de los tipos de función mencionados FT_{0} a FT_{31}. El tipo de función FT indica una función que proporciona un dispositivo periférico. Hay 32 tipos de función en total, comprendiendo cada una comandos de selección y formatos de datos.

\vskip1.000000\baselineskip

TABLA 12 Tipos de función

Bit	Función	Bit	Función
FT_{31}	Reservada	FT_{15}	Reservada
FT_{30}	Reservada	FT_{14}	Reservada
FT_{29}	Reservada	FT_{13}	Reservada
FT_{28}	Reservada	FT_{12}	Reservada
FT_{27}	Reservada	FT_{11}	Reservada
FT_{26}	Reservada	FT_{10}	Reservada
FT_{25}	Reservada	FT_{9}	Reservada
FT_{24}	Reservada	FT_{8}	Reservada
FT_{23}	Reservada	FT_{7}	(Provisional) Arma Luminosa
FT_{22}	Reservada	FT_{6}	(Provisional) FFB
FT_{21}	Reservada	FT_{5}	(Provisional) Salida de sonido
FT_{20}	Reservada	FT_{4}	(Provisional) Entrada de Sonido
FT_{19}	Reservada	FT_{3}	(Provisional) Temporizador
FT_{18}	Reservada	FT_{2}	B/W LCD
FT_{17}	Reservada	FT_{1}	Almacenamiento
FT_{16}	Reservada	FT_{0}	Controlador

\vskip1.000000\baselineskip

Por ejemplo, en un único dispositivo es posible proporcionar tres tipos de función, y los bits de selección que corresponden a una función provista se fijan en "1". Existe una orden de prioridad para los bits de selección: el bit más significativo (FT_{31}) tiene la mayor prioridad, y el bit menos significativo (FT_{0}) tiene la menor prioridad. Se seleccionan hasta tres librerías de función según este orden de prioridad.

En la tabla 11, FD1_{31} a FD1_{0} indican los primeros bloques de definición de función. Estos son bloques que definen los elementos individuales que constituyen la primera función. Los contenidos de los mismos varían dependiendo de la función. Los detalles los controlan las especificaciones de función correspondientes (no se muestran en los
dibujos).

FD2_{31} a FD2_{0} indican los segundos bloques de definición de función. Estos son bloques que definen los elementos individuales que constituyen la segunda función. Los contenidos de los mismos varían dependiendo de la función. Los detalles los controlan las especificaciones de función correspondientes.

De manera similar, FD3_{31} a FD3_{0} indican los terceros bloques de definición de función. Estos son bloques que definen los elementos individuales que constituyen la tercera función. Los contenidos de los mismos varían dependiendo de la función. Los detalles los controlan las especificaciones de función correspondientes.

Formato de datos de función y bloques de definición

A continuación, se describe el formato de datos y los bloques de definición para funciones. Esto muestra el formato de datos que se usa para intercambiar datos con un dispositivo periférico.

En primer lugar, los dispositivos periféricos (periféricos) se clasifican y diferencian según se muestra en la Tabla 13.

\vskip1.000000\baselineskip

TABLA 13 Tipos de Dispositivo Periférico

Tipo de dispositivo	Tipo de periférico	Ejemplos
Dispositivo base	Controlador	Controlador estándar,
		joystick, volante
	Otro	Teclado, ratón, arma
Dispositivo de expansión	Unidad de expansión	Entrada de sonido, arma,
		memoria de reserva

\vskip1.000000\baselineskip

Según muestra la tabla, un controlador de juego representa un dispositivo base típico. El tipo de función de un controlador de juego es "controlador", y se usa conectándolo a un puerto del servidor. El controlador de juego utiliza un formato de datos estándar seleccionado con lo cual se puede usar con múltiples aplicaciones. Los elementos funcionales de un sistema de controlador son los siguientes:

- Tecla digital A de mando:	Ra, La, Da, Ua
- Tecla digital B de mando:	Rb, Lb, Db, Ub
- Botones digitales:	A, B, C, D, X, Y, Z, START
- Tecla analógica:	A1, A2, A3, A4
- Palanca analógica:	A5, A6

Además, es una condición de los dispositivos periféricos de sistema de controlador que estén provistos de los siguientes elementos:

- Tecla digital A de dirección:	Ra, La, Da, Ua
- Botones digitales:	A, B, START

Otros tipos de dispositivos base

Estos y otros tipos comprenden dispositivos periféricos de un tipo de función diferente a la del controlador de juego. Ya que el contenido de los datos, el formato de los datos y el ciclo de lectura/escritura, etc., varían dependiendo del dispositivo periférico, cada dispositivo tiene un formato y librerías de datos correspondientes a sus funciones.

Dispositivos de expansión

Estos son dispositivos periféricos para expandir las funciones de los dispositivos base. Ya que el contenido y el formato de los datos, el ciclo de lectura/escritura, etc, varían dependiendo del dispositivo periférico, cada dispositivo tiene un formato y librerías de datos que se corresponden con sus funciones.

Funciones de tipo controlador

El tipo de función indica el formato de datos del controlador y el bloque de definición de ID del dispositivo.

En la Tabla 14 se muestra un formato de datos de lectura. El formato de datos de lectura es un formato que se usa para leer datos del controlador. El tamaño del formato de datos es de 8 bytes.

TABLA 14 Formato de lectura del controlador

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	Ra	La	Da	Ua	Start	A	B	C
2^{os} Datos	Rb	Lb	Db	Ub	D	X	Y	Z
3^{os} Datos	A1_{7}	A1_{6}	A1_{5}	A1_{4}	A1_{3}	A1_{2}	A1_{1}	A1_{0}
4^{os} Datos	A2_{7}	A2_{6}	A2_{5}	A2_{4}	A2_{3}	A2_{2}	A2_{1}	A2_{0}
5^{os} Datos	A3_{7}	A3_{6}	A3_{5}	A3_{4}	A3_{3}	A3_{2}	A3_{1}	A3_{0}
6^{os} Datos	A4_{7}	A4_{6}	A4_{5}	A4_{4}	A4_{3}	A4_{2}	A4_{1}	A4_{0}
7^{os} Datos	A5_{7}	A5_{6}	A5_{5}	A5_{4}	A5_{3}	A5_{2}	A5_{1}	A5_{0}
8^{os} Datos	A6_{7}	A6_{6}	A6_{5}	A6_{4}	A6_{3}	A6_{2}	A6_{1}	A6_{0}

\vskip1.000000\baselineskip

En esta tabla, los primeros datos son datos de los botones digitales (ON = "0", OFF = "1"), Los segundos son datos de los botones digitales (ON = "0", OFF = "1"). Los terceros son datos del eje analógico 1 (valor entre 00 h y FFh). Los cuartos datos son datos del eje analógico 2 (valor entre 00 h y FFh). Los quintos son datos del eje analógico 3 (valor entre 80 h y \pm 7F). Los sextos datos son datos del eje analógico 4 (valor entre 80 h y \pm 7F). Los séptimos son datos del eje analógico 5 (valor entre 80 h y \pm 7F). Los octavos datos son datos del eje analógico 6 (valor entre 80 h y \pm 7F).

Formato de datos de escritura

No hay formato para pasar datos de escritura al controlador. El tamaño de los datos es de 0 bytes. Si los datos se escriben, no hay respuesta.

Bloques de definición de función

Los bloques de definición FD para el controlador de juego indican funciones que se dividen en elementos empleados en el formato de lectura que se muestra en la Tabla 14. La Tabla 15 muestra un ejemplo de bloques de definición de función para un controlador de juego.

\vskip1.000000\baselineskip

TABLA 15 Composición de los Bloques FD de Definición de Función para un Controlador

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	RB_{15}	RB_{14}	RB_{13}	RB_{12}	RB_{11}	RB_{10}	RB_{9}	RB_{8}
2^{os} Datos	RB_{7}	RB_{6}	RB_{5}	RB_{4}	RB_{3}	RB_{2}	RB_{1}	RB_{0}
3^{os} Datos	0	0	0	0	0	0	0	0
4^{os} Datos	0	0	0	0	0	0	0	0

\vskip1.000000\baselineskip

En esta tabla, RB_{n} indica un bloque de formato de lectura particionado. La Tabla 16 muestra un ejemplo de una división de bloque.

TABLA 16 División del Bloque de Formato de Lectura del Controlador

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	Rb_{1}	RB_{0}
2^{os} Datos	RB_{9}	RB_{8}	RB_{7}	RB_{6}	RB_{5}	RB_{4}	RB_{3}	RB_{2}
3^{os} Datos	RB_{10}
4^{os} Datos	RB_{11}
5^{os} Datos	RB_{12}
6^{os} Datos	RB_{13}
7^{os} Datos	RB_{14}
8^{os} Datos	RB_{15}

Esta tabla corresponde a la Tabla 14, los bits de selección para los bloques que se han usado se fijan en "1" y para los bloques que no se han usado se fijan en "0". La librería de función ignora los bloques que no se han usado.

ID del dispositivo y formato de datos para un controlador estándar

La Tabla 17 muestra un ejemplo de ID de dispositivo para un controlador estándar. Este ejemplo se refiere a un ID de dispositivo para un controlador estándar que sólo tiene funciones de controlador.

TABLA 17 ID de Dispositivo para un Controlador Estándar

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	0	0	0	0	0	0	0	0
2^{os} Datos	0	0	0	0	0	0	0	0
3^{os} Datos	0	0	0	0	0	0	0	0
4^{os} Datos	0	0	0	0	0	0	0	1
5^{os} Datos	0	0	1	1	1	1	0	0
6^{os} Datos	0	0	0	1	1	1	1	1
7^{os} Datos	0	0	0	0	0	0	0	0
8^{os} Datos	0	0	0	0	0	0	0	0
9^{os} Datos	0	0	0	0	0	0	0	0
10^{os} Datos	0	0	0	0	0	0	0	0
11^{os} Datos	0	0	0	0	0	0	0	0
12^{os} Datos	0	0	0	0	0	0	0	0
13^{os} Datos	0	0	0	0	0	0	0	0
14^{os} Datos	0	0	0	0	0	0	0	0
15^{os} Datos	0	0	0	0	0	0	0	0
16^{os} Datos	0	0	0	0	0	0	0	0

El ID de dispositivo que se muestra en esta tabla comprende, en secuencia desde los primeros datos hasta los sextos: 00h-00h-00h-01h-3Ch-1Fh-00h-00h-00h- 00h-00h-00h-00h-00h-00h-00h.

La Tabla 18 muestra el formato de datos (formato de lectura) de un controlador estándar.

\vskip1.000000\baselineskip

TABLA 18 Formato de Lectura para un Controlador Estándar

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	Ra	La	Da	Ua	Start	A	B	C
2^{os} Datos	1	1	1	1	1	X	Y	Z
3^{os} Datos	A1_{7}	A1_{6}	A1_{5}	A1_{4}	A1_{3}	A1_{2}	A1_{1}	A1_{0}
4^{os} Datos	A2_{7}	A2_{6}	A2_{5}	A2_{4}	A2_{3}	A2_{2}	A2_{1}	A2_{0}
5^{os} Datos	A3_{7}	A3_{6}	A3_{5}	A3_{4}	A3_{3}	A3_{2}	A3_{1}	A3_{0}
6^{os} Datos	A4_{7}	A4_{6}	A4_{5}	A4_{4}	A4_{3}	A4_{2}	A4_{1}	A4_{0}
7^{os} Datos	1	0	0	0	0	0	0	0
8^{os} Datos	1	0	0	0	0	0	0	0

\vskip1.000000\baselineskip

No se espera ningún formato de escritura en un controlador estándar.

Función de tipo de almacenamiento

Una función del tipo de almacenamiento es un tipo de función para almacenar datos e indica los bloques de definición de función. La información diferente a las definiciones de función (capacidad total, etc.) se deduce mediante un comando Get Media Info.

El tipo de función es FT_{1} = 1, y el bloque de definición de función (almacenamiento) es como se muestra en la Tabla 19.

\vskip1.000000\baselineskip

TABLA 19 Composición de los Bloques de Definición de Función de Almacenamiento

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	PT_{7}	PT_{6}	PT_{5}	PT_{4}	PT_{3}	PT_{2}	PT_{1}	PT_{0}
2^{os} Datos	BB_{7}	BB_{6}	BB_{5}	BB_{4}	BB_{3}	BB_{2}	BB_{1}	BB_{0}
3^{os} Datos	WA_{7}	WA_{6}	WA_{5}	WA_{4}	RA_{3}	RA_{2}	RA_{1}	RA_{0}
4^{os} Datos	RM	FD_{6}	FD_{5}	FD_{4}	FD_{3}	FD_{2}	FD_{1}	FD_{0}

\vskip1.000000\baselineskip

En esta tabla, PT_{0} a PT_{7} representan números particionados. El número de particiones puede establecerse entre 1 y 256. Número de particiones = (PT + 1). BB_{0} a BB_{7} representan el número de bytes en 1 bloque. Estos se pueden establecer entre 32 bytes y 8.192 bytes. Número de bytes en un bloque = (BB + 1) x 32 (bytes). RA_{0} a RA_{3} representan el número de accesos de lectura en 1 bloque. Estos establecen el número de veces que se debe acceder para leer los datos en un bloque. El número de accesos se puede establecer entre 1 y 15. El volumen de datos para un acceso es el volumen de un bloque dividido a partes iguales por el número de accesos. Número de accesos = RA (veces), y volumen en un acceso = volumen de un bloque / RA (bytes). RA = 0 indica que no hay acceso de lectura. WA_{3} a WA_{0} representa el número de accesos de lectura en un bloque. Estos establecen el número de veces que se tiene que acceder para escribir los datos en un bloque. El número de accesos se puede establecer entre 1 y 15. El volumen de los datos para un acceso es el volumen de un bloque dividido a partes iguales por el número de accesos. Número de accesos = WA (veces), y volumen en un acceso = volumen de un bloque / WA (bytes). WA = 0 indica que no hay acceso de escritura. RM representa medios separables. Esto establece si los datos de almacenamiento de medios se pueden separar (FD o tarjetas de memoria flash, etc). Un ejemplo de selecciones de RM se muestra en la
Tabla 20.

\vskip1.000000\baselineskip

TABLA 20 Valores RM

Medios	RM
Fijos	0
Separables	1

\vskip1.000000\baselineskip

En la Tabla 19, FD_{6} a FD_{0} representan bits reservados. Un bit reservadoes un bit de selección que se reserva para un uso futuro. Normalmente, todos estos bits se fijan en "0".

Función tipo B/WLCD

Una función tipo B/WLCD indica una función de visualización en cristal líquido matricial de puntos monocromos, y un bloque de definición de función. La información que no sea la definición de función (resolución, etc.) se obtiene mediante un comando Get Media Info.

La función tipo FT2 = "1". Un bloque de definición de función tipo B/WLCD puede ser, por ejemplo, como se muestra en la Tabla 21.

\vskip1.000000\baselineskip

TABLA 21 Composición de Bloques de Definición de Función B/W LCD

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	PT_{7}	PT_{6}	PT_{5}	PT_{4}	PT_{3}	PT_{2}	PT_{1}	PT_{0}
2^{os} Datos	BB_{7}	BB_{6}	BB_{5}	BB_{4}	BB_{3}	BB_{2}	BB_{1}	BB_{0}
3^{os} Datos	WA_{3}	WA_{2}	WA_{1}	WA_{0}	0	0	0	0
4^{os} Datos	H/V	B/W	FD_{5}	FD_{4}	FD_{3}	FD_{2}	FD_{1}	FD_{0}

\vskip1.000000\baselineskip

En la Tabla 21, PT_{7} a PT_{0} representan números LCD. Estos se pueden establecer entre 1 y 256. Número LCD =
(PT + 1). BB_{7} a BB_{0} representan números de byte para la transferencia de un solo bloque. Estos se pueden establecer entre 32 bytes y 8.192 bytes. Número de bytes en un bloque = (BB + 1) x 32 (bytes). WA_{3} a WA_{0} representan números de accesos de escritura de un boque. Estos establecen el número de veces que se tiene que acceder para escribir un bloque de datos. El número de accesos se puede establecer entre 1 y 15. El volumen de datos para un acceso es el volumen de un bloque dividido en partes iguales por el número de accesos. Número de accesos = WA (veces), y volumen en un acceso = volumen de un bloque / WA (bytes). WA = 0 indica que no hay acceso de
escritura.

\newpage

H/V indica si una cadena de datos LCD es horizontal o vertical. Esto se muestra en la Tabla 22.

TABLA 22 Valor H/V

Secuencia de Datos	H/V
Horizontal	0
Vertical	1

En la Tabla 21, B/W indica si la visualización en cristal líquido es normalmente blanca o normalmente negra. Esto se muestra en la Tabla 23.

TABLA 23 Valor B/W

Normalmente	B/W
Negra	0
Blanca	1

Otras funciones

Los detalles del formato de datos y de los bloques de definición de función para funciones que no sean de tipo controlador se determinan mediante las especificaciones individuales para cada función (no se muestra en los dibujos).

Ejemplo de acceso real a un dispositivo periférico

Más adelante se describe un ejemplo de un método real para acceder a un dispositivo periférico.

Procesamiento después de la conexión

(1): El servidor confirma la región de destino, el nombre del producto, la licencia, el voltaje de funcionamiento, etc., que se dan en el comando Device Status que devuelve el dispositivo base, y comprueba si el dispositivo periférico es incompatible con la región de destino del servidor, que no soporta la aplicación o que no puede operar debido al hardware, etc. Si el dispositivo base no es compatible, el servidor ejecuta una reinicialización de hardware del dispositivo base, o controla el procesamiento para evitar que se acceda después al dispositivo base en cuestión.

(2): El servidor confirma el tipo de función del dispositivo base a partir de los datos dados en el Device Status. El servidor busca los bits más significativos de selección del tipo de función y demanda hasta tres de las librerías de función más significativas. Acto seguido, se preparan los datos necesarios para los bloques de definición de función.

(3): Si el servidor identifica a partir del valor del AP fuente que se ha conectado un dispositivo de expansión, transmite un Device Request a ese dispositivo de expansión y repite el proceso desde (1).

Acceso a las funciones

Después de conectarse, el servidor entra en comunicaciones con el dispositivo periférico, y accede a las funciones del dispositivo periférico. A continuación se describe esto mediante un ejemplo en el que el dispositivo periférico conectado al puerto A es un controlador (de juego) estándar.

(1): El servidor pide datos desde el controlador estándar. Se usa un comando Get Condition. Este comando necesita la condición física de la función que se va a transmitir de nuevo al servidor. El servidor pide las condiciones de los botones, teclas y palancas que pertenecen al controlador de juego. De manera deseable, el intervalo entre las transmisiones de comandos es, por ejemplo, 1 intervalo (INT), y un acceso más rápido que éste está prohibido. En la Tabla 24 se muestra un ejemplo de transmisión de datos enviados desde el servidor a un dispositivo periférico.

TABLA 24 Transmisión de Datos desde el servidor al Dispositivo Periférico

Orden de	Datos	Secuencia de	Descripción
transmisión		establecimiento
1^{os} Datos	Código de comando	09 h	Especifica ``Get Condition''
2^{os} Datos	AP destino	20 h	Especifica disp. en puerto A
3^{os} Datos	AP fuente	00 h	Transmite desde puerto A
4^{os} Datos	Tamaño de datos	01 h	Tamaño de Datos = 4 Bytes
5^{os} Datos	Tipo de función	00 h	Tipo de función indica "controlador"
6^{os} Datos		00 h
7^{os} Datos		00 h
8^{os} Datos		01 h

(2): Los datos se transmiten desde el controlador al servidor según el formato de datos. Se usa un comando Data Transfer. La Tabla 25 muestra un ejemplo de datos transmitidos desde un dispositivo periférico (controlador) al servidor.

TABLA 25 Transmisión de Datos desde el Dispositivo Periférico al Servidor

Orden de	Datos	Secuencia de	Descripción
transmisión		establecimiento
1ª	Código de comando	08 h	Especifica ``Data Transfer''
2ª	AP destino	00 h	Especifica puerto A
3ª	AP fuente	20 h	No dsp. expansión
4ª	Tamaño de datos	03 h	Tamaño de datos = 12 Bytes
5ª	Tipo de función	00 h	Tipo de función indica "controlador"
6ª		00 h
7ª		00 h
8ª		01 h
9ª	Formato de lectura	FFh	Los datos del
10ª		FFh	controlador se
11ª		00 h	almacenan según el
12ª		00 h	formato del
13ª		80 h	controlador. Los
14ª		80 h	bloques usados ya
15ª		80 h	se han descrito
16ª		80 h	mediante Device ID

El tipo de función almacena directamente el tipo transmitido por el servidor, y el formato de lectura se anexiona según el mismo. El formato de lectura del controlador comprende 8 bytes.

Procesamiento excepcional

Procesamiento excepcional se refiere a un proceso especial definido para dispositivos que no pueden controlar la transmisión y recepción de datos mediante comandos. Un ejemplo típico es un arma luminosa.

Arma Luminosa

(1): Si el servidor determina que el dispositivo periférico tiene el ID del dispositivo de un arma luminosa o de un arma de tiro empleada en un juego de tiro, éste cambia el bus M del modo normal al modo de ocupación SDCKB cuando se usa el arma luminosa. El cambio de modo no es posible desde el lado del dispositivo periférico. Si el servidor transmite un patrón de ocupación SDCKB (ver Figura 52) y el puerto cambia al patrón de ocupación SDCKB, entonces todos los dispositivos periféricos que están en ese puerto cambian al patrón de ocupación SDCKB y sólo pueden funcionar los dispositivos periféricos que operan en el patrón de ocupación SDCKB. Si múltiples dispositivos que tienen el ID de dispositivo de un arma luminosa se conectan a un puerto, el servidor indica entonces esto al usuario mediante un mensaje de aviso, o similar, e informa al usuario a través de la pantalla o mediante sonido para que reduzca el número de tales dispositivos conectados a un puerto.

(2): Con miras a hacer que vuelva el bus M desde el modo de ocupación SDCKB, el servidor dirige un proceso de cancelación. Cuando termina el modo de ocupación SDCKB, el bus M vuelve inmediatamente al modo normal.

(3): En el caso de un arma luminosa, el modo de ocupación SDCKB representa el periodo de tiempo tomado para 1 intervalo (INT) de escritura en pantalla menos el periodo de supresión vertical; dicho de otro modo, el periodo de tiempo durante el cual se dibuja la pantalla de TV. Cuando termina el periodo de tiempo en el que se dibuja la pantalla y comienza un periodo de blanqueo, el bus M cambia inmediatamente al modo normal, y otros dispositivos periféricos que están en ese puerto pueden transmitir y recibir datos.

(4): Para realizar la función de un arma luminosa, una sección que comprende un elemento fotorreceptor se toma como una función (también se puede usar un dispositivo de expansión), y una sección que comprende el gatillo, teclas direccionales, teclas analógicas, etc., se toma como una función diferente (también se puede usar un dispositivo de expansión). De este modo, se pueden evitar problemas usuales como, por ejemplo, deshabilitar las teclas de dirección cuando se usa el arma luminosa.

(5): En el modo de ocupación SDCKB, no se ejecuta ningún proceso Time Out.

Interfaz interna del servidor

A continuación se describe la interfaz entre el driver del bus M y el MIE del servidor (ver Figuras 46 y 63).

Resumen de la interfaz interna del servidor

El controlador periférico que mostrado en la Figura 63 comprende un conjunto de registro que consiste en múltiples registros dentro de una sección objeto 52a. En concreto, el controlador periférico comprende: un registro de dirección de tabla de instrucciones DMA de 32 bits; un registro de selección de gatillo DMA; un registro de habilitación DMA; un registro de puesta en marcha/estado DMA; un registro de control de sistema; un registro de estado; un registro de borrado de gatillo de hardware; un registro de protección de área de RAM de trabajo; y equivalentes.

Posteriormente se describe el funcionamiento básico de la interfaz periférica en el servidor. El controlador periférico carga datos de transmisión en la RAM de trabajo indicada mediante el registro de dirección de tabla de instrucciones DMA al FIFO de datos de transmisión en sincronismo con la V_BLANK (se puede establecer un retraso de la puesta en marcha en el registro de control del sistema). La RAM de trabajo se puede crear asignando un área particular de la memoria principal. Los datos de transmisión comprenden: instrucción + dirección de almacenamiento de datos de recepción + datos de salida.

La instrucción es un comando para el controlador periférico, y cuando ésta se completa, se establecen el puerto de salida, la longitud de los datos de transmisión, etc. Además, si no se completa, tan pronto como se vacía el FIFO de datos de transmisión, los datos de transmisión que están en la RAM de trabajo se cargan en el FIFO de datos de transmisión (que se realiza en unidades de 32 bits). Una dirección cabecera donde se almacenan los datos recibidos se establece en la dirección de almacenamiento de datos de recepción. Los datos de transferencia son los datos que realmente se transfieren al dispositivo periférico que controla el protocolo de aplicación (unidades de 4 bytes). Los datos de recepción procedentes del dispositivo periférico son unidades de 4 bytes, y en el momento en el que se llena el FIFO de datos de recepción (32 bytes), se transfieren sucesivamente al área de trabajo de la RAM indicada por la dirección de almacenamiento de datos de recepción. Aquí, incluso aunque el FIFO no esté lleno, tan pronto como termina la recepción, se transfiere obligatoriamente como 32 bytes (datos válidos + datos no válidos).

Además, si el dispositivo periférico genera un Time Out (por ejemplo 1 ms) debido a una desconexión, un fallo, etc., el ffff_ffffh de 32 bits se copia en la dirección de cabecera de almacenamiento de datos de recepción que corresponde a esa instrucción. Cuando se completa esta secuencia de operaciones, el controlador periférico detiene su operación, y refleja el estado del registro de puesta en marcha/estado DMA.

Mapa de registro Registro de dirección de tabla de instrucciones DMA

El registro de dirección de tabla de instrucciones DMA es un registro que se puede leer y escribir y que comprende 32 bits. Los elementos que lo forman son: un comando (instrucción) al controlador periférico; una dirección de almacenamiento de datos de recepción; y bits que indican una dirección de cabecera para el grupo de datos de transmisión (Ct_{31} a Ct_{5}).

Registro de selección de gatillo DMA

El registro de selección de gatillo DMA es un registro que se puede leer y escribir y que comprende 32 bits. El elemento que lo forma es un bit de selección (Ts) que nos dice si el gatillo de puesta en marcha de transmisión y recepción es una puesta en marcha de software o una puesta en marcha de hardware (V blank-out).

Registro de habilitación

El registro de habilitación es un registro que se puede leer y escribir y que comprende 32 bits. El elemento que lo forma es un bit de selección de habilitación y deshabilitación de transmisión/recepción (Tn). En el caso de un gatillo de software, se habilita este bit y comienza la transmisión o recepción estableciendo en "1" el bit de puesta en marcha DMA que se muestra en el registro de puesta en marcha/estado DMA. En el caso de un gatillo de hardware, se habilita este bit y comienza la transmisión y recepción tan pronto como se detecta el gatillo de hardware (V blank-out). Además, en el estado habilitado, es posible ejecutar una terminación obligatoria escribiendo "0".

Registro de puesta en marcha/estado DMA

El registro de puesta en marcha/estado DMA es un registro que se puede leer y escribir y que comprende 32 bits. El elemento que lo forma es un bit (Ss) para ejecutar una puesta en marcha de software para transmisión/recepción. Además, cuando se lee, se convierte en un registro de estado que indica el estado de transmisión/recepción. Sólo cuando se selecciona un gatillo de software como gatillo de puesta en marcha, es válido introducir "1", empezando así la transmisión.

Registro de control de sistema

El registro de control de sistema es un registro que se puede leer y escribir y que comprende 32 bits. Los elementos que lo forman son: bits de establecimiento de Time Out (TO_{15} a TO_{0}) procedentes de la transmisión de datos a un dispositivo periférico; un bit de selección (Si) para seleccionar si hay una puesta en marcha en cada V blank-out en el caso de un gatillo de hardware, o si se suspende la operación hasta que se borra la marca que está en el registro de borrado; bits de establecimiento de velocidad de transferencia (DC3 a DC0); bits de establecimiento de sincronización de puesta en marcha (Dt3 a Dt0) (retraso de establecimiento desde V blank-out) cuando hay una puesta en marcha hardware. Tiempo de establecimiento Time Out = 20 ns x To_{15} a To_{0}. Por ejemplo, se puede fijar en 300 \mus = 20 ns x 3a98. Si es un bit de establecimiento de repetición para una puesta en marcha automática. Cuando este bit es "0", se ejecuta una puesta en marcha en cada intervalo. Cuando es "1", la siguiente puesta en marcha no se ejecuta hasta que se borra la marca que está en el registro de borrado del gatillo de hardware. DC_{1} a DC_{0} indican los bits de establecimiento de velocidad de transferencia.

Registro de estado

El registro de estado es un registro de sólo lectura que comprende 32 bits. Los elementos que lo forman son: un bit (Do) que indica que el controlador periférico está funcionando (durante la transmisión/recepción); bits para monitorizar un contador de estado de bloque interno (St_{5} a St_{0}); y bits para monitorizar la línea de entrada/salida de cada puerto (La_{3} a La _{0}, Lb_{3} a Lb_{0}). Este registro se usa para buscar y corregir errores de hardware, y no para la aplicación.

Registro de borrado de gatillo hardware

El registro de borrado de gatillo hardware es un registro de sólo lectura que comprende 32 bits. El elemento que forma este registro es un bit de cancelación (Tc) para realizar una única parada automática de puesta en marcha de hardware en el controlador periférico. La parada automática se borra escribiendo "1" en este bit.

\newpage

Registro de protección del área RAM de trabajo

El registro de protección del área RAM de trabajo es un registro de sólo lectura que comprende 32 bits. Los elementos que forman este registro son bits que establecen: un código de seguridad de escritura de 16 bits; un rango de cabecero para la recepción de una dirección de almacenamiento de datos (Ha); y una dirección de terminación (Ta).

Registro de recuento de direcciones de datos de transmisión

El registro de recuento de direcciones de datos de transmisión es un registro de sólo lectura que comprende 32 bits. Los elementos que forman este registro indican un punto de dirección para transmitir datos que están en la RAM de trabajo, que lee el controlador periférico. Ya que este registro es para buscar y corregir errores, no lo usa la aplicación.

Registro de recuento de direcciones de datos de recepción

El registro de recuento de direcciones de datos de recepción es un registro de sólo lectura que comprende 32 bits. Los elementos que forman este registro indican un punto de dirección para recibir datos que están en la RAM de trabajo, que lee el controlador periférico. Ya que este registro es para buscar y corregir errores, no lo usa la aplicación.

Registro de dirección de base de datos de recepción

El registro de dirección de base de datos de recepción es un registro de sólo lectura que comprende 32 bits. Los elementos que forman este registro indican una dirección de cabecera para datos de recepción que están en la RAM de trabajo, escritos por el controlador periférico. Ya que este registro es para buscar y corregir errores, no lo usa la aplicación.

Datos de transmisión

A continuación se describen datos de transmisión. Una unidad de datos de transmisión comprende: una instrucción, una dirección de almacenamiento de datos de recepción y datos de salida. Ya que estos datos se almacenan en la RAM de trabajo como: instrucción + dirección de almacenamiento de datos de recepción + datos de salida + instrucción + dirección de almacenamiento de datos de recepción + datos de salida..., el controlador periférico los ejecuta en secuencia.

Instrucciones

Una instrucción comprende 32 bits de datos que se suministran a un controlador periférico mediante el programa de aplicación para controlar el controlador periférico. Los elementos que la forman son: un bit de fin que indica el final de la instrucción en curso; bits de selección de puerto activo (Po_{1} a Po_{0}) para transmitir y recibir; bits de selección de patrón (Pn_{2} a Pn_{0}); y bits de selección de longitud de datos de salida (Ln_{8} a Ln_{0}). Cuando el controlador periférico detecta que el bit Ef es "1", termina el procesamiento para esa instrucción (el comando final en los datos de transmisión debe ser siempre para fijar el bit Ef en "1"). Además, si el controlador periférico detecta que el bit Ef es "0", ejecuta la siguiente instrucción. Cuando se selecciona "START" en los bits de selección de patrón se emiten los datos de salida. Cuando se selecciona otro patrón (ocupación SDCKB permitida, RESET, ocupación SDCKB cancelada) sólo es valida la emisión de un modelo de información en el puerto, y se invalida la especificación de la longitud de datos de salida. Cuando se selecciona un patrón de permiso de ocupación SDCKB, el bit Ef que está en esa instrucción debe fijarse en "1". Se invalida la ejecución de cualquier instrucción posterior a excepción del modelo de cancelación de ocupación SDCKB.

Además, durante la ocupación SDCKB, el controlador periférico emite a los terminales negativos que ha introducido la línea SDCKB como señales de bloqueo del contador HV. El bit de selección de longitud de datos de salida Ln se puede fijar, por ejemplo, en hasta 1.024 bytes, en unidades de 4 bytes.

Dirección de almacenamiento de datos de recepción

La dirección de almacenamiento de datos de recepción es un bit de selección (Ra) para que la dirección de cabecera almacene los datos de recepción.

Datos de salida

Los datos de salida son aquellos que realmente se transmiten al dispositivo periférico. La longitud de los datos de salida debe ser igual que la longitud de los datos de salida que se ha establecido mediante la instrucción mencionada (unidades de 32 bits).

Registro de interrupción

El registro de interrupción no se encuentra en esta interfaz. En vez de esto, se conectan seis señales desde la interfaz a un bloque de interrupción. Una interrupción se produce, por ejemplo, cuando se completa la transmisión o recepción (conclusión DMA), cuando la operación de transmisión o recepción (DMA) se prolonga hasta V BLANK IN, cuando la recepción FIFO está llena y se busca copiar más datos en el FIFO de recepción, cuando hay una selección o puesta en marcha fuera de la región de protección de la dirección de la tabla de instrucciones DMA, y cuando hay una operación de búsqueda de instrucciones ilegales, y similares.

Registro de contador HV

El registro de contador HV en el modo de arma luminosa no se encuentra en esta interfaz. En vez de esto, se conecta cualquier señal de bloqueo HV desde la interfaz a un bloque de dibujo. La aplicación lee el valor del contador HV en el bloque de dibujo durante V BLANK.

Secuencia de transmisión/recepción

A continuación se describe la secuencia de transmisión/recepción. La secuencia de transmisión/recepción comprende una secuencia normal y un procedimiento de ocupación SDCKB, como se describe después.

Secuencia normal

Un ejemplo de secuencia normal se muestra en la Figura 61. Este diagrama ilustra la transmisión y recepción de datos entre la CPU del servidor y el controlador periférico, como se muestran en la Figura 63 descrita en detalle después, y los dispositivos periféricos A y B que se ilustran en la Figura 64.

En la Figura 61, la CPU del servidor determina si un dispositivo periférico está conectado a cualquiera de sus puertos e identifica los APs destino para los dispositivos periféricos relevantes mediante la operación de establecimiento de AP mencionada. Acto seguido, deduce los detalles de cada dispositivo periférico transmitiendo un Device Request a los dispositivos periféricos y recibiendo las respuestas correspondientes. Después, por ejemplo, la CPU selecciona datos de transmisión que están en la RAM de trabajo para la operación DMA, con el fin de controlar las comunicaciones de datos con el dispositivo periférico A en respuesta a una petición de la aplicación, o equivalente, y se ejecutan varias operaciones de establecimiento de instrucciones, etc en los registros que están en la sección objeto 52a del controlador periférico. Estas instrucciones son comandos que se suministran al controlador periférico y establecen el final de una instrucción, el puerto de salida, la longitud de los datos de salida y similares. Además, si no se indica el final de una instrucción, los datos de transmisión que están en la RAM de trabajo se continúan cargando en el FIFO de transmisión 53a, tan pronto como se vacía el FIFO de transmisión 53a. La operación de carga se realiza, por ejemplo, en unidades de 32 bytes.

El controlador periférico carga los datos de transmisión en la RAM de trabajo indicada por el registro de dirección de tabla de instrucciones DMA al FIFO de transmisión 53a en sincronismo con la aparición de la señal V BLANK, por ejemplo en la señal visual que aparece (final del periodo de borrado). Como se ha explicado antes, se puede establecer un retraso en la puesta en marcha mediante un registro de control de sistema. El controlador periférico crea datos de transmisión en el formato del frame ilustrado en la Figura 48 en base a las instrucciones y datos de salida de la CPU y envía estos datos de transmisión al bus M del puerto relevante.

El dispositivo periférico A monitoriza continuamente la señal de los datos en el bus M. Cuando confirma que el AP destino de los datos de transmisión coincide con su propia dirección (AP), lee estos datos de transmisión. El dispositivo periférico A ejecuta después un procesamiento que corresponde al comando, y crea datos de respuesta en un formato preseleccionado de frame, que envía al bus M.

Cuando el controlador periférico recibe los datos del dispositivo periférico A, los coloca primeramente en un FIFO de recepción 56b, y después los transfiere a la RAM de trabajo para la operación DMA. Los datos recibidos desde el dispositivo periférico están, por ejemplo, en unidades de 4 bytes y tan pronto como se llena el FIFO de recepción 56b (32 bytes), los datos se transfieren a la RAM de trabajo indicada por la dirección de almacenamiento de datos de recepción.

Sin embargo, aunque el FIFO de recepción 56b no se llene, tan pronto como termine la recepción, los datos se transfieren obligatoriamente como 32 bytes (datos válidos + datos no válidos). Después, se leen los datos que permanecen en la RAM de trabajo y que se va a transmitir al dispositivo periférico B, se colocan en el FIFO de datos de transmisión 53a y se organizan en datos de transmisión que se envían al dispositivo periférico B. Después se transmiten al bus M del puerto al que está conectado el dispositivo periférico B.

De manera similar al dispositivo periférico A, el dispositivo periférico B monitoriza continuamente la señal de los datos en el bus M. Cuando confirma que el AP destino de los datos de transmisión coincide con su propia dirección (AP), lee estos datos de transmisión. El dispositivo periférico B ejecuta después un procesamiento que corresponde al comando, y crea datos de respuesta en un formato preseleccionado de unidad de información, que envía al bus M.

Cuando el controlador periférico recibe los datos del dispositivo periférico B, los coloca primeramente en un FIFO de recepción 56b, y después los transfiere a la RAM de trabajo para la operación DMA.

La CPU lee el estado del controlador periférico en sincronismo con la desaparición de la señal V BLANK que está en la señal de vídeo suministrada (comienzo del periodo de borrado). Por tanto, se puede identificar la presencia de datos procedentes de un dispositivo periférico. Después lee los datos de recepción almacenados procedentes de un área relevante de la RAM de trabajo, y suministra estos datos a la aplicación.

Las comunicaciones de datos entre el servidor y los dispositivos periféricos se controlan repitiendo este procedimiento. Cuando termina una secuencia de operaciones, el controlador periférico detiene la operación, e indica su estado al registro de puesta en marcha/estado DMA.

Si el dispositivo periférico genera un Time Out (por ejemplo 1 ms) debido a una desconexión, un fallo, etc, el controlador periférico copia un ffff_ffffh de 32 bits en el registro de dirección de cabecera de almacenamiento de datos de recepción correspondiente a esa instrucción. Si se produce un error de paridad, se copia un ffff_ff00h de 32 bits. La CPU ejecuta un proceso que se corresponde con esto.

Procedimiento de ocupación SDCKB (arma luminosa)

A continuación se describe el procedimiento de ocupación SDCKB con referencia a la Figura 62. El procedimiento de ocupación SDCKB se usa, por ejemplo, para las comunicaciones de datos entre el servidor y un arma luminosa que constituye un dispositivo periférico en un juego de tiro. Como se ha explicado antes, la CPU determina si un dispositivo periférico está o no conectado a cualquiera de sus puertos e identifica los APs destino de los dispositivos periféricos relevantes mediante la operación de establecimiento de AP mencionada. Entonces deduce los detalles de los dispositivos periféricos transmitiendo un Device Request a cada dispositivo periférico y recibiendo sus respuestas correspondientes. La CPU, por ejemplo, selecciona los datos de transmisión que están en la RAM de trabajo mediante una operación DMA con el fin de establecer comunicaciones de datos con el arma luminosa en respuesta a una petición de la aplicación del juego de tiro, y lleva a cabo varias operaciones de selección para instrucciones, etc, en registros que están en la sección objeto 52 del controlador periférico.

Por ejemplo, si una aplicación de juego de arma pide una ocupación SDCKB a la CPU, la CPU cambia la operación del puerto de modo normal a modo de ocupación SDCKB. Mediante los comandos mencionados, los datos de transmisión que contienen el puerto seleccionado y el permiso de ocupación SDCKB se escriben en la RAM de trabajo. La dirección de datos en la RAM de trabajo se copia en el registro de dirección de tabla de comandos DMA.

El controlador periférico carga los datos de transmisión de la RAM de trabajo indicada por el registro de dirección de tabla de comandos DMA en el FIFO de los datos de transmisión 53a en sincronismo con la aparición de la señal V BLANK, por ejemplo, en la señal de vídeo suministrada. El controlador periférico lee después los comandos y datos de la RAM de trabajo, crea un patrón de permiso de ocupación SDCKB del formato ilustrado en la Figura 52 y transmite esto al bus M del puerto relevante.

El dispositivo periférico A monitoriza continuamente la señal de datos en el bus M. Al recibir el patrón de permiso de ocupación SDCKB, el dispositivo periférico A puede transmitir su salida al bus M con la sincronización deseada. Si el usuario manipula (aprieta el gatillo) del dispositivo periférico A (arma luminosa), el dispositivo periférico A (arma luminosa) transmite una señal de disparo al bus M.

Cuando el dispositivo periférico recibe los datos de la señal de disparo del dispositivo periférico A, éste emite una señal del bloqueo al contador HV (se omite en los dibujos). El contador HV cuenta los valores que corresponden a la posición del punto de iluminación que se escanea en la pantalla de vídeo. A partir de los valores del contador HV bloqueado, es posible identificar el punto de mira del dispositivo periférico A (arma luminosa) en la pantalla cuando se aprieta el gatillo.

Si el dispositivo periférico es un arma luminosa, la CPU asigna el periodo de dibujado de la pantalla de vídeo de 1 intervalo de la señal visual que se suministra como un periodo de ocupación SDCKB. Después, cuando termina el periodo de dibujado y desaparece la señal V BLANK (comienzo del periodo de borrado), la CPU cancela el modo de ocupación SDCKB y cambia la operación del puerto relevante del modo de ocupación SDCKB al modo normal. Para este fin, la CPU escribe los datos de transmisión que contienen el puerto seleccionado y la cancelación de ocupación SDCKB en la RAM de trabajo mediante los comandos mencionados. La dirección de los datos de la RAM de trabajo se copia en el registro de dirección de la tabla de comandos DMA.

El controlador periférico carga inmediatamente los datos de transmisión en la RAM de trabajo indicada por el registro de dirección de la tabla de comandos DMA en el FIFO de transmisión. El controlador periférico lee los comandos y los datos procedentes de la RAM de trabajo, crea un patrón de cancelación de permiso de ocupación SDCKB y transmite esto al bus M del puerto relevante. El dispositivo periférico A monitoriza continuamente la señal de los datos en el bus M. Si recibe un patrón de cancelación de ocupación SDCKB, el dispositivo periférico A cancela su estado habilitado de salida.

De esta manera, el modo de ocupación SDCKB ocupa el periodo durante el cual se dibuja la pantalla de vídeo en 1 intervalo de la señal de vídeo. Por tanto, incluso aunque se use un dispositivo periférico que produce una información de salida aleatoria, por ejemplo un arma luminosa, es todavía posible usar otros dispositivo periféricos conectados al mismo bus M.

Método de selección de registro

A continuación, se describen ejemplos de selección de registro en el caso de una puesta en marcha software y una puesta en marcha hardware (puesta en marcha automática en cada disparo).

En una puesta en marcha software, se establecen los valores de registro definidos en los siguientes casos.

Inicialización

1. Selección de registro de protección de área RAM de trabajo

2. Selección de registro de control de sistema

3. Selección de registro de selección de disparo DMA

Procedimiento de ejecución

4. Selección de datos de la RAM de trabajo (tabla de comandos DMA)

5. Selección de registro de dirección de tabla de comandos DMA

6. Selección de registro permitido DMA

7. Selección de registro de puesta en marcha/estado DMA

Comprobación de finalización

8. Confirmación de puesta en marcha/estado DMA

9. Interrupción de datos de recepción en la RAM de trabajo

En una puesta en marcha hardware (puesta en marcha automática en cada disparo), los valores de registro definidos se establecen en los siguientes casos.

Inicialización

1. Selección de registro de protección de área RAM de trabajo

2. Selección de registro de control de sistema

3. Selección de registro de selección de disparo DMA

Procedimiento de ejecución

4. Selección de datos de la RAM de trabajo (tabla de comandos DMA)

5. Selección de registro de dirección de tabla de comandos DMA

6. Selección de registro permitido DMA

7. Selección de registro de puesta en marcha/estado DMA

Comprobación de finalización

8. Confirmación de puesta en marcha/estado DMA

9. Interrupción de datos de recepción en la RAM de trabajo

Diagrama de bloques del MIE del servidor

La Figura 63 es un diagrama de bloques que muestra la composición aproximada de un controlador periférico (MIE) 1h en un servidor. En este diagrama, a las secciones que corresponden a la Figura 21 se les ha asignado el mismo símbolo.

En la Figura 63, una sección iniciadora 50 realiza el papel de un bus master para acceder a la RAM de trabajo, cuando el controlador periférico 1h ha asumido un estado de operativo. Ésta lee los datos que se van a transmitir a un dispositivo periférico desde la RAM de trabajo y escribe los datos recibidos desde el dispositivo periférico en la RAM de trabajo. Un divisor de reloj 51 es un circuito de división de reloj para seleccionar la velocidad de transferencia de bits (velocidad de transferencia) de los datos de transmisión. La sección objeto 52a es un bloque que opera como un objeto en el bus de ruta, y la forma la CPU del servidor mediante el grupo mencionado de registros de 32 bits que se pueden leer y escribir. En esta sección se copian fundamentalmente instrucciones o similares. Un registro temporal de datos de transmisión 53b es un registro para almacenar 32 bits de datos de transmisión procedentes del FIFO de datos de transmisión de 3 bytes 53a. El FIFO de datos de transmisión 53a es un registro FIFO de 32 bytes (First In First Out) para almacenar temporalmente datos de transmisión. El FIFO de datos de recepción 56b es un registro FIFO de datos de recepción de 32 bytes. El registro temporal de datos de recepción 56a es un registro para almacenar datos de recepción de 32 bits. En cuanto termina la recepción de datos, éstos se escriben en el FIFO de datos de recepción 56b. Una sección de control de señal de interrupción 54 genera una señal de interrupción de un pulso de reloj que se envía a una sección de interrupción bajo determinadas condiciones. Un controlador de unidad de información 58 es un bloque que controla el frame de transmisión (patrón de puesta en marcha, de fin, etc) en base a las instrucciones y similares. Un codificador de frames 59 es un bloque para crear un patrón de frame. Un registro de desplazamientos alternos (paralelo/serie) 60 es un circuito para transformar, de manera alterna, datos de transmisión paralelos en dos líneas en serie. Además, el registro de desplazamientos alternos 60 realiza un cálculo de paridad para los datos de transmisión y añade los datos de paridad (por ejemplo un byte de bits de paridad) al final de los datos de transmisión. Un descodificador de frame 61 es un circuito para analizar un frame de la señal de recepción. Un registro de desplazamientos alternos (serie/paralelo) 62 es un circuito para transformar, de manera alterna, los datos recibidos de dos líneas en serie en datos paralelos. Además, el registro de desplazamientos alternos realiza un cálculo de paridad para los datos de recepción. Los resultados de este cálculo se comparan con los datos de paridad recibidos para determinar si hay o no un error. Si hay un error, se envía una notificación al controlador de interrupción de la CPU vía la sección de control de señal de interrupción 54. De ese modo, la CPU puede controlar un proceso de error emitiendo un comando de retransmisión o similar. Un controlador de señal de bloqueo HV 63 es un circuito para transferir una señal de bloqueo HV desde las líneas en serie a un contador HV que está en una sección del procesador de dibujo (sección de generación de señales visuales) 1f. El controlador de puerto 57 controla el puerto activo que se refiere al proceso de transmisión/recepción. Dicho de otro modo, el búfer de tres estados 68a a 68h del puerto de transmisión seleccionado mediante la instrucción se controla de manera que las salidas SDCKA y SDCKB de los selectores 64 y 65 se dirigen al puerto seleccionado. El selector 64 se controla mediante el controlador de frame 58, y forma una señal SDCKA seleccionado la salida del codificador de frame 59 o la salida del registro de desplazamientos alternos 60, y emite esta señal a una línea de bus M vía el búfer de tres estados seleccionado 68. El selector 65 se controla mediante el controlador de frame 58, y forma una señal SDCKB seleccionando la salida del codificador de unidad de información 59 o la salida del registro de desplazamientos alternos 60, y emite esta señal a una línea de bus M vía el búfer de tres estados seleccionado 68. El selector 66 selecciona un puerto de recepción de acuerdo con los comandos procedentes del controlador de puerto 57, y suministra una señal de recepción SDCKA, que ha atravesado un búfer amplificador 69, al descodificador de frame 61 y al registro de desplazamientos alternos 62. El selector 67 selecciona un puerto de recepción de acuerdo con los comandos procedentes del controlador de puerto 57, y suministra una señal de recepción SDCKA, que ha atravesado un búfer amplificador 69, al descodificador de frame 61 y al registro de desplazamientos alternos 62.

Interfaz interna del dispositivo periférico

La Figura 64 es un diagrama de circuitos en bloque que muestra una ilustración aproximada de la composición de los circuitos de un dispositivo periférico que es un dispositivo base. Además, la Figura 65 es un diagrama de circuitos en bloque que muestra una ilustración más detallada de la interfaz (MIE del dispositivo base) entre la sección de control de socket 203 y la sección de procesamiento de comunicaciones 204 que se muestran en la Figura 64. En estos ejemplos, para simplificar la descripción (ilustración), sólo se representan dos sockets de expansión externos, aunque en realidad, se pueden proporcionar cuatro sockets de expansión externos.

El bloque de CPU 201 realiza las funciones de control del dispositivo base, por ejemplo crear los datos de transmisión que incluyen la información de la operación de entrada, y procesar datos de respuesta para hacer las peticiones correspondientes desde el servidor 1. Esto también incluye operaciones de inicialización, por ejemplo establecer los APs de dispositivo y los APs de los dispositivos de expansión durante la instalación, como se ha descrito antes. El bloque I/O 202 transforma información de funcionamiento del medio de entrada a una señal de datos. Si el dispositivo base 2 es un mando de control de un dispositivo de juego, entonces múltiples botones digitales y claves analógicas, etc corresponden al medio de entrada. Además, el bloque I/O 202 indica un número de bus LM conectado a los dispositivos de expansión vía los terminales ID0 e ID1 de cada socket de expansión, de acuerdo con la salida de la CPU. El papel de los terminales ID0 e ID1 se ha descrito antes en el procedimiento de establecimiento de APs para los dispositivos de expansión, con referencia a la Figura 59. El bloque de control de socket 203 determina la presencia o ausencia de una conexión de dispositivo de expansión en cada socket de expansión. Acto seguido, las líneas de transmisión de datos SDCKA y SDCKB suministradas al dispositivo mediante el servidor se conectan respectivamente a las líneas de transmisión de datos SDCKA y SDCKB del bus LM, mediante los búfers de tres estados, a los sockets de expansión a los que están conectados los dispositivos de expansión. Por tanto, viendo el bus M desde el servidor 1, esto equivale a conectar múltiples dispositivos periféricos (dispositivos base y dispositivos de expansión) al bus M en paralelo. El bloque de procesamiento de comunicaciones 204 realiza descodifica los datos de recepción y codificación los datos de salida procedentes de la CPU, y equivalentes. El bloque de la CPU 201 y el bloque de procesamiento de comunicaciones 204 se pueden constituir como un único chip
integrado.

La sección de procesamiento de comunicaciones 204 realiza las funciones de desmodular frames recibidas desde el servidor y framing (descodificar) datos de transmisión emitidos por la sección de CPU 201. La sección de procesamiento de comunicaciones 204 y la sección de control de socket 203 juntas forman los componentes principales del MIE (interfaz de entrada/salida).

La señal SDCKA (señal corriente abajo) emitida por el servidor al bus M se suministra a la sección de procesamiento de comunicaciones 204 vía el búfer amplificador 212a. Además, la señal SDCKA, al haber pasado por el búfer amplificador 212a, forma una señal SDCKADS-1 y una señal SDCKADS-2 vía los búfers de tres estados correspondientes 215a y 215b, que se suministran a los buses LM 1 y 2.

La señal SDCKB (señal corriente abajo) emitida por el servidor al bus M se suministra a la sección de procesamiento de comunicaciones 204 vía el búfer amplificador 212b. Además, la señal SDCKB, al haber pasado por el búfer amplificador 212b, forma una señal SDCKBDS-1 y una señal SDCKBDS-2 vía los búfers de tres estados correspondientes 216a y 216b, que se suministran a los buses LM 1 y 2.

Por otro lado, la señal SDCKA (corriente arriba) que va al servidor emitida por la sección de procesamiento de comunicaciones de dispositivo 204 se emite vía (el primer terminal de) una puerta OR 214a y un búfer de tres estados 211a a la línea de datos del bus M SDCKA, donde es recibida por el MIE del servidor. Además, una señal SDCKB que va al servidor emitida por la sección de procesamiento de comunicaciones 204 vía (el primer terminal de) una puerta OR 214b y un búfer de tres estados 211b a la línea de datos del bus M SDCKB, donde es recibida por el MIE del servidor. Cuando la sección de procesamiento de comunicaciones 204 transmite una señal SDCKA o SDCKB, se habilita una señal al terminal de control del búfer de tres estados 211a vía (el primer terminal de) una puerta OR 213a para abrir la puerta 211a (conectarla), y se habilita una señal al terminal de control del búfer de tres estados 211a vía (el primer terminal de) una puerta OR 213b para abrir la puerta 211b. Los terminales de entrada correspondientes de las tres puertas OR de entrada 213a y 213b se conectan a tierra vía una resistencia. Si no se emite una señal de entrada a un terminal de entrada, ese terminal de entrada permanece a nivel del suelo. Además, los terminales de entrada correspondientes de las tres puertas OR de entrada 214a y 214b se conectan a una fuente de alimentación Vcc vía una resistencia. Por tanto, los terminales de entrada a los que no se les envía ninguna señal de entrada se mantienen en el nivel "H".

Una señal SDCKA emitida por el primer dispositivo de expansión al bus LM 1 se emite a la línea de transmisión de datos SDCKA del bus M vía el terminal SDCKAUS-1 del socket de expansión 1, la (segundo terminal de entrada de) puerta OR 214a y el búfer de tres estados 211a. Una señal SDCKB emitida por el primer dispositivo de expansión al bus LM 1 se emite a la línea de transmisión de datos SDCKA del bus M vía el terminal SDCKBUS-1 del socket de expansión 1, la (segundo terminal de entrada de) puerta OR 214b y el búfer de tres estados 211b. Cuando el primer dispositivo de expansión transmite una señal SDCKA o SDCKB suministra una señal de habilitación al terminal de control del búfer de tres estados 211a, vía la línea de transmisión de señales del bus LM 1 SDCKAEN1 y la (segundo terminal de entrada de) puerta OR 213a, para abrir la puerta 211a. Además, suministra una señal de habilitar al terminal de control del búfer de tres estados 211b, vía la línea de transmisión de señales del bus LM 1 SDCKAEN1 y la (segundo terminal de entrada de) puerta OR 213b, para abrir la puerta 211b.

De manera similar, una señal SDCKA emitida por el segundo dispositivo de expansión al bus LM se emite a la línea de transmisión de datos SDCKA del bus M vía el terminal SDCKAUS-2 del socket de expansión 2, la (tercer terminal de entrada de) puerta OR 214a y el búfer de tres estados 211a. Una señal SDCKB emitida por el segundo dispositivo de expansión al bus LM se emite a la línea de transmisión de datos SDCKB del bus M vía el borne SDCKBUS-2 del socket de expansión 2, la (tercer terminal de entrada de) puerta OR 214b y el búfer de tres estados 211b. Cuando el segundo dispositivo de expansión transmite una señal SDCKA o SDCKB, suministra una señal de habilitar el terminal de control del búfer de tres estados 211a, vía la línea de transmisión de señales del bus LM 2 SDCKAEN2 y la (tercer terminal de entrada de) puerta OR 213a, para abrir la puerta 211a. Además, suministra una señal de habilitar al terminal de control del búfer de tres estados 211b, vía la línea de transmisión de señales del bus LM 2 SDCKAEN2 y la (tercer terminal de entrada de) puerta OR 213b, para abrir la puerta 211b.

Se suministra una fuente de alimentación operativa al dispositivo base desde el servidor mediante la líneas de transporte de energía Vcc y GND del bus M. El suministro de energía a los dispositivos de expansión lo realiza el dispositivo base vía las líneas de energía Vcc y GND de los buses LM. Como se muestra en la Figura 65, la sección de control de socket 203 está constituida por un controlador de bus LM 203a. El controlador de bus LM monitoriza el voltaje de un terminal determinado proporcionado para comprobar las conexiones que hay en los sockets de expansión. En este ejemplo, se monitoriza el voltaje de la clavija o pin ID2 de los sockets de expansión. En el lado del dispositivo base, el pin ID2 se conecta a la toma de tierra GND del dispositivo base vía una resistencia R. Como se muestra en la Figura 66, cuando un dispositivo de expansión se conecta a un socket de expansión, la fuente de alimentación Vcc y el GND se suministran al dispositivo de expansión 3 vía los terminales Vcc y GND del socket de expansión. Este suministro de energía Vcc en el lado del dispositivo de expansión se aplica vía el terminal ID2 del socket de expansión del dispositivo base a la resistencia R. El controlador de bus LM 203a determina si se conecta o no un dispositivo de expansión a un socket según la presencia o ausencia (o magnitud) del voltaje que se genera en la resistencia R. El controlador de bus LM 203a indica la conexión o no conexión de un dispositivo de expansión en cada bus LM con un registro de control 204a.

\newpage

El controlador del bus LM 203a también abre la puerta de los búfers de tres estados del bus LM del socket de expansión al que está conectado el dispositivo de expansión, y conecta respectivamente las líneas de datos SDCKA y SDCKB del bus M a las líneas de datos SDCKADS y SDCKBDS del bus M. El controlador del bus LM 302a puede controlar la activación de los buses del conector de expansión independientemente de la operación de otras secciones, aunque también es posible hacer que esto dependa del juicio de la CPU. En concreto, el controlador del bus LM 203a detecta la conexión de un dispositivo de expansión y establece una salida de detección en el registro de control 204a. La CPU 201 identifica la conexión de un dispositivo de expansión con un bus LM monitorizando el registro de control 204a. Si la CPU 201 permite la conexión del dispositivo de expansión, establece una marca LMC ordenando la conexión del bus LM relevante del registro de control 204a. El controlador de bus LM 203a abre (conecta) el búfer de tres estados 215, 216 del bus LM que corresponde a la marca LMC. Mediante estas operaciones, como se muestra en la Figura 47, cuando se conecta un dispositivo de expansión a un dispositivo base, el dispositivo base reconoce automáticamente la conexión del dispositivo de expansión y lo conecta al bus M.

El bloque de procesamiento de comunicaciones 204 comprende: un registro de control 204a; un registro de paridad 204b; un controlador de frame 204c; un monitor de línea 204d; un codificador de frames 204e; un registro de desplazamientos alternos P/S 204f: un registro temporal 204g; un descodificador de frames 204h; un registro de desplazamientos alternos S/P 204i; un búfer de transmisión/recepción 204j; y un registro de longitud de datos 204k.

El registro de control 204a es un registro para almacenar varias marcas, etc, con el fin de controlar los datos de transmisión y recepción. Estas diversas marcas se describen después con referencia a la Tabla 26. El registro de paridad 204b es un tabla en búfer para cálculos de paridad y cálculos que se refieren a la conversión serie/paralelo y paralelo/serie. El búfer de transmisión y recepción 204j es un registro para almacenar datos que se han empleado en la transmisión y recepción de datos. El controlador de frame 204c controla la transmisión y recepción de frames monitorizando las diferentes marcas que hay en el registro de control 204a. Además, también establece las marcas relevantes en el registro de control 204a en respuesta a la detección de un patrón de puesta en marcha, de fin, de ocupación SDCKB, de reinicialización o similar. El codificador de frames 204e genera frames agregando secciones de patrones a los datos. El registro de desplazamientos alternos P/S 204f realiza una conversión paralelo/serie para transformar datos paralelos en datos serie. El monitor de líneas 204d monitoriza las líneas de señales SDCKA y SDCKB. El registro de longitud de datos 204k indica el tamaño de los datos de transmisión cuando transmite.

La interfaz con el MIE vista desde la sección de la CPU 201 del dispositivo periférico comprende: 21 marcas de control (CFLAG), un registro de longitud de datos (LREG) 204k y un búfer de transmisión y recepción máximo de 1.024 bytes. La capacidad del búfer de transmisión y recepción se optimiza para que se adapte al dispositivo.

Se describe después la interfaz entre el controlador del MIE (CPU 201) y el MIE del dispositivo base (control de socket 203, procesador de transmisión 204) según la composición anterior.

Los datos de los frames transmitidos desde el servidor vía las líneas de datos SDCKA y SDCKB son recibidos por el descodificador de frames 204h. El descodificador frames 204h desmodula los datos frame procedentes de las señales SDCKA y SDCKB y separa las secciones de patrón y datos de los datos frame. Cuando el descodificador de frames 204h detecta secciones de patrones, por ejemplo un patrón de puesta en marcha, de fin, de ocupación SDCKB, reinicialización o similar, transfiere la información detectada en esa sección de patrones al controlador de frame 204c. El controlador de frame 204c, además de controlar la operación de recepción, también establece marcas en el registro de control que corresponden a la detección del patrón. Estas marcas incluyen: una marca de recepción RXB; una marca completa de recepción RFB; una marca de modo de ocupación SDCKB POS; y una marca de recepción de patrón de reinicialización HRES.

Las secciones de datos separados se transfieren al registro de desplazamientos alternos 204i. El registro de desplazamientos 204i tiene una función de conversión de datos serie/paralelo, y transforma las señales de datos en serie separadas en datos paralelos, que envía a un registro temporal 204g. El registro temporal 204g ejecuta un cálculo de control de paridad para los datos recibidos. También extrae la sección de bits de paridad desde los datos recibidos y los almacena en un registro de paridad 204b. El resultado de la comprobación de paridad se compara con los bits de paridad del registro de paridad 204b, y si se detecta un error, se establece una marca de error de paridad PERR en el registro de control 204a. Los datos de control de error se almacenan entonces en el búfer de transmisión y recepción 204j. Si el volumen de los datos de recepción sobrepasa la capacidad del búfer de transmisión y recepción 204j, se establece una marca de overflow (desbordamiento) de capacidad de búfer BFOV en el registro de control 204a. Los datos de overflow no se almacenan en el búfer de transmisión y recepción 204j. Cuando se completa la recepción, se establece una marca de recepción completa RFB en el registro de control 204a. La CPU 201 monitoriza el contenido del registro de control 204a, y lee los datos de recepción almacenados en el búfer de transmisión y recepción 204j en respuesta a la marca de recepción completa RFB.

Cuando la CPU 201 transmite datos, los datos de transmisión se almacenan en el búfer de transmisión y recepción, y el volumen de los datos de transmisión se escribe en el registro de longitud de datos 204k. La CPU 201 establece una marca de transmisión TXB y una marca de transmisión de patrón de fin ENP (si no hay datos de transmisión después) en el registro de control 204a. Los datos de transmisión del búfer de transmisión y recepción 204j se envían al registro temporal 204g, donde se realiza un cálculo de paridad. El registro temporal 204g almacena el resultado del cálculo de paridad como un byte de bits de paridad, el cual se añade al final de los datos de transmisión. Después, los datos de transmisión se envían desde el registro temporal 204g al registro de desplazamientos alternos 204f, donde se convierten en datos en serie y se envían al codificador de frame 204e. El codificador de frame 204e crea un frame de transmisión añadiendo un patrón de puesta en marcha y un patrón de fin al principio y al final de los datos de transmisión respectivamente y los datos de paridad. El controlador de frame 204c abre los búfers de tres estados correspondientes 211a y 211b mediante las puertas OR 213a y 213b. El frame de transmisión es codificado por el codificador de frame 204e en las señales SDCKA y SDCKB. Las señales SDCKA y SDCKB se emiten a las líneas se datos SDCKA y SDCKB del bus M respectivamente.

El monitor de líneas 204d monitoriza continuamente las líneas de datos SDCKA y SDCKB. El resultado (haya o no una señal) se establece en el registro de control 204a como una marca de monitorización de líneas SDCKA y SDCKB. La CPU 201 puede investigar un Time Out para los datos transmitidos por el servidor consultando estas marcas.

Como se muestra en la Figura 62, el MIE del dispositivo de expansión se compone de manera similar al MIE del dispositivo base aunque no comprende una sección de control de socket. La sección de función de soporte en este diagrama corresponde al medio de entrada y a la sección I/O 202 del dispositivo base y ejecuta las funciones características de, por ejemplo, un monitor LCD, un cartucho de salida de sonido, un cartucho de entrada de sonido, un cartucho de arma luminosa, un cartucho de vibración, un cartucho de memoria, y similares. La sección de la CPU 301 y la sección de procesamiento de comunicaciones 304 corresponden, respectivamente, a la sección de la CPU 201 del dispositivo y a la sección de procesamiento de comunicaciones 204.

A continuación se describe la composición del registro de control 204a, el registro de longitud de datos 204k y el búfer de transmisión y recepción (TRBF) provistos en el MIE del dispositivo base (o dispositivo de expansión).

La Tabla 26 muestra la composición del registro de control 204a que contiene varias marcas de control (CFLAG). Estas marcas de control comprenden 21 marcas para controlar la transmisión y recepción de datos. Los tipos de marca empleados para formar este registro varían dependiendo del tipo de dispositivo periférico.

TABLA 26 Composición de CFLAG

Dir	R/W	R/W	R/W	R/W	R/W	R/W	R/W	R/W	R/W	R/W	R/W
Datos	HRES	CTXB	TBF	TXB	BFOV	RFB	ENDP	LMC1	LMC2	LMC3	LMC4
Ini	0	0	0	0	0	0	0	0	0	0	0

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

Dir	R	R	R	R	R	R	R	R	R	R
Datos	RXB	EMP	SDAM	SDBM	PERR	POS	LMM1	LMM2	LMM3	LMM4
Ini	0	0	-	-	0	0	-	-	-	-

En esta tabla, R/W indica que la marca se puede leer y escribir. R indica que la marca sólo se puede leer. "Ini" representa el establecimiento inicial. HRES representa una marca de recepción de patrón de reinicialización. La marca de recepción de patrón de reinicialización HRES se convierte en "1" cuando se recibe un patrón de reinicialización y provoca la inicialización del controlador del MIE. TXB es una marca de transmisión. Si TXB se escribe durante la transmisión o recepción, no se garantizan los contenidos de los datos correspondientes. CTXB es una marca de transmisión continua. Si se transmite un volumen de datos que sobrepasa la capacidad del búfer de transmisión y recepción 204j, después de almacenar la continuación de los datos del búfer de transmisión y recepción 204j, estos datos se transmiten con la marca de transmisión continua CTXB, en vez de con la marca de transmisión TXB. TFB es una marca de transmisión completa. BFOV es una marca de overflow de capacidad de búfer de transmisión y recepción. La marca de overflow BFOV se borra cuando comienza la transmisión o recepción. Cuando el búfer de transmisión y recepción 204j produce un overflow, la marca de overflow BFOV se establece en "1". RFB es una marca de recepción completa. ENDP es una marca de transmisión de patrón de fin. Cuando se añade un patrón de fin a los datos de transmisión, ENDP se establece en "1". RXB es una marca de recepción, que cambia cuando se reciben datos. EMP es una marca de vacío. Si desaparecen los datos transmitidos al búfer de transmisión y recepción 204j durante la transmisión, la marca de vacío EMP se estable en "1". PERR es una marca de error de paridad. Cuando la paridad que está en el frame recibido no concuerda, esta marca de error de paridad PERR se establece en "1", y en condiciones normales, se borra a "0". POS es una marca de modo de ocupación SDCKB. La marca de modo de ocupación SDCKB POS indica si el bus M está en modo normal (POS = "0") o en modo de ocupación SDCKB (POS = "1"). SDAM es una marca de monitorización de línea SDCKA (sólo se proporciona en el dispositivo base). SDBM es una marca de monitorización de línea SDCKB (sólo se proporciona en el dispositivo base). SDAM y SDBM indican el estado de las líneas de datos SDCKA y SDCKB, respectivamente. LMC1 a 4 son marcas de conexión para los buses LM 1 a 4 (provistas únicamente en el dispositivo base). Las marcas LMC1 a 4 indican una conexión (= "1") o desconexión (= "0") en los buses LM 1 a 4. LMM1 a 4 son marcas de monitorización de conexión de los buses LM 1 a 4 (provistas únicamente en el dispositivo base). Estas marcas LMM1 a 4 indican el estado de uso de los buses LM 1 a 4. El controlador del MIE investiga un Time Out para los datos procedentes del servidor comprobando las marcas SDAM y SDBM. El procesamiento de time Out es controlado únicamente por los dispositivos base y no por los de expansión.

Registro de longitud de datos (LREG)

La Tabla 27 muestra la composición del registro de longitud de datos. El registro de longitud de datos es un registro de un solo byte para indicar el tamaño de un único frame durante la transmisión.

TABLA 27 Composición del LREG

Bit	7	6	5	4	3	2	1	0
Dir	R/W	R/W	R/W	R/W	R/W	R/W	R/W	R/W
Datos	Ln_{7}	Ln_{6}	Ln_{5}	Ln_{4}	Ln_{3}	Ln_{2}	Ln_{1}	Ln_{0}
Ini	-	-	-	-	-	-	-	-

En esta tabla, R/W indica que un bit se puede leer y escribir. En su estado inicial, todos los bits son indefinidos. Ln representa la longitud de los datos, donde 00h \leq Ln \leq FFh. La relación entre el valor de Ln y la longitud de los datos se ilustra en la Tabla 28.

TABLA 28 Longitud de los Datos

Bit	7	6	5	4	3	2	1	0
Longitud datos	Ln_{7}	Ln_{6}	Ln_{5}	Ln_{4}	Ln_{3}	Ln_{2}	Ln_{1}	Ln_{0}
4 bytes	0	0	0	0	0	0	0	0
8 bytes	0	0	0	0	0	0	0	1
:	:	:	:	:	:	:	:	:
512 bytes	0	1	1	1	1	1	1	1
516 bytes	1	0	0	0	0	0	0	0
:	:	:	:	:	:	:	:	:
1020 bytes	1	1	1	1	1	1	1	0
1024 bytes	1	1	1	1	1	1	1	1

Durante la transmisión y recepción de datos y después de la recepción de datos, el registro de longitud de datos (LREG) es indefinido. La longitud de los datos se puede especificar en unidades de cuatro bytes.

A continuación se describe el búfer de datos. El búfer de transmisión y recepción mencionado (TRBF) 204j se usa como búfer de datos. El búfer de transmisión y recepción 204j es una zona de búfer donde se almacenan un frame de datos de transmisión y uno de recepción. La capacidad oscila entre un mínimo de 4 bytes y un máximo de 1.024 bytes, en unidades de 4 bytes. La capacidad se optimiza para cada dispositivo periférico. El búfer se comparte para la transmisión y recepción, y se divide en zonas para un código de comando, un AP destino, un AP fuente, el tamaño de datos, y los datos.

La Tabla 29 muestra la composición del búfer de transmisión y recepción. En esta tabla, R/W indica que un bit se puede leer y escribir. En el estado inicial, el contenido del búfer es indefinido. Los datos se transmiten en secuencia empezando por los primeros datos, y los datos recibidos se escriben en el búfer en secuencia, empezando por la zona de almacenamiento de los primeros datos. Las secciones de datos primera a cuarta son zonas donde se especifican los datos que se van a almacenar.

TABLA 29 Composición de TRBF

Bit	7	6	5	4	3	2	1	0
Dir	R/W	R/W	R/W	R/W	R/W	R/W	R/W	R/W
1^{os} Datos	D1_{7}	D1_{6}	D1_{5}	D1_{4}	D1_{3}	D1_{2}	D1_{1}	D1_{0}
2^{os} Datos	D2_{7}	D2_{6}	D2_{5}	D2_{4}	D2_{3}	D2_{2}	D2_{1}	D2_{0}
3^{os} Datos	D3_{7}	D3_{6}	D3_{5}	D3_{4}	D3_{3}	D3_{2}	D3_{1}	D3_{0}
4^{os} Datos	D4_{7}	D4_{6}	D4_{5}	D4_{4}	D4_{3}	D4_{2}	D4_{1}	D4_{0}
5^{os} Datos	D5_{7}	D5_{6}	D5_{5}	D5_{4}	D5_{3}	D5_{2}	D5_{1}	D5_{0}
6^{os} Datos	D6_{7}	D6_{6}	D6_{5}	D6_{4}	D6_{3}	D6_{2}	D6_{1}	D6_{0}
7^{os} Datos	D7_{7}	D7_{6}	D7_{5}	D7_{4}	D7_{3}	D7_{2}	D7_{1}	D7_{0}
8^{os} Datos	D8_{7}	D8_{6}	D8_{5}	D8_{4}	D8_{3}	D8_{2}	D8_{1}	D8_{0}
:	:	:	:	:	:	:	:	:

En esta tabla, la sección de los primeros datos (1^{os} Datos) es una zona para almacenar códigos de comando. La sección de los segundos datos (2^{os} Datos) es una zona para almacenar valores de APs destino. La sección de los terceros (3^{os} Datos) es una zona para almacenar valores de APs fuente. La sección de los cuartos (4^{os} Datos) es una zona para almacenar tamaños de datos. Cuando el valor que está en los valores de los cuartos datos D4_{0} a D4_{7} es "00h", esto indica que no hay datos. A partir de la sección de los quintos datos (5^{os} Datos) en adelante son zonas para almacenar datos de parámetros. El número de bytes de datos almacenados es el número de bytes indicado con el tamaño de datos. El contenido de las zonas de datos que sobrepasen el tamaño de datos es indefinido.

Procedimiento de transferencia de datos entre el MIE del servidor y el MIE del dispositivo base

A continuación se describe la recepción de datos y la transmisión de datos mediante el MIE del servidor y el MIE del dispositivo base que tienen las composiciones ya mencionadas. Ya que se usa un procedimiento de transferencia similar en los dispositivos de expansión, no se va a describir aquí el procedimiento de transmisión de datos entre el MIE del servidor y un MIE de un dispositivo de expansión.

Procedimiento de recepción de datos

Primeramente, se describe un resumen de una recepción de datos en un dispositivo base. La recepción de datos se realiza automáticamente mediante los MIEs correspondientes del servidor y del dispositivo base. Cuando el servidor transmite una señal de datos y el dispositivo base comienza el proceso de recepción, la marca de transmisión TXB, la marca de transmisión completa TFB y la marca de recepción completa RFB se cambian a "0" mediante el MIE. Cuando la marca de recepción RXB es "1", esto indica que el MIE está en proceso de recibir datos, y cuando RXB es "0", esto indica que la recepción ha terminado. Cuando la recepción de datos se completa de forma normal y los datos se han almacenado en el búfer de transmisión y recepción (TRBF), mientras que se almacena el estado de error de paridad mediante la marca de error de paridad PERR, la marca de recepción completa RFB se establece en "1" (en caso de interrupción del proceso, se genera una interrupción de recepción en este punto), y termina el proceso de recepción. Si tanto la marca de recepción RXB como la marca de recepción completa RFB son "1", esto indica que se ha producido un error durante la recepción. Además, si los datos de recepción sobrepasan la capacidad del búfer de transmisión y recepción, la marca overflow de búfer de transmisión y recepción BFOV se establece en "1", y los datos de recepción desde el comienzo de la recepción hasta la capacidad del búfer de transmisión y recepción se almacenan en el búfer de transmisión y recepción. Si no coincide la paridad en los datos del frame, el PERR se establece en "1", y si la paridad es normal, el PERR es a "0".

La Figura 67 es un diagrama que ilustra la recepción de datos en el MIE del dispositivo, en un caso en el que el volumen de los datos transmitidos desde el servidor al dispositivo (dispositivo periférico) no sobrepasa la capacidad del búfer de transmisión y recepción 204j.

Primero, en el lado del servidor, los datos de transmisión que se van a enviar se crean en la RAM de trabajo 1e, y el MIE del servidor crea los datos frame que contienen estos datos y comienza a transmitirlos al bus M. El MIE del dispositivo recibe estos datos de frame y los descodifica mediante un descodificador de frames 204h. La sección de datos (patrón de datos) y los datos de paridad de los datos de frame se transforman de serie a paralelo mediante un registro de desplazamientos alternos 204i, y se comprueba la paridad (cálculo de paridad) mediante un registro temporal 204g. La sección de datos comprobados se almacena entonces en un búfer de transmisión y recepción 204k, y los datos de paridad se almacenan en un registro de paridad 204b.

Cuando el descodificador de frame 204h detecta un patrón de puesta en marcha en los datos del frame, el controlador frames 204c fija en "0" la marca de transmisión TXB, la marca de transmisión completa TFB y la marca de recepción completa RFB del registro de control 204a. Como se ha indicado anteriormente, cuando la marca de recepción RXB es "1", esto indica que el MIE está en proceso de recibir datos, y cuando RXB es "0", esto indica que la recepción de datos ha terminado. La sección de la CPU 201 lee el hecho de que la marca de recepción RXB se ha establecido en "1", y concluye que los datos se están recibiendo. Además, la sección de la CPU 201 también puede monitorizar el uso de líneas de datos SDCKA y SDCKB comprobando las marcas SDAM y SDBM. Cuando el descodificador de frame 204h detecta un patrón de fin en los datos del frame, el controlador de frame 204c concluye que la recepción de datos ha terminado, y establece la marca de recepción RXB en "0".

La sección de registro de paridad 204b compara los resultados de comprobación de paridad para los datos de recepción con los datos de paridad recibidos, para determinar si hay error de paridad. La ocurrencia o ausencia de un error se escribe en la marca de error de paridad PERR del registro de control 204a. Cuando se termina de manera normal la recepción de datos del frame, y los datos se almacenan en el búfer de transmisión y recepción 204j, mientras que el estado de error de paridad se almacena en la marca de error de paridad PERR del registro de control 204a, la marca de recepción completa RFB se establece en "1", y termina el proceso de recepción. La marca de recepción completa RFB se puede tomar como una señal de interrupción en la sección de la CPU 201.

Si se monitoriza la marca de recepción completa RFB de manera periódica, o alternativamente, recibiendo una señal de interrupción cuando la marca de recepción completa RFB se fija en "1", la sección de la CPU 201 ejecuta un programa para procesar los datos de recepción. Primero confirma que la marca de error de paridad PERR del registro de control 204a no indica que haya un error. A continuación, lee los datos de recepción que van del búfer de transmisión y recepción 204j a la memoria principal de la sección de la CPU 201. La sección de la CPU 201 lleva a cabo después el procesamiento que corresponde a los comandos y parámetros transmitidos por el servidor, y el procesamiento para crear datos de respuesta y equivalentes.

Si la marca de recepción RXB y la marca de recepción completa RFB se fijan en "1", ya que estos son estados básicamente incompatibles, la CPU identifica que se ha producido un error durante la recepción y realiza un procesamiento pertinente. Además, si la marca de error de paridad PERR indica que hay un error, la sección de la CPU 201 realiza un procesamiento para enviar, por ejemplo, un comando de petición de retransmisión al servidor.

La Figura 68 es un diagrama que ilustra la recepción de datos en un MIE del dispositivo base en el caso en el que el volumen de datos de transmisión que van del servidor al dispositivo base (dispositivo periférico) sobrepasa la capacidad del búfer de transmisión y recepción TRBF. Cuando los datos de recepción sobrepasan la capacidad del búfer de transmisión y recepción 204j, la marca de overflow de búfer de transmisión y recepción TRBF se fija en "1", y los datos de recepción desde el comienzo de la recepción hasta la capacidad del búfer de transmisión y recepción se almacenan en el búfer de transmisión y recepción. A continuación, se describen las operaciones que se realizan en este caso.

En primer lugar, de manera similar a la Figura 67, los datos de transmisión a enviar al servidor se crean en la RAM de trabajo 1e, y el MIE del servidor forma datos frame que contienen estos datos y empieza a transmitirlos al bus M. El MIE del dispositivo base recibe estos datos de frame y los descodifica con la ayuda del descodificador de frame 204h. La sección de datos (patrón de datos) y los datos de paridad de los datos de frame se transforman de datos serie a paralelo mediante el registro de desplazamientos alternos 204i, y el registro temporal 204g realiza una comprobación de paridad (cálculo de paridad). La sección de datos de comprobación se almacena después en el búfer de transmisión y recepción 204j, y los datos de paridad se almacenan en el registro de paridad 204b.

Cuando el descodificador de frame 204h detecta un patrón de puesta en marcha en los datos de frame, el controlador de frame 204c fija en "0" la marca de transmisión TXB, la marca de transmisión completa TFB y la marca de recepción completa RFB del registro de control 204a. Como se ha explicado antes, cuando la marca de recepción RXB es "1", esto indica que el MIE está en proceso de recibir datos y cuando RXB es "0", esto indica que la transmisión ha terminado. La sección de la CPU 201 lee el hecho de que la marca de recepción RXB se fija en "1" y deduce que se están recibiendo datos. Además, la sección de la CPU 201 puede monitorizar el uso de las líneas de datos SDCKA y SDCKB comprobando las marcas SDAM y SDBM.

Si los datos de recepción sobrepasan la capacidad del búfer de transmisión y recepción 204j, éste fija en "1" la marca de overflow del búfer de transmisión y recepción BFOV en el registro de control. Para este fin, un overflow se detecta, por ejemplo, generando una salida de detección cuando un contador de dirección que está en el búfer de transmisión y recepción 204j alcanza el máximo valor de dirección en la memoria. Incluso después de que el volumen de los datos de recepción ha sobrepasado el búfer de transmisión y recepción 204j, los datos de recepción se suministran aún al búfer de transmisión y recepción 204j vía el registro temporal, aunque el búfer de transmisión y recepción no lea estos datos. Por tanto, sólo se realiza un cálculo de paridad para todos los datos. La sección de datos de paridad de los datos de recepción se almacena en el registro de paridad.

Cuando el descodificador de frame 204h detecta un patrón de fin en los datos de frame, el controlador de frame 204c identifica que la recepción ha terminado y fija la marca de recepción RXB en "0". La sección del registro de paridad 204b compara los resultados de la comprobación de paridad para los datos de recepción con los datos de paridad recibidos para determinar si hay un error de paridad. La ocurrencia o ausencia de error se escribe en la marca de error de paridad PERR del registro de control 204a. Cuando los datos se establecen en el búfer de transmisión y recepción 204j y el estado de error de paridad se establece en la marca de error de paridad PERR del registro de control 204a, la marca de recepción completa RFB se fija en "1" y termina el proceso de recepción. La marca de recepción completa RFB se puede tomar como una señal de interrupción en la sección de la CPU 201.

La sección de la CPU 201 identifica que debe ejecutar un programa para procesar datos de recepción monitorizando de manera periódica la marca de recepción completa RFB del registro de control, o recibiendo una señal de interrupción cuando la marca de recepción completa RFB se fija en "1". Además, la sección de la CPU 201 confirma que la marca de error de paridad PERR del registro de control 204a no indica que hay un error. También comprueba que la marca de overflow BFOV del búfer de transmisión y recepción se fija en "1". Al identificar que los datos están en mitad de la transmisión, la sección de la CPU 201 lee los datos de recepción que van del búfer de transmisión y recepción 204j a la memoria principal de la sección de la CPU 201, y después ejecuta un proceso pertinente.

Método de transmisión de datos

A continuación se describe un procedimiento de transmisión de datos desde un dispositivo base al servidor con referencia a la Figura 69. El procedimiento de transmisión de datos desde el dispositivo de expansión al servidor es similar al procedimiento de transmisión de datos desde el dispositivo base al servidor, con lo cual no se describe aquí.

Cuando el dispositivo base recibe un comando del servidor, crea unos datos de respuesta para responder al comando, y envía estos datos de respuesta al servidor. Como se ha explicado ya, si no hay respuesta en un periodo de tiempo determinado (por ejemplo, 1,0 ms) después de la transmisión del comando, el servidor deduce que no hay conexión. Por tanto, el dispositivo base tiene que devolver un comando en este periodo de tiempo.

En primer lugar, la sección de la CPU 201 del dispositivo base escribe los datos de transmisión (comandos, parámetros) en el búfer de transmisión y recepción 204j. A continuación, escribe el volumen de datos de los datos de transmisión en el registro de longitud de datos 204k y fija en "1" la marca de patrón de fin ENDP en el registro de control.

Cuando la sección de la CPU 201 fija en "1" la marca de transmisión TXB del registro de control 204a, el MIE comienza una operación de transmisión para transmitir los datos del tamaño indicado en el registro de longitud de datos. Si la marca de transmisión TXB se fija en "1", la marca de recepción RXB, la marca de recepción completa RFB, la marca de transmisión completa TFB y la marca de overflow BFOV del búfer de transmisión y recepción que están en el registro de control 204a se fijan (borran) a "0". Si el volumen de los datos fijados en el registro de longitud de datos 204k sobrepasa la capacidad del búfer de transmisión y recepción 204j, la marca de overflow BFOV del búfer de transmisión y recepción cambia a "1", y se transmiten todos los datos que están el búfer de transmisión y recepción 204j.

El controlador de frame 204c permite la transmisión de los datos almacenados en el búfer de transmisión y recepción 204j en respuesta a la marca de transmisión TXB que se fija en "1". El registro temporal 204g realiza un cálculo de paridad para los datos de transmisión, y el registro de desplazamientos alternos 204f transforma los datos de paralelos a serie y los transmite al codificador de frame 204e. El registro temporal 204g añade los datos de paridad al final de los datos de transmisión. El codificador de frame 204e transmite en secuencia un patrón de puesta en marcha, datos de transmisión (comandos, parámetros), datos de paridad y un patrón de fin, bajo el control del controlador de frame 204c. El frame de transmisión formado por estos contenidos se envía al bus M mediante las citadas señales SDCKA y SDCKB. Cuando los datos finales se envían desde el búfer de transmisión y recepción 204j, la marca de transmisión TXB del registro de control se fija en "0", la marca de vacío EMP se fija en "1" y la marca de transmisión continua se fija en "0". Los contenidos del búfer de transmisión y recepción 204j después de que se ha completado la transmisión son indefinidos. El controlador de frame 204c transmite un patrón de fin y si la transmisión de datos termina de manera normal, la marca de transmisión completa TFB del registro de control 204a se fija en "1". El MIE del dispositivo base asume después un estado standby, en espera de una entrada desde el bus M. La sección de la CPU 201 confirma que ha terminado la transmisión monitorizando periódicamente la marca de transmisión completa TFB del registro de control para ver si se fija en "1". Además, si la marca de transmisión TXB que indica que la transmisión está en progreso y la marca de transmisión completa TFB se fijan en "1", la sección de la CPU 201 identifica que se ha producido un error.

Por otro lado, el MIE del servidor recibe los datos del frame transmitidos por el dispositivo base. Cuando el descodificador de frame 61 detecta el patrón de puesta en marcha en los datos, se envía una señal vía la sección de control de señal de interrupción 54 al controlador de interrupción en la CPU 1a del servidor, para avisar a la CPU de que se están recibiendo datos. El registro de desplazamientos alternos 62 transforma los datos de recepción de serie a paralelo, después de lo cual se transmiten desde la sección iniciadora 50 vía el registro temporal de datos de recepción 56a y el FIFO de datos de recepción 56b a la RAM de trabajo 1e. En el emplazamiento de almacenamiento de datos de recepción de la RAM de trabajo 1e, la dirección de almacenamiento de datos de recepción que ha predeterminado la CPU 1a se toma como la posición binaria inicial. Cuando el descodificador de frame 61 detecta un patrón de fin, termina la recepción y la sección de control de señal de interrupción 54 envía una señal que indica la terminación del proceso de recepción al controlador de interrupción. Por tanto, a la CPU se le avisa de que la recepción ha terminado, y puede acceder y procesar los datos de recepción que están en la RAM de trabajo 1e.

A continuación, y con referencia a la Figura 70, se describe el caso en el que la transmisión de datos procedente del dispositivo base sobrepasa la capacidad de su búfer de transmisión y recepción 204j. En un dispositivo de expansión, se ejecuta un procedimiento similar al del dispositivo base. Si los datos de transmisión sobrepasan la capacidad del búfer de transmisión y recepción 204j, la sección de la CPU 201 del dispositivo base puede transmitir los datos particionándolos en varios bloques según la capacidad del búfer de transmisión y recepción 204j.

Si la sección de la CPU 201 del dispositivo base recibe un comando desde el servidor, forma datos de respuesta para responder a esto, y envía estos datos al servidor. Si no hay respuesta dentro de un periodo de tiempo determinado (por ejemplo 1,0 ms) después de la transmisión del comando, el servidor deduce que no hay conexión. Por tanto, el dispositivo base debe devolver un comando y los parámetros en este periodo de tiempo.

En primer lugar, la sección de la CPU 201 del dispositivo base compara el volumen de los datos a transmitir con la capacidad del búfer de transmisión y recepción 204j para identificar si el volumen de los datos de transmisión es muy grande. La sección de la CPU 201 particiona después los datos de transmisión en longitudes iguales o menores que la capacidad del búfer de transmisión y recepción 204j (por ejemplo, 1.024 bytes) y copia los datos en el búfer de transmisión y recepción 204j (agrupamiento en bloques).

Acto seguido, el volumen de los datos de transmisión almacenados en el búfer de transmisión y recepción 204j se escribe en el registro de longitud de datos 204k, y la marca de patrón de fin ENDP del registro de control 204a se fija en "0".

Cuando la sección de la CPU 201 fija en "1" la marca de transmisión TXB del registro de control 204a (modo transmisión), el MIE comienza la operación de transmisión para transmitir datos del tamaño indicado por el registro de longitud de datos. Cuando la marca de transmisión TXB se fija en "1", el controlador de frame 204c fija en "0" (borra) la marca de recepción RXB, la marca de recepción completa RFB, la marca de transmisión completa TFB, la marca de vacío EMP y la marca de overflow del búfer de transmisión y recepción BFOV, que están en el registro de control 204a.

El controlador de frame 204c permite la transmisión de los datos de transmisión almacenados en el búfer de transmisión y recepción 204j en respuesta a que la marca de transmisión TXB se fija en "1". Se hace un cálculo de paridad para los datos de transmisión del registro temporal 204g, y el registro de desplazamientos alternos 204f transforma después los datos paralelo a serie y éstos se transmiten a un codificador de frame 204e. El codificador de frame 204e transmite sucesivamente el patrón de puesta en marcha y los datos de transmisión (comandos y parámetros), según los comandos procedentes del controlador de frame 204c. Ya que la marca ENDP se fija en "0", los datos de paridad y el patrón de fin no se añaden al final de este bloque de datos. Un frame de transmisión que comprende los items mencionados se transmite al bus M mediante las señales SDCKA y SDCKB. Cuando el item de dato final se emite desde el búfer de transmisión y recepción 204j, la marca de vacío EMP que está en el registro de control se fija en "1" y la marca de transmisión continua se fija en "0".

La sección de la CPU 201 monitoriza periódicamente la marca de vacío EMP del registro de control 204a. Si confirma que la marca de vacío EMP ha cambiado a "1", particiona los datos de transmisión añadidos hasta un tamaño igual o menor que la capacidad del búfer de transmisión y recepción y los almacena en el búfer de transmisión y recepción 204j. La longitud de estos datos se establece en el registro de longitud de datos 204k. Acto seguido, la sección de la CPU 201 fija en "1" la marca de transmisión continua CTXB del registro de control 204a.

Cuando se fija en "1" la marca de transmisión continua, el controlador de frame 204c fija en "0" (borra) la marca de vacío EMP y la marca de overflow del búfer de transmisión y recepción BFOV del registro de control 204a.

El controlador de frame 204c permite la transmisión de los datos de transmisión almacenados en el búfer de transmisión y recepción 204j en respuesta a que la marca de transmisión TXB se fija en "1". Se hace un cálculo de paridad para los datos de transmisión del registro temporal 204g, y el registro de desplazamientos alternos 204f transforma después los datos paralelo a serie y se envían a un codificador de frame 204e. El codificador de frame 204e transmite sucesivamente los datos de transmisión (comandos y parámetros) bajo el control del controlador de frame 204c. Estos items de datos, y equivalentes, se transmiten al bus M mediante las señales SDCKA y SDCKB mencionadas. Cuando los datos finales se emiten desde el búfer de transmisión y recepción 204j, la marca de vacío EMP del registro de control se fija en "1" y la marca de transmisión continua se fija en "0".

La sección de la CPU 201 identifica que la marca de vacío EMP ha cambiado a "1" monitorizando el registro de control a intervalos periódicos. La sección de la CPU 201 particiona los datos de transmisión restantes (no transmitidos) a un tamaño igual o menor que la capacidad del búfer de transmisión y recepción 204j, y los almacena en el búfer de transmisión y recepción 204j. En el caso de este ejemplo, los datos restantes son menores que la capacidad del búfer de transmisión y recepción 204j, con lo cual todos los datos restantes se almacenan en el búfer de transmisión y recepción 204j. La longitud de estos datos se establece en el registro de longitud de datos 204k. Además, ya que el bloque de datos final se está transmitiendo, la marca de transmisión de patrón de fin ENDP se fija en "1" con lo cual se añade un patrón de fin al final de los datos. Acto seguido, la sección de la CPU 201 fija en "1" la marca de transmisión continua CTXB del registro de control 204a.

Cuando la marca de transmisión continua CTXB se fija en "1", el controlador de frame 204c fija (borra) en "0" la marca de vacío EMP y la marca de overflow del búfer de transmisión y recepción BFOV del registro de control 204a.

El controlador de frame 204c permite la transmisión de los datos de transmisión almacenados en el búfer de transmisión y recepción 204j en respuesta a que la marca de transmisión TXB se fija en "1". Se hace un cálculo de paridad para los datos de transmisión del registro temporal 204g, y el registro de desplazamientos alternos 204f transforma después los datos de paralelo a serie y se envían a un codificador de frame 204e. El registro temporal 204g adopta los resultados del cálculo de paridad para todos los datos de transmisión como datos de paridad (un byte de bits de paridad), que los añade al final de los datos de transmisión. El codificador de frame 204e transmite sucesivamente los datos de transmisión (comandos y parámetros), los datos de paridad y el patrón de fin, bajo el control del controlador de frame 204c. Estos items de datos, y equivalentes, se transmiten al bus M mediante las señales SDCKA y SDCKB mencionadas. Cuando los items de datos finales se emiten desde el búfer de transmisión y recepción 204j, la marca de vacío EMP del registro de control se fija en "1" y la marca de transmisión continua CTXB se fija en "0". Ya que la transmisión ha terminado, la marca de transmisión TXB y la marca de transmisión completa TFB se fijan en "0". La sección de la CPU 201 identifica que se ha completado la transmisión de todos los datos según el estado de varias marcas monitorizando periódicamente el registro de control 204a.

Por otro lado, cuando el MIE del servidor recibe un patrón de puesta en marcha, comienza una operación de recepción, y almacena sucesivamente datos de recepción (comandos, parámetros) en la RAM de trabajo 1e. El registro DMA especifica previamente el emplazamiento de almacenamiento en la RAM de trabajo 1e. Los datos de transmisión originales se restauran encajando cada uno de los bloques de datos recibidos en la RAM de trabajo 1e. Cuando al final el MIE del servidor recibe un patrón de fin, termina la recepción de datos.

Como se ha descrito antes, cuando los datos de transmisión se particionan y transmiten en bloques, el primer bloque usa la marca de transmisión TXB, y el segundo bloque y siguientes usan la marca de transmisión continua CTXB para transmitir los datos restantes. Si el periodo de tiempo que va desde que se envía un bloque de datos hasta que se envía el siguiente bloque sobrepasa un periodo de tiempo prescrito, por ejemplo 1,0 ms, se genera un time Out en el servidor, con lo cual el dispositivo transmite el segundo bloque y los siguientes dentro de este periodo de tiempo. El tamaño de los bloques se puede establecer en unidades de bloque. El tamaño de los bloques se establece en el registro de longitud de datos 204k para cada transmisión de bloque. Exceptuando el último bloque, la marca de patrón de fin se fija en "0" cuando se ha transmitido el bloque, con lo cual no se añade ningún patrón de fin. Cuando se envía el último bloque, la marca de patrón de fin se fija en "1", con lo cual se añade un patrón de fin al final de los datos de transmisión.

De este modo, el dispositivo base puede transmitir datos que sobrepasen la capacidad de su propio búfer de transmisión y recepción. Los mismo ocurre con los dispositivos de expansión.

Relación entre marcas y los estados de comunicaciones

A continuación, se describen las relaciones entre las marcas que están en el registro de control 204a del dispositivo base y su estado de comunicaciones.

(1): Estado de las marcas del dispositivo base (cuando el dispositivo base se está comunicando con el servidor)

(a): Cuando el dispositivo base está transmitiendo datos al servidor

TABLA 30 Transmisión de Datos al Servidor

Bit	Comienzo de	Durante la	Fin de	Error de
	transmisión	transmisión	transmisión	transmisión
TXB	1	1	0	1
TFB	0	0	1	1
RXB	0	0	0	0
RFB	0	0	0	0

: Si tanto la marca de transmisión TXB como la marca de transmisión completa TFB se fijan en "1", esto representa un error de transmisión.

(b): Cuando el dispositivo base está recibiendo datos del servidor

TABLA 31 Recepción de Datos desde el Servidor

Bit	Durante la recepción	Fin de la recepción	Datos de recepción almacenados	Error de recepción
TXB	0	0	0	0
TFB	0	0	0	0
RXB	1	1	0	1
RFB	0	0	1	1

: Cuando tanto la marca de recepción RXB como la marca de recepción completa se fijan en "1", esto representa un error de recepción.

(2): Estado de las marcas del dispositivo base (cuando un dispositivo de expansión se está comunicando con el servidor)

(a): Cuando un dispositivo de expansión está transmitiendo datos al servidor.

TABLA 32 Estados de Marcas Individuales con respecto al Estado de Transmisión de Otro Dispositivo Periférico

Bit	Comienzo de transmisión	Durante la transmisión	Fin de la transmisión	Error de transmisión
TXB	0	0	0	0
TFB	0	0	0	0
RXB	0	0	0	0
RFB	0	0	0	0

: Si cualquiera de los dispositivos de expansión (dispositivos de transmisión) transmite datos al servidor, es posible que ese dispositivo de expansión ocupe un bus LM. Esta ocupación es posible si se controlan las puertas OR 213, 214 mediante el dispositivo de transmisión. En casos de este tipo, se excluyen del bus dispositivos base y de expansión que no sean el dispositivo de transmisión, con lo cual no es necesario monitorizar la recepción de datos, reduciéndose por tanto la carga.

(b): Cuando el dispositivo de expansión recibe datos del servidor

TABLA 33 Estados de Marcas Individuales con respecto al Estado de Recepción de Otro Dispositivo Periférico

Procesamiento de Error

A continuación se describe el procesamiento de error. Como se ha explicado antes, si la marca de transmisión TXB y la marca de transmisión completa TFB se fijan en "1", es que hay un error de transmisión. Si la marca de recepción RXB y la marca de recepción completa RFB se fijan en "1", es que hay un error de recepción. Si se produce un error durante el procesamiento de transmisión, el MIE puede indicar que hay un error fijando tanto la marca de transmisión TXB como la marca de transmisión completa TFB en "1". Lo mismo ocurre si se produce un error durante el proceso de recepción. Si se produce un error de paridad, la marca de error de paridad PERR se fija en "1". Si los datos recibidos sobrepasan la capacidad del búfer de transmisión y recepción (desbordamiento de capacidad) durante la recepción de datos, o si se especifica que durante la transmisión la longitud de los datos sobrepasa la capacidad del búfer, la marca de overflow del búfer de transmisión y recepción BFOV se fija en "1".

A continuación se describen ejemplos de procesamiento de errores en un dispositivo base cuando se producen errores de estos tipos.

(a): Si se produce un error cuando se transmite al servidor, no se ejecuta ninguna operación con respecto al error, sino que simplemente se borran las marcas de transmisión TXB y de transmisión completa TFB.

(b): Si se produce un error cuando se reciben datos desde el servidor, primero, si el destino de los datos corresponde al del dispositivo base, éste puede enviar un comando de retransmisión al servidor. Si el destino de los datos indica otro dispositivo, el dispositivo base borra sus propias marcas de recepción RXB y de recepción completa RFB.

(c): Si el error durante la recepción de datos desde el servidor es un exceso de tiempo permitido, se reinicializa tanto el dispositivo base como los dispositivos de expansión. En otras palabras, a) se reservan los IDs de los dispositivos de expansión con el fin de formar señales de parada de operación para los dispositivos de expansión, haciendo así que los dispositivos de expansión detengan su procesamiento. b) El dispositivo base se reinicializa y después revierte su ID (lo devuelve a su ID original). Cuando se revierte el ID, los dispositivos de expansión se reinicializan. c) Después de la reinicialización, el dispositivo asume el mismo estado que asume después de una reinicialización software.

Referencia de comandos

A continuación, se describen los diferentes comandos que se usan en un frame. Se pueden usar 254 códigos de comandos desde 01 h a Feh. 00 h y FFh no se pueden emplear. Estos códigos se reservan para indicar "error de comunicación:datos no seguros". Los comandos incluyen comandos de control y comandos de error.

Comandos de control

El rango de código de comandos que va de 01 h a DFh se puede usar para comandos de control. Estos comandos se emplean para controlar la transmisión y recepción de datos. Las diferentes librerías de funciones del servidor, dispositivos base y dispositivos de expansión no pueden proporcionar diferentes comandos para el mismo código de comandos. Si se añaden más comandos, es deseable buscar compatibilidad con los estándares aplicando previamente el grupo que gestiona los estándares. A continuación se describen comandos de control.

\vskip1.000000\baselineskip

Device Request (Figura 71)

: Derecho de emitir: Servidor

: Código de comando: 01 h

: Tamaño de datos: 00 h

: Zona de datos: ninguna

: Valor de respuesta esperada: Device Status

: Descripción: un comando a un dispositivo periférico en el AP destino pidiendo un Device Status. También se emplea para comprobar el estado de conexión en los puertos.

\vskip1.000000\baselineskip

All Status Request (Figura 72)

: Derecho de emitir: Servidor

: Código de comando: 02 h

: Tamaño de datos: 00 h

: Zona de datos: ninguna

: Valor de respuesta esperada: Device All Status

: Descripción: una petición a un dispositivo periférico en el AP destino para todos los Device Status (Fixed Device Status y Free Device Status).

\vskip1.000000\baselineskip

Device Reset (Figura 73)

: Derecho de emitir: Servidor

: Código de comando: 03 h

: Tamaño de datos: 00 h

: Zona de datos: ninguna

: Valor de respuesta esperada: Device Reply

: Descripción: Permite la inicialización de un dispositivo periférico especificado por el AP receptor.

: Procedimiento operativo: (1) El dispositivo periférico devuelve un Device Reply. (2) El dispositivo periférico se reinicializa.

\vskip1.000000\baselineskip

Device Kill (Figura 74)

: Derecho de emitir: Servidor

: Código de comando: 04 h

: Tamaño de datos: 00 h

: Zona de datos: ninguna

: Valor de respuesta esperada: Device Reply

: Descripción: Prohíbe el funcionamiento del dispositivo periférico especificado por el AP destino. El dispositivo periférico espera después en estado de consumo de corriente de espera y no acepta ningún comando. Para accionar el dispositivo periférico, es necesario bien realizar una reinicialización hardware o bien reactivarlo cortando el suministro de corriente.

: Procedimiento operativo: (1) El dispositivo periférico devuelve un Device Reply. (2) El dispositivo periférico detiene su funcionamiento.

\vskip1.000000\baselineskip

Device Status

: Derecho de emitir: Dispositivo periférico

: Código de comando: 05 h

: Tamaño de datos: 1 Ch (28)

: Zona de datos: ID de dispositivo: 16 bytes; código de región de destino: 1 byte; nombre del producto: 31 bytes; licencia: 60 bytes; consumo de corriente en espera: 2 bytes; consumo máximo de corriente; 2 bytes.

: Descripción: los datos de Fixed Device Status se envían en respuesta a un Device Request desde el servidor. Los detalles de los contenidos de los datos se describen en la información del dispositivo periférico que se dará posteriormente.

\newpage

Device All Status

: Derecho de emitir: Dispositivo periférico

: Código de comando: 06 h

: Tamaño de datos: 1 Ch + (n/4)

: Zona de datos: Fixed DEvice Status: 112 bytes, ID de dispositivo: 16 bytes; código de región de destino: 1 byte; nombre del producto: 31 bytes; licencia: 60 bytes; consumo de corriente en espera: 2 bytes; consumo máximo de corriente; 2 bytes, Free Device Status: n bytes.

: Descripción: tanto el Fixed Device Status como el Free Device Status se envían en respuesta a un All Status Request desde el servidor. Los detalles de los contenidos de los datos se describen en la información del dispositivo periférico posterior.

\vskip1.000000\baselineskip

Device Reply

: Derecho de emitir: Dispositivo periférico

: Código de comando: 07 h

: Tamaño de datos: 00 h

: Zona de datos: ninguna

: Descripción: se usa como respuesta desde el dispositivo periférico.

\vskip1.000000\baselineskip

Data Transfer (Figura 75)

: Derecho de emitir: Dispositivo periférico

: Código de comando: 08 h

: Tamaño de datos: n (01 h \leq n \leq FFh)

: Zona de datos: Tipo de función: 4 bytes; datos: (n-1) x 4 bytes

: Valor de respuesta esperada: ninguno

: Descripción: Envía datos de acuerdo con el tipo de función especificada por el servidor. Los datos varían dependiendo del comando solicitado.

\vskip1.000000\baselineskip

Get Condition (Figura 76)

: Derecho de emitir: Servidor

: Código de comando: 09 h

: Tamaño de datos: 01 h

: Zona de datos: tipo de función: 4 bytes

: Valor de respuesta esperada: Data Transfer

: Descripción: Pide el estado físico de la función especificada por el tipo de función del dispositivo periférico. El dispositivo periférico devuelve el mismo tipo como tipo de función transmitida por el servidor. Sólo se puede designar un tipo de función cada vez.

\vskip1.000000\baselineskip

Get Media Info (Figura 77)

: Derecho de emitir: Servidor

: Código de comando: 0Ah

: Tamaño de datos: 02 h

: Zona de datos: tipo de función: 4 bytes; PT (partición): 4 bytes (de los cuales 3 son bytes ficticios)

: Valor de respuesta esperada: Data Transfer

: Descripción: Pide información de los soportes de información de la función especificada por el tipo de función de dispositivo periférico y PT. Los detalles dependen de las especificaciones de los tipos de función correspondientes.

\vskip1.000000\baselineskip

Block Read (Figura 78)

: Derecho de emitir: Servidor

: Código de comando: 0Bh

: Tamaño de datos: 02 h

: Zona de datos: tipo de función: 4 bytes; partición (PT): 1 byte; Fase: 1 byte; Nº de bloques: 2 bytes

: Valor de respuesta esperada: Data Transfer

: Descripción: pide datos de un emplazamiento especificado por el tipo de función de dispositivo periférico, fase y número de bloques del medio de almacenamiento de información de la partición (por ejemplo emplazamiento de almacenamiento de datos en FDD, HDD, memoria, CD-ROM, etc). Los detalles dependen de las especificaciones de los tipos de función correspondientes.

\vskip1.000000\baselineskip

Block Write (Figura 79)

: Derecho de emitir: Servidor

: Código de comando: 0Ch

: Tamaño de datos: 02 h+n

: Zona de datos: Tipo de función: 4 bytes; partición: 1 byte; Fase: 1 byte; Nº de bloques: 2 bytes; datos de escritura: n x 4 bytes

: Valor de respuesta esperada: Data Transfer

: Descripción: copia datos en un emplazamiento especificado por el tipo de función de dispositivo periférico y la división, fase y número de bloques. Los detalles dependen de las especificaciones de los tipos de función correspondientes.

\vskip1.000000\baselineskip

Get Last Error (Figura 80)

: Derecho de emitir: Servidor

: Código de comando: 0Dh

: Tamaño de datos: 02 h

: Zona de datos: Tipo de función: 4 bytes; partición: 1 byte; Fase: 1 byte; Nº de bloques: 2 bytes

: Valor de respuesta esperada: Device Reply

: Descripción: Investiga si ocurre un error en un comando previo. Si no hay error, responde con un Device Reply, si aparece un error envía un comando de error. La partición y el número de bloques mantienen los mismos valores que tenían en el comando justo anterior, y la fase se incrementa en 1. Los detalles dependen de las especificaciones de los tipos de función correspondientes.

Comandos de error

A continuación se describen comandos de error. El tango de código de comando que oscila entre E0h y FEh se usa para comandos de error. Un comando de error informa que se ha producido un error en la transmisión, recepción o procesamiento de datos. Las librerías de función del servidor, los dispositivos base y los dispositivos de expansión correspondientes tienen prohibido proporcionar comandos diferentes para el mismo código de comando. Es deseable buscar compatibilidad con los estándares aplicando previamente el grupo que los gestiona. A continuación se describen comandos de error.

\vskip1.000000\baselineskip

Function Type Unknown

: Derecho de emitir: Dispositivo Periférico

: Código de comando: FEh

: Tamaño de datos: 00 h

: Zona de datos: ninguno

: Descripción: se emite cuando la función especificada por el tipo de función transmitida no está presente en el dispositivo periférico.

: Causas posibles: (1) La especificación del tipo de función es incorrecta. (2) La descripción de los datos es incorrecta. (3) Los datos del ID del dispositivo están corruptos. (4) Los datos se corrompen durante las comunicaciones.

: Acción: (1) Especificación correcta del tipo de función. (2) Descripción correcta de los datos. (3) Transmitir Device Request de nuevo y obtener ID de dispositivo. (4) Intentar transmitir de nuevo (hasta un máximo de tres veces, después de lo cual el mismo procesamiento es Time Out).

\vskip1.000000\baselineskip

Command Unknown

: Derecho de emitir: Dispositivo Periférico

: Código de comando: FDh

: Tamaño de datos: 00 h

: Zona de datos: ninguno

: Descripción: se emite cuando el comando transmitido no se encuentra en las funciones del lado del dispositivo periférico.

: Causas posibles: (1) Especificación de comando incorrecta. (2) Descripción de datos incorrecta. (3) Los datos del ID del dispositivo están corruptos. (4) Los datos se corrompen durante las comunicaciones.

: Acción: (1) Especificación correcta del comando. (2) Descripción correcta de los datos. (3) Transmitir Device Request de nuevo y obtener ID de dispositivo. (4) Intentar transmitir de nuevo (hasta un máximo de tres veces, después de lo cual el mismo procesamiento es un Time Out).

\vskip1.000000\baselineskip

Transmit Again

: Derecho de emitir: Servidor; dispositivo periférico

: Código de comando: FCh

: Tamaño de datos: 00 h

: Zona de datos: ninguno

: Descripción: pide que los mismos datos se transmitan de nuevo cuando se produce un error de algún tipo en los datos de transmisión.

: Causas posibles: (1) Se produce un error de paridad. (2) Desbordamiento de capacidad. (3) Los datos se corrompen durante las comunicaciones.

: Acción: Transmitir de nuevo (hasta un máximo de tres veces, después de lo cual el mismo procesamiento es un time Out).

\vskip1.000000\baselineskip

File Error

: Derecho de emitir: Dispositivo Periférico

: Código de comando: FBh

: Tamaño de datos: 01 h

: Zona de datos: código de error de función

: Descripción: se emite cuando se produce un error en File Function. Se transmite un error detallado mediante el código de error de función.

: Causas posibles:

\vskip1.000000\baselineskip

TABLA 34 Código de error de función archivo

Bit	7	6	5	4	3	2	1	0
1^{os} Datos	FE_{31}	FE_{30}	FE_{29}	FE_{28}	FE_{27}	FE_{26}	FE_{25}	FE_{24}
2^{os} Datos	FE_{23}	FE_{22}	FE_{21}	FE_{20}	FE_{19}	FE_{18}	FE_{17}	FE_{16}
3^{os} Datos	FE_{15}	FE_{14}	FE_{13}	FE_{12}	FE_{11}	FE_{10}	FE_{9}	FE_{8}
4^{os} Datos	FE_{7}	FE_{6}	FE_{5}	FE_{4}	FE_{3}	FE_{2}	FE_{1}	FE_{0}

: En esta tabla, un item que ha producido un error se fija en "1", y un item que no produce error se fija en "0". FE_{0} representa un error de partición (PT Error); FE_{1}, un Phase Error; FE_{2}, un Block Error; FE_{3}, un Write Error; FE_{4}, un Length Error; y FE_{5}, un CRC Error. Después, se reservan los bits.

LCD Error

: Derecho de emitir: Dispositivo Periférico

: Código de comando: FAh

: Tamaño de datos: 01 h

: Zona de datos: código de error de función

: Descripción: se emite cuando se produce un error en la Función LCD. Se transmite un error detallado mediante el código de error de función.

: Causas posibles:

\vskip1.000000\baselineskip

TABLA 35 Código de error de función LCD

: En esta tabla, un item que ha producido un error se fija en "1", y un item que no produce error se fija en "0". FE_{0} representa un error de partición (PT Error ); FE_{1}, un Phase Error; FE_{2}, Block Error; FE_{3}, Write Error; FE_{4}, un Length Error; y FE_{5}, ninguno. Después, se reservan los bits.

Información del dispositivo periférico

A continuación, se describe la información inherente (Device Status) que se refiere a un dispositivo base o a un dispositivo de expansión. Los datos del Device Status se almacenan de manera que no se pueden sobreescribir o borrar. Device Status comprende: Fixed Device Status y Free Device Status. El Fixed Device Status es un Device Status predeterminado que tiene un formato de 112 bytes, que siempre hay que definir. Si no se definen todos los datos, no se puede garantizar ni la conexión ni el funcionamiento. El Free Device Status es un Device Status que pueden usar libremente los dispositivos individuales. Tiene una capacidad máxima de 912 bytes.

Fixed Device Status

Todos los datos que vienen a continuación tienen que definirse en el Fixed Device Status.

(1): ID de dispositivo

: Volumen: 16 bytes

: Descripción: indica los atributos del dispositivo periférico y el formato de datos (función). Hay información que se refiere al ID de dispositivo que está en la sección de protocolo.

(2): Región de destino

: Volumen: 1 byte

: Descripción: indica el destino del producto (zona de venta). La Tabla 36 muestra la composición de los bits de selección de la región de destino. La Tabla 37 muestra la relación entre los bits de selección de región de destino y las regiones de destino.

TABLA 36 Formación de bits de selección para la zona de destino

Bit	7	6	5	4	3	2	1	0
Datos	DES_{7}	DES_{6}	DES_{5}	DES_{4}	DES_{3}	DES_{2}	DES_{1}	DES_{0}

TABLA 37 Bits de selección para los destinos

Zonas de destino	Bits de selección
América de Norte	DES_{0} = "1"
Japón	DES_{1} = "1"
Asia	DES_{2} = "1"
Europa	DES_{3} = "1"
Área reservada 1	DES_{4} = "1"
Área reservada 2	DES_{5} = "1"
Área reservada 3	DES_{6} = "1"
Área reservada 4	DES_{7} = "1"

: Por ejemplo, en el caso de un destino global común, DES = "11111111" = FFh, y en el caso de un destino común de Japón y Asia, DES = "00000110" = 06 h. Está prohibido fijar DES en 00 h.

(3): Nombre del producto

: Volumen: 31 bytes

: Descripción: ofrece el nombre del producto en inglés o alfabeto romano. Se puede usar el formato Em o en. En el volumen libre (bits) se insertan códigos de espacio. Este nombre de producto se registra previamente.

(4): Licencia

: Volumen: 60 bytes

: Descripción: descripción del código ASCII de la licencia del producto en inglés o alfabeto romano. Se insertan códigos de espacio (20 h) en los bits libres. Por ejemplo, "producido por o con la licencia de XXXXX, LTD.".

(5): Consumo de corriente en espera

: Volumen: 2 bytes

: Descripción: muestra el consumo de corriente en espera durante una detención temporal en unidades de 0,1 mA, en notación hexadecimal. Por ejemplo, si el valor es 10,5 mA, los datos son 00-69 h.

(6): Máximo consumo de corriente

: Volumen: 2 bytes

: Descripción: describe un consumo de corriente máximo en unidades de 0,1 mA, en notación hexadecimal. Por ejemplo, si el valor es 127,9 mA, los datos son 04-FFh.

Free Device Status

El Free Device Status es una zona que puede copiar libremente el planificador de los productos, el constructor, el diseñador, el programador o similar, y el servidor la puede recuperar mediante un All Device Request. Cuando se usa el software de aplicación, etc., es necesario que combine la configuración de los datos, y similares.

A continuación se describen otros ejemplos de dispositivos base y dispositivos de expansión que usan la presente invención con referencia a los dibujos.

La Figura 81 muestra una ilustración aproximada de un ejemplo de la composición de otro dispositivo base (controlador) que se refiere al primer modo de ejecución, que usa direcciones relativas. En el ejemplo de la composición de una función de dispositivo-U que se ilustra en la Figura 33, donde se usa un sistema de direcciones relativas, la presencia o ausencia de una conexión de dispositivo de expansión la juzga el terminal SDCKA OUT (conectado a una resistencia), aunque en el presente ejemplo, se proporciona un terminal ID2 conectado a una resistencia R en cada conector de expansión, de manera similar al ejemplo de la Figura 64, y la presencia o ausencia de una conexión de socket de expansión se juzga identificando el voltaje que se genera en este terminal. En la Figura 81, el circuito de control de un dispositivo base (controlador de juego) 2 puede estar formado por un sistema microinformático de un solo chip 200. El sistema informático 200 comprende: una CPU 201a para controlar cada sección; una ROM 201b para almacenar programas de control y librerías de datos para la CPU 201a; una RAM 201c para almacenar programas de la CPU y datos y ejecutar procesamientos de datos; una sección I/O 202a para transformar operaciones de presión que están en 11 switches digitales 206 en datos código; un convertidos A/D 202b para transformar salidas de nivel variable desde cuatro switches analógicos 207 a una señal de datos; y un MIE de dispositivo base 205 para controlar las comunicaciones de datos entre el dispositivo base y el servidor y mantener las comunicaciones de datos entre un dispositivo de expansión y el servidor. Además, el sistema informático 200 comprende: un circuito generador de señales de reinicialización, que comprende resistores, capacitores y diodos, para generar una señal de reinicialización cuando se conecta la energía; un oscilador cristalino para generar varias señales de reloj para el sistema; y un circuito transformador de voltaje para generar un voltaje eficaz de señal de 3,3V para el MIE del dispositivo base 205 y para los dispositivos de expansión desde una fuente de energía Vcc (+5V). La fuente de energía Vcc (+5V) que va al dispositivo base la suministra el dispositivo de juego vía un cable de conexión externo. El cable de conexión externo comprende la línea de señales SDCKA, la línea de señales SDCKB, la línea de suministro de energía Vcc, y una línea a tierra GND. La fuente de energía Vcc (+5V) que suministra el dispositivo de juego a través del cable de conexión externo alimenta los dispositivos de expansión (se omiten del dibujo) junto con el suministro de potencia de señal (+3,3V) mediante el conector de
expansión.

La sección de la CPU 201a, la ROM 201b y la RAM 201c corresponden a la CPU en la Figura 33, el transformador A/D 20b y la sección I/O 202a corresponden a I/O en la Figura 33, y el MIE del dispositivo base 205 corresponde a la sección de procesamiento de comunicaciones, la sección de control de socket y las puertas en la Figura 33. La fuente de energía VCC y la línea a tierra GND se suministran al dispositivo base 2 desde el servidor mediante un bus M. Además, las comunicaciones de datos se controlan mediante la líneas de señales SDCKA y SDCKB. El dispositivo base y el dispositivo de expansión se conectan mediante: líneas de señales SDCKA-US-1, SDCKA-DS-1, SDCKA-EN-1, SDCKB-US-1, SDCKB-DS-1, SDCKB-EN-1, SDCKA-US-2, SDCKA-DS-2, SDCKA-EN-2, SDCKB-US-2, SDCKB-DS-2, SDCKB-EN-2, la fuente de energía Vcc (+5V, 3,3V) y las líneas a tierra GND (cuatro líneas). En este ejemplo, se ha descrito un dispositivo base que tiene dos conectores de expansión, aunque como se ha explicado antes, es posible proporcionar cuatro conectores de expansión externos. En este caso, se usan cuatro terminales ID2, ID2-1 a ID2-4 para confirmar si el dispositivo está o no conectado. La función del dispositivo base 2 es la misma que la función del dispositivo-U que se ilustra en la Figura 33, y por tanto se aquí se omite la descripción.

La Figura 82 muestra otro ejemplo de la composición de un dispositivo base (controlador) que se refiere a un segundo modo de ejecución, que usa direcciones absolutas y corresponde al ejemplo de la Figura 81 que usa direcciones relativas. En este diagrama, las secciones que corresponden a la Figura 65 o a la Figura 81 se han identificado de manera similar y no se describen aquí. En un dispositivo base que emplea un sistema de direcciones absolutas, el bloque I/O 202a indica un número de bus M a un dispositivo de expansión que se conecta vía los terminales ID0 e ID1 de cualquiera de los sockets de expansión, según la salida de la CPU. El papel de los terminales ID0 e ID1 se ha descrito en el procedimiento de establecimiento de AP de dispositivo de expansión a que se refiere a la Figura 59. Desde el I/O 202a, los terminales ID0-1 e ID1-1 se proporcionan en el primer socket de expansión y los terminales ID0-2 e ID1-2 se proporcionan en el segundo socket de expansión.

La Figura 83 y la Figura 84 muestran ejemplos de un dispositivo de expansión provisto de un dispositivo LCD (cartucho LCD) en una sistema de direcciones relativas y un sistema de direcciones absolutas, respectivamente. En este diagrama, el circuito de control del dispositivo de expansión (cartucho LCD) 3 puede formarse con el denominado sistema microinformático de un solo chip 300. El sistema microinformático 300 comprende:

: una CPU 301 para controlar cada sección; una ROM 302 para almacenar programas de control y librerías de datos para la CPU 301; una RAM 303 para almacenar programas de la CPU y datos y ejecutar procesamiento de datos; un MIE de dispositivo de expansión 304 para controlar las comunicaciones de datos entre el dispositivo de expansión y el servidor; una sección I/O 305 que ejecuta una interfaz de entrada y salida; un controlador LCD 306 para controlar la representación visual del LCD 308; y un driver LCD 307 para accionar el elemento LCD.

El MIE de dispositivo de expansión 304 se constituye de manera similar al MIE del dispositivo base, aunque no está provisto ni de un controlador de bus LM 203a ni de puertas. El cartucho LCD almacena datos de texto, datos de imágenes fijas, datos de imágenes animadas (que incluyen información LD, CD-V, DVD y vídeo TV) y equivalentes que se transmiten en formato frame desde el servidor vía el bus M, el bus LM y el MIE 304 en la RAM 303. Estos datos que se van a mostrar visualmente los suministra después la CPU 301 al controlador LCD 306 y los transforma en imágenes.

Además, el sistema informático 300 también comprende un circuito de generación de señales de reinicialización para generar una señal de reinicialización cuando se conecta la fuente de energía, un oscilador de cristal para generar una señal de reloj y, si es necesario, se proporciona un circuito transformador de voltaje (se omite en los dibujos) para generar un voltaje de 3,3V para la señal del MIE del dispositivo 205, o equivalente, desde la fuente de energía Vcc (+5V). La fuente de energía Vcc (5V, 3,3V) la suministra el dispositivo base, aunque es posible que el dispositivo de expansión genere los voltajes que necesita para conseguir sus funciones mediante un circuito interno. En la línea de transmisión de señales ID2, el voltaje de la fuente de energía Vcc se aplica en el lado del dispositivo de expansión. Como se ha explicado antes, en el sistema de direcciones absolutas del dispositivo de expansión, los terminales ID0 e ID1 para indicar el número de bus LM se conectan a la sección I/O 305.

Las Figuras 85 y 86 muestran ejemplos de cartuchos de memoria (dispositivos de expansión) en un sistema de direcciones relativas y en un sistema de direcciones absolutas, respectivamente. En estos diagramas, a las secciones que corresponden a las Figuras 83 y 84 se les asigna los mismos símbolos, y se omite la descripción de estas secciones.

En este ejemplo, se proporciona una RAM fija 312, por ejemplo EEPROM o memoria con batería de reserva, etc. Los datos que se van a retener se almacenan en la RAM 303 mediante el MIE 304. La CPU 301 copia los datos almacenados en la RAM fija 312 a través del driver del bus de salida externo 311. Además, según las instrucciones procedentes del servidor, la CPU 301 también lee los datos escritos en la RAM 312 a la RAM 303, y después los transfiere al servidor vía el MIE 304. Por ejemplo, si el jugador detiene el juego a medias, si almacena los parámetros del juego transmitidos por el servidor hasta ese punto medio del juego, es posible empezar el siguiente juego desde ese punto medio. La RAM fija 312 se conecta con el driver del bus 311 vía un socket y puede cambiarse por múltiples RAMs fijas 312 en forma de una tarjeta. También es posible colocar una RAM fija 312 en el sistema informático
300.

Las Figuras 87 y 88 muestran ejemplos de cartuchos vibratorios (dispositivos de expansión) en un sistema de direcciones relativas y un sistema de direcciones absolutas, respectivamente. En estos diagramas, a las secciones que corresponden a las Figuras 83 y 84 se les asigna los mismos símbolos, y se omite la descripción de estas secciones.

En estos ejemplos, se proporciona una sección driver/controlador 321 para accionar una unidad vibratoria 322 mediante un motor, un solenoide o equivalente, que hace que un peso excéntrico gire, generando así una vibración. Un comando de activación o de paro de señal para la unidad de vibración se almacena en la RAM 303 mediante el servidor vía el MIE 304, y se suministra mediante la CPU 301 a la sección driver/controlador 321 vía la sección I/O 305.

Las Figuras 89 y 90 muestran ejemplos de cartuchos de armas luminosas (dispositivos de expansión) en un sistemas de direcciones absolutas y un sistema de direcciones relativas, respectivamente. En los diagramas, a las secciones que corresponden a las Figuras 83 y 84 se les asigna los mismos símbolos, y se omite la descripción de estas secciones.

En estos ejemplos, el punto de iluminación de un haz de electrones que escanea una parte determinada (punto de mira del arma luminosa) de una pantalla de vídeo, es leído por un elemento fotorreceptor 332 vía una lente del cartucho del arma luminosa. El nivel de la señal del fotorreceptor se amplifica en un amplificador 331. Cuando se acciona el gatillo (por ejemplo, el elemento 2d en la Figura 97(b) que se describe después) del controlador del juego, se genera la señal de gatillo y la salida desde el amplificador 331 se suministra como una señal de detección al MIE 304. Esta señal se transfiere al servidor y se usa como una señal de bloqueo para el contador HV.

Las Figuras 91 y 92 muestran ejemplos de cartuchos de entrada de sonido (dispositivos de expansión) en un sistema de direcciones absolutas y un sistema de direcciones relativas, respectivamente. En los diagramas, a las secciones que corresponden a las Figuras 83 y 84 se les asigna los mismos símbolos, y se omite la descripción de estas secciones.

En estos ejemplos, se amplifica la salida de un micrófono 345 hasta un nivel adecuado mediante un amplificador 344 y después se muestrea con un transformador A/D 343. Los datos del sonido muestreados se almacenan alternativamente en unos registros primero y segundo (FIFO) de una memoria de búfer 342. Estos datos los lee un controlador de bus 341 y los transmite al búfer del transmisión y recepción del MIE 304. Los datos de sonido se forman como frames mediante el MIE 304 y se transmiten al servidor (dispositivo de juego). Esta función hace posible que se pueda usar el servidor como entrada de sonido, "karaoke", teléfono o dispositivo de comunicación.

Las Figuras 93 y 94 muestran ejemplos de cartuchos de entrada de sonido (dispositivos de expansión) en un sistema de direcciones absolutas y un sistema de direcciones relativas, respectivamente. En los diagramas, a las secciones que corresponden a las Figuras 83 y 84 se les asigna los mismos símbolos, y se omite la descripción de estas secciones.

En estos ejemplos, los datos de sonido transmitidos por el servidor se suministran desde el MIE 304 a un controlador de bus 351 vía un bus local. El controlador de bus 351 almacena datos de sonido en una memoria 352 que tiene como base una operación FIFO (First In First Out), y enlaza datos de sonido que se transmiten sucesivamente. Los datos de sonido que emite la memoria 352 se transforman en una señal de sonido mediante un transformador D/A 352, se amplifica su nivel mediante un amplificador 354, y se emite como sonido desde un altavoz 355. Este tipo de función permite al servidor funcionar como un dispositivo de respuesta de sonido (salida de sonido), dispositivo de efectos de sonido de juego (en particular efectos de sonido que múltiples altavoces), dispositivo de "karaoke", receptor de teléfono o equivalente.

Los modos anteriores para ejecutar la presente invención describen dos formatos estándar, aunque también es posible combinar elementos del primer modo de ejecución con elementos del segundo modo de ejecución, siempre que esto no produzca incompatibilidades tecnológicas. Además, la presente invención no se limita a aplicaciones de dispositivos de juego sino que también se puede usar como sistemas informáticos a pequeña escala, redes de ordenador, aparatos informáticos, dispositivos terminales de comunicaciones portátiles, y equivalentes.

Las Figuras 95 y 96 ilustran otros modos de ejecución, en los que el bus M que conecta el servidor con los dispositivos periféricos tiene una construcción inalámbrica. En estos diagramas, a las secciones que corresponden a los modos de ejecución primero y segundo se les asigna los mismos símbolos y no se describen aquí.

En la Figura 95, dispositivos MODEM de radio 500 están conectados respectivamente al controlador periférico 1h de un servidor (dispositivo de juego) 1 y al controlador periférico de un dispositivo de juego (dispositivo base) 2. Los MODEM de radio 500 comprenden: un controlador de datos 501, una sección de transmisión 502, un duplexor 503, una sección de recepción 504, una antena 505 y similares, y retransmiten datos de transmisión entre el servidor y un dispositivo periférico. En este caso, el dispositivo periférico 2 puede ser accionado mediante una batería.

El controlador de datos 501 ejecuta una modulación de múltiples valores de las señales SDCKA y SDCKB que se van a transmitir, por ejemplo, para transmitir mediante una modulación QPSK de desplazamiento \eta/4, se procesan los datos para crear un componente de señal I y un componente de señal Q. Estos componentes de datos ortogonales se suministran a la sección de transmisión 502. Además, el controlador de datos 501 crea una señal SDCKA y una señal SDCKB desde los componentes de datos I y Q descodificados por la sección de recepción 504, y suministra estas señales al controlador periférico 501. La sección de transmisión 502 comprende un modulador de múltiples valores, por ejemplo un modulador ortogonal para una modulación QPSK de desplazamiento \eta/4, y crea una señal portadora de frecuencia f_{1} para ejecutar los datos del frame. Esta señal portadora se suministra a la antena 505 mediante el duplexor 503, y se transmite al espacio libre como una onda electromagnética. Por otro lado, en el dispositivo periférico 2, la onda electromagnética que recibe la antena 505 forma una señal portadora que se suministra a la sección de recepción 504 mediante el duplexor 503. La sección de recepción 504 comprende, por ejemplo, un detector de ondas sincrónico, que separa el componente de señal I y el componente de señal Q de la señal portadora, y desmodula los datos de valores múltiples. Como se ha explicado antes, el controlador de datos 501 crea una señal SDCKA y una señal SDCKB a partir de estos datos de valores múltiples y los suministra al controlador periférico 501.

Por tanto, los cables y equivalentes para el bus M que conecta el servidor y el dispositivo periférico se quedan obsoletos. El dispositivo periférico inalámbrico 2 aumenta la libertad en las especificaciones de uso y en el diseño de la estructura separada del servidor. El mencionado dispositivo inalámbrico Modem 500 puede usar también un dispositivo de teléfono portátil (o dispositivo PHS). En este caso, se pueden conseguir chips IC relativamente económicos, y no solo es posible el uso inalámbrico del dispositivo periférico sino que también se puede usar un juego competitivo o Internet conectando el servidor a un circuito de comunicaciones.

El sistema de transmisión y el sistema de recepción pueden duplicarse según las dos señales SDCKA y SDCKB, o se puede usar una composición que emplee dos canales de transmisión f_{1} y f_{2}. Además, después de hacer que la señal SDCKA y la señal SDCKB vuelvan a ser señales frame de datos en serie, los datos se pueden transmitir al otro lado mediante un único canal de comunicaciones f_{1}, descodificándose la señal SDCKA y la señal SDCKB a partir de la señal desmodulada del frame del lado receptor.

La Figura 96 muestra un ejemplo en el que la composición inalámbrica que se muestra en la Figura 95 está formada por comunicaciones ópticas. En este diagrama, a las secciones que corresponden a la Figura 95 se les asigna los mismos símbolos, y estas secciones no se describen aquí.

En este ejemplo, un dispositivo Modem infrarrojo 600 está formado por un controlador de datos 601, un modulador, una sección de emisión de luz 603, una sección de recepción de luz 604, una sección desmoduladora 605, y equivalentes. El controlador de datos 601 hace que la señal SDCKA y la señal SDCKB vuelvan a ser señales frame de datos en serie. El modulador 602 modula la corriente de excitación mediante una señal de frame. Por ejemplo, se puede seleccionar la modulación de nivel o la modulación de frecuencia. La corriente de excitación se suministra a un elemento emisor de luz de la sección de emisión de luz 603, por ejemplo un LED de emisión de infrarrojos para encender y apagar el LED. La luz destellante del LED se transmite externamente vía un sistema óptico. Esta luz transmitida se introduce en la sección de recepción de luz 604 del otro dispositivo módem infrarrojo 600. La luz introducida se transforma en una señal eléctrica mediante un elemento fotorreceptor, por ejemplo un fototransistor, y después se desmodula en una señal de datos digitales mediante la sección de desmodulación 605. Esta señal de datos se vuelve a transformar en una señal SDCKA y una señal SDCKB mediante el controlador de datos 601, y se transmiten al controlador periférico. El controlador periférico del servidor (dispositivo de juego) 1 o el dispositivo periférico 2 ya se han descrito. De este modo, el bus M puede estar formado por un sistema (inalámbrico) de radio en vez de por un sistema con cables.

A continuación, se describen los conectores y equivalentes que están en el servidor y el dispositivo periférico con referencia a la Figura 97. La Figura 97(a) es un diagrama ilustrativo que muestra un conector de bus M que conecta un dispositivo de juego 1, que forma el servidor, con un dispositivo base (controlador de juego) 2, que forma un dispositivo periférico. En este diagrama, a las secciones que corresponden a la Figura 1 se les asignan los mismos símbolos.

En el ejemplo de la Figura 97, se proporcionan cuatro conectores (sockets) 1i en la cara lateral del dispositivo de juego. Los conectores (clavijas) 110 del controlador de juego 2 se conectan a cualquiera de los conectores 1i. Los sockets 1i y las clavijas 110 tienen cada una el siguiente formato que comprende 5 terminales (pins). En la cara superior del controlador de juego 2, se proporcionan unos botones A, B, C y D (switches A, B, C, D) 2a y una tecla en cruz 2b (switch direccional arriba/abajo izquierda/derecha), y en la sección de sujeción del controlador de juego, se proporciona una palanca de gatillo (interruptor de gatillo) 2d (ver Figura 97(b)). Estos botones diferentes accionan los switches de entrada digitales 206. Además, se proporcionan botones analógicos (teclas analógicas) 2c para accionar unos switches analógicos 207 con el fin de controlar la entrada analógica. Las teclas analógicas se utilizan, por ejemplo, para mover cursores y punteros por la pantalla.

La Figura 97(b) es un diagrama ilustrativo para describir un conector de bus M 131 que conecta el dispositivo base (controlador de juego) 2 con el dispositivo de expansión 3 (se omite de los dibujos). En este diagrama, a las secciones que corresponden a la Figura 97(a) se les asignan los mismos símbolos, y no se describen aquí. En el lado posterior del controlador de juego 2 que está orientado hacia el dispositivo de juego 1c, se proporcionan dos conectores de bus M (sockets) 131.

La Figura 98(a) muestra otro ejemplo de un controlador de juego. Este controlador de juego tiene funciones que incorporan un controlador de juego. En este diagrama, el controlador de juego 2 comprende unos botones A, B, C y D 2a, una tecla en cruz 2b, teclas analógicas 2c, una palanca 2d (ver Figura 97(b) descrita), y un botón de puesta en marcha (interruptor de puesta en marcha) 2e. Además, se proporciona una ranura para insertar un dispositivo de expansión en el lado posterior del controlador de juego (ver Figura 97(b)). Se proporciona una ventana 2f en el centro de la cara superior del controlador de juego 2, hacia el lado posterior del mismo.

La Figura 98(b) muestra un ejemplo de un cartucho LCD que forma un dispositivo de expansión 3. El cartucho LCD está formado de manera que cuando el cartucho LCD 3 se inserta en la ranura mencionada y se conecta al controlador de juego 2 a través del conector de expansión 131, el panel LCD 308 se coloca directamente debajo de la ventana 2f. En consecuencia, cuando se conecta un cartucho LCD 3 al controlador de juego 2, es posible ver imágenes de vídeo y equivalentes que se transmiten desde el dispositivo de juego 1 del controlador de juego 2. Además, este cartucho LCD 3 está provisto también de una tecla en cruz 2b, de unos botones A, B, C y D 2a y similares, de manera que el cartucho LCD 2 como unidad se puede usar como dispositivo de juego portátil.

Las Figuras 99 a 101 son diagramas que muestran la composición del conector de bus M que se usa en un bus M.

La Figura 99 es una ilustración aproximada del lado de la toma de corriente de un conector de bus 1i en el caso de un servidor 1, visto de frente (se inserta un conector de dirección). El socket comprende una sección con un perímetro en forma más o menos de D 101, una base de pin hexagonal con forma más o menos de D 102 y una ranura con forma más o menos de D 103 formada entre la sección del perímetro 101 y la base de pin 102. El socket es un molde extruído de plástico aislante y los pins de contacto 1, 3, 5 conforman la cara principal (cara superior) de la base de pins 102, mientras que los pins de contacto 2, 4 se colocan en la cara opuesta (cara inferior), que es paralela a la cara principal. El pin de contacto 2 está situado enfrente de la zona aislante entre los pins de contacto 1, 3, de manera que no es probable que se produzca acoplamiento capacitivo con los pins de contacto 3 ó 5. Cada pin de contacto es un componente metálico flexible y se conecta respectivamente a cinco terminales de conexión de placas de circuitos que están en el lado posterior de la base de pin 102, que se omite en los dibujos. Los pins de contacto 1 y 5 se conectan respectivamente a líneas de datos SDCKA y SDCKB. El pin de contacto 3 que está entre el pin de contacto 1 y el 5 se conecta a un alambre blindado que evita el acoplamiento entre los pins de contacto 1 y 5 que están conectados, respectivamente, a las líneas de datos. Los pins de contacto 2 y 4 son líneas de suministro de energía y se conectan, respectivamente, a una fuente de energía Vcc y a una línea a tierra GND. Como se ha explicado antes, las superficies de metal de los pins de contacto 2 y 4 se colocan de manera que no queden directamente opuestas a las superficies de metal de los pins de contacto 1, 3 y 5 y por tanto la fuente de energía Vcc y la línea a tierra GND tienen poco efecto sobre las líneas de datos.

La Figura 100 muestra la composición del lado de conexión del conector de bus 1i que corresponde a esta socket. La Figura 100(a) es una vista lateral del conector; la Figura 100 (b) es una vista superior; y la Figura 100(c) es una vista frontal. El conector se moldea a partir de un plástico con buenas propiedades aislantes, y 111 es una carcasa para alojar las secciones de conexión que hay entre cables y terminales pin, 112 es una sección de inserción que tiene una sección transversal en forma más o menos de D que se corresponde con la forma de la ranura 103 del socket, 113 es una pared interna con forma más o menos de D de la sección de inserción, 114 es una ranura que tiene una forma que se corresponde con la forma externa de la base de pin 102, y los números 1 a 5 son pins de contacto situados en la pared interna 113. Cada pin de contacto es un componente metálico flexible y se coloca, en correspondencia con los pins determinados, en el socket. Los dos conjuntos de pins de contacto 1 a 5 se conectan entre si insertando la sección de inserción 112 del conector en la ranura 103 del socket.

La Figura 101 es una vista lateral que ilustra un conector (enchufe) que está en el lado del dispositivo periférico (dispositivo base) de un cable de bus M. El conector 121, que se moldea a partir de un plástico con buenas propiedades aislantes, comprende los terminales 1 a 5 que conectan los diferentes alambres del cable. Los terminales se proporcionan en fila en un lado de un socket que tiene forma aproximadamente rectangular o de placa. Este socket 121 se conecta a los alambres de una placa de circuitos que está en el dispositivo periférico mediante un conector (socket) o directamente soldando.

La Figura 102 muestra un ejemplo de la composición de un socket 131 de un conector de bus LM que conecta un dispositivo base con un dispositivo de expansión. La Figura 102(a) es una vista superior y la Figura 102(b) es una vista frontal. Además, la Figura 103 muestra un ejemplo de la composición de una clavija 141 de un conector de bus LM. La Figura 103(a) es una vista superior, y la figura 103(b) es una vista frontal.

En términos generales, el socket comprende una sección de inserción 132, una sección de recepción 133 y una carcasa 134 que acomoda estas dos secciones. De manera similar, la clavija 141 también comprende una sección de inserción 142, una sección de recepción 143 y una carcasa 144 que acomoda estas dos secciones. La sección de inserción 132 del socket 131 se inserta en la sección de recepción 143 de la clavija 141, y la sección de inserción 142 de la clavija 141 se inserta en la sección de recepción 133 del socket 131.

La sección de inserción 132 del socket 131 es un componente con forma de barra que se proyecta desde el lado izquierdo de la cara frontal de la carcasa 134 y una ranura de inserción 132a que tiene forma rectangular delgada que se prolonga en una dirección lateral está formada en el extremo frontal de este componente en forma de barra. La ranura de inserción es una ranura provista para insertar la sección de inserción 132 en una ranura 143a que está en la clavija 141 de manera que se coloca, por encima de una base de pin con forma de placa 143c, en la ranura 143a. La ranura de inserción 132a se forma hacia la parte inferior del extremo del componente en forma de barra desde del centro del mismo en dirección vertical, para evitar una inserción incorrecta, y también para colocar los múltiples pins de contacto aproximadamente en el centro del componente en forma de barra 132. Los pins de contacto metálicos 1 a 7 se proporcionan en fila en la cara superior de la pared interna 132b de la ranura de inserción 132a. Estos pins de contacto se colocan aproximadamente en posición central en la dirección vertical de la unidad en forma de barra 132. Aunque no se muestra en el diagrama, cada uno de los pins de contacto 1 a 7 se prolonga hasta múltiples terminales de conexión que están provistos respectivamente en correspondencia con los pins de contacto 1 a 7, en el lado posterior de la carcasa 134, y por tanto conectados a unos alambres o cable de una placa de circuitos. Los pins de contacto 1 a 7 se conectan respectivamente a una línea de suministro de energía Vcc (3,3V), una línea de suministro de energía Vcc (5V), una línea de control SDCKA EN, una línea de datos SDKB DS, una línea de datos SDCKA US, una línea de identificación ID1, una línea a tierra GND.

La sección de recepción 133 del socket 131 es un componente con forma de barra que se proyecta desde el lado derecho de la cara frontal de la carcasa 134 y una ranura en forma de O 133a que rodea la base de pin 133c está formada en el extremo frontal de este componente en forma de barra 133. La forma de la pared interna 133b de la ranura 133a corresponde a la forma externa de la sección de inserción 142 de la clavija 141. La base de pin 133c que está en el centro de la ranura es un componente en forma de placa que tiene una forma que se corresponde con la ranura rectangular delgada 142a que se prolonga en dirección lateral. La cara superior de la base de pin 133c está formada de manera que queda en posición más o menos central en la dirección vertical del extremo del componente en forma de barra 133, y unos pins de contacto metálicos flexibles 8 a 14 se colocan en esta cara superior. Aunque no se muestra en el diagrama, los pins de contacto correspondientes 8 a 14 se conectan respectivamente a una línea a tierra GND, a una línea de identificación ID2, a una línea de datos SDKB DS, una línea de datos SDCKB US, a una línea de control SDCKB EN y a una línea de identificación ID0. El pin de contacto 14 no se usa ahora y constituye un terminal de reserva.

La clavija 141 que se inserta en el socket 131 se forma de manera parecida al socket 131. Sin embargo, como se muestra en la Figura 103(a), los pins de contacto 1 a 7 se proporcionan dentro de la sección de recepción 143, y los pins de contacto 8 a 14 se proporcionan dentro de la sección de inserción 142.

Ya que el conector de expansión que tiene la composición mencionada comprende las secciones de inserción 132, 142 y las secciones de recepción 133, 143, que están formadas cada una de manera separada y que tienen formas externas diferentes entre si, el usuario puede identificar de un vistazo la dirección en la que se van a conectar el socket 131 y la clavija 141. Además, ya que la conexión sólo es posible en una dirección (configuración), no se produce una conexión incorrecta. Además, es una ventaja que las manos del usuario no toquen directamente los pins de conexión.

Como se ha descrito antes, según la presente invención, se puede llevar a cabo la comunicación de datos entre un dispositivo de juego (o servidor) y dispositivos periféricos mediante dos líneas de datos y una composición de circuito I/O relativamente simple.

Además, cuando se realizan comunicaciones de datos, ya que las direcciones se establecen automáticamente para múltiples dispositivos conectados a una red, los dispositivos periféricos se pueden conectar libremente al dispositivo de juego (o servidor), y el dispositivo de juego puede identificar los detalles de un dispositivo periférico conectado que está, preferentemente, en un sistema informático orientado al consumidor, por ejemplo un dispositivo de juego.

Claims

1. Método de transmisión de datos para transmitir en serie una señal de reloj y datos formados por múltiples bits de datos vía un par de canales de transmisión de señales, donde se generan una señal de reloj para incluir una primera secuencia de pulsos de reloj y una segunda secuencia de pulsos de reloj con el mismo periodo cíclico que el de la primera secuencia de pulsos de reloj aunque con un desfase entre si,

caracterizado porque:

se asignan dichos múltiples bits de datos de los datos alternativamente en orden a dichas secuencias primera y segunda de pulsos de reloj de manera que se asigna en orden cada segundo bit de datos de dichos múltiples bits de datos entre pulsos de reloj de la primera secuencia de pulsos de reloj para proporcionar una primera señal de datos, con lo cual se asigna en orden cualquier otro segundo bit de datos que no sea cada segundo bit mencionado de dichos múltiples bits de datos entre pulsos de reloj de la segunda secuencia de pulsos de reloj para proporcionar una segunda señal de datos, y de manera que un bit de datos asignado en una de dichas secuencias primera y segunda de pulsos de reloj se produce en un momento determinado que corresponde a una transición de un pulso de reloj en la otra de dichas secuencias primera y segunda de pulsos de reloj; y

se transmiten en serie una de dichas señales de datos primera y segunda vía uno de los mencionados pares de canales de transmisión de datos y la otra señal de datos vía el otro canal de transmisión de señales,

donde, en un receptor de datos, dichos múltiples bits de datos de los datos se recuperan de las señales de datos primera y segunda recibidas vía dicho par de canales de transmisión de señales.

2. Método de transmisión de datos según la reivindicación 1, caracterizado porque cada segundo bit de datos mencionado asignado en dicha primera secuencia de pulsos de reloj es un bit impar de los datos y los otros segundos bits de datos mencionados asignados a dicha segunda secuencia de pulsos de reloj son bits pares de los datos.

3. Método de transmisión de datos según la reivindicación 1 ó 2, caracterizado porque:

dichas señales de datos primera y segunda están dispuestas para formar un formato de transmisión de datos que incluye, como frame de datos, un patrón de puesta en marcha, un patrón de datos y un patrón de fin, en una transmisión que sincroniza el patrón de puesta en marcha anterior con el patrón de datos y con el patrón de fin que va después del patrón de datos,

dicho patrón de puesta en marcha incluye un formato de datos en el que, mientras se suministra un nivel de potencial constante como primera señal de datos, se suministra una primera secuencia de pulsos sucesivos como segunda señal de datos,

dicho patrón de fin incluye un formato de datos en el que, mientras se suministra un nivel de potencial constante como segunda señal de datos, se suministra una segunda secuencia de pulsos sucesivos como primera señal de datos, y

dicho patrón de datos incluye, como primera señal de datos, dicha primera secuencia de pulsos de reloj con cada segundo bit de datos mencionado de los datos asignados y, como segunda señal de datos, dicha segunda secuencia de pulsos de reloj con los otros segundos bits de datos mencionados de los datos asignados.

4. Método de transmisión de datos según la reivindicación 3, caracterizado porque dicho nivel de potencial constante es o bien un potencial procedente de una fuente de alimentación o bien el potencial de tierra y/o donde dichas secuencias primera y segunda de pulsos sucesivos están formadas por un número diferentes de pulsos la una de la otra.

5. Método de transmisión de datos según cualquiera de las reivindicaciones 1 a 4, caracterizado porque, en el receptor de datos, dichos bits de datos de los datos que están incluidos en las señales de datos recibidos primera y segunda se recuperan bloqueando sucesivamente el nivel de potencial de una de dichas señales de datos durante la sincronización del componente de la señal de reloj de las otras señales de datos mencionadas.

6. Método de transmisión de datos según cualquiera de las reivindicaciones 1 a 5, donde la detección de dicho componente de señal de reloj se realiza bien con el borde descendente o bien con el borde ascendente de cada pulso de una secuencia de impulsos.

7. Dispositivo de juego que comprende un puerto periférico al que se puede conectar un dispositivo periférico, donde las señales de datos que incluyen datos y una señal de reloj se transmiten entre el dispositivo de juego y el dispositivo periférico vía una ruta de transmisión de señales, comprendiendo dicho dispositivo de juego medios adaptados para llevar a cabo las fases del método según cualquiera de las reivindicaciones 1 a 6.

8. Dispositivo de juego según la reivindicación 7 que comprende múltiples puertos periféricos pudiéndose conectar a cada uno un dispositivo de juego,

caracterizado porque:

cada uno de los puertos de los múltiples puertos periféricos está definido por una dirección de puerto única, y, cuando se conecta un dispositivo periférico a uno de dichos puertos periféricos, tal dispositivo de juego suministra datos al dispositivo periférico presentando una dirección de puerto única al puerto periférico al que está conectado el dispositivo periférico.

9. Dispositivo de juego según la reivindicación 8, caracterizado porque el dispositivo de juego transmite datos al dispositivo periférico según dicho formato de transmisión de datos con un parámetro, en tal patrón de datos, incluyendo una dirección que representa el dispositivo periférico conectado al dispositivo de juego y la dirección que representa el puerto periférico al que se conecta el dispositivo periférico.

10. Dispositivo de juego según cualquiera de las reivindicaciones 7 a 9, caracterizado porque dicha ruta de transmisión de señales está formada por un par de líneas de señales de datos a través de las cuales se transmiten por separado las citadas señales de datos primera y segunda.

11. Dispositivo periférico que se puede conectar a un puerto periférico del dispositivo de juego vía una ruta de transmisión de señales, donde las señales de datos que incluyen datos y una señal de reloj se transmiten entre el dispositivo periférico y el dispositivo de juego, comprendiendo dicho dispositivo periférico medios adaptados para llevar a cabo las fases del método según cualquiera de las reivindicaciones 1 a 6.

12. Dispositivo periférico según la reivindicación 11, caracterizado porque está adaptado para reproducir los datos transmitidos de las señales de datos primera y segunda transmitidas desde el dispositivo de juego y para transmitir a dicho dispositivo de juego datos en respuesta a una petición de transmisión de datos contenida en los datos reproducidos.

13. Dispositivo periférico según la reivindicación 11, caracterizado porque está adaptado para conectarse a cualquier puerto periférico de los múltiples puertos periféricos del dispositivo de juego.

14. Dispositivo periférico según la reivindicación 13, caracterizado porque el dispositivo periférico incluye al menos una función de dispositivo, generándose dicha dirección de origen que representa el dispositivo periférico, mientras está conectado al puerto periférico, en base a la información que representa el tipo de dicha función de dispositivo, a la información que representa un estado de conexión de dicha función de dispositivo con dicha ruta de transmisión de señales y en base a los datos que representan la dirección de puerto suministrada por dicho dispositivo de juego.

15. Dispositivo periférico según la reivindicación 13 ó 14, caracterizado porque

el dispositivo periférico se almacena junto con información de identificación indicativa de que el dispositivo periférico es un tipo de dispositivo periférico principal que se va a conectar directamente a dicho dispositivo de juego;

el dispositivo periférico comprende además un conector de expansión a través de cual se conecta un periférico de expansión con dicha ruta de transmisión de señales;

dicha dirección de origen que representa el dispositivo periférico principal, mientras está conectada al puerto periférico, se genera en base a la información que representa el tipo de dispositivo periférico principal, a los datos que representan la dirección de puerto que suministra dicho dispositivo de juego y a la información de conexión indicativa del estado de conexión o no conexión del dispositivo de expansión a dicho conector de expansión.

16. Dispositivo periférico según la reivindicación 15, caracterizado porque es posible una transmisión de datos entre dicho dispositivo de juego y un dispositivo periférico de expansión vía dicha ruta de transmisión de señales cuando se conecta un dispositivo periférico de expansión con dicho conector de expansión y se incluye la dirección de origen junto con información de conexión indicativa de que el dispositivo periférico de expansión está conectado a dicho conector de expansión.

17. Dispositivo periférico según la reivindicación 15 ó 16, caracterizado porque comprende además un controlador periférico para controlar las comunicaciones de datos con dicho dispositivo de juego a través de la citada vía de transmisión de datos, generando dicho controlador la dirección de origen en base a tal información de identificación de dispositivo periférico, representando dicha información de puerto periférico que notifica el dispositivo de juego el puerto periférico al que está conectada dicha vía de transmisión de datos, e información de conexión que indica si un dispositivo periférico de expansión está o no conectado a dicho conector de expansión,

donde es posible una transmisión de datos entre dicho dispositivo de juego y un dispositivo periférico de expansión a través de dichas vías de transmisión de datos cuando se conecta un dispositivo periférico de expansión con dicho conector de expansión y las señales de datos transmitidas desde el dispositivo de juego incluyen información que señalan al citado dispositivo periférico de expansión como dirección de destino.

\newpage

18. Dispositivo periférico según las reivindicaciones 15 a 17, caracterizado porque el estado de conexión de dicho conector de expansión se determina identificando el nivel de voltaje en un terminal determinado de dicho conector de expansión, el cual está conectado a un circuito de alternancia de nivel compuesto de manera tal que el citado dispositivo periférico de expansión suministra un voltaje de polarización.