Claro. Puedes implementar 8 funciones digitales, las que quieras, de 20 entradas y una salida de 1 bit. El retardo en el resultado sería de menos de 10ns, lo cual es razonable. Eso sí, previamente debes cargar los 2Mb de RAM.Zup escribió: Pensando en abstracto... ¿se podría usar el add-on como "aceleradora" combinatoria? En algunos circuitos se usan EPROM para sustituir circuitos combinatorios. ¿Quizás se podría usar la SRAM para meter alguna GAL que no quepa en algún core?
Hilo de peticiones para el core de Spectrum para mcleod
- antoniovillena
- Mensajes: 2621
- Registrado: 27 Sep 2015, 20:41
Re: Hilo de peticiones para el core de Spectrum para mcleod
- Tromponauta
- Mensajes: 123
- Registrado: 03 Feb 2016, 20:15
Re: Hilo de peticiones para el core de Spectrum para mcleod
Una cosa que me ronda por la cabeza últimamente debido a la necesidad de desconectar la tarjeta SD del ZX-UNO y conectarla al PC para transferir programas y demás cosas ¿Sería posible añadir una opción a la BIOS para reconfigurar el puerto Joystick como puerto RS-232? con eso sería cuestión de software el poder transferir archivos bidireccionalmente.
Enviado desde mi ZX-UNO
Re: Hilo de peticiones para el core de Spectrum para mcleod
Se puede, pero sería necesario control de flujo por hardware (señales RTS/CTS). Yo lo implementé en la UART que hizo @mcleod_ideafix, para poder usar el módulo WiFi que también va por UART a 3.3V.Tromponauta escribió:Una cosa que me ronda por la cabeza últimamente debido a la necesidad de desconectar la tarjeta SD del ZX-UNO y conectarla al PC para transferir programas y demás cosas ¿Sería posible añadir una opción a la BIOS para reconfigurar el puerto Joystick como puerto RS-232? con eso sería cuestión de software el poder transferir archivos bidireccionalmente.
Si se quiere RS-232 auténtico con niveles de 12V ya no sería posible directamente, habría que usar conversores de voltaje. Pero hoy en día lo más cómodo es usar un conversor serie USB-TTL de 3.3V o de 5V adaptando los niveles con un par de resistencias. Sin embargo estos USB-TTL no suelen soportar RTS/CTS, lo que es un problema.
- antoniovillena
- Mensajes: 2621
- Registrado: 27 Sep 2015, 20:41
Re: Hilo de peticiones para el core de Spectrum para mcleod
¿Has probado con CargandoLeches? Se pueden conseguir 21Kbps que es bastante rápido (vía EAR).Tromponauta escribió:Una cosa que me ronda por la cabeza últimamente debido a la necesidad de desconectar la tarjeta SD del ZX-UNO y conectarla al PC para transferir programas y demás cosas ¿Sería posible añadir una opción a la BIOS para reconfigurar el puerto Joystick como puerto RS-232? con eso sería cuestión de software el poder transferir archivos bidireccionalmente.
Re: Hilo de peticiones para el core de Spectrum para mcleod
Es como debugueo yoantoniovillena escribió: ¿Has probado con CargandoLeches? Se pueden conseguir 21Kbps que es bastante rápido (vía EAR).
![Smile :)](./images/smilies/icon_e_smile.gif)
- Tromponauta
- Mensajes: 123
- Registrado: 03 Feb 2016, 20:15
Re: RE: Re: Hilo de peticiones para el core de Spectrum para mcleod
Pues por un lado lo había pensado, pero CL ¿ no es solo para cargar muy rápido ? La idea es con la ROM del ±3e crear unas particiones y con un par de programitas ir pasando a las unidades montadas sin mucho hardware de por medio, pero veo que los voltajes son un problema serio, seguramente seria mas sencillo con las simples conexiones ear/mic un par de programitas tanto en el PC como en el ZX-UNO poder establecer una conversación bidireccional de tal forma que se pueda ver un listado ofrecido por el PC a modo de directorio y ser transferido al destino requerido en el +3e a demanda, creo que lo "gordo" del trabajo de algo así seria establecer el protocolo de mensajes con peticiones al estilo "FTP"yombo escribió:Es como debugueo yoantoniovillena escribió: ¿Has probado con CargandoLeches? Se pueden conseguir 21Kbps que es bastante rápido (vía EAR).
Enviado desde mi ZX-UNO
Re: RE: Re: Hilo de peticiones para el core de Spectrum para mcleod
Tromponauta escribió:Pues por un lado lo había pensado, pero CL ¿ no es solo para cargar muy rápido ? La idea es con la ROM del ±3e crear unas particiones y con un par de programitas ir pasando a las unidades montadas sin mucho hardware de por medio, pero veo que los voltajes son un problema serio, seguramente seria mas sencillo con las simples conexiones ear/mic un par de programitas tanto en el PC como en el ZX-UNO poder establecer una conversación bidireccional de tal forma que se pueda ver un listado ofrecido por el PC a modo de directorio y ser transferido al destino requerido en el +3e a demanda, creo que lo "gordo" del trabajo de algo así seria establecer el protocolo de mensajes con peticiones al estilo "FTP"yombo escribió:Es como debugueo yoantoniovillena escribió: ¿Has probado con CargandoLeches? Se pueden conseguir 21Kbps que es bastante rápido (vía EAR).
Quizá se pudiera hacer un servidor PC que soporte CLTP (Cargando Leches Transfer Protocol) y un dot command en ZX-Uno que permita dar órdenes a dicho servidor, por EAR.
El "servidor" en el PC básicamente estaría esperando oir una órden por la entrada de audio del PC, donde las ordenes podrían ser DIR, GET <file> o PUT <file>. Una vez recibida la órden si es un DIR o UN GET, esperaría un segundo e inmediatamente pasaría a modo reproducción, lanzando bien el fichero en sí, bien el contenido del directorio compartido. Por su parte el cliente una vez lanzada una orden GET o DIR se pondría en modo "LOAD" para bien recibir el listado del directorio o un fichero, usando cargando leches claro. En caso de ser un PUT el servidor seguiría en modo LOAD, pero en lugar de esperar un comando esperaría el fichero, y el cliente tras lanzar un PUT esperaría un segundo y lanzaría la reproducción del fichero.
Por supuesto se puede mejorar mucho metiendo ACKs de órdenes y cosas así, e incluso manteniendo una comunicación duplex, que no se si es posible en un Spectrum (EAR y MIC a la vez?).
Teóricamente mola mucho, pero en la práctica es una tarea bastante gorda para la que creo que ya hay mejores soluciones (como la SD wifi, o el FTP por wifi). Cierto es que ninguna de esas funciona en +3e, tiene que ser DivIDE/MMC porque es FAT)
- Tromponauta
- Mensajes: 123
- Registrado: 03 Feb 2016, 20:15
Re: RE: Re: RE: Re: Hilo de peticiones para el core de Spectrum para mcleod
Me has leído el pensamiento, estaba pensando exactamente en esos pasos / método. También he pensado en el tema Wifi, pero si no funciona en +3e estamos en las mismas, aparte cuando me surgió la idea me pareció muy atractiva la idea de Hardware "Minimalista" como hace mucho que no tocó la programación y me faltaba una idea que supusiese una "Motivación" para ponerme a saco con ello, por lo menos ya tengo la idea, ahora me parece que voy a tardar muchísimo en tener algo .....Uto escribió:Tromponauta escribió:Pues por un lado lo había pensado, pero CL ¿ no es solo para cargar muy rápido ? La idea es con la ROM del ±3e crear unas particiones y con un par de programitas ir pasando a las unidades montadas sin mucho hardware de por medio, pero veo que los voltajes son un problema serio, seguramente seria mas sencillo con las simples conexiones ear/mic un par de programitas tanto en el PC como en el ZX-UNO poder establecer una conversación bidireccional de tal forma que se pueda ver un listado ofrecido por el PC a modo de directorio y ser transferido al destino requerido en el +3e a demanda, creo que lo "gordo" del trabajo de algo así seria establecer el protocolo de mensajes con peticiones al estilo "FTP"yombo escribió:Es como debugueo yoantoniovillena escribió: ¿Has probado con CargandoLeches? Se pueden conseguir 21Kbps que es bastante rápido (vía EAR).
Quizá se pudiera hacer un servidor PC que soporte CLTP (Cargando Leches Transfer Protocol) y un dot command en ZX-Uno que permita dar órdenes a dicho servidor, por EAR.
El "servidor" en el PC básicamente estaría esperando oir una órden por la entrada de audio del PC, donde las ordenes podrían ser DIR, GET <file> o PUT <file>. Una vez recibida la órden si es un DIR o UN GET, esperaría un segundo e inmediatamente pasaría a modo reproducción, lanzando bien el fichero en sí, bien el contenido del directorio compartido. Por su parte el cliente una vez lanzada una orden GET o DIR se pondría en modo "LOAD" para bien recibir el listado del directorio o un fichero, usando cargando leches claro. En caso de ser un PUT el servidor seguiría en modo LOAD, pero en lugar de esperar un comando esperaría el fichero, y el cliente tras lanzar un PUT esperaría un segundo y lanzaría la reproducción del fichero.
Por supuesto se puede mejorar mucho metiendo ACKs de órdenes y cosas así, e incluso manteniendo una comunicación duplex, que no se si es posible en un Spectrum (EAR y MIC a la vez?).
Teóricamente mola mucho, pero en la práctica es una tarea bastante gorda para la que creo que ya hay mejores soluciones (como la SD wifi, o el FTP por wifi). Cierto es que ninguna de esas funciona en +3e, tiene que ser DivIDE/MMC porque es FAT)
![Smile :)](./images/smilies/icon_e_smile.gif)
Enviado desde mi ZX-UNO
- antoniovillena
- Mensajes: 2621
- Registrado: 27 Sep 2015, 20:41
Re: Hilo de peticiones para el core de Spectrum para mcleod
La idea no es mala, pero hay que currarse el servidor en el PC. En la parte ROM del Spectrum no hay que programar nada. En la primera carga en lugar de un juego se mostraría un listado (un programa que muestra el listado de un directorio de PC) y el PC se quedaría escuchando. Al seleccionar una opción del listado en el Spectrum se enviarían los pocos bytes que suponga el nombre o un índice. El método de carga upstream podría ser más sencillo y lento, puesto que serán pocos bytes a enviar desde el Spectrum al PC.
Re: Hilo de peticiones para el core de Spectrum para mcleod
Alguna manera de poder acceder a la tarjeta SD via wifi u otro método, para poder enviar/modificar archivos desde el pc sería la ostia para algunos de nosotros ![Smile :)](./images/smilies/icon_e_smile.gif)
Es algo que envidio muy mucho del M4 de amstrad, junto con el control remoto de la máquina.
![Smile :)](./images/smilies/icon_e_smile.gif)
Es algo que envidio muy mucho del M4 de amstrad, junto con el control remoto de la máquina.