Mejias3D escribió:Otra posibilidad es que os animéis a hacer un pedido conjunto para reducir presupuesto, comparando precios en diferentes proveedores.
Será barato el kilo de plástico, pero hacer cada carcasa es leeeeeento. Hacer una puede que no parezca lento, pero multiplca el tiempo de una carcasa por 300 o por 500, a ver quien tiene paciencia para ponerse a hacer eso. A mi lo que me gustaría saber es lo que costaría hacerlo de forma profesional, usando moldes, o inyección o lo que quiera que se use para esas cosas.
De todas formas, desde el principio hemos querido alejarnos del tema precisamente para no tener que meter el coste NRE de hacer carcasas de plástico en el proyecto. Y por eso lo de mantener el tamaño de una Raspi. Luego, y al igual que ha pasado con la Raspi, si un usuario (pongamos tú, o jepalza) quiere hacer un diseño de caja más personalizado, con espacio para addons, un miniteclado, un anclaje VESA para atornillarlo detrás de una tele LCD, o cualquier cosa de estas, y ofrecerlo para que cada uno se lo imprima, o incluso hacer un miniproyecto a la sombra del ZX-Uno y vender las carcasas, pues por mi perfecto.
-- Actualizado 02 Ene 2015, 01:49 --
antoniovillena escribió:Hace falta multiplexar, por lo que 3 chips 74hc244 o algo similar no nos lo quita nadie. Yo estoy hablando de un addon puerto de expansión sin Z80
Sí, esa era mi idea inicial. Si hablé de ello a propósito de la plaquita del Z80 fue porque esa plaquita ya tenía casi casi todas las señales que se rutan al bus trasero, y de haber tenido más pines, pues hubiera añadido las que faltan, pero en ningún mmento he pensado en hacer la placa del bus trasero con un Z80 real.
Para adecuar las señales desde el exterior al core, y además implementar el multiplexor y todo lo necesario, usaré una CPLD, y así mato dos pájaros de un tiro

Bueno, una CPLD no es exactamente un level shifter. Esta trabaja a 3.3V pero sus entradas son tolerantes a 5V, y en cuanto a las salidas, aunque sean a 3.3V, son rail a rail, y lo curioso es que precisamente en el Spectrum, por usar un Z80 NMOS y no tener buffereadas sus señales, lo que se ve en el bus de expansión son señales en el rango de aproximadamente 0V a 3V. A efectos de compatibilidad con entradas TTL no hay problemas

Las señales que pretendo poner en el bus trasero (excluyo alimentación) son:
- Todas las señales del Z80 excepto HALT, BUSRQ y BUSAK. ¿Alguien conoce alguna interface, aparte del MB-02, que las use? (35 señales)
- La señal ROMCS. No creo que haga falta implementar ROMOE1 y ROMOE2, a menos que haya alguna interface que deshabilite de forma selectiva una de las dos ROMs. (1 señal)
- La señal /Y (luminancia invertida). La usa la interfaz Spectra. En realidad la señal que va a aparecer por ahí será la de sincronismo compuesto, invertida (pulsos positivos). (1 señal)
- La señal IORQGE (o IORQULA como se la llama por ejemplo en Harlequin). Se usa en algunas interfaces de teclado PS/2 (la de JROK por ejemplo) y en mi cacharro adaptador de video MSX (1 señal)
Total: 38 señales. Hay 33 señales disponibles en el conector del ZX-Uno, si he contado bien:
- Señales del bus de datos: D0-D7. Se rutan tal cual, usando la CPLD como level shifter: 8 señales
- Señales del bus de control: MREQ, IORQ, RD, WR, INT, NMI, CLK, RFSH, M1, RESET, WAIT. Lo mismo. 11 señales
- Señales accesorias: ROMCS, /Y, IORQGE. Lo mismo. 3 señales.
- Señales del bus de direcciones: A0-A15. Candidatas a ser multiplexadas. Usando el reloj de 28MHz, y multiplexando 2 en 1, se usan 8 señales para el bus de direcciones, más 1 señal de selección y otra de reloj del multiplexor: 10 señales.
Total: 8+11+3+10 = 32 señales desde el core a la CPLD, y 38 de salida de la CPLD al bus trasero. Total, 70 señales. Con un XC9572XL-TQ100 deberían poder caber todas muy justitas (72 pines de I/O). Cuando escriba el core para la CPLD lo podré saber seguro.
http://es.aliexpress.com/item/10PCS-XC9 ... 70776.htmlMe falta comprobar cómo quedan los ciclos de bus si el bus de direcciones tiene un retraso de 71ns respecto a las señales de control. No debería haber problemas con la mayoría de periféricos, pero me pregunto si para aquellos que hacen sniffer del bus del Z80 (como Spectra) supondrá algún problema el que la dirección aparezca un poquitín después de lo esperado.
En caso de problemas de rutado dentro de la CPLD o similares, las señales que se caerán de este listado serán, por orden: RFSH, /Y y IORQGE. Pongo RFSH primero aunque /Y e IORQGE no existan de hecho en el bus trasero del +2A, porque al menos estas dos últimas señales sé seguro que se usan en al menos un periférico existente. Respecto de RFSH, no sé si hay alguna interface que las use.
Aparte de esto, este bus trasero tendrá algunas características especiales, para interactuar de la mejor forma posible con los periféricos integrados en ZX-Uno. A saber:
- Un RESET que venga desde el bus trasero reiniciará sólo el procesador (equivalente a Ctrl-Alt-Supr)
- La señal INT será bidireccional: ZX-Uno indica con ella, como salida, que se está produciendo un retrazo vertical, y como entrada, un periférico podrá emitir interrupciones al micro. Hay una interfaz MIDI que usa este sistema, y alguna otra cosa más que no recuerdo.
- La señal ROMCS, si se fuerza a nivel alto, provocará que el espacio de memoria 0000-3FFF se quede completamente a merced de lo que ponga el periférico en el bus de datos. Es decir, se deshabilita la ROM del sistema, la ROM del ESXDOS, y la página de RAM que estuviese presente ahí, si estamos en el modo all-RAM del +2A/+3. Además, si se fuerza ROMCS a nivel alto, la interfaz DivMMC interna se deshabilita por completo, permitiendo a un periférico con ROM externa tomar el control de la NMI. Respecto a esto, se me ocurre otra alternativa: que mediante el teclado (una tecla de función por ejemplo) se permita o prohiba que un periférico externo tome el control de la NMI y el espacio de ROM. Así, se puede tener DivMMC habilitado para cargar cualquier cosa, un juego por ejemplo, y luego deshabilitar DivMMC y habilitar un periférico externo, por ejemplo un pokeador, para que sea él quien tome el control vía NMI y permita introducir pokes, o un transtape para hacer una copia de un juego a Microdrive o a disco, etc.
- Las señales NMI y M1. Se comportarán de acuerdo a lo explicado en el punto anterior. Si un periférico externo no tiene permiso para adueñarse del espacio de ROM, estas señales (junto con A15) siempre estarán a nivel alto.
Bueno, pues esa de momento es mi propuesta para este otro add-on.