QLSD

Subforo oficial del Sinclair QL: realiza aquí las consultas relativas a tu QL.

Moderador: Sir Cilve Sinclair

QLSD

Notapor mcleod_ideafix el Dom Abr 17, 2011 10:58 pm

A falta de otro nombre para el invento, pues le pongo este (con connotaciones alucinógenas incluídas :P )
Al final no he esperado al lunes, y hoy me he acercado al laboratorio a fresar la placa. Aquí está, con el baño de flux recién puesto (por eso se ve como brillante).

Imagen

Si parece un poco grande es sencillamente porque los prototipos los hago así, un poco más grandes de lo que realmente es necesario, ya que es la única forma de poder hacer las pistas un poco más anchas, y esto último es conveniente porque las vías que unen pistas en ambas caras de la placa las tengo que mecanizar a mano, y si el pad y la pista son pequeñitos pues... es jodío hacerlo :D

Tambien se ve grande (mejor dicho, "larga") porque el zócalo que estoy usando para la SD es de longitud completa, en lugar de ser de estos "partidos" que además son más baratos. Pero para una prueba, pues me vale :D
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3983
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: QLSD

Notapor radastan el Lun Abr 18, 2011 8:56 am

¡Jorl! Muy buena pinta tiene eso McLeod, sobre todo porque es exactamente lo que necesita ahora el QL. Eso si, la versión definitiva debería ser en vertical, es decir, que la SD quede hacia arriba. Algo así como un cartucho que se ponga por detrás del QL.

Más que nada para que no sobresalga mucho, que es lo que le pasa al DIVIde+.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________
Avatar de Usuario
radastan
Phantomas
 
Mensajes: 2186
Registrado: Lun May 07, 2007 5:34 pm

Re: QLSD

Notapor mcleod_ideafix el Lun Abr 18, 2011 12:04 pm

radastan escribió:¡Jorl! Muy buena pinta tiene eso McLeod, sobre todo porque es exactamente lo que necesita ahora el QL. Eso si, la versión definitiva debería ser en vertical


Pero es que el conector de cartuchos del QL te obliga a que el cartucho ROM vaya en posición horizontal. ¿Cómo vas a hacer que el circuito sea vertical si no puedes "doblar" la placa? La idea es que sea lo más barata posible, así que hacer dos placas para el "angulo recto" o un conector en medio, o lo que sea, encarecería la fabricación. Ya he dicho que si ésta es tan "larga" es porque las hago así cuando son prototipos. La definitiva sería más corta.

De todas formas, discutir eso en este momento es "pa ná". Si todo sale bien y esto se convierte en un producto real, ya habrá tiempo para discutir si horizontal o vertical, si con carcasa de plástico o "desnudo", etc.
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3983
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: QLSD

Notapor radastan el Lun Abr 18, 2011 1:41 pm

Hombre, es evidente que si ocupa poco puede ir en horizontal y así ser más económico. Yo es que recordaba el adaptador CF para +3 de Jose Leandro y lo mono que quedaba como si fuera una interfaz tipo kempston.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________
Avatar de Usuario
radastan
Phantomas
 
Mensajes: 2186
Registrado: Lun May 07, 2007 5:34 pm

Re: QLSD

Notapor afx el Lun Abr 18, 2011 5:34 pm

Mcleod .... ¡vas como una moto! Es fantástico ir teniendo "visibilidad" del proyecto.

El nombre que has elegido está muy bien, seguro que QLSD ... será "alucinante" (valga la redundancia :D ...) cuando vea la luz.

Yo pensé que estas cosas costaban muchísimo. Winston, haciendo referencia al desarrollo de su Spectranet, me comento en la RE que en este tipo de desarrollos hardware más del 80% del trabajo se lo llevaba el software y que el hardware era bastante más simple de desarrollar. Yo siempre había imaginado que era al revés.

Algunas preguntas:

Si no te he entendido mal ¿al final tienes pensado desarrollar un driver nativo QDOS para acceder al dispositivo, al estilo QSD1_ QSD2_, (o algo así)...?
¿Vas a adaptar el código de la QUBIDE?
¿Qué plazos te has planteado?

Sobre lo de la orientación de la tarjeta (horizontal / vertical) pienso que es irrelevante. Mi opinión es que da igual la orientación y el tamaño. Una cosa que si sería importante es que la tarjeta sea totalmente autónoma y que no necesite de disquetera ni microdrives para cargar el software del controlador del dispositivo. Que lleve todo lo necesario en su Rom o Eprom, sería estupendo.

Sobre lo que preguntabas en el otro hilo sobre un IDE de desarrollo en ensamblador para el QL, yo no he visto nada. Alguna vez he realizado algunas pruebas de juguete con ensamblador, utilizaba el ensamblador de Metacomco que sólo tenía un front-end muy primitivo y un editor de textos ordinario. Creo que el ensamblado de GST es el más utilizado, pero lo desconozco.

Mcleod, ... ¡ánimo!
afx
Sabreman
 
Mensajes: 396
Registrado: Dom Feb 24, 2008 11:56 pm

Re: QLSD

Notapor mcleod_ideafix el Lun Abr 18, 2011 7:00 pm

afx escribió:Winston, haciendo referencia al desarrollo de su Spectranet, me comento en la RE que en este tipo de desarrollos hardware más del 80% del trabajo se lo llevaba el software y que el hardware era bastante más simple de desarrollar. Yo siempre había imaginado que era al revés.


Eso que dice Winston es MUY CIERTO. De hecho, el hardware (salvo fallos) estará terminado hoy. El software... no lo sé :D

afx escribió:Si no te he entendido mal ¿al final tienes pensado desarrollar un driver nativo QDOS para acceder al dispositivo, al estilo QSD1_ QSD2_, (o algo así)...?


Exacto, aunque había pensado llamarlo MMC1_, MMC2_, etc. :D

afx escribió:¿Vas a adaptar el código de la QUBIDE?


Soy muy nefasto cogiendo código de otras personas, sobre todo cuando el código del QubIDE es a su vez un remiendo de otro código para no se qué interfaz. Lo que haré (estoy haciendo) es estudiar ese código para ver cómo se comunican las diferentes capas del driver (la access layer, physical layer, etc.). El libro "Advanced User Guide" me está sirviendo de mucha ayuda, ya que trae un driver de ejemplo bien explicado (aunque no es un driver de directorio). Creo que ya le voy cogiendo el truco a esto.

afx escribió:¿Qué plazos te has planteado?


Me he planeado metas, pero no tiempo para llegar a cada una de ellas. Las metas son:
- Desarrollar el hardware (placa)
- Desarrollar el hardware (lógica programada)
- Probar a bajo nivel el hardware (desde SuperBASIC, enviado comandos directamente a la tarjeta)
- Pasar a C/M las rutinas básicas que haya prototipado en SuperBASIC y así tener un conjunto de primitivas de comunicación (leer sector, escribir sector, inicializar tarjeta, etc)
- Implementar un driver sencillo (no de directorios)
- Implementar un driver de directorio.

afx escribió:que la tarjeta sea totalmente autónoma y que no necesite de disquetera ni microdrives para cargar el software del controlador del dispositivo. Que lleve todo lo necesario en su Rom o Eprom, sería estupendo.


Para eso está precisamente la EPROM :D Para que sea autónoma. Aunque para las pruebas, cargaré el código desde disquete por la sencilla razón de que es más rápido (imagínate que para cada prueba tuviera que coger la EPROM, borrarla, esperar a que se borre del todo, volver a programarla, pincharla, encender el equipo, ver como falla en el enésimo test, vuelta a empezar).

afx escribió:Sobre lo que preguntabas en el otro hilo sobre un IDE de desarrollo en ensamblador para el QL, yo no he visto nada.


Lástima... Bueno, creo que al menos para las primeras pruebas me vale el Easy68K.
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3983
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: QLSD

Notapor mcleod_ideafix el Lun Abr 18, 2011 7:43 pm

radastan escribió:Hombre, es evidente que si ocupa poco puede ir en horizontal y así ser más económico. Yo es que recordaba el adaptador CF para +3 de Jose Leandro y lo mono que quedaba como si fuera una interfaz tipo kempston.


Pero recuerda también que en el Spectrum es el periférico quien lleva el conector, y por tanto ahí si es posible montar la placa en horizontal (Spectranet) o vertical (mismamente mi interfaz multinorma). En el QL el periférico lleva solamente "pistas"; no lleva conector, por lo que una solución que permita a ese adaptador ir en vertical pasa por usar dos placas independientes, soldadas en ángulo recto.
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3983
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: QLSD

Notapor mcleod_ideafix el Mar Abr 19, 2011 6:17 am

La descripción para la CPLD ya está terminada. Uffff! ¡¡por poco no cabe!! He usado todos los pines de la CPLD, y más del 80% de sus recursos.

Imagen

He pedido una simulación del comportamiento de la CPLD para un posible caso de escritura de un valor en la SD. Para entender el cronograma que viene a continuación, hay que saber la asignación que he escogido para activar las diferentes funciones de esta interfaz, que es la siguiente:

Todas las operaciones son de lectura, ya que el slot ROM sólo se activa con lecturas, así que hay que simular escrituras con lecturas (ahora veremos cómo). Las posiciones "reservadas" hacen que no se active la EPROM.

La interfaz tiene un reloj programable, de forma que se puede establecer la velocidad con la que se accede a la tarjeta SD/MMC. La programación consiste en un valor de 8 bits, en el rango 00 a F9 inclusive. Este valor establece la longitud de un semiperíodo de la señal de reloj SPI (la usada por la tarjeta SD/MMC) en unidades de reloj del sistema (en el prototipo, 40MHz).

Leyendo la posición de memoria $FFFE se obtiene el último valor asignado al divisor de reloj. Para establecer un nuevo valor, hay que leer cualquier posición de memoria en el rango $FF00 a $FFF9 . El nuevo valor del divisor de reloj será el byte menos significativo de la dirección escogida (esto es, un valor entre $00 y $F9). Por supuesto, el valor leído no tiene sentido y se debe ignorar.

Tiene además un registro de estado de 3 bits. El bit 0 indica si la tarjeta está presente o no, el bit 1 indica si está activa la protección contra escritura (sólo disponible en zócalos SD/MMC adecuados), y el bit 2 indica si hay en curso una operación de lectura o escritura en la SD. Leyendo la posición de memoria $FFFD se obtienen los valores de estos 3 bits. El resto del byte leído debe ignorarse.

Para activar la tarjeta SD, se lee de la posición de memoria $FFFA. Esto hace que se encienda el LED que indica que una operación está activa. Leyendo de la posición $FFFB se desactiva la tarjeta SD y se apaga el LED. Al igual que antes, el valor leído en la operación no sirve para nada.

Para enviar un valor a la tarjeta SD se debe leer una posición de memoria comprendida entre $FE00 y $FEFF. El valor entregado a la tarjeta SD será el byte menos significativo de la dirección escogida.

Para leer el último dato entregado por la tarjeta SD, se lee la posición $FFFC.

Este esquema en el que se comparte el espacio de direcciones para la EPROM y el manejo de la interfaz hace que el firmware que vaya en dicha EPROM no pueda disponer de los últimos 512 bytes. El tamaño máximo del firmware es de $3E00 (15872) bytes, desde la posición $C000 hasta la $FDFF inclusive.

En resumen:
Código: Seleccionar todo
     FExx : envía el dato xx de 8 bits a la SD
     FF00-FFF9 : envia el valor 00 a F9 al divisor de reloj. El valor es el número de cuentas de un semiperíodo de SCLK, medido en unidades del reloj maestro (40MHz en el prototipo)
     FFFA : activa la SD
     FFFB : desactiva la SD
     FFFC : último dato leído de la SD
     FFFD : bits de busy, protección de escritura y tarjeta presente
     FFFE : valor actual del divisor de reloj


Este es el resultado.

Imagen

Y se interpreta así. Cada acceso a la interfaz, sea para leer la EPROM o para leer los registros de acceso a la tarjeta SD, están señalizados en los momentos en los que la señal ROMOEH pasa de 1 a 0 (flanco de bajada).

    Hay un acceso a la posición $C000, que es una posición perteneciente a la EPROM de la interfaz, y no es una dirección reservada para registros, así que la señal de habilitación de la EPROM se activa (eprom_o).
    Casi a la vez, se quita la tarjeta SD, con lo que la señal card_det pasa a 0.
    Se lee la posición $FFFD, que devuelve $01 (tarjeta quitada)
    Se inserta una tarjeta, y la señal card_det pasa a 1
    Se lee de nuevo la posición $FFFD, que devuelve $00 (tarjeta puesta)
    Se establece $03 como valor del divisor de frecuencia para el reloj SPI. Para ello se lee la posición $FF03. Se ignora el resultado.
    Se activa la tarjeta SD y se enciende el LED, leyendo la posición $FFFA. la señal SS pasa a 0. Se ignora el resultado.
    Se envía el byte $AA a la tarjeta SD. Para ello se lee la posición de memoria $FEAA. Se ignora el resultado.

En el cronograma se observan 8 ciclos de reloj en SCLK. En MOSI se tiene el valor binario $AA (10101010), emitido un bit cada vez. Una vez enviado el dato, hay que esperar a que termine el envío. Para ello se lee continuamente el bit de busy (bit 3 de la posición $FFFD).

    Se lee la posición $FFFD, que devuelve $04 (tarjeta ocupada)
    Se lee de nuevo la posición $FFFD, que devuelve $04 (tarjeta ocupada)
    Se lee de nuevo la posición $FFFD, que devuelve $00 (tarjeta NO ocupada)

    Se desactiva la tarjeta (y se apaga el LED) leyendo la posición $FFFB. La señal SS pasa a 1. Se descarta el resultado.
    (sólo por comprobación). Se lee el valor actual del divisor de frecuencia desde la posición $FFFE. El valor devuelto es $03, que por supuesto coincide con el valor que escribimos casi al principio de la simulación.
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3983
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: QLSD

Notapor radastan el Mar Abr 19, 2011 12:52 pm

¡Esto promete! muy ingenioso lo de simular escrituras con lecturas a cierto rango de memoria, enletece el proceso pero seguro que es mucho más rápido que el Microdrive de lejos. Supongo que el siguiente paso será ensamblar y probar en un QL si puedes leer los datos de la SD y escribir en ella, para luego liarte con el tema del driver.

Vas por buen camino McLeod. Siento no poder ser de mucha ayuda pero si necesitas algo no dudes en pedirlo.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________
Avatar de Usuario
radastan
Phantomas
 
Mensajes: 2186
Registrado: Lun May 07, 2007 5:34 pm

Re: QLSD

Notapor mcleod_ideafix el Mar Abr 19, 2011 1:29 pm

radastan escribió:¡Esto promete! muy ingenioso lo de simular escrituras con lecturas a cierto rango de memoria, enletece el proceso pero seguro que es mucho más rápido que el Microdrive de lejos.


Es que no hay otro remedio, ya que el slot ROM del QL no se activa cuando se hacen escrituras, sólo cuando se hacen lecturas. Si esto se hiciera en el slot lateral (el de las ampliaciones "buenas") se podrían usar escrituras, y no haría falta siquiera ponerse a testear la señal BUSY, ya que sencillamente el handshake del 68008 se encargaría de hacer que la operación de lectura o escritura se demorara el tiempo necesario hasta que se terminara la operación.

Pero sí: esto es más rápido que el Microdrive, y que el Ser-USB ;)

radastan escribió:si necesitas algo no dudes en pedirlo.


Hay algo en lo que sí podrías ayudarme. ¿Tienes alguna pantalla en modo 8 que sea chula, para hacer pruebas de lectura desde la SD? Lo que necesito son los 32768 bytes de dicha pantalla.
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3983
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: QLSD

Notapor Scooter el Mar Abr 19, 2011 1:44 pm

Como diría un conocido famosete: im-presionante

Un par de reflexiones en voz alta:

- Efectivamente el hard es mas sencillo que el soft, ya se que suena raro pero así es; se podría hacer un interface SD conectado a un puerto joystik (si es bidireccional; en el C64 lo es) por bit-bang osea harware=0, seguro que es lento pero menos que una cinta.
- ¿Para que se usa el puerto de expansión "bueno" que tanto hay que reservar? ¿No sería mejor meter allí una ampliación de ram+SD?¿O simplemente es porque el slot de rom no se usa para nada?
- ¿No sería bueno usar una eeprom en lugar de una eprom y que sea el firm actualizable sin necesitar un programador?-Semirespuesta: Supongo que en el slot de rom sería una complicación, pero no en el slot "bueno" y de aquí se pasa de nuevo a la segunda reflexión.

¡Oñio! si han sido un par de tres reflexiones....

PD1. Si las reflexiones marean, ignoradlas; a fin de cuentas no tengo un QL, solo soy un cotilla de los retrosistemas
PD2. Enhorabuena por mantener vivos a las viejas glorias
Aquellos chalados en sus viejos cacharros...
Avatar de Usuario
Scooter
Freddy Hardest
 
Mensajes: 710
Registrado: Jue Nov 11, 2010 11:17 pm

Re: QLSD

Notapor radastan el Mar Abr 19, 2011 2:17 pm

mcleod_ideafix escribió:Hay algo en lo que sí podrías ayudarme. ¿Tienes alguna pantalla en modo 8 que sea chula, para hacer pruebas de lectura desde la SD? Lo que necesito son los 32768 bytes de dicha pantalla.


Te lo envío por privado.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________
Avatar de Usuario
radastan
Phantomas
 
Mensajes: 2186
Registrado: Lun May 07, 2007 5:34 pm

Re: QLSD

Notapor mcleod_ideafix el Mar Abr 19, 2011 5:19 pm

Scooter escribió:- Efectivamente el hard es mas sencillo que el soft, ya se que suena raro pero así es; se podría hacer un interface SD conectado a un puerto joystik (si es bidireccional; en el C64 lo es) por bit-bang osea harware=0, seguro que es lento pero menos que una cinta.


Pues sí. En esa línea hice un ultracargador de juegos para Spectrum.
http://www.zxprojects.com/index.php/ext ... x-spectrum

Scooter escribió:- ¿Para que se usa el puerto de expansión "bueno" que tanto hay que reservar? ¿No sería mejor meter allí una ampliación de ram+SD?¿O simplemente es porque el slot de rom no se usa para nada?


Uso el slot de ROM por varias razones:
- Es barato: cualquier cosa que se conecte al bus de expansión lateral necesita por fuerza un conector que no es barato, y por otra parte, a causa de la loongitud de dicho conector, la placa debe tener unas dimensiones mínimas, que son mayores que la placa que os he enseñado, por lo que sería más cara de fabricar.
- El slot lateral requiere, en la mayoría de los casos, abrir el ordenador, más que nada porque a veces es difícil atinar con la posición de la tarjeta.
- Por regla general, el slot de ROM no se usa (aunque en mi caso sí que lo uso para el MK-II).
- La ampliación de RAM ya la tengo hecha, y no requiere ni usar el slot lateral ni el de ROM ni nada. Va soldada directamente en placa :D

Scooter escribió:- ¿No sería bueno usar una eeprom en lugar de una eprom y que sea el firm actualizable sin necesitar un programador?-Semirespuesta: Supongo que en el slot de rom sería una complicación, pero no en el slot "bueno" y de aquí se pasa de nuevo a la segunda reflexión.


Sí, pero ya has visto que en el slot de la ROM no se puede escribir, sólo leer, así que hay que añadir lógica a la CPLD para simular las escrituras, y con la CPLD que estoy usando ya me he quedado sin pines, y la utilización de recursos ronda el 90%. Haría falta otra CPLD más grande, es decir, más cara. En el slot lateral seguramente no haría falta lógica añadida para poder escribir en una Flash EPROM. De todas formas, usar EEPROM o EPROM en estos momentos es accesorio. Mi meta es que la interfaz funcione. De poco me sirve meterle EEPROM y toda la pesca, si luego resulta que no funciona bien lo que tiene que funcionar. Para las "advanced features" siempre habrá tiempo.
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3983
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Re: QLSD

Notapor afx el Mar Abr 19, 2011 7:00 pm

Mcleod, genial esos progresos, ...

Sobre el nombre para los dispositivos, cuando dices ...
mcleod_ideafix escribió: aunque había pensado llamarlo MMC1_, MMC2_, etc ...

..., si si, efectivamente esos nombres le van muy bien al invento (acrónimo de Multipurpose Macleod Card ... :D ).

Sobre la velocidad, creo que al final será más que aceptable para lo que es un QL. Yo tengo la RomDisQ y al cargar un programa va fenomenal. No puedo comparar la velocidad con un disco duro porque no lo tengo, pero comparado con una disquetera la diferencia es abismal.

Lo que si he notado en la RomDisQ es que las lecturas son muchísimo más rápidas que las escrituras (tal vez por lo que comentais ?).

Sobre el tema del por qué NO emplear el puerto de expansión, otra razón poderosa es porque ya hay muchos usuarios que tienen esa expansión ocupada, la mayoría de las veces con la típica expansión de controladora de disquetera + memoria extra. Aquí estarían todos los usuarios que tengan TrumpCard, GoldCard, etc ... (por ejemplo mi caso, que la tengo ocupada con la GoldCard). La mayoría de estas tarjetas no tienen un conector pass-through para encadenar otra expansión, con lo que la QLSD, para ser usable con estas tarjetas tendrían que tener dos conectores y dar soporte al pass-through para pinchar otras tarjetas. De no ser así, se estaría restringiendo muchísimo el uso de QLSD. Incluso, más grave aún, creo que tarjetas como la TrumCard de 768K se come las direcciones reservadas para otras tarjetas de expansión.

En definitiva, la opción por puerto ROM me parece "acertadísima".
afx
Sabreman
 
Mensajes: 396
Registrado: Dom Feb 24, 2008 11:56 pm

Re: QLSD

Notapor mcleod_ideafix el Mar Abr 19, 2011 8:03 pm

afx escribió:Lo que si he notado en la RomDisQ es que las lecturas son muchísimo más rápidas que las escrituras (tal vez por lo que comentais ?).


Creo que es sencillamente porque las lecturas en una flash ROM son más rápidas que las escrituras. Aquí de hecho pasará lo mismo, y por la misma razón: las SD/MMC están basadas en la tecnología Flash NAND, y en estas memorias la lectura es bastante más rápida que la escritura.
Web: ZX Projects | Twitter: @zxprojects
Avatar de Usuario
mcleod_ideafix
Johnny Jones
 
Mensajes: 3983
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera

Siguiente

Volver a Sinclair QL

¿Quién está conectado?

Usuarios navegando este Foro: No hay usuarios registrados visitando el Foro y 0 invitados