Otra propuesta: ampliación interna de 512K (¡FUNCIONA!)

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

Moderador: Sir Cilve Sinclair

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por mcleod_ideafix » Mié Ago 11, 2010 8:53 pm

afx escribió:Mcleod, otra pregunta:
¿A día de hoy es viable "reproducir" una tarjeta del tipo TrumpCard "copiando" el diseño? (no entro en el tema de asuntos legales, sólo si es realizable o no).


¿Hay esquemáticos de esa tarjeta? O al menos, ¿una descripción técnica?
Web: ZX Projects | Twitter: @zxprojects

afx
Sabreman
Mensajes: 396
Registrado: Dom Feb 24, 2008 10:56 pm

Re: Otra propuesta: ampliación interna de 512K

Mensaje por afx » Jue Ago 12, 2010 12:32 pm

mcleod_ideafix escribió:¿Hay esquemáticos de esa tarjeta? O al menos, ¿una descripción técnica?


Yo no he encontrado nada en Internet, sólo el manual de usuario.

Mi pregunta iba por ahí, y no sólo en relación a la TrumCard sino cualquier otra placa de plataformas retro. ¿Es viable la ingeniería inversa sin esos esquemáticos de cara a una posible reproducción de esas placas? (Suponiendo siempre que se puedan conseguir los chips originales o equivalentes).


PD:
No estoy puesto en la electrónica y simpre me he preguntado eso.

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por mcleod_ideafix » Jue Ago 12, 2010 2:11 pm

afx escribió:Mi pregunta iba por ahí, y no sólo en relación a la TrumCard sino cualquier otra placa de plataformas retro. ¿Es viable la ingeniería inversa sin esos esquemáticos de cara a una posible reproducción de esas placas? (Suponiendo siempre que se puedan conseguir los chips originales o equivalentes).

Pues depende de los medios con los que cuentes, y el tiempo que puedas invertir en ello, claro está. En hacerle ingeniería inversa al Abaco Phoenix 3 y scar su esquemático, etc, tardé un par de horas. No tengo ni idea de lo que es una TrumCard, así que no sé cuán difícil puede ser. Bicheando por internet parece ser que es una tarjeta de expansión de memoria, en la que ponen más de 512KB aprovechando que hay un hueco de 128KB al final del espacio de memoria normalmente reservado a las EPROM de las expansiones, más una unidad de disquete. ¿Se tiene al menos un volcado de la ROM de la parte que gobierna la disquetera? ¿Unas fotos del aparatito?
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por radastan » Vie Ago 13, 2010 11:14 am

mcleod_ideafix escribió:No tengo ni idea de lo que es una TrumCard, así que no sé cuán difícil puede ser. Bicheando por internet parece ser que es una tarjeta de expansión de memoria, en la que ponen más de 512KB aprovechando que hay un hueco de 128KB al final del espacio de memoria normalmente reservado a las EPROM de las expansiones, más una unidad de disquete. ¿Se tiene al menos un volcado de la ROM de la parte que gobierna la disquetera? ¿Unas fotos del aparatito?


¿Y si te mando una para que la examines y luego me la devuelvas? creo que el riesgo a que se me joda es muy inferior a lo que puedes hacer con tal información, y no conozco mejores manos que las tuyas.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por mcleod_ideafix » Sab Ago 14, 2010 2:55 am

radastan escribió:¿Y si te mando una para que la examines y luego me la devuelvas? creo que el riesgo a que se me joda es muy inferior a lo que puedes hacer con tal información, y no conozco mejores manos que las tuyas.


Te lo agradezco, pero salvo que no tengas ninguna prisa... es que dentro de unos días me pondré con la tesis y no podré hacerme cargo de más nada, hasta mediados de septiembre, o quizás octubre. Si aún tengo pendiente terminar de documentar la placa madre del Inves :O

Es por eso que el proyecto este que llevo a cabo con el QL lo quiero "finiquitar" en este fin de semana. Léase: comprobar que mi diseño es correcto, antes de decidirme por una versión "pinchable" en el lateral.

Para empezar, ya he visto claramente que lo de poner cosas encima de la CPU... como que no cabe. Hay unos 5-7 milímetros entre la parte de arriba de la CPU y la placa metálica que cubre el teclado, en la carcasa superior.

De todas formas, ya dije que esto era un prototipo, y me sirve para comprobar eso, que es correcto. Está claro que si quiero hacerlo "perdurable" tiene que ser vía conector lateral.

He cambiado un par de pistas respecto al diseño original, ya que por necesidades de rutado interno de la GAL, los pines que había elegido para ciertas entradas no son válidos. Ayer escribí el código que irá dentro de la GAL y lo simulé con cuatro ciclos de memoria: sólo el segundo y el tercero caen dentro del área de los 512KB expandidos, y sólo en ellos baja RAMCE. De estos dos, sólo en el ciclo de lectura baja también RAMOE. Creo que DTACK funciona como debe funcionar... no lo he podido leer en ningún sitio, pero parece ser que DTACK es una señal en colector abierto, que o bien está a alta impedancia (y por ende, a 5V gracias a una resistencia de pull-up) o bien a 0V. Por eso en la simulación se ve que pasa de alta impedancia a 0, y de ahí de vuelta a alta impedancia.

Imagen

Sea como fuere, hoy he podido pasarme por el laboratorio a fresar una placa en la máquina de prototipos...

Imagen

Y éste es el resultado, a punto de darle un bañito de flux que le durará toda la noche, así que mañana seguiré con ella. El bañito es muy aconsejable cuando se van a soldar componentes SMD, como es el caso.

Imagen

Mañana espero tener buenas noticias :)
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
radastan
Phantomas
Mensajes: 2232
Registrado: Lun May 07, 2007 5:34 pm
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por radastan » Sab Ago 14, 2010 1:07 pm

Pues cuando veas que tienes tiempo me das un toque y te la mando sin problemas, puedo prescindir de ella un mes o dos.
_________________________________________
Hay otras páginas.... pero no son Bytemaniacos
http://www.bytemaniacos.com
Orgullo de 8 bits
_________________________________________

Zerover
Jack The Nipper
Mensajes: 112
Registrado: Mar Abr 08, 2008 9:00 am

Re: Otra propuesta: ampliación interna de 512K

Mensaje por Zerover » Sab Ago 14, 2010 1:14 pm

mcleod_ideafix escribió:Para empezar, ya he visto claramente que lo de poner cosas encima de la CPU... como que no cabe. Hay unos 5-7 milímetros entre la parte de arriba de la CPU y la placa metálica que cubre el teclado, en la carcasa superior.


Aparte de que no sea la finalidad de este experimento que estás haciendo, ¿se podría sustituir la CPU por una menos voluminosa y de paso añadir 3MiB más de RAM?
Imagen

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por mcleod_ideafix » Sab Ago 14, 2010 3:36 pm

Zerover escribió:Aparte de que no sea la finalidad de este experimento que estás haciendo, ¿se podría sustituir la CPU por una menos voluminosa y de paso añadir 3MiB más de RAM?
Imagen

No sé si cabría, quizás sí, si la placa se hace con un espesor de 0,8 en lugar del espesor clásico de 1,6mmm. Este chip que has puesto... ¿se sigue vendiendo? ¿Tiene más líneas de dirección?
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por mcleod_ideafix » Dom Ago 15, 2010 10:50 am

mcleod_ideafix escribió:Mañana espero tener buenas noticias :)

Bueno, pues mañana fue ayer y aún no tengo buenas noticias, pero ya falta menos. De hecho, no le pude echar mucho rato a la interfaz porque hemos tenido una desgracia familiar: uno de mis gatitos (una gatita) que estaba en tratamiento por una insuficiencia crónica de riñón, no pudo más, y la urea en sangre terminó por debilitarla tanto, que hubo que llevarla al veterinario. La analítica salió por encima de los valores máximos que marca el aparato, y al final optamos por ponerla a dormir :(

Volviendo al tema: la interfaz está ya hecha, pero no funciona. El QL no reconoce ninguna memoria adicional.

Lo curioso es, que desde BASIC, si hacia POKE's y PEEK's a ciertas direcciones pertenecientes al espacio "expandido", me guardan los valores bien. "Qué extraño", ¿cómo puede haber memoria RAM más allá de la posición 262144 si la RAM termina precisamente en esa posición?

Pensando, erróneamente, que mi ampliación estaba siendo usada, pero en un rango de memoria equivocado, repasé las ecuaciones de la GAL, pero nada, están bien. Miro con el analizador lógico, y la RAM se selecciona cuando debe hacerlo. Aun así, haciendo POKE/PEEK a la dirección 262144 no me obedece (haciendo POKE/PEEK a una dirección 128K más hacia adelante, sí me obedece).

Me da por probar lo mismo pero con la expansión deshabilitada, y... ¡hace lo mismo!

Pero ¿dónde hay en el QL RAM adicional? No la hay. El mapa de memoria está bien clarito.

No encuentro ninguna documentación que hable de las interioridades del QL excepto... el manual de servicio técnico. Allí encuentro una referencia a una señal llamada KILLH que es activada por el QL cuando se accede a una posición que tiene A18 o A19 puesto a 1, cosa que ocurre con la ampliación de memoria. Esa señal desactiva a las dos ULA's del QL, para que de esa forma no intenten activar memoria RAM o ROM para ese ciclo de bus.

Miro en el esquemático, y veo que KILLH, cuando vale 1, lo que hace es activar un transistor que a su vez pone a 1 de forma permanente la señal DSMC, que es una copia de la señal /DS que viene del procesador y que va a las dos ULA's. De esa forma, mientras el transistor conduzca, DSMC siempre valdrá 1, y las ULA's se quedarán "sordas".

KILLH no tengo que activarla yo, sino que lo hace el QL, entonces... ¿no está funcionando? Miro con más detenmiento y veo que a la base del transistor llegan dos señales: una es la mencionada KILLH, y la otra es la versión negada de /VPA, una señal de entrada a la CPU. Habitualmente, esta señal está a 1 merced a una resistencia de pullup, con lo que su versión negada vale 0, y ese 0 es el que se mete en la base del transistor. Cuando VPA vale 0, la versión negada vale 1, pero no un 1 "fuerte" sino que quien "niega" la señal es un 74LS03, que tiene salidas en colector abierto. Esto significa que el 1 en realidad es "circuito abierto", por lo que lo que pasa es que se aisla de la base del transistor y KILLH puede entrar en acción.

¿Cómo se puede forzar entonces un 1 en la base del transistor? Pues hay dos formas: poniendo a 0 VPA, pero esto hace que el 68008 crea que hay un periférico síncrono al otro lado del bus, y la otra opción, que es la que creo que se usa de forma "oficial", es forzando un 1 en DSMC. DSMC funciona, para los que conozcáis el hardware del Spectrum, exactamente igual que nuestra amiga la señal IORQGE (o IRQULA en algunos documentos). Esta señal desactiva la ULA y permite usar en el Spectrum números de puerto par. Otra señal que funciona de forma análoga es ROMCS, que es la que desactiva la ROM del Spectrum cuando ponemos un cartucho de Interface II, o se pagina la shadow ROM de la interface 1, del DivIDE, etc.

Así que, en cuanto nos tranquilicemos un poco por todo lo pasado recientemente, añadiré una ecuación más a la GAL para generar correctamente la señal DSMC y la soldaré directamente con un cablecillo al punto más adecuado. (Otra razón más para hacer esta ampliación como una tarjeta enchufable por el puerto lateral, por cierto).

La pregunta que queda pendiente es: ¿qué estaba pokeando en la dirección 262144+131072 que me estaba haciendo caso? Pues creo (no lo he comprobado, pero visto lo visto, tiene todo el sentido), que la ULA mapea la ROM y la RAM varias veces en el espacio de memoria, por hacer una decodificación parcial del bus de direcciones. Lo que estaba pokeando en esa dirección es lo mismo que pokearía en la dirección 131072, que es precisamente el inicio de la RAM. Cuando creí que mia ampliación estaba decodificándose en un rango equivocado hice un pequeño programa que testeara toda la zona de la RAM desde 262144 hasta el final, y la primera dirección "pokeable" la encontró en 262144+131072. Ahora entiendo por qué no encontré ninguna dirección válida entre 262144 y 262144+131071. Ah! y ahora también entiendo porque al seguir pokeando más arriba se acabó llenando el programa BASIC de basura (había pokeado en la zona donde se guarda el programa!!)
Web: ZX Projects | Twitter: @zxprojects

Zerover
Jack The Nipper
Mensajes: 112
Registrado: Mar Abr 08, 2008 9:00 am

Re: Otra propuesta: ampliación interna de 512K

Mensaje por Zerover » Dom Ago 15, 2010 12:43 pm

mcleod_ideafix escribió:Este chip que has puesto... ¿se sigue vendiendo?

Pues no sé, pero es posible que los chinos sí que lo vendan.

mcleod_ideafix escribió:¿Tiene más líneas de dirección?

Sí. Tiene cuatro pines más, dos de ellos son las líneas de dirección A20 y A21.

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por mcleod_ideafix » Dom Ago 15, 2010 8:01 pm

Zerover escribió:Sí. Tiene cuatro pines más, dos de ellos son las líneas de dirección A20 y A21.

Vale, ya sé cuál es. Con esa versión, efectivamente, puedes direccionar hasta 4MB de memoria. Pero el mapa de memoria del QL tiene un problema: oficialmente, los últimos 256KB del espacio de memoria de 1MB están reservados para EPROM's de periféricos (hasta 16 EPROM's de 16KB cada una). Si se respeta eso, cualquier ampliación posterior (los 3MB que pueden añadirse) estarían más allá de ese hueco.

Esto no sé si lo soporta alguna de las ROM's que hay para QL (estoy pensando sobre todo en Minerva). No sé si para detectar la cantidad de RAM libre necesita que ésta sea contigua o no. Si necesita que sea contigua, habría que "invadir" el espacio dedicado a dichas EPROM's para no perder la continuidad de la RAM.

Otra cosa que no sé si se soporta en Minerva o algún otro S.O. para QL es tener más de 1MB de RAM.

El caso ideal es que el S.O. soporte más de 1MB de RAM y que no le importe que haya un "hueco" de 256KB al final del primer mega de memoria. Si esto es así, mucho mejor. La cosa es, ¿cómo se puede averiguar?
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por mcleod_ideafix » Dom Ago 15, 2010 8:10 pm

Zerover escribió:Pues no sé, pero es posible que los chinos sí que lo vendan.

Lo estoy viendo en eBay, a unos 6 euros la unidad (más gastos de envío)...
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K

Mensaje por mcleod_ideafix » Lun Ago 16, 2010 6:00 am

Vale, pues esto ya funciona. Unas fotillos, mientras explico cómo ha ido la cosa:

La placa, con los puentes soldados (las pistas en rojo en la PCB, para no tener que usar una placa de doble cara):
Imagen

Una vez puestos los puentes, soldamos los componentes SMD: dos pequeños condensadores de desacoplo (casi no se verán en la foto), y la memoria. Soldar la memoria es más sencillo de lo que parece: se "presenta" el chip a la placa, se embadurna de flux las dos filas de pines, se pone un pegote de estaño en la punta del soldador, y se "pasea" la punta por tooooda la fila. Si se formaran puentes juntando dos o más pines, se limpia con la malla desoldadora.
Después de la memoria se suelda el zócalo para la GAL, y el zócalo de patas largas para el 68008 (en realidad son dos zócalos de 24 pines unidos, de los que se usan para diseño wire-wrapping)
Imagen

La cara de componentes sólo tiene los zócalos para los chips. Aquí está ya puesta la GAL.
Imagen

La placa, ya pinchada sobre el zócalo del 68008. Por supuesto, el QL no se puede cerrar con esta placa puesta, pero me da igual, ya que sólo quiero cercionarme de que esto funciona. Ya he comentado en posts anteriores que debido a esto, y a que cierta señal que me hace falta está sólamente disponible en el conector de expansión, esta ampliación, para ser usada "en producción" debería ir pinchada a dicho conector.
Imagen

El cablecillo que sale de la GAL hacia la placa ha sido el quebradero de cabeza de estas últimas 24 horas. (¡UPDATE!: debería haberme leído con calma la página 64 del QL Technical Guide, que dice esto mismo que voy a decir yo ahora, bien clarito. En finx...)

Algo expliqué antes, pero para simplificar: existe una señal en el interior del QL que permite desactivar a voluntad las dos ULA's, a la manera en que se hace en el Spectrum 48K. ¿Y por qué hace falta desactivar las ULA's cuando accedemos a la ampliación de memoria? Pues porque éstas son las responsables de direccionar y activar los primeros 256K del mapa de memoria: esto incluye la ROM del sistema, la ROM auxiliar, el espacio para periféricos del sistema, y los primeros 128K de RAM, y "gracias" a que la decodificación del bus de direcciones es incompleta, resulta que si no se desactivan las ULA's, al acceder a una dirección de memoria donde se supone que no hay nada, lo que tenemos es un "espejo" de los primeros 256K del mapa de memoria.
Por ejemplo: si en un QL original, sin expandir, hacemos un PEEK a la dirección 262144, lo que se lee es lo mismo que se leería en la dirección 0.
El resultado final de esto es que con la ampliación puesta, si no se desactivan la ULA's lo que pasará es que la memoria de la ampliación colisionará con lo que quiera que esté enviando el QL por la ROM o la RAM del sistema, según la dirección a la que accedamos (en el ejemplo del PEEK 262144 sería el primer byte de la ROM del sistema).
En el QL la señal que desactiva las ULA's se llama DSMC(L). En los esquemáticos y en otros documentos le ponen la L para indicar que es activa a nivel bajo. Yo simplemente la llamaré DSMC (Data Strobe Master Chip). Está en el pin 5 de IC22, entre otros lugares, y se muestra parcialmente en este esquema.
Imagen

DSMC es una señal que, en principio, viene "casi" directamente desde la señal DS del procesador. Esta señal indica cuándo la transferencia de datos es posible desde o hacia el 68008. Si nunca baja, el dispositivo piensa que la CPU no está haciendo un ciclo de bus, y por tanto no hace nada. El "casi" de antes significa que DSMC está desacoplada de DS mediante una resistencia de 330 ohmios. Si nadie fuerza un valor 1 ó 0 en DSMC, esta señal seguirá las variaciones de DS, pero si un dispositivo externo fuerza un 1 en esta línea, DSMC dejará de seguir a DS y se quedará con el valor que le digamos.

En el QL hay dos formas de forzar esta línea a 1. La primera forma es bajando la señal VPA y a la vez, acceder a una dirección que tenga A18 ó A19 a 1. En la ampliación se cumple que la memoria se selecciona precisamente con esta combinación de A18 y A19, pero no bajamos VPA porque la memoria no es un periférico síncrono de la familia 6800 (que es para lo que sirve esta señal VPA) así que este método no nos vale. EDITO: en realidad sí que vale. Lo acabo de comprobar :) Si se hace así, basta con llevar la señal RAMCE directamente a VPA, con lo que la señal DSMC no hace falta ser generada.

La segunda forma es forzando directamente el 1 en la línea DSMC. Esto es lo que haremos nosotros. Para ello se ha añadido una ecuación más a la GAL que calcula el valor que debe tener DSMC para el ciclo de bus actual, y que puede ser "alta impedancia" o 1.
Imagen

Y ahora sí que podemos arrancar el QL, y ver los resultados :) Se nota para empezar que tarda más en arrancar, debido a que se chequea mucha más memoria. Pero al final, obtenemos esto (arrancando con Minerva 1.98):
Imagen

Y desde SuperBASIC, probando algunos comandos para ver dónde reserva memoria un RESPR, y usando una de las variables del sistema (una variable análoga a la variable P_RAMT del Spectrum) para obtener la dirección máxima de RAM+1 disponible:
Imagen

El valor, 786432, corresponde en hexadecimal a C0000, que es ni más ni menos que el tope asignado a la memoria expandida del QL en el mapa de memoria :) . En resumen: tenemos toda la RAM que oficialmente podemos tener en el QL :D
Imagen

Por último, en lugar de poner las ecuaciones de la GAL, pongo el circuito equivalente que habría que hacer con componentes discretos. Si uno echa las cuentas, verá que necesitará un puñado de chips para implementar este circuito, por otra parte sencillo. Teniendo disponible las GAL, no hay color :)
Imagen
Última edición por mcleod_ideafix el Lun Ago 16, 2010 8:49 pm, editado 1 vez en total.
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
Zitror
Herbert
Mensajes: 69
Registrado: Mié Oct 07, 2009 10:36 am
Ubicación: el interior de un Z80

Re: Otra propuesta: ampliación interna de 512K (¡FUNCIONA!)

Mensaje por Zitror » Lun Ago 16, 2010 5:50 pm

Madre mía, merece la pena leerse el artículo, sí señor pese a ser un neófito del QL :D
No soy técnico en la materia (ni mucho menos) pero cuenta con un ávido lector de este hilo.

Salu2 :wink:

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: Otra propuesta: ampliación interna de 512K (¡FUNCIONA!)

Mensaje por mcleod_ideafix » Lun Ago 16, 2010 9:02 pm

Gracias! :) Creo que puedo hacer una versión de esta ampliación para instalar internamente en un QL, como si fuera un "modchip" (ya sabes: un chip de estos de consola de los que tienes que soldar tropecientos cablecillos :D )
Web: ZX Projects | Twitter: @zxprojects

Responder

¿Quién está conectado?

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