Espiando transfers

Juegos, aplicaciones, ROMs;
todo lo que se pueda ejecutar en un Spectrum

Moderador: Sir Cilve Sinclair

Responder
zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Espiando transfers

Mensaje por zup » Sab Feb 04, 2017 4:48 pm

He estado echando una ojeada a algunos juegos copiados con transfer (había unos cuantos en los tzx de ralphy), con vistas de hacer una utilidad que convierta snapshots a tap (¿para qué inventar el proceso de carga si puedo copiarlo?). Por el camino, he encontrado cosas curiosas.

Los que he mirado son:
  • Transtape
  • Phoenix
  • Dinamid 3
  • "La máquina alucinante" (a partir de aquí, LMA)
  • Pokeador automático (Transfer publicado en MH144 y corregido en 147). Hay otros dos programas de transfer para el pokeador automático (Transpoke, MH179 y Transfer para +3, MH191) que no he probado.
  • Specmate
  • Multiface 1 (este no lo he mirado demasiado)
Como curiosidad, Phoenix, Dinamid 3 y LMA están muy emparentados. Aunque el cargador es diferente (Dinamid 3 utiliza la ROM, Phoenix y LMA tienen cargadores turbo), el programa que restaura los registros es idéntico en ambos casos. El Pokeador automático parece más "de aficionados" (no preserva R, pero preserva explícitamente PC) y Multiface 1... Multiface 1 es una bestia rara que no he analizado del todo por pereza (si en algún apartado no lo comento, es porque no lo he analizado).

Algunas características:
Corrupción de pantalla: Transtape corrompe tres líneas de la pantalla, pero como lo hace en líneas contiguas el efecto son tres rayas bastante visibles. Phoenix es más discreto, corrompiendo solo las dos líneas superiores y su primo Dynamid se cepilla tanto las dos líneas superiores como las inferiores. El Pokeador es más "cacharrero", corrompiendo líneas por todas partes. En cuanto al Multiface... no dudo que sea un buen transfer, pero es que corrompe todo un tercio de la pantalla. Specmate se aparta de la tónica general ya que es muy flexible: nos deja elegir qué zona de la pantalla corromper (podemos elegir una que se refresque frecuentemente y así no tener basurilla en pantalla) y además podemos elegir entre incorporar la pantalla de carga original, utilizar solo la del snapshot o no incluir ninguna (pensándolo bien, esta última opción es la más destrozona de todas).

Gestión de interrupciones: El menos respetuoso es el Pokeador. Si I=63, pone el modo IM1 y si es cualquier otro valor el modo IM2. Esto podría llevar a algunas incompatiblidades. Transtape guarda IM y el estado de las interrupciones en un byte, y tiene una rutina para descifrarlo (solo preserva IM1/IM2), mientras que Phoenix/Dinamid 3/LMA y Specmate meten el IM y la habilitación como instrucciones (en vez de almacenarlo en un byte y decodificarlo como Pokeador y Transtape). Esto es más compacto y ocupa menos en pantalla, y además hace que puedan preservar algo tan raro como IM0 (dudo mucho que el hardware original detecte IM0 o que esto sea de utilidad en un juego).

La pila: Excepto el Specmate (que necesita 12 bytes de la pila en todos sus modos), los demás interfaces sólo necesitan 2 bytes de la pila para hacer su trabajo.

Borde: Me ha parecido curioso que el único transfer que guarda el borde explícitamente (y probablemente podría guardar todo el estado del puerto 254) es el Transtape. Ninguno de los demás incluye instrucciones para restaurar el borde, lo que me lleva a pensar que confían en que el valor de BORDCR sea el correcto.

Carga y compresión: Transtape y Pokeador automático guardan el programa al completo (ojo: el programa original del Pokeador Automático no guarda el último byte de la memoria). Phoenix/Dinamid 3 "recortan" el final de uno de los bloques, de manera que si la RAM está llena de ceros (porque el programa no llene toda la RAM) pueden ahorrar cinta (LMA además puede recortarlo por el principio). Multiface 1 parece necesitar menos espacio, pero no sé si comprime datos, los recorta o qué hace exactamente. Specmate puede tanto ahorrar cinta (si no incorporas ninguna pantalla) como desperdiciarlas (si incorporas la pantalla de carga original).

Formatos de carga:
Transtape:
- Bloque BASIC.
- Bloque CODE 16384,75 (rutina para cargar el programa y restaurar los registros).
- Bloque sin cabecera, inicio en 16484 y longitud 49052. Los primeros bytes son el estado de la máquina. Se carga con la rutina de la ROM.

Phoenix:
- Bloque BASIC.
- Bloque CODE 64000,354 (contiene el cargador, creo que tiene rutinas de carga a velocidad estándar y turbo).
- Bloque headerless, inicio en 16384 y longitud 9216. Creo que puede ser turbo.
- Bloque headerless, inicio en 25600 y longitud máxima 38400. El bloque puede "recortarse" si la RAM contiene ceros. La longitud de este bloque está en la dirección 16644, y creo que también podría ser turbo.
- Bloque headerless, inicio en 64000 y longitud 1536. Carga con la rutina de la ROM.

Dynamid 3:
- Bloque BASIC.
- Bloque SCREEN$.
- Bloque headerless, inicio en 23296 y longitud 9216. Carga con la rutina de la ROM.
- Bloque headerless, inicio en 25600 y longitud máxima 38400. El bloque puede "recortarse" si la RAM contiene ceros. La longitud de este bloque está en la dirección 16644. Carga con la rutina de la ROM.
- Bloque headerless, inicio en 64000 y longitud 1536. Carga con la rutina de la ROM.
(NOTA: La descripción de los dos últimos bloques es muy similar a la del Phoenix, aunque debido a que Dynamid NO usa el área a partir de 64000, podría cargar esos dos últimos bloques en uno solo)

Pokeador automático (Transfer, MH144):
- Bloque BASIC.
- Bloque SCREEN$.
- Bloque headerless, inicio en 23296 y longitud 42239 (o 42240 si usa la versión corregida).

Pokeador automático (Transpoke, MH179):
- Bloque BASIC
- Bloque headerless, inicio en 16384 y longitud 24576
- Bloque headerless, inicio en 40959 y longitud 24577 (si la primera versión tenía un bug que no guardaba toda la memoria, esta versión guarda un byte dos veces)

Specmate (sin pantallas):
- Bloque BASIC.
- Bloque headerless, inicio 18432 y longitud 288 (rutina cargador y de arranque)
- Bloque headerless, inicio 25000 y longitud 20000
- Bloque headerless, inicio 45000 y longitud 20536
- Bloque headerless, inicio 23296 y longitud 1704

Specmate (con una pantalla pantalla):
- Bloque BASIC.
- Bloque headerless, inicio 16384 y longitud 6916 (pantalla del snapshot)
- Bloque headerless, inicio 25000 y longitud 20000
- Bloque headerless, inicio 45000 y longitud 20536
- Bloque headerless, inicio 23296 y longitud 1704

Specmate (con dos pantallas):
- Bloque BASIC.
- Bloque headerless, inicio 16384 y longitud 6912 (pantalla de carga original)
- Bloque headerless, inicio 25000 y longitud 20000
- Bloque headerless, inicio 45000 y longitud 20536
- Bloque headerless, inicio 16384 y longitud 6916 (pantalla de carga del snapshot)
- Bloque headerless, inicio 23296 y longitud 1704

Disciple (en realidad, esto viene de una utilidad publicada en MH167 que permite pasar snapshots de Disciple a cinta):
- Bloque BASIC
- Bloque headerless, inicio 16384 y longitud 15300
- Bloque headerless, inicio 31864 y longitud 33852

He recopilado todos estos datos en una hoja de cálculo que se puede consultar aquí.
Última edición por zup el Vie Feb 10, 2017 12:24 pm, editado 6 veces en total.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zx81
Freddy Hardest
Mensajes: 619
Registrado: Vie Dic 28, 2007 2:14 pm
Ubicación: Valencia
Contactar:

Re: Espiando transfers

Mensaje por zx81 » Sab Feb 04, 2017 6:46 pm

Vaya curro te has pegado, amigo. Al Multiface le daba igual lo que corrompía porque, se suponía, eran tus copias de seguridad y las volvías a cargar con el MF1 activado.N ese caso, el MF tiene 8K de RAM propias, lo que no sé es cómo las usaba ni donde guardaba esos datos para no cargarse la pantalla.

JSpeccy soporta los Multifaces, a ver si un día de estos pruebo a grabar en una cinta virtual algo, para ver cómo se lo montaba.
Debido al fallo de un mecanismo, el lanzagranadas M203 se te podía disparar cuando menos lo esperaras, lo que te habría hecho bastante impopular entre lo que quedara de tu unidad.
Revista del ejército EE.UU. PS, agosto 1993.

Emulador JSpeccy
ZXBaremulator

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Espiando transfers

Mensaje por zup » Dom Feb 05, 2017 8:54 am

Pues todavía tengo que preparar una hoja de cálculo que dice qué registros se almacenan en qué direcciones, y el desensamblado de las rutinas de los transfer (lo tengo todo escrito en un txt).

Hablando un poco de todo...

Para localizar los juegos he utilizado la información de "Pasadisk". En ella menciona que los juegos de Multiface muestran el mensaje M1 LOADING, así que he buscado en los juegos de Ralphy uno que lo hiciera.

En alguna parte (no recuerdo dónde) leí que las primeras series de Multiface 1 podían grabar el juego y después se podía cargar sin necesidad de Multiface. De lo que sí estoy seguro es que hay utilidades que eliminan el requerimiento de tener el Multiface para cargar. El juego que encontré (Bazooka Bill) carga sin multiface.

En cuanto a la corrupción de pantalla, esta corrupción viene de que para hacer el snapshot necesitas toda la RAM y el estado de la máquina. Habitualmente se pone en la pantalla por dos razones:
- Es muy raro que la pantalla tenga código ejecutable (muy raro, no imposible... Skool Daze tiene datos ahí durante la carga y los mantiene hasta que dibuja el colegio por primera vez).
- La pantalla se redibuja durante el juego, de manera que esas antiestéticas líneas desaparecen (salvo que te toque en la zona de marcadores, como en 1942 o las Tortugas Ninja).

Ahora bien, estos interfaces paginan sus propias rutinas sobre la ROM del Spectrum (si no, la NMI no funcionaría), y en algunos casos también paginan RAM para sus tejemanejes. Esta RAM se puede usar para salvar el estado de la máquina, de manera que no haya corrupción en pantalla. La pega es que para cargar un juego salvado así, necesitarás tener el mismo interface conectado al ordenador.

Por cierto, no he encontrado ningún juego que haya podido identificar positivamente como Specmate o Disciple (he hecho una búsqueda rápida buscando contenidos en los ficheros), así que no he analizado estos dos cacharros.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zx81
Freddy Hardest
Mensajes: 619
Registrado: Vie Dic 28, 2007 2:14 pm
Ubicación: Valencia
Contactar:

Re: Espiando transfers

Mensaje por zx81 » Dom Feb 05, 2017 11:03 am

Me parece recordar que los Multiface MF1 y MF128 podían cargar los juegos sin el aparato conectado. Fue en el MF3 cuando el tema de la piratería empezó a ponerse seria y creo que ya no permite cargar los juegos sin el aparato conectado.

Incluso diría que del MF1 hay al menos dos versiones. Una, que no permitía "ocultar" el aparato más que con un switch externo de forma manual y que solo tenía 2KB de RAM propia. Y una segunda versión que ya permitía escamotear la existencia del aparato por software, además de llevar 8KB de RAM. Luego ya el MF128 y el MF3 tienen más en común y éste último ya tiene un hardware bastante sofisticado que hace bastantes más cosas de las que parece.

Teniendo esos 8KB de RAM, ya puedes preservar la pantalla sin problemas, pero en alguna parte deberá cargar desde cinta bien la parte de la pantalla que estropea para poder restaurarla, bien el bloque que en lugar de meter en la pantalla mete en su RAM.

Es un poco sorprendente, pero después de las ROMs del Spectrum y del IF1 las de los Multifaces deben ser de las más interesantes de desensamblar, no sé como nadie se ha puesto a ello hasta ahora.
Debido al fallo de un mecanismo, el lanzagranadas M203 se te podía disparar cuando menos lo esperaras, lo que te habría hecho bastante impopular entre lo que quedara de tu unidad.
Revista del ejército EE.UU. PS, agosto 1993.

Emulador JSpeccy
ZXBaremulator

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: Espiando transfers

Mensaje por mcleod_ideafix » Dom Feb 05, 2017 4:39 pm

zup escribió:Gestión de interrupciones: El menos respetuoso es el Pokeador. Si I=63, pone el modo IM1 y si es cualquier otro valor el modo IM2. Esto podría llevar a algunas incompatiblidades. Transtape guarda IM y el estado de las interrupciones en un byte, y tiene una rutina para descifrarlo (solo preserva IM1/IM2), mientras que Phoenix/Dynamid 3 meten el IM y la habilitación como instrucciones en la dirección 16640 (más compacto y menos corrupción en pantalla). Phoenix/Dynamid pueden preservar algo tan raro como IM0, pero dudo mucho que el hardware original lo haga.
El Z80 no tiene ninguna instrucción que te permita saber en qué modo de interrupción estás, por lo que estos interfaces sólo pueden "adivinar", y una heurística muy común era mirar el valor del registro I como hace el Pokeador. Una heurística más elaborada podría mirar si el bloque de memoria apuntado por I*256 es un bloque con 257 valores iguales. Eso haría prácticamente seguro el que la máquina estuviera en modo IM 2. De hecho, la única forma de saber a ciencia cierta en qué modo estamos es que un hardware externo "espie" los ciclos de búsqueda de instrucción y determine cuál fue la última instrucción IM que se ejecutó.

CORRIJO: repasando la ROM del Phoenix, veo que sí que hay una forma de, al menos, distinguir entre IM 1 e IM 2 de forma fiable. La idea es la siguiente y se basa en que en las direcciones de ROM hay código nuestro, y no de Sinclair (el firmware del transfer, obviamente):
- En la dirección 0038h se pone una pequeña rutina de interrupción que activa un flag para indicar que estamos en IM 0/IM 1. Por otra parte, en otro lado en la ROM se pone otra pequeña rutina de interrupción para activar otro flag que indique que estamos en IM 2.
- Después de haber salvaguardado el registro I, se le da el valor correspondiente para que apunte a la rutina que activa el flag de IM 2.
- Se habilitan las interrupciones y se espera un tiempo prudencial (un HALT, vamos)
- Tras esto, se vuelven a deshabilitar las interrupciones y se mira cuál de los flags es el que ha saltado. Si estábamos en IM 1, el valor que hubiera en I no afecta para nada a la rutina de interrupción, que siempre está en 0038h. Si estábamos en IM 2, se saltará a la otra rutina de interrupción de acuerdo con el valor de I que hubiéramos puesto.

Este es el cacho de código que hace esta "magia":

Código: Seleccionar todo

		xor	a
		ld	i, a		; Ponemos el vector I a	0, con lo que la direccion de
					; la supuesta rutina de	interrupción IM	2 estará en la
					; palabra de 16	bits apuntada por 00FF,	que es 003C.
		ei
		halt			; Habilitamos interrupciones y esperamos a que se produzca una.
		di
		ld	(4101h), de	; Según	estuviéramos en	IM 1 o IM 2, se	ejecutará la rutina
					; en 0038 o en 003C, y el valor	de E será distinto en cada caso.
					; Recordemos que D contenía el código de operación DI o	EI según
					; estuvieran deshabilitadas las	interrupciones enmascarables al
					; interrumpir el programa, o no.
zup escribió:Borde: Me ha parecido curioso que el único transfer que guarda el borde explícitamente (y probablemente podría guardar todo el estado del puerto 254) es el Transtape. Ninguno de los demás incluye instrucciones para restaurar el borde, lo que me lleva a pensar que confían en que el valor de BORDCR sea el correcto.
Con el color del borde pasa lo mismo que con las interrupciones: que no hay puerto de lectura para saber qué color de borde estamos usando, así que en ausencia de ayuda hardware externa, lo único que puedes suponer es, o bien que el color del borde es 0 (por aquello de que es el valor más común en un juego), o bien coger aquello que indique la variable del sistema BORDCR, con la esperanza de que estés en BASIC en el momento de dar al botón o algo. Como de todas formas, en el momento en que el programa haga uso del altavoz interno, ese valor se va a cambiar, el tiempo en que se queda el borde a un color erroneo suele ser muy poquito. Como en el caso anterior, se puede añadir hardware al transfer para que espie los ciclos de bus de I/O y se quede con una copia del último valor enviado al puerto $FE. Así sí se tendría un valor 100% fiable del borde.

Sobre el Abaco Phoenix publiqué alguna cosilla por aquí hace tiempo...
http://foro.speccy.org/viewtopic.php?f=8&t=937&p=11912
Web: ZX Projects | Twitter: @zxprojects

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Espiando transfers

Mensaje por zup » Dom Feb 05, 2017 5:32 pm

No he estudiado las ROMs de los interfaces, lo que he hecho es pillar muestras de juegos grabados con esos transfers y mirar las rutinas que cargan y arrancan los snapshots.

En el caso de Phoenix/Dinamid 3, el hecho de que puedan almacenar cosas tan raras como IM0 (dudosa utilidad en juegos) no significa que realmente tengan la capacidad de hacerlo. Pero si pillas un snapshot de algo en IM0, su "formato" de cinta sí que tendría opción para cargarlo (Transtape y el Pokeador no pueden).

En el caso de Transtape, el byte que guarda el color del borde (o el estado de 0xFE) podría ser una copia de los valores de BORDCR o quizás el Transtape guarda realmente el valor de 0xFE. Habría que mirar el esquema electrónico (o desensamblar la ROM) para saberlo.
mcleod_ideafix escribió:Como en el caso anterior, se puede añadir hardware al transfer para que espie los ciclos de bus de I/O y se quede con una copia del último valor enviado al puerto $FE. Así sí se tendría un valor 100% fiable del borde.
Por lo que he leído, estás definiendo el funcionamiento de los Multiface de Amstrad CPC. En el artículo que hay en la CPCWiki dicen que el Multiface 2 espía los valores enviados al ASIC, CRTC y a AY para poder restaurarlos luego. Me pregunto si el Multiface 128 y el Multiface 3 hacen lo mismo (para preservar paginación y sonido) o determinan la paginación heurísticamente y pasan olímpicamente del sonido.

P.D.: He añadido algo más al primer post. Ya he encontrado un par de muestras del Specmate 1 y es "curioso". Por una parte pasa a ser el mejor parado en cuanto a corrupción de pantalla, por otra parte utiliza demasiado la pila. Por otra parte, voy a hacer algún experimento con la máquina alucinante a ver qué diferencias hay en las rutinas con respecto a la parejita Phoenix/Dinamid 3.

Por otra parte, le he echado un ojo a la máquina alucinante. Para poder hacer migas, he creado mi propia rom de "la máquina menos alucinante" ya que ZX Spin no graba nada a tzx a menos que se use la rutina en 1218. Efectivamente, tenemos otro caso para la familia numerosa... la rutina de arranque es idéntica a la de Phoenix y Dinamid 3. El bloque de longitud variable también guarda su longitud en la misma dirección que los bloques variables de Phoenix y Dinamid. A ver si luego la documento también...
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Espiando transfers

Mensaje por zup » Lun Feb 06, 2017 10:00 am

Después de examinar las rutinas de carga de los transfer, he recopilado esta hoja de cálculo. Ahí se indican varias cosas:

- Dónde guarda cada transfer los registros.
- Qué bloques carga cada transfer desde cinta, junto con sus características.
- Comentarios de todo lo que me he encontrado por ahí.

Si tengo algo de tiempo, voy a intentar hacer un programa que convierta snapshots de 48k a taps (o dsk) usando los formatos de los transfer (insisto: para qué inventar algo si ya lo tienen inventado). Si no he metido la pata al calcular las direcciones en la hora de cálculo, debería ir rodado...
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

zx81
Freddy Hardest
Mensajes: 619
Registrado: Vie Dic 28, 2007 2:14 pm
Ubicación: Valencia
Contactar:

Re: Espiando transfers

Mensaje por zx81 » Lun Feb 06, 2017 8:18 pm

Los Multiface 128/+3 espían el bus para saber qué valores se envían a los puertos de paginación, probablemente el color del borde y alguna cosa más, para evitar "que le descubran". Es pero que muy cuco en ese aspecto.

De hecho, solo hay una combinación que el MF3 no cubre y es cuando se ha configurado la memoria en modo All-RAM. Es un modo pensado para ejecutar CP/M, pero los de Opera Soft lo usaron con el fin de que no funcionaran los transfers con sus versiones de 128k (Livingstone Supongo II, por ejemplo), ya que no hay ROM que sustituir en ese momento.
Debido al fallo de un mecanismo, el lanzagranadas M203 se te podía disparar cuando menos lo esperaras, lo que te habría hecho bastante impopular entre lo que quedara de tu unidad.
Revista del ejército EE.UU. PS, agosto 1993.

Emulador JSpeccy
ZXBaremulator

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Espiando transfers

Mensaje por zup » Vie Feb 10, 2017 12:39 pm

Edito el primer post para añadir algunas cosillas que he visto por ahí.

Resumiendo:
- He puesto el enlace a mi hoja de cálculo en el primer post.
- Corregido algunos errores por ahí.
- Ampliado la información del specmate y sus tres modos de grabación.
- Añadidos los formatos del otro programa para el Pokeador automático y el conversor disciple a cinta.
- Añadida información sobre "La máquina alucinante".

Algunas curiosidades encontradas por el camino...
- Aunque se puede cargar la ROM de "La máquina alucinante" en cualquier emulador, algunos (ZX Spin) no son capaces de grabar snapshots con él. Hay que modificarla un poquito para que use las rutinas de la ROM y entonces se puedan grabar snapshots (pero ya pierdes la capacidad de grabar con turbo). La modificación más fácil es poner un jp 1218 en la dirección 15124 y un jp 1366 en la dirección 15429. Esto hace que, independientemente de la velocidad de carga seleccionada, se utilicen siempre las rutinas de la ROM (por otra parte, la velocidad 1 es idéntica a la de la ROM).
- El programa de Transfer para 128k del Pokeador Automático muestra un modo interesante para determinar la paginación de un 128k en el momento de activarse. Lo que ya no hace es determinar/guardar el estado del AY. Quizás con esta información se podría hacer una ROM de 128k que pueda hacer snapshots (tomando como base la de "La máquina alucinante").
- Real Spectrum puede emular specmate si tienes su ROM (specmate.rom)... que no está disponible por ninguna parte. Supongo que este es el más fácil de emular, ya que solo pagina ROM sobre ROM (no tiene RAM). Aparte de eso y los Multifaces, no hay emulador que emule Transtape, Phoenix, Dinamid ni el Pokeador automático.
- He buscado algo en la base de datos de WOS y la única utilidad que copia snapshots de disciple a cinta es la de MicroHobby (salvo que haya algo enterrado en los discos de Outlet, que esos tíos tenían de todo).
- Pasadisk (el programa de la MH195 que transfería snapshots de cinta a disco), soporta dos de los tres formatos de grabación de Specmate. El formato de dos pantallas es el que ellos llaman "Specmate 1", mientras que el de una sola pantalla es el que llaman "Specmate 2".
- Ese mismo programa también puede convertir snapshots del Pokeador automático... pero solo soporta la primera versión (y además la versión bugeada). Los snapshots generados por el Transpoke no están soportados.
Última edición por zup el Vie Abr 27, 2018 8:09 pm, editado 1 vez en total.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

K.O.D.
Jack The Nipper
Mensajes: 115
Registrado: Mar Sep 30, 2008 8:45 am
Ubicación: Valencia

Re: Espiando transfers

Mensaje por K.O.D. » Mié Mar 01, 2017 9:19 am

Como comentario: hasta donde sé, sí, fue el Multiface 3 (para +3) el que introdujo el tema de la protección antipiratería. El único programa que conozco que desprotege el snapshot creado por el M3 para que funcione sin el interface es el M3 Unlock (http://www.worldofspectrum.org/infoseek ... id=0023824), que lo he usado y funciona bien, aunque es posible que existan más programas de estas características.

Un saludo.

Responder

¿Quién está conectado?

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