ZX-Uno, clon barato basado en FPGA

[jotego]

El AY afortunadamente no ocupa mucho espacio, así que sí, cabría. Es más, podría tener dos AY's para implementar Turbo Sound.

Mi clon del AY es más compacto que el que circula por ahí en VHDL al usar menos tablas. Estaría bien que usarais ese y así queda todo en casa.

[Hark0]

Como has cerrado el hilo de la encuesta, he creado otra en este hilo para concretar el nombre. La encuesta dura 5 días y sólo se puede elegir una opción.

No hay problema... pensé en montarla como has hecho tu... pero ayer estuve todo el dia programando... y te adelantaste... para lo que haya que rediseñar, SIN PROBLEMAS

-- Actualizado 20 Ago 2013, 11:04 --

Para fijar ideas, tened en cuenta:

Si tú preguntas si el clon puede soportar la característica X que tú has visto implementada en un emulador, imagínate que tienes un Spectrum de Sinclair pelao y mondao delante tuya. Ahora pregúntate que tendrías que añadirle a ese Spectrum para soportar la característica X.
- ¿Quieres soporte para cargar y grabar a tarjeta de memoria desde el BASIC? Añade una interfaz comptible con el proyecto +3E
- ¿Quieres poder cargar snapshots y TAP's de forma sencilla? Añade un DivIDE
- ¿Quieres poder reproducir ficheros RZX? No existe, que yo sepa, una interfaz que haga eso. Tendrías que implementar un dispositivo, usando un microcontrolador por ejemplo, que leyera el fichero RZX desde una tarjeta de memoria, y enviara pulsaciones de teclado sincronizadas al ciclo con lo que ejecuta el clon en ese momento. No es imposible, pero si complicado.
- ¿Quieres soporte de ethernet? Habría que añadirle una Spectranet
Fíjate que en los emuladores, implementar las tres primeras cosas no requiere que el Spectrum emulado tenga esos interfaces añadidos. Emuladores como el Z80 de Gerton Lunter, o el de Pedro Jimeno, ya cargaban desde TAP de forma instantánea antes de que existiera el DivIDE.

Si la característica X es algo que debe ser soportado de forma transparente por el Spectrum, tal como la carga con LOAD "" desde una tarjeta de memoria usando ficheros TAP o DSK, entonces eso implica que hay que "engañar" al Spectrum haciéndole creer que todo se hace "como siempre". Es lo que hace el DivIDE, o lo que hace el HxC. Las interfaces que hacen este tipo de cosas trabajan de una de estas dos formas: o bien se modifica el SO en ROM, cambiando las rutinas de bajo nivel por otras que acceden al nuevo hardware (lo que hace DivIDE, o +3E, o Spectranet) o bien se cambia el hardware por uno que se comporta de manera idéntica al original de cara al Spectrum pero usando la nueva característica (lo que hace HxC)

El formato TZX es un formato de audio. Si no puedes usarlo en un Spectrum original para cargar a velocidad de DivIDE, tampoco puedes usarlo en un clon. Al ser de audio, sólo hay un sitio por el que se pueda usar: la entrada EAR. Un emulador puede cargar un TZX casi instantáneamente porque usa técnicas que incluyen la aceleración de la emulación en momentos determinados (no lo recuerdo muy bien, pero es algo así como que se emula a toda velocidad la rutina de carga hasta el momento en que se detecta un flanco de subida o bajada en la señal de EAR, entonces se procesa y se vuelve a subir la velocidad para detectar el siguiente flanco.... algo así)

Excelente explicación...

[zup]

Bueeeno... un poco de paz, no quería alterar tanto el tema. Estaba más bien interesado en saber cómo puede ser de cómodo un cacharro de estos para las nuevas generaciones.

Estaba pensando un poco en el one chip MSX, que cargaba los ficheros desde la SD sin más cambios. Lo que ya no sé es cómo le indicabas los ficheros, si la trataba como un disco duro o tenía un mini UI para seleccionar ficheros dsk.

Salvando las distancias...

El DivIDE puede hacer LOAD "" desde una tarjeta de memoria. Si no existe DivIDE, LOAD "" leerá del puerto EAR, como en un Spectrum original.

Supongo que eso es una emulación completa de divIDE. También se podría hacer un mini UI para seleccionar un fichero tap, y emular únicamente las rutinas de la ROM (lo que yo decía que era un soporte de tap básico) sin llegar a emular completamente el divIDE.

Sí, es perfectamente factible, y no hace falta implementar un DivIDE completo: basta con implementar algo mucho más sencillo, como el ZXMMC.

Mi preocupación era si todos los chips especiales cabían dentro del invento (por lo de que no había sitio para el 765). Imagino que si caben el AY y los 128k para la inmensa mayoría de la gente va que se mata.

Por otra parte, soportar varios interfaces de disco es diversificar esfuerzos. Dado que (probablemente) se necesite el divIDE para los 48k, quizás el ZXMMC estaría bien para una segunda fase.

Para fijar ideas, tened en cuenta:

He de confesar que ignoro el coste de las opciones en relación a lo que cabe dentro de un integrado de esos y al tiempo/esfuerzo de desarrollador. Tomad estas preguntas como las de alguien que no tiene ni diea.

¿Quieres poder cargar snapshots y TAP's de forma sencilla? Añade un DivIDE

Quizás un divIDE completo no sea necesario, con solo trapear las ROMs podrías tener un soporte de ficheros tap muy básico/arcaico. Otro tema sería cómo hacer un UI para seleccionar un fichero tap determinado (o la entrada EAR).

¿Quieres soporte de ethernet? Habría que añadirle una Spectranet

Eso sí que tengo serias dudas de que llegue a caber.

El formato TZX es un formato de audio...

Desde mi ignorancia... ¿sería factible hacer un "descompresor de tzx" por hardware? La idea sería que (mientras se lee de cassette) se calcule cada ciclo qué debería haber en el puerto EAR y mandárselo, de manera que el Spectrum lo pudiera leer. Sería una carga en tiempo real (nada de aceleraciones). Y, de ser factible, ¿cabría en ese chip?

En ninguno de los casos anteriores he hablado de cargas aceleradas (aunque en el formato tap es factible), simplemente es saber si tendría esas posibilidades para mayor comodidad de uso.

Recordad que no tengo mucha idea del esfuerzo que requiere esto, ni de si cabe o no cabe. Simplemente es saber cómo sería de fácil usarlo.

Otra pregunta que se me ocurre referida al divIDE y otros dispositivos es cómo se podrían configurar (¿qué tal un bloque de jumpers?). Por poner un par de casos configurables:
- Sería interesante poder configurar la interfaz de joystick para usarla como Sinclair o Kempston sin necesidad de reconfigurar todo el equipo.
- Cuando conecto mi divIDE al +3e, a veces lo conecto en modo deshabilitado (para acceder a la partición de disco) y a veces en modo normal (para usar ESXDOS).

Y ya sin tirar de jumpers... ¿se pueden reescribir las ROMs sin reconfigurar todo el invento? Más que nada lo comento por las actualizaciones del divIDE.

[imd]

Mi versión de ZX-ONE:


Espero que no moleste a nadie, no soy ni diseñador ni nada....

[mcleod_ideafix]

El DivIDE puede hacer LOAD "" desde una tarjeta de memoria. Si no existe DivIDE, LOAD "" leerá del puerto EAR, como en un Spectrum original.

Supongo que eso es una emulación completa de divIDE. También se podría hacer un mini UI para seleccionar un fichero tap, y emular únicamente las rutinas de la ROM (lo que yo decía que era un soporte de tap básico) sin llegar a emular completamente el divIDE.

El DivIDE es un dispositivo sencillo. Ocuparía menos que, por ejemplo, un AY-3-8912. No creo que haya que hacer un DivIDE capado cuando puedes hacerlo entero. Otra cosa es el tema de la tarjeta de memoria: si es una SD, ahí va a haber que meter más "morralla" porque las BIOs que hay para DivIDE asumen un dispositivo IDE, que es bastante diferente a comandar un bus SPI.

¿Quieres soporte de ethernet? Habría que añadirle una Spectranet

Eso sí que tengo serias dudas de que llegue a caber.

Pues se lo añades "de verdad", mediante el conector de expansión que se le pondrá a la FPGA.

Desde mi ignorancia... ¿sería factible hacer un "descompresor de tzx" por hardware? La idea sería que (mientras se lee de cassette) se calcule cada ciclo qué debería haber en el puerto EAR y mandárselo, de manera que el Spectrum lo pudiera leer. Sería una carga en tiempo real (nada de aceleraciones). Y, de ser factible, ¿cabría en ese chip?

Lo que tú pides es esencialmente lo que hay en algunos smartphones en forma de app. Si quieres hacerlo dentro de la FPGA habría que meter un microcontrolador con su ROM y su RAM, acceso al SPI de la tarjeta SD para poder leerla, e integrar en la ROM de ese microcontrolador, entre otras cosas, el sistema de ficheros FAT para poder leer ficheros de ella. Como poder se puede hacer un reproductor de TZX. Que quepa en la FPGA... va a ser que no, que si quieres reproducir TZX, se lo vas a tener que dar al clon desde un reproductor externo.
De todas formas... ¿por qué ese interés en el TZX? La mayoría de los juegos y aplicaciones ya existe en formato TAP, y en las que no, siempre puedes cargar el TZX en un emulador y hacer un snapshot cuando comience a ejecutarse. Ese snapshot es el que luego puedes cargar a toda velocidad en el clon, con el DivIDE o el +3E. Los únicos juegos que tendrían problemas serían los multicarga que no tengan soporte de 128K, pero son los menos. Hay incluso un llamamiento a la comunidad de desarrolladores de juegos nuevos para que dichos juegos nuevos se distribuyan, a ser posible, en formato TAP, precisamente para que su uso en Spectrums reales con chismes tales como el DivIDE, +3E o Spectranet, sea factible.

Otra pregunta que se me ocurre referida al divIDE y otros dispositivos es cómo se podrían configurar (¿qué tal un bloque de jumpers?). Por poner un par de casos configurables:
- Sería interesante poder configurar la interfaz de joystick para usarla como Sinclair o Kempston sin necesidad de reconfigurar todo el equipo.
- Cuando conecto mi divIDE al +3e, a veces lo conecto en modo deshabilitado (para acceder a la partición de disco) y a veces en modo normal (para usar ESXDOS).

El core que se encarga de leer el teclado PS/2 puede generar señales aparte cuando se pulsen ciertas teclas especiales: así, una de las teclas puede ser para hacerle un reset al Z80, otra para conmutar de joystick Kempston a Sinclair, otra para deshabilitar o habilitar la ROM del DivIDE, etc.
Otra idea es que la interfaz de joystick que se implementa sea una interfaz multijoystick. Ya hice una hace algunos años, y no hay problema porque la interfaz dé a la vez información según Sinclair y según Kempston. La que yo hice soporta la norma Fuller, Kempston, Sinclair y Cursor. Sinclair y Cursor son mutuamente excluyentes, por operar ambas en el teclado, pero nada impide que los datos del joystick salgan a la vez por Fuller, Kenpston y una a elegir: Sinclair o Cursor.

Y ya sin tirar de jumpers... ¿se pueden reescribir las ROMs sin reconfigurar todo el invento? Más que nada lo comento por las actualizaciones del divIDE.

Las actualizaciones de las BIOS del DivIDE ocurren de vez en cuando. No es algo que tengas que hacer todas las semanas. Por otra parte, reconfigurar el core por completo es algo que se podrá hacer sin necesidad de hardware adicional, y es una operación que lleva unos 10 segundos.

[antoniovillena]

Ahora mismo en los esquemáticos tengo el pin 7 (que es VCC en norma Atari) sin conectar. Al no alimentar el joystick no funcionarían los joysticks con autodisparo, con la ventaja de que evitamos que se produzca un corto que queme el regulador.

Desgraciadamente el pin 7 en SJS es la dirección izquierda, por lo que habría que conectarlo a algún pin de la FPGA en el clon para soportar multinorma. O bien usamos otro pin más, o se lo quitamos a uno de los otros dos pines (5 y 9) o lo compartimos con ellos. ¿Qué opináis?

[mcleod_ideafix]

¿Qué opináis?

Que no soportes en absoluto el pineado SJS. Fue una decisión vil y maquiavélica, a la par que torpe, para intentar crear artificialmente un mercado propio de joysticks. Implementa únicamente el estándar Atari, y si alguien tiene muchísimo interés en usar joysticks SJS, que le compre a Retrocables un adaptador Atari-SJS (funcionan en ambas direcciones)

Sobre el pin 7 a 5V, pon en medio una resistencia de 125 ohmios. Eso le dará 40 miliamperios máximo al circuito de autodisparo del joystick, cosa que debería ser suficiente y evitará un disgusto con el regulador (que no te lo cargarás ni nada de eso, para eso tienen los reguladores protección contra cortocircuitos, pero tampoco es bueno ir por ahí cortocircuitando cosas)

[antoniovillena]

Entonces hago eso para la próxima revisión, pongo una resistencia de 150 ohm desde el pin 7 hacia VCC (5V). Yo tampoco entiendo lo de la norma SJS, sobre todo teniendo en cuenta que los Amstrad CPC iban con norma Atari.

[antoniovillena]

Después de 2 encuestas, el nombre final para el clon será:

ZX-Uno

[mcleod_ideafix]

Acabo de cambiar el título del hilo para reflejar el nombre definitivo, para que así sea más fácil de encontrar este hilo en futuras consultas sobre el clon