En esta sección queremos hablarles sobre las "reglas de buena educación" en la programación. Desafortunadamente, en las páginas de "ZX-Revue" y "SPECTROFON" se han acumulado suficientes declaraciones y creaciones de programadores desafortunados que creen que es suficiente aprender ensamblador para poder escribir programas maravillosos. Si todo fuera tan simple, ¿por qué existen universidades que enseñan el "noble" oficio de los programadores, y por qué los estudiantes son "molestados" allí durante cinco (a veces cinco años y medio) años?
La razón es muy sencilla: un programador debe saber muchas cosas que, a primera vista, no están relacionadas con la programación, pero que en realidad son necesarias. A pesar de esto, la "oferta" ("SPECTROFON", "INFORCOM") dio "luz verde" a programas autorales, olvidando esto (o quizás simplemente no lo sabía). Y así comenzó a aparecer una "montaña" de programas autorales de consumo masivo, útiles solo para que sus autores mostraran sus creaciones a mujeres desprevenidas y dijeran: "Mira qué inteligente soy, he escrito este programa, vamos a cenar juntos esta noche". Así que decidimos hacer algo al respecto.
Esta sección no está destinada a profesionales, es para todos aquellos para quienes "SPECTRUM" es un poco más que solo una máquina de juegos. Intentaremos no "cargar" con términos profesionales, ni con "extrañas" técnicas de programación, sino contarles cómo se deben (y cómo no se deben) hacer programas para "SPECTRUM" (ya sea un juego "para la venta" o un simple programa para "uso doméstico"). Por cierto, también haremos un recorrido por la historia de las computadoras, lo cual es una actividad bastante interesante. En los próximos números planeamos contarles sobre la historia y las razones de la aparición de las computadoras, la cibernética, los virus informáticos, etc. (por supuesto, no en forma de aburridas conferencias con frases como: "de esta manera", "como resultado de esto"...). Todas estas son historias bastante interesantes, a veces recordando novelas de ciencia ficción (pero todo esto es nuestra historia, es decir, la realidad) y detectives. Así que, como se dice en un excelente dibujo animado soviético: "¡comprad nuestros elefantes!".
Comencemos, como siempre, con los términos. Personalmente, la frase "he escrito un programa en códigos de máquina" nos provoca alternativamente dos tipos de emociones: risa histérica y una gran compasión por quien lo dice. Risa por la imagen que se forma ante nuestros ojos. Compasión porque el protagonista de esta imagen terminará en un hospital psiquiátrico en la próxima semana. En las clases de informática, si las asistieron, lo primero que se "martilla" a todos es sobre las generaciones de computadoras, ¿no es así? Bueno, así que. Las primeras computadoras no tenían ni el teclado que conocemos, ni mucho menos pantallas. ¿Y cómo se programaban? En esos mismos CÓDIGOS DE MÁQUINA. El operador de la computadora (de ahí proviene esta especialidad) para liberar al programador para tareas más complejas, se encargaba de introducir el programa. ¿Y adivinen cómo lo hacía? Correcto. Con ocho interruptores introducía el siguiente byte (interruptor hacia arriba - bit establecido, interruptor hacia abajo - bit reiniciado), después presionaba el botón para introducir el byte en la memoria, y luego hacía lo mismo con el siguiente byte. ¿Y qué hacía el programador mientras tanto? Él escribía el programa en forma de esos mismos bytes (a menudo en forma BINARIA (!!!)) - un programa en LENGUAJE DE MÁQUINA. ¿Sienten la romanticismo? ¡Y cuánto tiempo se necesitaba para componer un programa y su entrada en la computadora! Por cierto, tales programas se escribían y depuraban durante meses, y tenían un tamaño... de solo unos pocos kilobytes. Luego a todos les aburría y se inventaron otras formas de introducir programas, y lo más importante, LENGUAS DE PROGRAMACIÓN. Ahora queda claro, ¿por qué un hospital psiquiátrico? Si no lo han adivinado, les diré: la carga mental de los programadores era tan alta que de vez en cuando "se les iba la cabeza". Sí, y otra cosa, las direcciones de ubicación del programa también se representaban en forma binaria, y el programador debía operar con ellas. Y una línea de programa en lenguaje de máquina se veía aproximadamente así: 0001000101 111010101, donde el primer número binario es la dirección del comando, y el segundo es el propio comando.
Si quieren dedicarse a la pintura, al menos echen un vistazo a las obras clásicas. Y si están programando, es una vergüenza si a medianoche no pueden decir nada sobre la historia de las computadoras, que por cierto tiene solo cincuenta años, y que sus abuelos ni siquiera sabían qué era una computadora y que, en general, un trozo de metal podía calcular, y mucho más rápido y preciso que una persona, además sin la participación de esta.
El primer LENGUAJE DE PROGRAMACIÓN fue... el lenguaje ENSAMBLADOR. Era (y es) un lenguaje de bajo nivel - se encuentra justo en medio entre el lenguaje de máquina (un conjunto de diferentes CÓDIGOS BINARIOS (!!)) y el lenguaje humano. Cada comando de Ensamblador corresponde de manera única a un comando de lenguaje de máquina, y viceversa. La diferencia entre ellos es la misma que entre el número "3" y la palabra "tres": significan lo mismo, pero uno es parte del sistema numérico árabe, y el otro es parte del idioma ruso!!!!! Los siguientes dos programas son lo mismo, pero escritos en diferentes lenguajes (los códigos de máquina, que en teoría se representan en binario, los traduciremos a código hexadecimal para no abarrotar la pantalla):
Ensamblador: Códigos de máquina:
LOOP LD A,1 #3E,1
CALL #3D13 #CD,#13,#3D
JR Z,LOOP #28,#F9
OR A #B7
JR NZ,LOOP #20,#F6
RET #C9
Adivinen cuál es más fácil de entender. ¿Y cuál es más fácil de modificar? Pista: si quieren insertar un comando después de la línea "LD A,1", en los códigos de máquina tendrán que recalcular manualmente (!!) los desplazamientos para los saltos condicionales cortos (bytes #F9 y #F6), es decir, recalcular la dirección, y eso es solo en un programa tan pequeño y simple (fue "tomado del aire" y, por supuesto, no funciona)!
Así que, hablemos correctamente y con precisión: "he escrito un programa en Ensamblador". De lo contrario, terminarán en... (en la misma sala).
Sigamos adelante. La red de dígitos.
¿Y qué es esto? Esto, señores, es lo que afecta la precisión de los cálculos matemáticos en cualquier tipo de computadora. Esto lo digo porque si han decidido hacer un programa que realice cálculos precisos, es útil saber sobre las "trampas" y aceptar de antemano la imprecisión en los cálculos (lo que no los exime de la necesidad de calcular esta imprecisión y comunicarla a los usuarios).
Supongamos que han decidido hacer un programa que calcule el estado del sistema solar en un momento dado, o un juego - simulador de vuelo de la nave espacial "según fórmulas" (la simulación no es como en ELITE, sino teniendo en cuenta las leyes reales de la mecánica celeste: por cierto, llevo aproximadamente un año "poco a poco" trabajando en "modelar" un simulador similar), o simplemente hacer cálculos ingenieriles terrenales. Para el ejemplo, tomemos un programa astronómico. En su camino hay varios icebergs bastante grandes.
Primero. La máxima precisión del "SPECTRUM" es de siete cifras después del punto decimal, y eso es bastante poco para cálculos serios. La astronomía opera con números muy grandes, una imprecisión del 1% de una unidad astronómica equivale a unos 1 millón 495 mil kilómetros. Poco, ¿no? Y lo más desagradable de cualquier imprecisión es que siempre aumenta, y lo hace a una velocidad creciente. Donde había un 0.01 por ciento, muy pronto habrá un 0.1 por ciento. Así que los desarrolladores de sistemas de procesamiento de información precisa recurren a trucos especiales (no los tocaremos ahora), cuya implementación en nuestro querido "SPECTRUM" no es tan fácil (y aun si se aplican, el cálculo puede llevar bastante tiempo). Así que no olviden sobre la red de dígitos.
Si han intentado escribir un programa inspirado en "Lunonautas" para calculadoras programables (vean las revistas "Técnica-Jóvenes" desde el número 8 de 1985), en BASIC para "SPECTRUM" (y yo intenté hacerlo antes y planeo hacerlo nuevamente, pero con nuevos conocimientos), entonces probablemente conozcan un "bug": sin trucos especiales NO SE PUEDE calcular correctamente la proyección de un vector en un eje coordenado (por ejemplo, usando la expresión SIN ()*), ya que las funciones trigonométricas dan una imprecisión notable, que, multiplicándose por un valor considerable del vector, da una imprecisión completamente astronómica.
En segundo lugar. Para calcular la posición de un cuerpo celeste en un momento dado, se deben conocer los parámetros de su órbita y su posición en ella en un momento inicial. Y cuanto más tiempo haya pasado desde el momento inicial, mayor será la imprecisión (lean sobre esto unas líneas más arriba). Y, cuanto más lejos esté la órbita del Sol, más... nuevamente mayor será la imprecisión.
"¿Cómo es eso, cómo es eso - dirá alguno - hemos oído hablar, pero qué dirán sobre el artículo de S.Krushinskiy (Moscú) en "ZX-Revue" No 9,10 de 1993 "SPECCY + ASTROLOGÍA"? Eso es en tercer lugar. El autor mismo dice: "en astrología no se requiere gran precisión, una imprecisión de ±10 minutos nos conviene". Sin embargo, el autor olvidó mencionar que esos 10 minutos, incluso para Marte, se traducen en 663 mil kilómetros, lo que equivale a aproximadamente 100 (!!) diámetros de Marte. Bueno, y en lo que respecta a la astrología, aquí todo está claro desde hace tiempo: "V-e-n-u-s en c-o-n-j-u-n-c-i-ó-n con Acuarios. U-s espera una reunión con amigos cercanos. P-u-e-d-e haber algunas sorpresas."
En cuarto lugar. El número "pi" es solo adecuado para cálculos aproximados. Si no les importa, es mejor que guarden este número en una variable y lo usen como constante. Y deben guardar el siguiente número: 3.141592653.
Y, en quinto lugar. Si han decidido hacer un programa serio, y no solo una demostración de sus habilidades y preferencias, entonces "revienten" una montaña de literatura y encuentren TODOS los factores que afectan el cálculo. Por supuesto, nadie usará su programa para calcular un "vuelo real" a Marte o la nave espacial del tercer milenio, pero aun así...
Así que, al planear escribir cualquier programa que realice cálculos precisos, por favor, prevean la corrección de al menos algunos errores, y adviertan honestamente a los usuarios sobre la magnitud de la "imprecisión no corregida" en los cálculos. Porque alguien podría usar sus programas para obtener datos que indiquen que la Luna caerá a la Tierra en 2050, ¡y creer en ello! ¿Se imaginan lo que sucederá?
Y por último. Por el amor de Alá, no cambien la página de la memoria 128 a través del puerto #FD. Es un gran "error", por el cual nadie los alabará. El comando "OUT (#FD),A" no les da ABSOLUTAMENTE ninguna ventaja en velocidad - el tiempo que el procesador gasta en extraer de la memoria el argumento del comando (el número del puerto, en este caso el byte #FD) es solo un (!) ciclo menos que el tiempo de ejecución del comando "OUT (C),r". Si la velocidad es tan importante para ustedes, entonces guarden el número #7FFD en un par de BC, y que se quede allí.
Ese comando toma un par de BC, dicen los fanáticos del puerto #FD. ¿De verdad? ¿Qué tipo de programador es este, si no puede diseñar su algoritmo de tal manera que "los lobos estén satisfechos y las ovejas estén a salvo" (y cumplir con esta condición es la tarea principal de CUALQUIER programador al crear CUALQUIER programa)? Después de todo, hay una pila, registros alternativos, ¡memoria, finalmente! Todo se explica fácilmente: alguien alguna vez "metió la pata" (posiblemente, simplemente no sabía sobre este bug), y cuando le dijeron amablemente: "Amigo, tus programas no funcionan en nuestras computadoras debido al puerto #FD: por favor, cambia estos y esos bytes (lista adjunta) en los programas existentes, y por favor, en los próximos desarrollos usa la dirección completa del puerto", simplemente se puso "como un rebaño de ovejas" (disculpen la comparación, pero es muy difícil contener las emociones). "Soy el autor, y tú eres un hacker, tus consejos no me importan, me importa un comino. Si no funciona, cambia tu computadora o deséchala". Después de lo cual, obstinadamente continúa su oscuro trabajo, inventando un montón de argumentos en su defensa. Y el villano, el hacker,... - el hacker bajo los gritos y escupitajos de "SPECTROFON" (le pido perdón, aún no he controlado mis emociones), alegremente frota sus manos, "hace estallar" la nueva creación de este "pobre" autor, agrega un funcionamiento normal con el puerto #7FFD (dándole así una nueva vida al programa), sin olvidar escribir su nombre en el INTRO (pantalla de presentación, información sobre los autores...), y luego, mirando furtivamente, la vende a su amigo revendedor "hackeado". Parece un argumento de un detective estadounidense. Y el criminal, como siempre, es el hacker - violador de derechos de autor y de la paz pública... ¿Y si no fuera por los hackers, cómo podría la humanidad progresista enterarse de los errores en uno u otro programa?
Por supuesto, también se puede entender la posición de los Autores, ¿quién quiere escuchar reproches de incompetencia de otros, haciendo públicos los datos sobre las causas de los fallos de los programas?
Pero, afortunadamente, nuestro Club ZX de Samara no comparte la manía de "SPECTROFON" de oprimir a todos los hackers y coloca a los buenos hackers (no moriremos de modestia, ¿verdad?) en la misma categoría que a los buenos autores, por lo que en nuestra ciudad siempre podrán encontrar la versión "normal" del programa que necesitan. Regularmente les contaremos sobre los programas que podrán comprar en las tiendas del Club ZX.
Y, ya que hemos tocado el tema de los hackers, "para concluir", unas líneas sobre las líneas en movimiento (un juego de palabras, pueden anotarlo), aunque esto se relaciona muy vagamente con nuestra sección. ¿Por qué "SPECTROFON" no ama las líneas en movimiento (por cierto, los distribuidores de software creen que una buena línea en movimiento solo aumenta la belleza del programa)? No, por supuesto, las líneas que son solo FUCK, huelen mucho a un profesional alcohólico consumado, pero ¿y las demás (donde hay saludos, pero todo según las reglas de la etiqueta)? Todo es muy simple: allí se contiene información sobre las deficiencias o hábitos arraigados de algunos Autores, que se difunden por todo el país y disminuyen la calificación de esos Autores. Así que eso es todo.
Bueno, por hoy es suficiente. Espero que me perdonen por el carácter algo confuso de nuestro primer encuentro. Hasta la próxima en el siguiente número. Escriban sobre qué les gustaría leer en "LIKBEZ", y cómo ven esta sección en general. Encontrarán las direcciones para comunicarse con nosotros en la sección "SOBRE TODO".
(C) E.Milun.
* * * * *
Contenido de la publicación: Oberon #01
- Introducción
Introducción al primer número de Oberon, una revista electrónica de Samara creada por el grupo STARS OF KELADAN, pensada como alternativa a SPECTROFON, centrándose en la profesionalidad en programación.
- Pergamino
Análisis de problemas de software en los juegos de ZX Spectrum presentados en 'SPECTROFON', específicamente 'SPACE CRUSADE' y 'REBEL STAR'. Discusión sobre los fallos de los programas, intentos de hackeo y falta de pruebas. Crítica a la gestión de la calidad del software de la revista 'SPECTROFON'.
- Pergamino
Descripción del ZX/IBM Editor v1.0 con análisis detallado de sus funciones, como la navegación por menús, operaciones de archivos y compresión de texto. Discute la compatibilidad con varias unidades de disco y la adaptación para máquinas de 128K. Proporciona información sobre limitaciones y actualizaciones realizadas en la versión 1.5D.
- Reseña
El artículo aborda el software disponible en ZX-Club, incluyendo reseñas detalladas de Animation 2.0, un paquete para crear comerciales simples, y el juego 'País de Mitos', un juego del género Dungeons & Dragons. Se destaca 'Insult Megademo' de Code Busters por su música y efectos de video, advirtiendo sobre problemas de compatibilidad para ciertos ordenadores. Se enfatiza la importancia de comprar solo software adecuadamente probado para evitar problemas.
- Reseña
Análisis del software distribuido por 'INFORCOM' resalta problemas en programas como STS, TASM128 y VIRUS, criticando sus fallos técnicos y afirmaciones de marketing. El artículo cuestiona la calidad y legalidad de estos programas, mientras ofrece soluciones alternativas. Refleja sobre los desafíos en el desarrollo y distribución de software para ZX Spectrum.
- Sobre Todo
Discusión sobre trucos y errores de programas ZX Spectrum, mencionando experiencias y comentarios de usuarios, con especial enfoque en juegos y desafíos técnicos.
- Programa Educativo - Paul Atrides
Discusión sobre la etiqueta en la programación y la necesidad de un conocimiento integral más allá de las habilidades de codificación, con ideas históricas sobre la informática.
- Hardware - Александр Королёв
El artículo trata sobre el puerto de atributos #FF en clones rusos de ZX Spectrum, sus peculiaridades y problemas potenciales con el esquema de Gromov. El autor ofrece una versión revisada del esquema, ofreciendo mejoras para una mejor compatibilidad. Esta nota técnica está dirigida a los entusiastas que desean mejorar sus sistemas.
