Spectrofon #15: Sistema: Discusión sobre comandos no documentados de Z80

┌──────────────────────────────┐
│ ─────── SISTEMA ──────── │
└──────────────────────────────┘

Continuando el tema de los comandos no documentados del procesador, planteado en uno de los números anteriores de nuestra revista, hoy publicamos la respuesta de Stanislav Efimov a la carta de Sim Oleg, en la que se continúa la discusión sobre este tema. La redacción de la revista está dispuesta a escuchar otras opiniones al respecto.

Stanislav V. Efimov (Fanatic Stas)
E-Mail 2:5020/525.29@FIDOnetg

¿QUIÉN MATO A QUIÉN "EN MANADA" O APRENDAN A LEER TÍTULOS, ASÍ COMO EPÍLOGOS!

A principios de mayo, la redacción de "Spectrofon" recibió una carta de un lector, parte de la cual fue una respuesta a un artículo publicado en "S"N11 en la sección "Sistema". Leí esta carta con interés. Algunas posiciones de esta carta me causaron cierta (si no decir más) confusión, y quise comentar sobre algunas cosas. Espero que a los lectores de "Spectrofon" les interese...

Comenzaré con el P.P.S de Oleg:

Sim O.R: "P.P.S: Si le interesa, me gustaría continuar el tema de los comandos no documentados y he preparado el material que se ofrece a continuación. Si no le interesa, no mire."

FS: "¡Nada de eso, es interesante!"

Oleg (O):
1995 Sim O.R. y SERGE,
Volgogrado.

El motivo para preparar este material fue la aparición prácticamente simultánea del artículo de Fanatic Stas en la revista 'Spectrofon' y el programa informático del programador de Volgogrado SERGE titulado 'Top Secret'. Ambos están dedicados a los comandos no documentados del Z-80. El primero está lleno de vacíos evidentes, el segundo es muy interesante, pero contiene una serie de imprecisiones. Se presenta una situación interesante, donde muchas personas conocen estos comandos, los utilizan activamente, pero no se apresuran a compartir secretos. Esto es bastante comprensible: el uso de comandos no documentados es más efectivo en programas de codificación (¿dejan un 'rincón oscuro' para protegerse?). Pero aún así ha llegado el momento de disipar un poco la niebla. Mi objetivo era sistematizar la información dispersa sobre este tema y de ninguna manera pretendo los laureles de descubridor.

FS: Sobre los 'vacíos evidentes': lea atentamente el epílogo de ese material... Y en general: es mejor no decir algo si no está completamente seguro, que ofrecer un material 'crudo' que puede inducir a error o llevar en otra dirección (esto lo digo sobre el artículo dedicado a TRDOS, en uno de los primeros números de "S"). No estoy de acuerdo con el 'rincón oscuro': todo lo que he visto de las protecciones programáticas (aunque también basadas en registros VG93 - en el sentido de disco) hasta el momento, me permite concluir que no es necesario conocer los comandos no documentados en absoluto. ¡Estos comandos no pueden dificultar mucho el acceso al código protegido, solo es importante saber DÓNDE 'excavar' y CÓMO! CUALQUIER protección tiene un punto débil, ahí es donde hay que excavar (y no golpear de frente).

En general, el grado de fiabilidad de la protección en su conjunto se determina por el grado de protección de su eslabón más débil (he citado a alguien, pero no recuerdo a quién). Es muy importante que los programadores que implementan tales protecciones lo sepan, aunque en "Spectrum" parece que no se podrá implementar tal protección. Solo se puede dificultar al máximo el camino del hacker... Lo que se ha hecho en el más reciente lanzamiento de Step - Herencia Estelar... No continuaré con este tema, ya que respeto a los Autores de los Programas y no quiero fomentar a los 'hackers' principiantes (no uso el término hacker en este caso, ya que todo lo que sucede ahora en Spectrum se refiere exclusivamente al término Software Piracy).

O: Comencemos por no considerar las operaciones sobre mitades de registros de índice que ya han cansado a todos. Hace tiempo que se han convertido en patrimonio de la amplia comunidad. También parece que se ha aclarado el comando SLI y se han llenado ocho celdas vacías en la tabla de prefijos CB. Por lo tanto, tiene sentido pasar directamente a los comandos, cuyas descripciones aún no se han publicado en ningún lugar (excepto, parcialmente, en el programa 'Top Secret').

COMANDOS DUPLICADOS.

Primero que nada, los comandos duplicados son esos comandos astutos que se presentan no con uno, sino con dos o más códigos de operación (COP).

Estos comandos son de conocimiento público y no requieren descripción, basta con mirar la tabla. El comando NEG, por ejemplo, puede establecerse con ocho COP diferentes, pero los monitores depuradores 'solo entienden' uno: ED44. A pesar de esto, los ocho hacen lo mismo, invierten el acumulador. Preste atención a un par de comandos que ni siquiera tienen un código mnemotécnico adecuado y la acción de estos comandos se explica en una nota al pie...

FS: Aquí interrumpiré la exposición de Oleg y presentaré mi análogo de la gran tabla que dibujó el autor. Es difícil incluirla en este texto, hay mucho espacio vacío, además, el ancho de la línea de 32 caracteres limitó mucho mi imaginación...

Espero que mi lectura de esta tabla sea correcta, y los posibles errores serán 'responsabilidad' del autor. También 'eliminé' de ella todos los comandos que ya han cansado, como EDB0 (LDIR). Así que, los comandos no documentados (todos los valores - hexadecimales). Primero ED, luego:

54, 64, 74, 4C, 5C, 6C, 7C - NEG;
55, 65, 75 - RETN;
5D, 6D, 7D - RETI;
66, 4E, 6E - IM 0;
76 - IM 1;
7E - IM 2;
70 - análogo {IN A,(C); OR A} por resultado OR se establecen los flags S, Z, P;
71 - análogo {LD A,0; OUT (C),A} el registro A se guarda. El tiempo de ejecución de los dos últimos comandos - 12 ciclos.

COMANDOS DE DOS PREFIJOS.

El grupo de comandos más amplio. En general, los comandos de este grupo se presentan en la forma:
1 byte - prefijo DD o FD
2 byte - prefijo CB
3 byte - desplazamiento
4 byte - código del comando

Estos comandos funcionan de manera muy interesante. Por ejemplo, tal secuencia de bytes: ddcb0100 tendrá la forma RLC B,(IX+1). Primero, la acción (RLC, en este caso) se realiza sobre la celda (IX+1), y luego el resultado se copia en el registro correspondiente. Los comandos que antes trabajaban con (HL) no sobrecargan el resultado en ningún lugar.

Los comandos de la serie BIT solo prueban los bits en la dirección (IX+n) y establecen los flags en F. Por lo tanto, se duplican ocho veces, ya que independientemente del registro sobre el que se realizó el comando antes, aquí se sustituye (IX+n). Especialmente 'tuvo suerte' el comando SLI. No solo es un comando no documentado, sino que también puede ejecutarse de manera 'ilegal'.

La declaración de Fanatic Stas de que los comandos presentados se pueden utilizar con una utilidad no mayor que NOP, me dejó sin palabras. ¡Resulta un NOP interesante si altera activamente el contenido de la memoria y los registros!

FS: Puedo repetir una vez más la frase sobre 'utilidad', sin embargo, en el contexto del artículo anterior. Espero que no lo mate de un golpe, si digo que no es necesario para mí conocer los comandos duplicados. ¿Para qué necesito, como programador, saber que existe un número determinado de NEG o IM2? Dos comandos, para los cuales no hay mnemotécnica, ni siquiera sé dónde 'encajar' en mis programas, y estoy seguro de que pocos podrán encontrarles aplicación.

Y en cuanto a RLC y similares, puedo decir que estos comandos son bien conocidos por mí y no son en esencia no documentados.

Para 'descubrirlos' solo es necesario dar un paso desde LD IX,nn, es decir, desde los comandos más simples con prefijos (¿resulta que LD IX también está no documentado?).

O: Tome, por ejemplo, los programas de C. Hantsis 'Screen Manager', 'Super List', etc., y para su desarrollo general, descodifíquelos. Si lo logra, se le presentará un ejemplo vivo de un codificador que cumple perfectamente su propósito, utilizando precisamente el llamado 'NOP'.

FS: Ya he escrito que en el artículo anterior, como espero en todos los siguientes, me baso en los programadores, y no en los hackers.

En mi opinión, la mayoría (léase - todos) de aquellos que han puesto una mano en el ensamblador, escriben tales codificadores exclusivamente para sí mismos, para su propia autoafirmación, ya que ninguna de estas personas (codificadores) soportará un ataque serio de pensamiento. Yo, desde hace tiempo, 'en términos públicos' no me ocupo, ni de la implementación, ni de la eliminación (me arrepiento - no me pateen) de diversas protecciones...

O: Sin embargo, ¿qué más se puede esperar de un hacker que no sabe cambiar páginas correctamente en modo 128k?

FS: Finalmente... 'Me atacaron'... ¿Y en qué te he ofendido tanto? ¡Poco has visto de mis programas, Oleg, lamentablemente, si haces tal conclusión! ¿Compraste Spectrum hace un par de años? En cuanto al cambio de páginas en dos (Stifflip, Deactivators) programas, contaré más adelante, si hay solicitudes, pero, de verdad, es una historia muy instructiva, relacionada con la verificación de algunas de mis sospechas sobre la honestidad de ciertas personas... Solo diré que dos semanas después de la aparición de los programas 'ilegales' se lanzaron sus versiones 'correctas'... No tuve suerte de que "Spectrofon" a Deactivators, como a mí, le gustó tanto. ¡No emitan un veredicto de manera anticipada, señores!

O: Una concepción interesante, la aplicación de dos prefijos nos da dos tablas completas de codificación, es decir, 510 COP (¿por qué 510 y no 512? No lo entendí... - FS), que no están bien descritas en ningún lugar. Junto con los comandos duplicados, los comandos que trabajan con mitades de registros y los comandos SLI, los comandos no documentados en número se acercan al conjunto básico de comandos.

Además, lo más probable es que esto no sea el límite, mire la tabla ED, hay tantos 'puntos blancos' que es bastante probable la aparición de nuevos y nuevos comandos. ¿Quién conoce al final al viejo Z80? En la actualidad, los bits no documentados del registro de flags deben representar un interés especial. Hasta donde sé, nadie ha realizado investigaciones fundamentales en esta área. El hecho es que algunos comandos bajo ciertas condiciones cambian estos flags. ¿Quizás alguien se pronuncie al respecto?

FS: A mí también me gustaría que alguien 'excavara' en Z80, pero lamentablemente, Oleg, tu carta es la única con material que genera interés. Sin embargo, hay muchas más respuestas, ¡eso es alentador! Ya he tocado el tema de los flags en el artículo anterior, aunque, parece, solo un poco.

Es una pena que Oleg no haya citado las fuentes de su conocimiento, ya que su material, espero, no está completamente 'copiado' del programa 'Top Secret', que no he visto. Me gustaría conocer las fuentes de donde provino tal información, así como en 'Top Secret'. Estoy seguro de que tales fuentes existieron, ya que adivinar cuánto tiempo se ejecutan ED70 y ED71, me parece imposible. IM0 e IM1 también son difíciles de diferenciar. La situación es similar en el caso de RETN, RETI, aunque aquí, aún con dificultad, podré diferenciarlos...

"S": Invitamos a todos los interesados en este problema a expresarse en las páginas de nuestra revista. Esperamos que con esfuerzos conjuntos lleguemos a la verdad.

¡ESPERAMOS CARTAS!

* * *

Contenido de la publicación: Spectrofon #15

  • Pericia - Matthias
    Una novela informática basada en el juego 'CAPTAIN BLOOD' que explora su trama, jugabilidad y desafíos para encontrar una versión funcional del juego.
  • Debut - Дмитрий Усманов
    Descripción del juego Sidewalk donde el jugador ayuda a Daniel a recuperar su ciclomotor y conseguir entradas para un concierto en tiempo limitado, interactuando con personajes de la ciudad y superando obstáculos.
  • De Todo un Bit - Chung Software
    Discusión sobre los desafíos y posibles mejoras para la computadora PROFI, incluidos los problemas de compatibilidad con otros sistemas y el desarrollo de software. Crítica a la empresa 'KONDOR' y su relación con los usuarios y la comunidad Spectrum. Exploración de los roles de diferentes software y hardware en la mejora de la utilidad de PROFI.
  • Del mundo un bit a la vez
    El artículo discute el debate en curso sobre las prácticas de la comunidad hacker en modificaciones de juegos, criticando específicamente su influencia en los juegos originales. Destaca un conflicto entre el diario electrónico 'Spectrofon' y los hackers sobre el contenido y propósito de las intros incluidas en los juegos modificados. El texto sirve como una refutación a las críticas anteriores del diario, enfatizando la necesidad de una perspectiva más equilibrada sobre el hacking en la comunidad de videojuegos.
  • Campeonato
    El artículo detalla los cambios en el formato del Campeonato de Virus, que ahora presenta etapas de grupos en lugar de un torneo round-robin debido a problemas con el juego 'VIRUS' y la introducción de 'VIRUS-2'. El artículo proporciona resultados de los partidos de grupo, destacando el rendimiento de varios virus y enumerando a los cuartofinalistas. También se incluyen comentarios y emparejamientos de los cuartos de final.
  • Sistema
    El artículo discute comandos no documentados del procesador Z80, destacando sus aplicaciones y discrepancias en los recursos existentes. Los autores Fanatic Stas y Sim O.R comparten ideas sobre la importancia y utilidad de estos comandos. Se anima a los lectores a contribuir con sus opiniones sobre este tema complejo.
  • Saludos Calientes
    El artículo trata sobre el problemático lanzamiento de 'Frontier: First Encounters', también conocido como Elite 3, detallando numerosos errores y un escándalo en torno a su lanzamiento, que decepcionó a los fans de larga data.
  • Premiere
    El artículo presenta varios programas de software nacionales, incluidos un verificador de autenticidad de códigos de barras, un calendario astronómico, una herramienta de cálculo de masa de cohetes y varios juegos, destacando sus características y usos.
  • Publicidad para la revista SPECTROFON
    El artículo proporciona información publicitaria sobre cómo comprar la revista electrónica SPECTROFON, así como los productos de software del grupo creativo STEP. Incluye procedimientos de pedido, direcciones de contacto y detalles de precios para juegos y números de revista. El texto sirve como guía para posibles clientes y distribuidores de software para ZX Spectrum.