ZX Spectrum + versus Inves Spectrum +

[mcleod_ideafix]

¿No hay por ningún sitio un esquemático del Inves?

[Gandulf]

¿Ein?

Pero no sé que tiene que ver la ULA con que la ROM sea un EPROM. Pokear la ROM, sea ram o eprom no produce ningún resultado, o sea, la dirección de memoria sigue con el valor original. Veo por tu respuesta que estás seguro de ello ?¿ Es lo más raro que he oído nunca.

Editado: Al ver la respuesta de McLeod, en todo caso podría ser algo raro del diseño del Inves, en plan bug de diseño pero es raro de caray. ¿Con sonido te refieres al sonido del beeper????, no entiendo como podía ser incompatible a este nivel, ya que el sonido se produce moviendo hacia dentro y fuera el zumbador por medio de un bit por OUTs. Es rarísimo esto que comentas.

[mcleod_ideafix]

Pokear la ROM es hacer un acceso de escritura de memoria a una dirección que tiene A5=0 y A14=0. La ULA del Inves no sé, pero la ULA original de Ferranti examina esos bits del bus de direcciones para saber cuándo la CPU está accediendo al banco de la memoria de video y pararla si hiciera falta.
Es posible que en el diseño de la máquina de estados de la ULA del Inves (de Texas Instruments si mal no recuerdo), no hubieran tenido en cuenta el acceder a memoria de ROM en escritura y de ahí los comportamientos raros...

[Gandulf]

Pero en el caso en que esto fuera así, si la ULA lo que chequea es el acceso a la memoria contenida y pokear la rom la confundiera por el motivo que sea, cómo podría hacer que el tratamiento del borde y el sonido fueran compatibles con el modelo original hasta un reset eléctrico?¿Esos pokes los sacasteis al azar? me imagino que sí.

[chernandezba]

Hola a todos
Bueno, yo tengo conocimientos mínimos de electrónica por tanto la explicación a ese nivel no os la puedo dar. Efectivamente, esos POKEs se sacaron primero al azar y luego a base de mucho probar. Al principio, nos dimos cuenta que juegos con el modo de carga speedlock, concretamente el Enduro Racer, que era uno de los que jugabamos bastante, si fallaba al cargar dejaba el inves con borde de color siempre 0, y sin sonido.

Creo que lo posterior fue intentar desproteger el speed lock del enduro racer (sin exito, si hay alguien que llegó a probarlo, es bastante complicadillo) y nos dimos cuenta de que dentro de los muchos bucles internos que tiene de protección, en uno hacia copias de datos de la RAM hacia la ROM, cosa que normalmente en un sinclair no afecta en nada, en el Inves lo dejaba sin sonido y con el borde en negro.

Sabiendo esto, hicimos una pequeña rutina en assembler que pokeaba toda la ROM con un valor determinado, fuimos probando desde 0 hasta 23, creo, hasta que dimos con los valores "mágicos". Un caso típico de juego que no se oía sonido era los Lemmings, en la música del principio (antes de cargar los niveles) se oye una música a "2 canales" con el beeper, bastante chula, pero en el inves solo se oía el canal del ritmo, bastante frustrante. Pokeando en la ROM se podia conseguir que se oyera todo. Tambien en el juego Batman, the caped crusader, sucedia algo similar. Eran muchos los juegos con música a 2 canales (en el beeper, nada del chip AY) en los que solo se oia el ritmo en el inves

Al cabo de unos años, me di cuenta que solo pokeando unas direcciones concretas de la ROM, y no toda, se podia conseguir el mismo efecto. Os he hecho un copy-paste de la doc que tengo en mi emulador, espero no haberme excedido demasiado:

"Existen determinadas direcciones "privilegiadas" de la ROM en las que se
puede alterar el funcionamiento normal del Inves; estas direcciones son las que el byte bajo de la
dirección es 254 (XXFEh), como el puerto del sonido.
Pokeando en todas estas direcciones de la ROM (254,511,,...,16383) con un mismo valor, lo que
se crea es una máscara AND que se aplicará en el valor enviado al puerto 254, y ese será el valor
real enviado. Debemos asumir que el POKE en la ROM al enchufar el ordenador (y no al hacer un
RESET) es 255. De esta manera, se producen dos efectos:
1. El primero es que los tres bits inferiores constituyen una máscara a la hora de cambiar el
borde con un OUT 254, es decir, al valor enviado al puerto 254 se le hace un AND con el
valor que se POKEa la ROM, y ese será el color del borde: por ejemplo: con un POKE en la
ROM con 6, tendremos Borde de color par, es decir, el borde 0 y 1 será el 0, el 2 y 3 será 2,
etc. Por otra parte, si POKEamos con 0, todos los bordes que pongamos seran negros (0).
2. El segundo efecto (y el peor en muchos juegos con música) es el sonido. Intentaré
explicarlo de manera sencilla, aunque es un poco complicado. A los bits 3 y 4 del valor que
se envía al puerto 254 se le hace un AND con el valor del POKE a la ROM. Entonces, se
hace un XOR de los bits 3 y 4 resultantes, de manera que obtenemos 1 bit de resultado.
Entonces, este bit será el enviado al altavoz, de manera que si se envía un bit igual al anterior,
el altavoz no se conmuta y no hay sonido. Hay que recordar que en un Spectrum normal,
cualquier valor de los bits 3 y 4 que sean diferentes a los anteriores producen sonido."

En esa doc hay una tabla donde explico todas las combinaciones

Saludos
Cesar Hernandez

[Gandulf]

Ahora sí lo he entendido bien. Vaya movida esta del inves. Parece que no lo probaron mucho antes de sacarlo al mercado ¿no?

[Borrocop]

El problema que tenia Inves como empresa es que Amstrad había adquirido Sinclair y en tiempo record tenían que sacar un "clónico" que ocupase ese lugar, y con las prisas vienen los errores.

Aún asi vendieron unos cuantos pero con la competencia del Zx +2 y +3 a las puertas eran residuales las ventas que podían tener y el servicio de reparación (un atraco por entonces) se iba al garete ya que amstrad tenía el suyo propio.

Saludos

[mcleod_ideafix]

-Refresco de la pantalla: El haz de electrones se situaba al inicio de una interrupcion a la altura de la pantalla visible, o sea, por debajo del borde superior

Síiiiiiiiiiiiii. Acabo de comprobarlo. Resulta que acabo de ponerle un adaptador de teclado PS/2 que tenía por ahí a uno de mis Inves, y he estado probando algunas cosillas que tenía hechas, a ver qué tal se comportaba. Con un programa muy simple que cambia el color del borde en cada retrazo, me he dado cuenta de que el cambio se produce justo en la línea de pantalla donde comienza el "PAPER".
¡¡Así no hay casi tiempo para mover sprites sin parpadeos!! ¿Por qué hicieron eso?

Voy a probar el famoso RANDOMIZE USR 4665...

Ya está probado: los resultados los he mostrado en mi sitio web

[jfroco]

mcleod_ideafix ,

Interesantes resultados. Gracias por compartirlos.

No había leído este hilo antes, y me llamó la atención que el Inves entregara siempre 255 cuando se leía el puerto 255. Esto obviamente, trae problemas de incompatibilidad:

Al hacer IN al puerto 255 o a algún puerto inexistente en el Spectrum se obtiene el dato de video que están escribiendo en pantalla. Lo anterior debido a que existen unas resistencias de 470[Ohms] entre la ULA y el bus de datos que no sirven como aislante cuando se direcciona un puerto inexistente.

El valor que se obtiente puede ser: un valor de píxel, un atributo (color) o nada (el borde). El borde entrega un valor de FFh.

Los programadores usaban esto para sincronización de video o para realizar una pausa de acuerdo a la tasa de refresco del video. Ejemplo:

Código: Seleccionar todo

      LOOP  IN A,(#FF) ; Lee el “puerto”
      CP A,#FF ; ¿Está en el borde o en la ventana?
      JP Z,LOOP ; Salta hacia atrás si está en el borde      ..... 
      ; Continúa

Estes tema es de mi atención porque yo tenía originalmente un Timex Computer 2048.

En el TC2048 no existe esta conexión y el bus de datos está levantado a +5V por 8 resistores de 10[KOhms], por lo que al direccionar a un puerto inexistente siempre se lee FFh. Lo mismo pasa en el Inves al contar con un buffer en el bus de datos.

Dado que al leer el puerto FFh siempre se obtiene el valor FFh algunos juegos que utilizan el bucle anterior quedan bloqueados, y por lo tanto deben ser “parchados” para funcionar correctamente en el TC2048.

¿Servirán estos parches para el Inves?

Saludos

JF

[mcleod_ideafix]

Dado que al leer el puerto FFh siempre se obtiene el valor FFh algunos juegos que utilizan el bucle anterior quedan bloqueados, y por lo tanto deben ser “parchados” para funcionar correctamente en el TC2048.

¿Servirán estos parches para el Inves?

Sí. De hecho el +2A/+3 también tienen este problema y los juegos más antiguos tienen que ser parcheados para estos sistemas, con lo que el Inves y el TC2048 no son los únicos que adolecen de este "fallo".
Por otra parte, en el +2A/+3 también había un remedio "hard" para volver a tener operativo ese puerto, pero me da a mi que en el Inves sería más difícil de implementar, ya que no hay bancos separados de memoria, lo que me lleva a su vez a otra pregunta: si hay, como parece ser, un solo banco de memoria, ¿cómo solucionaron el tema de la memoria contenida? Voy a mirar un poco a ver...

EDITO: acabo de mirar, y a la conclusión que llego es: en el Inves no hay memoria contenida. Toda la memoria va a la misma velocidad. No he medido nada con el osciloscopio, sólo he hecho una prueba de velocidad emitiendo un tono con un programita en ensamblador. El tono se escucha exactamente igual tanto si la rutina se ubica en la memoria superior, como si lo hace en la propia memoria de pantalla. He grabado el tono en ambos casos y los he comparado muestra a muestra con el Sound Forge, y no hay cambio de frecuencia, ni "glitches" ni nada de eso. Ambos tonos están en fase durante toda la grabación.

Para colmo, esto es lo que me devuelve el fusetest aplicado a este Inves:

[Gandulf]

en el Inves no hay memoria contenida

Uy, pues eso sí que está bien salvo que toda sea contenida. ¿Cómo han resuelto entonces el problema de los accesos simultáneos a la RAM? Esto quiere decir que toda la memoria es igual de rápida que la memoria no contenida de un spectrum, o que toda es tan lenta como la contenida??

[mcleod_ideafix]

Uy, pues eso sí que está bien salvo que toda sea contenida. ¿Cómo han resuelto entonces el problema de los accesos simultáneos a la RAM?

Pues como se "debería" haber hecho desde un principio en el Spectrum: usando multiplexación en el tiempo, es decir, intercalando accesos de la ULA con accesos de la CPU.

Esto quiere decir que toda la memoria es igual de rápida que la memoria no contenida de un spectrum, o que toda es tan lenta como la contenida??

De momento, lo que significa es que todos los accesos son idénticos, sea cual sea la dirección. Esto es, que la velocidad de la memoria es uniforme. Tengo que pincharle el osciloscopio a esto para ver si la señal de reloj que recibe la CPU cambia al pasar por ejemplo, de ROM a RAM.

[mcleod_ideafix]

Ea, pues ya le he pasado el osciloscopio a esto.

Aquí está la señal de reloj mientras ejecuta un bucle sin fin, con las interrupciones deshabilitadas. El código de este bucle lo he "pokeado" en la pantalla, a partir de la dirección 16384.


La captura está parada para poder sacar la foto cómodamente, pero os aseguro que la señal no varía. En el Spectrum de Sinclair aparecen esporadicamente niveles altos en esta señal, cuando se están aplicando las reglas de contienda. Aquí no aparece nada de nada.

Tampoco hay nada en las señales WAIT o BUSRQ. Ambas están permanentemente a nivel alto, es decir, desactivadas.

No he puesto la foto del mismo bucle ejecutándose en la memoria superior, porque es que la imagen que da es exactamente igual. Idem cuando se ejecuta una rutina en ROM (por ejemplo, un BEEP de 9 segundos).

Con lo que me reafirmo en lo dicho: el Inves Spectrum no sufre de ningún tipo de contienda en memoria, y además todos los accesos a la memoria se realizan a la velocidad nominal del micro, que como podéis ver, es ligeramente superior a la del Spectrum de Sinclair. Esta velocidad viene de dividir la señal del reloj maestro, de 17,7345 MHz entre 5.

Se puede ver la medida entre los dos puntos de la señal de reloj (cuadro titulado "Diferencia") en donde aparece la frecuencia de reloj medida: 3,546 MHz, que coincide con el cálculo expuesto.

Si repasáis cualquier imagen de la placa del Inves, veréis que sólo hay un cristal de cuarzo, no dos como suele ser habitual en los Spectrum's de Sinclair. El segundo cuarzo es para el reloj de color, que va a 4,43MHz. En el Inves lo que han hecho es derivar todas las frecuencias necesarias a partir de un único reloj. Así, si se divide la frecuencia de este reloj fundamental entre 4, obtenemos la frecuencia del reloj de color.

Otra cosa más: después de tenerlo un rato funcionando, veo que la ULA de Texas Instruments que incorpora apenas se calienta. Sí se calienta la chapa del disipador, que en el Inves es más pequeña que en los Sinclair, pero al menos tiene mejor ventilación que las primeras.

Bueno, creo que después de tanta incompatibilidad y comportamientos extraños, esto puede considerarse un punto a favor del Inves, ¿no?

[Gandulf]

un puntazo, en los juegos para speccy tienes que tener separadas las cosas y tener estoy muy en cuenta, porque se nota; al menos se nota lo bastante como para no poder pasarlo por alto en un juego que tenga uso intensivo de sprites o scroll y la verdad es que es un coñazo.

[mcleod_ideafix]

Pues sí. Lástima que después la cagaran con el rollo de disparar la interrupción justo cuando la ULA está a punto de escribir la primera línea visible de pantalla, en lugar de dispararla al comienzo del retrazo vertical.