Equipos/grupos mencionados
M.M.A/SPEED CO.'97
El problema de ejecutar archivos desde el disco siempre ha interesado tanto a los usuarios comunes como a los programadores. Aparentemente, no hay problema alguno: encontré el archivo y lo ejecuté con el comando RUN "GLUK". ¡Pero no! Incluso este proceso aparentemente primitivo se pudo automatizar.
Un astuto programador de TECHNOLOGY RESEARCH implementó en TR-DOS una función gracias a la cual el comando LOAD o RUN (así como POKE y PEEK) sin operando ejecuta un archivo BASIC llamado "boot". Aparentemente, con esta acción quería expiar su culpa por la codificación excesivamente compleja del propio sistema de disco. Así comenzaron a surgir programas que de una forma u otra facilitaban la selección y ejecución de archivos del directorio.
A continuación, quiero exponer una serie de mis (y no solo mis) pensamientos sobre el desarrollo de la construcción de BOOT y algunas de sus tendencias modernas. Se recomienda especialmente la lectura a aquellos programadores principiantes que ya han superado las modificaciones de los cargadores ajenos y quieren intentar escribir algo peculiar: ¡boot'oso!
Para empezar, veamos lo que ya se ha hecho en esta área durante el tiempo que SPECTRUM ha existido en los vastos espacios de nuestro inabarcable ZX-USSR. Pero primero, es necesario trazar una clara línea entre un programa boot y un file-commander. Consideraremos que cualquier programa que permita ejecutar archivos desde el disco se llamará boot. Si en este programa hay alguna indicación de copia de información, entonces ya es un commander. El tema del file-commander ideal también es muy interesante, pero dejaremos su discusión para el próximo número de la revista. Y ahora: "¡Atrás - hacia el futuro!".
Así, la historia de la construcción de boot en Rusia comenzó con la aparición de las primeras muestras de BETA DISK INTERFACE. No he visto ningún boot occidental, y probablemente nadie más lo haya hecho. Y el único programa de marca diseñado para TR-DOS era DISK DOCTOR.
Tan pronto como los programadores nacionales despertaron de su letargo, comenzaron a aparecer las primeras obras sobre el tema de los boot. Los primeros programas de este tipo se escribieron siguiendo el siguiente principio: se recopilaba una colección de juegos, los nombres de los programas se incrustaban en una línea DATA en BASIC y luego, introduciendo el número del programa o seleccionándolo con un cursor que se movía de manera errática (también, por supuesto, desde BASIC), se podía finalmente ejecutar el archivo favorito. Este método era interesante también porque, a menudo, los programas en discos similares estaban protegidos de la siguiente manera. Todos los archivos BASIC y CODE se renombraban en una combinación alfanumérica. Luego, los archivos en el disco se mezclaban intensamente, y al usuario común le resultaba difícil entender qué archivo era qué juego y qué bloques de código necesitaba para funcionar. La salida del directorio estaba prohibida mediante la inclusión de caracteres no imprimibles en el nombre del disco.
Como pueden ver, el boot se convirtió no solo en un medio de automatización, sino en la única forma de alcanzar el objetivo en la lucha por ejecutar un archivo. Además, el usuario no podía utilizar dicho boot para sus propios fines, reescribiéndolo en otro disco, ya que todos los nombres de los archivos ejecutables se almacenaban originalmente en el boot.
Pero el tiempo pasó, y comenzaron a aparecer las primeras muestras de verdaderos programas boot. Su aparición se vio obstaculizada también por el hecho de que con los medios tradicionales de BASIC era imposible leer en memoria la pista cero, que contenía la información de los archivos. Dominando los fundamentos de TR-DOS, los primeros programadores trajeron al mundo los primeros verdaderos boot. La mayoría de ellos seguía consistiendo en un 80-90 por ciento de BASIC y varios procedimientos en código máquina para trabajar con el disco. Esta etapa de desarrollo se caracteriza por la aparición de uno de los principios fundamentales: la selección de archivos se realiza con el cursor, cuyo control requiere solo 5 teclas o un joystick.
El siguiente paso clave fue la escritura de 
programas boot completamente ensamblados. Uno de 
los boot más conocidos fue escrito en 1991. 
Su autor fue probablemente alguien llamado M.RUSALOV, 
y dado que este boot 
agradó mucho a nuestros hackers, solo los más perezosos de ellos no crearon su propia versión modificada. Cabe destacar que, con más de 20 archivos BASIC en el directorio, este programa no funcionaba y mostraba el mensaje "No more 20 files". Esta limitación puramente técnica se convirtió luego en la teoría de los boot de juegos (es decir, boot especiales para disquetes con juegos).
Una idea interesante fue propuesta en el boot de 
TOLLYSOFT'92, donde la selección 
de archivos se realiza 
en una ventana, muy 
parecida (de hecho, una copia) a la ventana de menú en máquinas con 
128kB de memoria. Además, 
este boot ocupaba solo 5 sectores. Así comenzó otra epopeya en la creación de boot: la minimización del tamaño del programa.
En 1992, Shi-Soft lanzó un boot bastante conveniente de dos sectores. De hecho, este programa estableció un récord que fue imposible superar. Y solo en 1995/96, nuestros hackers de Samara POLTERGEIST y MAXSOFT lograron implementar primero una versión algo primitiva y luego una completamente funcional de un boot de un solo sector.
La situación en el mercado de la construcción de boot estaba experimentando cierto estancamiento, hasta que apareció una verdadera creación épica: ZYX BOOT. Este programa prácticamente sentó las bases de la moderna concepción de BOOT-DEMO. ¡Aquí había todo lo que un usuario común podría soñar!
Como cualquier otro programa similar, ZYX-BOOT sufrió una cantidad inimaginable de hackeos, modificaciones y mutaciones. Recuerdo incluso un disco en el que estaban grabados alrededor de 60 tipos y subtipos diferentes de este boot con música y sprites variados.
Durante mucho tiempo, el pueblo programador permaneció inactivo, ya que prácticamente no había nuevas ideas para una mayor automatización y simplificación de la ejecución de programas. Y así apareció una nueva maravilla, CODEBUSTERS BOOT by RST#7.
La tecnología de cambio de discos, aplicada por primera vez (para la construcción de boot) en esta obra maestra de la programación, simplemente insufló nueva vida a la propia idea. ¡Cientos de programadores arrancaron el procedimiento de consulta del disquetera, se lanzaron a la conquista de las cumbres de la automatización y el diseño! Y cuando otro genio de Járkov - COBRA - se dio cuenta de apoyar el método de reemplazo de música propuesto por RST#7, despertó un nuevo interés entre la gente común. Ahora los discos comenzaron a grabar los boot más nuevos y de moda, y la música que sonaba en ellos se volvió la más genial y prestigiosa.
El último toque a esta historia fue la aparición de programas boot que requieren 128K de memoria para funcionar. ¿Quién fue el primero en "pensar" en esto? Es difícil decirlo con certeza, pero hay dos candidatos: ROM BOOT (BY ROM/S.B.U.H.G.) y BOOT by SILICON BRAINS. Ambos programas fueron lanzados en 96 y utilizan el modo 128KB solo para realizar efectos visuales más impresionantes.
Entonces, ¿cómo debería ser un boot ideal desde el punto de vista del usuario moderno?
Para empezar, hay que entender que un boot puede ser de juego o del sistema. Para el primero, el principio de ventana desplazable es muy conveniente, mientras que para el segundo es simplemente necesario mostrar la mayor cantidad posible de archivos en la pantalla al mismo tiempo. En los discos del sistema puede haber entre 30 y 60 archivos ejecutables, y navegar por ellos en una ventana pequeña es muy incómodo. Por eso, en todos mis discos del sistema grabo ZYX-BOOT. Por otro lado, últimamente, programas boot del sistema como estos aparecen cada vez menos. ¡Y esto es totalmente comprensible! Ahora, un nuevo boot se escribe no tanto por necesidad, sino por el efecto visual que el recién llegado RST#7 planea impresionar. Y si en toda la pantalla hay un catálogo del disco, ¿dónde estará ese hipercool efecto? Así que nuestros programadores crean una gran cantidad de boot de juegos, ¡y no se ven boot del sistema! Muchos de mis conocidos ya han llegado al punto de que en los discos del sistema mantienen un commander en lugar de un boot. ¡Pero eso es antinatural!
Así que, continuemos. Dado que es difícil inventar un estándar para los boot del sistema por su falta, consideremos los de juego.
La selección de archivos en un programa de este tipo generalmente se realiza con el cursor desde una ventana en la que se desplaza. Las dimensiones de la ventana deben ser de al menos 6-8 caracteres de altura, de lo contrario, es difícil abarcar con la vista el contenido del disco.
El desplazamiento en la ventana debe ser controlado por la máxima cantidad posible de combinaciones de teclas y joysticks. Es razonable soportar las siguientes opciones:
┌----------------------┬-----------------┐
│arriba pixel a pixel │ Q,S,9,arriba │
├----------------------┼-----------------┤
│abajo pixel a pixel │ A,X,8,abajo │
├----------------------┼-----------------┤
│arriba un archivo │ O,6,izquierda │
├----------------------┼-----------------┤
│abajo un archivo │ P,7,derecha │
├----------------------┼-----------------┤
│selección de archivo │ ENTER,SPACE,0,M │
└----------------------┴-----------------┘
Si tienes a mano dispositivos como KEMPSTON MOUSE o AY-MOUSE, nadie prohíbe (y de hecho se recomienda) que también los soporten.
Quiero advertir a los programadores principiantes sobre un error común. Si la tecla "SPACE" se consulta comoselección de archivo, puede ocurrir la siguiente situación: el usuario mueve el cursor sobre el archivo que necesita, presiona la tecla BREAK (CAPS SHIFT + SPACE) y se inicia el programa. Pero en los próximos milisegundos todo se detiene y te sales a BASIC. ¿Por qué ocurre esto y cómo combatirlo? No es difícil de entender. Es importante no permitir tales errores en tus creaciones.
El cambio de discos también es un elemento importante en un boot moderno. Por un lado, este proceso debe ser manejado automáticamente, pero por otro lado, no en todas las unidades este método funciona sin problemas. En algunas máquinas, debido a un controlador mal ensamblado o a un fallo en la propia unidad, la relectura automática del disco produce un ruido terrible, amenazando con un fallo completo del sistema. Naturalmente, hay programas que funcionan bastante bien incluso en tales unidades, aunque los discos se relean automáticamente. Todo depende de cuán correctamente se implemente el algoritmo en ensamblador. Quizás en próximos números de la revista proporcionemos el texto de un procedimiento de consulta de disquetera que funcione correctamente. Pero por ahora, intentemos resolver el problema de raíz: ¿cómo determinar el cambio de disco, automáticamente o manualmente?
El programador MAXSOFT de Samara se acercó radicalmente a la solución de este problema. No le satisfacía en absoluto la lectura automática de discos en ninguna forma, ya que en el emulador de SPECTRUM en IBM este método conduce a terribles glitches. Aquí hay un pequeño desensamblador del programa MAXBOOT 11:
LD A,(#5DбE) : Verificación
CP #31 : número
CALL Z,#CEDB : MODO
LD A,(#5DбE)
CP #32
CALL Z,#CEDЧ
......................
#CEC8 LD C,#13
CALL #3D13
LD A,(#SCDD) : Verificación
CP #49 : emulador
RET NZ : UKV-DEBUGGER
#CEDЧ POP HL : Desactivación
LD HL,#C9AF : lectura automática
LD (START_OF_AUTOCHECK),HL
RET
#CEDB LD HL,#801 : Verificación
CALL #CEC8 : emulador
CP #1C : Z80
JR Z,#CEDЧ : (LUNTER)
LD HL,#ЗDAD
CALL #CEC8
LD HL,#ЗEB5
CALL #CEC8
LD HL,#1FFD
CALL #CEC8
RET
La idea es la siguiente. En el cargador BASIC hay una línea de texto "MODE 1", donde el uno es uno de los tres modos de operación:
1 - prueba en el emulador de SPECTRUM y si es así, desactivar la lectura automática. 2 - la lectura automática siempre está desactivada. 3 - la lectura automática siempre está activada. Así, si no te gusta que tu disquetera haga ruido por la lectura automática, basta con usar un disco doctor para cambiar un número en BASIC y el programa funcionará como debería. La relectura manual es más conveniente de asignar a la tecla SPACE (por supuesto, si no la estás utilizando como SELECCIÓN), y duplicarla con la tecla R. Al crear un procedimiento de lectura automática, es importante prestar atención al algoritmo de trabajo. A menudo, un algoritmo mal escrito conduce a errores al trabajar con discos protegidos contra escritura. Además, la lectura del disco debe comenzar solo cuando el usuario ya ha sacado el viejo disco y ha comenzado a insertar el nuevo (ver MAXBOOT#11).
Durante el tiempo de lectura del nuevo disco, es necesario detener completamente el funcionamiento de todos los efectos visuales y la reproducción de música. El hacker UNWINDER/CODERS ACADEMY resolvió radicalmente este problema. En su boot se aplicó un controlador cuasi-multitarea para la lectura desde el disco (como en BATTLE COMMAND e INSULT). Por lo tanto, al cambiar el disco, la pantalla se apaga, pero la música sigue sonando, lo que crea una sensación única de vitalidad en lo que ocurre. En general, si este boot no requiriera 128K de memoria, se podría considerar el mejor hasta la fecha en términos de servicio y diseño.
Casi inmediatamente después del primer boot que se escribió, la gente entendió la inutilidad de mostrar en la ventana de selección de archivos el propio archivo "boot". Se argumentaba que el boot siempre se graba primero en el disco y solo estorbaría al seleccionar archivos. Algunas "mentes calientes" incluso abogaron por ignorar no solo este archivo, sino cualquier otro que comenzara con una letra minúscula. De hecho, esta propuesta era relevante en los tiempos en que existían versiones de disco por el "método Rodionov", es decir, que contenían no uno, sino dos bloques BASIC. Solo el primero se ejecutaba, y al intentar ejecutar el segundo, en el mejor de los casos, el usuario se llevaba un ligero susto.
Hoy en día, prácticamente no quedan versiones de disco como estas, pero han aparecido nuevos formatos de juegos y revistas - disk size. Tal juego o revista electrónica ocupa un disco completo y, por supuesto, lleva el nombre boot. Si se inserta un disco así en un boot que lo ignora, no podrás ejecutar el juego o la revista, ya que el archivo llamado "boot" no se muestra en la pantalla. Espero haber convencido de la necesidad de mostrar el propio archivo "boot". Para aquellos a quienes les molesta ver constantemente la palabra boot en el primer punto del catálogo, puedo ofrecer el siguiente método. Después de leer el disco, en la ventana de selección se imprime primero el archivo boot, y luego los nombres de todos los demás programas. Al mismo tiempo, el cursor se coloca inmediatamente en el segundo programa. Así, incluso si se presiona la tecla SELECCIÓN inmediatamente después de la carga, no se ejecutará el boot, sino el primer programa en el disco (después del boot).
Por supuesto, un boot moderno debe poder cambiar de una unidad a otra al presionar las teclas 1 (unidad A), 2 (unidad B), 3 (unidad C) y 4 (unidad D). Claro, se puede argumentar que la mayoría de los usuarios comunes no tienen ni siquiera una segunda unidad, y una tercera o cuarta es un lujo. Pero no hay que olvidar la tendencia emergente hacia discos y unidades de 3.5', y en este caso, una configuración con dos unidades de 5.25' y una de 3.5' puede convertirse en una realidad objetiva. Y volviendo a los mencionados emuladores, es importante notar que en la última versión de UKV se pueden crear imágenes de discos flexibles en el disco duro y luego trabajar con ellas como si fueran las unidades "C" y "D".
Por supuesto, puede ocurrir una situación en la que el usuario intente seleccionar la unidad "D", aunque solo tenga la unidad "A". En tal caso, la forma más efectiva es realizar de 5 a 10 ciclos de intento de cambio a otro dispositivo, y si fallan, regresar a la unidad original. La música es una parte integral de un boot moderno y la tarea del programador es facilitar al usuario su reemplazo. El método más común es grabar la música en un archivo separado justo después del boot. La música debe estar compilada con el editor correspondiente, sin reproductor. Así, el reproductor mismo debe ser estándar y estar dentro del cuerpo del programa. Normalmente, un boot reproduce música creada solo en uno de los editores (ASM, ST, PT, STP). Soportar todos los formatos de música conocidos es difícil también porque almacenar en memoria 3-4 reproductores es bastante derrochador y nuevamente comienza a faltar memoria para implementar efectos visuales superhíper.
Como solución a esta situación, puedo proponer lo siguiente. Después de cargar en memoria un boot que contenga todos los reproductores, se carga la melodía y se prueba su pertenencia a uno u otro editor. Luego, todos los demás reproductores que no son necesarios para el funcionamiento se destruyen y en su lugar se descomprime el propio boot. Así se puede ahorrar memoria y soportar todos los formatos de música existentes. Aunque en principio es suficiente incluir en el boot dos reproductores: de PRO TRACKER y SOUND TRACKER PRO. Actualmente se escribe poca música en ASM, y cualquier melodía de un SOUND TRACKER normal se puede convertir fácilmente al formato STP.
También es importante recordar que el usuario puede grabar accidentalmente o intencionadamente algo diferente en lugar de música después del boot. En este caso, basta con realizar una prueba de la melodía para determinar su pertenencia al editor y si hay sospechas de que no es música en absoluto, ¡simplemente no reproducirla!
Por cierto, la cuestión de la determinación inequívoca de la pertenencia de una melodía compilada a un editor u otro es muy complicada. Por supuesto, se puede descomponer un programa como VIRTUAL PLAYER (by DISMASTER) y eliminar todas las verificaciones, pero nos gustaría que los propios autores de los editores de música (en particular KSA) proporcionaran métodos oficiales para la determinación inequívoca de la pertenencia de la música compilada a un editor u otro. Nuestra revista publicará con gusto dicha información. Eso es todo lo que quería contarles hoy sobre qué boot's han existido, existen y existirán. Naturalmente, mi opinión puede no ser objetiva. Por lo tanto, pido a todos los interesados en este tema que envíen cartas con consejos, comentarios y sugerencias. Publicaremos todo sin falta.
-════════════════════════════════════════
* * * * *
Contenido de la publicación: Oberon #03
- De los Autores
El editorial del tercer número de Oberon refleja su amplia distribución en Rusia y países cercanos, superando desafíos de producción y su objetivo de atender a varios lectores, incluidos jugadores, programadores y hackers.
- Cómo Escribir en Oberon - M.M.A
Guía sobre cómo enviar artículos a Oberon utilizando ZX-WINWORD. Explicaciones detalladas de formato y proceso para texto, gráficos y música. Perspectiva sobre prácticas editoriales y preferencias.
- Pergamino - M.M.A
Un resumen histórico del juego THE EIDOLON en ZX Spectrum, cubriendo su proceso de restauración y mecánicas de juego, incluyendo desafíos de nivel y antecedentes de la historia.
- Desplazamiento
Dark Star es un juego de disparos espaciales donde los jugadores pilotean una nave contra una raza alienígena tiránica. Los jugadores personalizan configuraciones, navegan el espacio y combaten fuerzas enemigas en varios niveles de dificultad. La planificación estratégica y la habilidad son vitales para un juego exitoso.
- Pergamino - M.M.A
Mecánicas de juego detalladas para el juego con Mechnotech klp2. La estrategia implica desarmar reactores y gestionar transformaciones de droides. Información sobre los diferentes tipos de droides y armas disponibles.
- Sobre Todo - M.M.A
Discusión de las interacciones de los lectores con el equipo editorial de 'Oberon', incluidos comentarios sobre números anteriores y compatibilidad de juegos y mejoras en el contenido de la revista.
- Sobre Todo - M.M.A
El artículo autobiográfico explora el papel del autor en la escena ZX Spectrum de Samara, detallando sus contribuciones y aspiraciones. M.M.A se posiciona como líder e innovador en la comunidad. Destaca la importancia de la distribución local y el impacto cultural.
- ¿Amiga rulez? - M.M.A
Ensayo crítico sobre la cultura informática contemporánea, contrastando las plataformas IBM y Amiga. Discute el impacto social de la estandarización de IBM y aboga por Amiga como símbolo de creatividad e individualidad. Reflexiona sobre la evolución del uso y las preferencias de computadoras desde la era del ZX Spectrum.
- Cómo debería ser el 'boot' - Unbeliever
El artículo explora la evolución de los programas de arranque para ZX Spectrum, discutiendo los primeros desarrollos y las innovaciones clave a lo largo del tiempo. Destaca importantes avances en automatización y diseño, incluyendo boots totalmente escritos en ensamblador y la introducción de características modernas. El texto concluye con reflexiones sobre las características ideales del boot desde la perspectiva del usuario contemporáneo.
- Carta de Queen Software
Una carta abierta de Queen Software critica el diseño de ZX-WINWORD y el diseño del teclado ruso, denuncia 'Mortal Compot' y la degradación de juegos, y comparte opiniones sobre eventos de la demoscena y emulación de computadoras.
- Revisión - Unbeliever
La reseña ofrece información sobre varios juegos exclusivos de 128K para ZX Spectrum, destacando títulos como 'Space Gun', 'World Championship Soccer' y 'Night Breed'. Se presta especial atención a su destreza gráfica y mecánicas de juego. Además, el artículo aborda la adquisición de software Spectrum a través de Internet.
- Revisión de Ensambladores - Maxsoft
Revisión de varios ensambladores para ZX Spectrum, destacando sus fortalezas y debilidades. Enfoque en EDAS 3.3, AFS, XAS, ZX-ASM, ALASM, MASM y TASM 4.1. Cada ensamblador se evalúa en rendimiento, características y usabilidad.
- Nuestra Respuesta - M.M.A
Análisis crítico de la revista electrónica FAULTLESS, destacando problemas de plagio y calidad del contenido. Discusión sobre la comparación con OBERON y otras revistas. Se proporcionan sugerencias para mejorar FAULTLESS.
- Nuestra Respuesta - Alex Noman
Debate sobre la compatibilidad y capacidades de las computadoras Scorpion y Profi con el ZX Spectrum. Crítica a las afirmaciones de programación de Chung Software respecto a lenguajes y métodos obsoletos. Discusión sobre sistemas operativos como CP/M e iS-DOS en el contexto de su utilidad en la informática moderna.
- Nuestra Respuesta
Exploración de las diversas interpretaciones del término 'hacker' en ruso, destacando distinciones y conceptos erróneos.
- Hardware - Dr.Death
Instrucciones de conexión para AY-3-8910 en máquinas compatibles con Spectrum. Soluciones para problemas de audio comunes en computadoras rusas. Consejos para mejorar la compatibilidad del sonido digital.
- Hardware - Dr.Death
Discusión sobre la modificación del SCORPION ZS 256 para un mejor rendimiento, centrándose en problemas de temporización y modo TURBO. Explicación de mejoras y posibles problemas con multicolores. Sugerencias para futuras mejoras.
- Hardware - Poltergeist Corp.
Análisis de problemas de hardware en Profi, un clon del ZX Spectrum, centrado en problemas de señal INT que causan parpadeo gráfico. Se propone una solución que implica una modificación de hardware simple. El autor comparte su éxito y la adopción generalizada en Samara.
- Vamos a Gurm
Una microdrama que ilustra la interacción caótica entre componentes de la computadora durante una tarea de impresión.
- Vamos a Banquetear
Historia satírica que representa una realidad alternativa donde la cultura y símbolos estadounidenses son humorísticamente distorsionados por influencias soviéticas.
- Banqueteemos
La historia describe humorísticamente los esfuerzos de Popov por ayudar a los papúes a progresar, en medio de luchas en el desierto, intrigas políticas y desafíos personales.
- Discutamos
Visión general del argot militar conocido como 'Absurdeces del Ejército' recopilado por estudiantes, destacando el lenguaje único e instrucciones utilizadas en el entrenamiento y comunicaciones militares.
- Vamos a Banquetear
Artículo satírico que describe el humor militar y equipo militar ficticio.
- Campaña de Alfabetización - Paul Atrides
Análisis de los conceptos erróneos sobre los hackers y las actitudes sociales, explorando las raíces de la cultura hacker y sus dilemas éticos.
- Introducción - Paul Atrides
El artículo discute el papel y las actividades de los hackers rusos a finales de los años 90, destacando casos notables y categorizando diferentes tipos de hackers. Cubre las operaciones, riesgos e impactos del hacking a nivel internacional y local. El texto también examina la percepción social de los hackers y su representación en los medios.
- Concurso - M.M.A
Un concurso que consiste en identificar canciones a partir de letras mal traducidas, inspirado en un segmento de radio. Los participantes adivinan la canción y el artista. No hay premio específico aún, pero se promete una edición gratuita de la revista.
- Concurso
Una reflexión poética sobre la lucha personal, la comunicación incomprendida y la carga de salvar el mundo.
- Concurso
Una reflexión poética sobre el aislamiento y los sueños internos, en contraste con la dura realidad.
- Concurso
El artículo presenta un tributo poético a la comunidad, destacando temas de unidad, inmortalidad y fortaleza a través de la música metal.
- Publicidad
La publicidad en la revista Oberon ofrece publicación gratuita y discute el software, hardware y tiendas disponibles relacionados con ZX Spectrum.
- Anuncio
Publicidad de reparación y mejoras de computadoras con precios para varios servicios. Opciones incluyen conexión de unidades, normalización de señales y ampliaciones de memoria. Servicios específicos para diferentes modelos de computadoras como Pentagon y ATM.
