GUÍA RÁPIDA PARA PROGRAMADORES DE SISTEMAS
Una persona que decide escribir un programa de sistema se enfrenta a muchas dificultades. Este texto tiene como objetivo ayudarle, al menos en parte, a hacer que su programa sea de calidad y cómodo de usar. Por supuesto, no pude tener en cuenta todos los matices, pero si utiliza los consejos que se exponen a continuación, será más fácil tanto para usted como para los usuarios de sus programas. Esta es una versión ampliada de un artículo que fue publicado en "Depth 1". Tenemos la intención de continuar este tema en números posteriores de "RU(S)H".
QUÉ DEBE TENER EN CUENTA PRIMERO AL CREAR UN PROGRAMA DE SISTEMA
1. En su obra deben tenerse en cuenta todas las desventajas y ventajas de programas anteriores de este tipo. Aprenda de los errores de los demás y utilice todos los logros de sus predecesores.
2. El control en el programa debe ser flexible y diverso. El conjunto estándar incluye: SINCLAIR (derecha), KURSOR, KEMPSTON (con verificación), TECLADO (O,P,Q,A, ESPACIO y M). También KEMPSTON y AY para el ratón. Si no tiene un ratón pero desea implementar su soporte, puede leer sobre cómo hacerlo en las siguientes publicaciones: sobre el ratón KEMPSTON - "SPECTROFON 20" en la sección "Constructor", sobre el ratón AY - "ZX-POWER 1" en la sección "Hardware".
3. Siempre debe verificar la presencia del joystick KEMPSTON y no interrogarlo si no está presente. De lo contrario, su obra no funcionará en todas las máquinas que no tengan este puerto. Recuerde que si no hay KEMPSTON, los bits 5-7 están establecidos.
4. Su programa debe utilizar al máximo todos los recursos de la máquina en la que se ejecuta. Debe probar la cantidad de memoria disponible y trabajar precisamente con ella. Puedo recomendar utilizar el autoconfigurador de memoria de "ZX-FORMAT5", escrito por CREATOR. Esto permitirá que su programa funcione con memoria desde 48k hasta un megabyte.
5. Los copiadores y otras utilidades de disco deben funcionar tanto con una como con dos unidades.
6. Si hay muchos parámetros modificables en el programa (más de tres), es absolutamente necesario grabarlos en disco (SAVE SETUP). La grabación debe realizarse dentro del propio programa, verificando previamente su existencia y ubicación en el disco.
7. Si su programa trabaja con el segundo modo de interrupciones, debe conectarlas creando una tabla de 257 bytes, llena de un solo número, ya que en muchas máquinas se lee desde el bus no #FF, sino cualquier número. Esto ya se ha mencionado mucho, pero aún así a veces aparecen programas que no lo tienen en cuenta.
8. Naturalmente, los segmentos (páginas) deben cambiarse no a través del puerto #FD, sino a través del puerto completo #7FFD (dec: 32765).
9. Al acceder al disco, debe estar habilitado el primer modo de interrupciones (IM 1). Si por alguna razón necesita IM 2, puede usar el vector de interrupción solo dentro de las áreas de memoria rápida (#8000-#BF00 (32768-49151) o en las páginas 0,1,2,3); si el vector de interrupciones se encuentra en un área de memoria lenta, toda la computadora, junto con TR-DOS, funcionará un 25 por ciento más lento, y las operaciones de disco se verán afectadas. Esto es característico solo de máquinas con campos de memoria separados; para otras, como Pentagon, no tiene importancia, pero aún así debe tenerse en cuenta. Se ha escrito en detalle sobre los campos de memoria separados en el periódico bielorruso "ECHO 2", le aconsejo que lo lea. También al cambiar al modo estándar de interrupciones (IM 1), es necesario restaurar en el registro I el valor 63 dec, de lo contrario, su programa no funcionará en muchas máquinas, incluida la de marca.
UNOS CONSEJOS MÁS DETALLADOS PARA TIPOS DETERMINADOS DE PROGRAMAS
14 CONSEJOS PARA QUIEN ESCRIBE UN "boot":
1. Primero debe decidir para qué discos se utilizará este "boot". Para sistemas, son preferibles las interfaces simples pero cómodas, sin efectos diversos y adornos innecesarios. Si el "boot" está destinado a juegos y demos, entonces es otra historia, los efectos, gráficos y música son bienvenidos.
2. Naturalmente, debe ocupar el menor espacio posible en el disco.
3. Cuanto más rápido se cargue y ejecute su "boot", mejor. En cualquier caso, no debe agregar efectos con largos DECRUNCHER' s.
4. Intente mostrar la mayor cantidad de archivos en la pantalla al mismo tiempo.
5. Los nombres de los programas deben ser legibles. Elija una fuente y un color de ventana adecuados. Es preferible que la ventana de archivos no se mueva. Fuera de la ventana, haga lo que quiera.
6. El control debe ser diverso y flexible. Al mismo tiempo desde la mayor cantidad de dispositivos. Si la selección de archivos se realiza mediante una flecha, implemente el soporte para los ratones KEMPSTON y AY. Personalmente, en la gran mayoría de los casos, uso las teclas de cursor para seleccionar archivos (teclado ampliado). Al interrogar el teclado, primero se verifica si se presiona CAPS SHIFT; si está presionado, las teclas 5,6,7,8 se interrogan como joystick KURSOR, de lo contrario como SINCLAIR. El cambio de disco generalmente se realiza con la tecla ESPACIO, esto ya se ha convertido en un estándar. También es conveniente usar la tecla "ENTER" como FIRE.
7. Si su boot no implementa la verificación automática del cambio de disco, antes de iniciar el programa debe volver a leer el directorio y, en caso de que el archivo necesario no esté allí, mostrar el directorio del nuevo disco y, por supuesto, no iniciar nada.
8. Antes de iniciar el programa, es necesario restaurar todas las variables del sistema y todo lo que se requiere para el funcionamiento normal de Basic. Puede dejar la pantalla negra (el área de atributos llena con el código 0), pero en las variables del sistema es necesario escribir los atributos estándar. También es deseable limpiar toda la memoria que ocupaba el "boot".
9. Hay muy pocos programas que utilizan 128k de ROM o 128k de Basic (siendo honesto, no recuerdo ninguno), pero hay muchos programas que no funcionan con 128k de ROM conectada. Por lo tanto, es deseable que el "boot" conecte inmediatamente 48k de ROM, pero con páginas activas. Si no sabe cómo hacerlo, tome líneas de los cargadores de ensambladores "TASM", "ALASM" o de algún otro. En una computadora de 48k, todo seguirá funcionando normalmente.
10. En la mayoría de los boots, los archivos con el nombre "boot" no se muestran, pero a veces esto es inconveniente, por lo que le aconsejo mostrar este archivo, pero si está grabado primero en el disco, mueva el puntero inmediatamente al siguiente archivo. Además, al buscar el nombre "boot", es necesario verificar las ocho letras, no solo las primeras cuatro.
11. A veces, en un mismo programa hay varios bloques de Basic, de los cuales solo se inicia uno. Este caso se puede prever y no mostrar ciertos archivos de Basic. No existe un estándar único en este caso. A veces no se muestran todos los archivos que comienzan con una letra minúscula, pero este método no siempre es conveniente. En mi opinión, es más conveniente filtrar todos los archivos que comienzan con un punto.
12. En algunos "boots" se implementa la clasificación de archivos alfabéticamente, pero generalmente solo dificulta el trabajo. Por lo tanto, es mejor hacer que la clasificación sea desactivable.
13. Es útil que, además de la lista de archivos, se muestre información breve sobre el disco en la pantalla. Por ejemplo, su nombre, la cantidad de sectores libres y la cantidad de archivos.
14. Es deseable no adjuntar música de manera rígida, sino hacerla fácilmente modificable. En este caso, hay dos maneras: se puede almacenar en memoria un reproductor de algún editor musical y cargar el archivo de música sin el reproductor. O bien cargar un bloque compilado con el reproductor de cualquier editor, pero debe estar compilado para una dirección específica. En cualquier caso, es necesario describir detalladamente el proceso de adjuntar música.
SI DECIDIÓ ESCRIBIR UN COMPRESOR...
Primero, debe permitir grabar bloques comprimidos sin un descompresor, para que se pueda descomprimir con un solo depacker muchos archivos. En segundo lugar, debe adjuntar al compresor una versión de texto del descompresor, para que cualquiera pueda modificarlo a su gusto o intentar acelerarlo. El tiempo de compresión no es especialmente importante, pero la velocidad de descompresión debe ser lo más rápida posible. El depacker debe funcionar correctamente con interrupciones habilitadas. Al trabajar con varios compresores, se ha encontrado que prácticamente todos los "crunchers" existentes (DSQ4, MS_PACK, LPC, etc.) no siempre funcionan correctamente. Una vez, al intentar comprimir un archivo, probé 6 o 7 compresores y ninguno de ellos lo descomprimió correctamente. Normalmente, los errores se manifiestan cuando un bloque comprimido o una pantalla ya está presente en el archivo a comprimir. No soy un experto en este campo, pero me atreveré a expresar mi opinión, que huele un poco a novato :-) ... Parece que los packers colocan sus códigos de control, y al volver a comprimir pueden coincidir, lo que resultará en una descompresión incorrecta (solo no me golpeen si dije alguna tontería :-) )... Tales errores son raros, pero trate de que su compresor no los tenga en absoluto. Estoy cansado de escribir loaders para programas. Me gustaría que se implementara en los compresores la función de multipacking de varios archivos con la adición de un cargador estándar que dispersara los archivos por las páginas...
UNOS CONSEJOS PARA QUIEN ESCRIBE UN EDITOR MUSICAL
1. Si ha decidido escribir uno, debe superar todos los editores existentes hasta ahora, de lo contrario, ¿para qué molestarse? En tal caso, es absolutamente necesario escribir un convertidor completo de todos los editores a su editor.
2. Es importante que el reproductor ocupe la menor cantidad de ciclos posible. Idealmente, de 2 a 3 mil. De lo contrario, el área de uso de su editor se reducirá significativamente.
3. Adjunte al editor la versión fuente del reproductor en el formato de algún ensamblador (preferiblemente "TASM", ya que es más fácil convertir el archivo a cualquier otro editor desde allí). También puede adjuntar el texto del reproductor en formato de texto normal.
4. En primer lugar, le aconsejo que se familiarice con los editores en otras plataformas. Puedo recomendar que vea el editor "OCTAMED" en AMIGA. Creo que encontrará allí un montón de ideas útiles para el servicio y su editor será mucho más cómodo.
5. Además de facilitar la vida al músico, también debe preocuparse por el codificador que utilizará la música en su programa. Sería muy conveniente si implementa un temporizador en tiempo real. Es decir, un temporizador que muestre el tiempo de reproducción de la música con precisión hasta la interrupción. Esto ayudará a sincronizar la música en el programa con los gráficos.
6. Haga posible cambiar el volumen de la melodía durante la reproducción, para que se pueda implementar fácilmente un desvanecimiento de la música. Puede introducir tres variables en el reproductor que contendrán el valor del volumen máximo para los canales A, B, C.
7. La salida en cualquiera de los tres canales debe poder cortarse en cualquier momento de la reproducción, para que se puedan reproducir efectos de sonido por ese canal.
8. No estaría mal hacer posible el cambio a cualquier posición. Esto permitirá saltar rápidamente a cualquier lugar de la melodía, almacenar varias melodías en una o, por ejemplo, usar una melodía como un conjunto de efectos de sonido.
9. Al escuchar música en Speccy, la mayoría ni siquiera sospecha que muchas melodías suenan "falsas" precisamente debido a las características programáticas de algunos editores. Un conocido mío de Kiev, Sasha, un músico profesional y afinador de instrumentos musicales, prestó especial atención a esto. Así que, confiando en su oído musical perfecto :-), se puede decir que ni en "Sound Tracker", ni en "ST-pro", ni en "Pro Tracker" hay una generación de sonido correcta desde el punto de vista musical. Solo el viejo "ASM" deleita el oído con su ajuste y precisión de sonido. Así que ya existen versiones modificadas del tercer "Pro Tracker", que incorporan tablas de generación de sonido tomadas de "ASM" de Sendetski. Espero que todos los autores de nuevos editores y sus versiones tengan en cuenta este importante matiz. La calidad del sonido es lo principal en un editor musical.
RECOMENDACIONES CONCRETAS PARA LOS AUTORES DE ALGUNOS PROGRAMAS DE SISTEMA
1. "ALASM" por ALEM
El ensamblador debe entender necesariamente la representación binaria de los números, escrita después del signo % (por ejemplo %00000001). Al cargar un archivo WORK, es mejor colocar el cursor inmediatamente en la última fuente grabada. Posibilidad de marcar parte del texto con otro color o inversión. También marcar con otro color las líneas con errores. Al presionar una combinación de teclas determinada, el ensamblador debe recordar la posición actual en el texto y luego debe tener la capacidad de saltar rápidamente a este lugar. Los comandos de compilación única son muy convenientes, pero a menudo se presenta la situación en la que se cargan varios archivos uno tras otro, y las etiquetas se colocan entre ellos. En este caso, al volver a ensamblar, las direcciones de las etiquetas se desajustarán. Por ejemplo, un fragmento de programa: MUSIC +INCBIN "RAVE+" SPRITES +INCBIN "GFX_CODE" TABLE +INCBIN "DATA". En la primera compilación, los valores de las etiquetas SPRITES y TABLE dependerán de la longitud de los archivos anteriores, como debe ser, pero en la siguiente ensambladura, cuando el marcador "+" se reemplace por "-", y los archivos no se cargarán, las tres etiquetas apuntarán a la misma dirección. Creo que para evitar esto, es suficiente recordar durante la ensambladura las longitudes de todos los archivos cargados y luego sumarlas en cada compilación posterior. También es útil desconectar el sonido en AY, después de regresar de un programa ejecutado. También se puede hacer que la tecla BREAK no utilizada en el modo de edición funcione como ENTER, pero con un salto de línea no al campo de etiquetas, sino al campo de comandos. La gestión del disco es mejor organizarla como en "TASM-4", es decir, cargar el directorio del disco en memoria y tomar los parámetros de los archivos directamente desde allí, sin mover la cabeza innecesariamente a la pista cero.
Y unos consejos más no solo para ALEM, sino para todos los creadores de ensambladores:
Es deseable prever la prueba de los procedimientos ejecutados en el tiempo, en el mejor de los casos con precisión hasta el ciclo, un poco peor con precisión hasta cuatro, y en el peor de los casos al menos con precisión hasta la interrupción, utilizando el contador del sistema (FRAMES). Es necesario que después de salir del programa ejecutado, sin limpiar la pantalla, se pueda entrar en un modo especial de cálculo de direcciones de pantalla. Es decir, en un modo en el que un puntero del tamaño de un byte o un punto se mueve por la pantalla, y al presionar FIRE se muestra la dirección de este byte en el archivo de pantalla, en el área de atributos y las coordenadas en X e Y. Sería útil un comando que vincule la siguiente dirección de compilación a una dirección hexadecimal exacta. Me gustaría que en los ensambladores hubiera comandos como: SAVE 0 TRACK TO 159 y RESTORE 0 TRACK FROM 159. También sería útil tener funciones de limpieza de memoria y páginas.
2. STS por STALKER
Si al grabar un archivo en el disco ya hay un archivo con el mismo nombre y que se encuentra al final del directorio, debe borrarse y grabarse el nuevo archivo en su lugar, como lo hace la gran mayoría de los programas. Al ingresar parámetros numéricos para diversas funciones, por ejemplo, COPY, es necesario vincular los números ingresados no al borde derecho de la ventana, sino al izquierdo, para no tener que mover constantemente el cursor unos signos a la derecha.
3. PERFECT COMMANDER por JAMES ADVENT
En mi versión del comando, hay un pequeño pero molesto error: al copiar varios archivos en un disco donde quedan menos de 256 sectores, el comando a veces "finge" que la copia fue exitosa, mientras que en realidad los últimos archivos no se sobrescriben. Si se reinicia el comando, todo se copiará perfectamente. Antes de ver la pantalla, es mejor llenar los atributos con el código 0, y el borde es mejor dejarlo siempre negro, ya que la "detectora inteligente" a veces parece un completo daltónico, esto te lo digo como artista...
También sería útil un reproductor elemental de música compilada, mientras que el propio comando debe "esconderse" en las páginas y cargar la música con el reproductor en cualquier dirección. Sería muy conveniente ver archivos de texto estándar con modos de 42 y 64 caracteres por línea. Me gustaría que se implementara la función estándar de guardar una copia del directorio en la pista 159.
Y además, por favor conecta 48k de ROM y limpia toda la memoria al iniciar programas. Sería simplemente maravilloso si implementaras en el comando un trabajo directo y completo con MS-DOS. Estoy cansado de usar un editor de texto para copiar archivos... :-)
4. TOTAL COMMANDER por Dr. L0VE
Asegúrate de hacer "teclas de acceso rápido", ya que trabajar con ventanas es demasiado lento. Te aconsejo que elijas mejor los colores en el comando, para que no se vea tan estridente, esto solo dificulta la percepción de la información. Es necesario implementar la posibilidad de ejecutar archivos de código. La posibilidad de elegir cualquier máscara para los archivos mostrados.
BEST VIEWER 2.5 por Ivan Roshin
¡Simplemente es una cosa maravillosa! ¡No puedo dejar de admirarme! Lo que falta para la felicidad completa:
Reproducción de archivos no compilados de "ST-pro" (como en "X-player"). Posibilidad de ver textos en formato de 42 caracteres por línea, y posiblemente en diferentes codificaciones (WORD, D.Mikhaylova (Amiga), etc.). Visualización de archivos de sprite en formato "SprGen 5.1" de Real Software. Control desde Kempston. Posibilidad de aumentar la ventana del file requester, cuando las listas de archivos se muestren en varias filas. Mostrar en pantalla información del sistema auxiliar (dirección de inicio y longitud del archivo, nombre del disco, etc.). A "petición insistente de los televidentes", reproducción de música cargada en segundo plano durante la visualización de textos, por ejemplo. En general, sería lo mejor de lo mejor combinar "BV" y "Perfect" en un todo único, o complementar "BV" con todos los atributos de los comandos, orientándose en "Perfect"...
En este artículo he considerado solo algunos programas, pero si tiene alguna idea o comentario sobre el software de sistema, escríbanos y continuaremos este tema en números posteriores de "RU(S)H". Los creadores de programas y sus usuarios deben comunicarse y juntos introducir cambios y mejoras en los nuevos productos.
¡Les deseamos éxito creativo en la creación de programas de sistema!!!
Contenido de la publicación: Rush #01
- AMIGA NOTICIAS
Amiga Inc trabaja en Amiga OS 3.5 con mejoras como soporte de unidad de CD y PowerPC. Desarrollo dividido para procesadores M68K y PPC. Lanzamiento retrasado a finales de 1999 o principios de 2000.
- NOTICIAS AMIGA
Descripción del visor 'Fast JPEG 1.10' para Amiga, enfocándose en sus características, instalación y uso. Destaca ventajas como el procesamiento rápido sin pérdida de calidad y ofrece consejos para el usuario. Se invita a los lectores a compartir sus experiencias con el software.
- AMIGA NOTICIAS
Programación básica para Amiga clásica, discutiendo desafíos y compartiendo conocimientos en codificación Amiga. Resumen de capacidades gráficas de Amiga y características del procesador. Introducción a las especificidades del lenguaje ensamblador de Amiga.
- AMIGA NEWS
Resumen de eventos relacionados con la plataforma Amiga desde principios hasta mediados de 1998. Incluye nuevos hardware, lanzamientos de software y colaboraciones destacadas de empresas. Se planifican futuras actualizaciones y desarrollos para el próximo número.
- NOTICIAS DE AMIGA
Colección de trucos y secretos para juegos clásicos de Amiga recopilada por Postcard Man. Se anima a los lectores a compartir sus hallazgos sobre juegos complejos. Se proporciona selección de consejos y códigos de niveles para varios juegos.
- AMIGA NEWS
Discusión sobre las tarjetas gráficas de Phase-5 y las capacidades del procesador Permedia 2. Detalles sobre la aceleración 2D/3D del Permedia 2 y su compatibilidad. Mención de los procesadores GLINT Delta y comparación de precios y disponibilidad.
- NOTICIAS DE AMIGA
Análisis de la supervivencia de Amiga en los 90, destacando los esfuerzos de la comunidad y los avances tecnológicos. Discusión sobre mejoras de hardware y desarrollo de software. Aliento para una mayor exploración y aprendizaje sobre la plataforma Amiga.
- Programación para Spectrum
Explicación de un método rápido para gráficos 3D en tiempo real en el ZX Spectrum. Introduce técnicas eficientes de rotación y deformación para objetos 3D. Destaca mejoras sobre métodos tradicionales con ejemplos prácticos.
- Programación de Spectrum - Ticklish Jim
Discusión sobre la combinación de efectos de sonido con música para el chip AY de Spectrum. Ejemplos del desarrollo de 'CSC: Deja Vu' y desafíos técnicos enfrentados. Contiene guía práctica y ejemplos de código.
- Programación de Spectrum
Discusión sobre el reflejo de bytes y la restauración de fondo en la programación de ZX Spectrum, con ejemplos.
- Programación para Spectrum
Guía completa para programadores de sistemas con consejos prácticos para crear software eficiente y fácil de usar, incluyendo técnicas de codificación, compatibilidad con dispositivos y estrategias de prueba de programas.
- Programación para Spectrum
Técnicas avanzadas de codificación y métodos modernos de gráficos para ZX Spectrum. Consejos para optimizar procedimientos gráficos y codificación en ensamblador. Consejos útiles para programadores para mejorar el rendimiento y la eficiencia.
- El Final
Reflexiones sobre la creación del primer número de la revista 'Rush', sus objetivos, audiencia y desarrollo futuro.
- ZX-SOFT - Вячеслав Медноногов
Actualizaciones de desarrollo del nuevo juego 'Black Raven II' de Vyacheslav Mednoy, incluyendo cambios en la jugabilidad, introducción de nuevos hechizos y mejoras de rendimiento.
- ZX-SOFT
Descripción general de las nuevas funciones en el comandante actualizado de REAL software para ZX Spectrum, incluyendo gestión de archivos, autodetección y visualización de medios. Mejoras en el manejo de texto, fuente y música. Se abordan preguntas sobre futuras actualizaciones.
- ZX-SOFT
Debate sobre qué demo merecía el primer puesto en Funtop'98: Forever de DR o Refresh de XTM. Las discusiones en la comunidad demoscene destacan el choque entre destreza técnica y profundidad conceptual. Las diferentes opiniones reflejan la evolución de las preferencias en la demoscene.
- Autores
Reconocimiento a colaboradores y socios en la creación de la revista Rush. Detalle de roles de cada autor y colaboraciones. Reconocimiento a soporte técnico y asociaciones mediáticas.
- Specky Virtual
Discusión sobre la conversión de gráficos de PC a Spectrum, con opiniones de varios expertos. Se detallan técnicas para mejorar la calidad de conversión y herramientas como Photoshop. Énfasis en el refinamiento post-conversión en editores gráficos de Spectrum.
- Espectro Virtual
Discusión sobre el emulador CBSpeccy para ZX-Spectrum en Amiga, destacando sus características, opiniones de la comunidad y rendimiento técnico. Críticas y elogios por sus capacidades de emulación, en particular en comparación con los emuladores de PC. Examen de posibles mejoras y debates comunitarios sobre las actualizaciones de versión.
- Espectro Virtual
FAQ sobre la emulación de ZX-Spectrum en PC, cubriendo emuladores populares y formatos de archivos. Instrucciones para usar diferentes emuladores y gestionar tipos de archivos como Hobeta y TR-DOS. Discusión sobre servidores y recursos rusos orientados al ZX.
- Introducción
Introducción a la revista Rush, enfatizando la creatividad, la escena progresiva y el objetivo de crear una fuente de información superior. La revista busca reunir grupos prometedores y ofrecer una perspectiva única. Se enfoca en el contenido y la atmósfera, invitando a los creadores a contribuir.
- Introducción - Grunge
Introducción a Rush, una nueva revista para entusiastas de Speccy/Amiga, busca ofrecer contenido de calidad y noticias mientras fomenta la retroalimentación de los lectores.
- Entrevista - Konex
Entrevista con el grupo ANTARES después de FUNTOP-98. Discusión sobre sus demos, desafíos y planes futuros. Perspectivas sobre la formación y dinámica del grupo.
- Entrevista - Kvazar, DUX
Entrevista con Alexander Seleznev (KVAZAR), discutiendo su historia con las computadoras, el estado de la escena ZX Spectrum y planes futuros.
- Entrevista - Kvazar
Entrevista con el grupo de Vitebsk POWER sobre la demo 'Crazy Love', experiencias de desarrollo y proyectos futuros.
- Informatorium
Exploración de un CD con emuladores para varias plataformas, destacando Spectrum. Detalla la organización y diversidad de contenidos. Concluye con ideas del CD-ROM Project y su colección de software Spectrum.
- Informacrium
Compilación de direcciones de Internet interesantes y útiles relacionadas con recursos de Amiga, incluyendo revistas, fabricantes de hardware y empresas de software.
- Informacrium - Viator
Resumen de las publicaciones existentes y futuras sobre la plataforma Amiga. Discusión sobre la disponibilidad y los desafíos de distribución de la literatura Amiga. Llamado a la colaboración con nuevas publicaciones.
- Sobre la Revista
Discusión sobre la creación de una revista multiplataforma centrada en Spectrum, Amiga y PC. Énfasis en una comprensión más amplia de la escena informática. Fomentar el profesionalismo y la adaptación a la tecnología cambiante.
- Mundos Paralelos
Descripción de la evolución del sistema operativo Windows y los procesadores de PC de 1981 a 2000. Hitos en el desarrollo de MS-DOS, Windows, procesadores Intel y competencia con AMD y Cyrix. Desafíos para mantener la compatibilidad con nuevas tecnologías de procesadores.
- Mundos Paralelos
Resumen de modelos Macintosh y su relevancia en los campos de diseño y gráficos, cubriendo precios y especificaciones de 1997-1998. La discusión incluye la evolución del hardware de Apple, notablemente la serie PowerMac, y compara los nuevos procesadores G3 con sus contrapartes de PC. Destaca el resurgimiento de Macintosh después de la crisis y su influencia continua en el mercado.
- Desarrollo del Spectrum - Slider
El artículo analiza una nueva extensión gráfica para el ZX Spectrum que mejora las paletas de colores sin aumentar las demandas de recursos. Al usar una señal de flash modificada, se crean nuevos colores sin interferir con la compatibilidad del software existente. El artículo proporciona detalles de implementación y aborda preocupaciones sobre el uso práctico.
- Desarrollo del Spectrum
Conexión de un módem CDOS al ordenador 'Compact-128' abordando conflictos de puertos del teclado. Descripción de modificaciones de hardware para resolver el problema. La solución incluye bloqueo automático mediante un inversor de transistor.
- Desarrollo de Spectrum - Ars
Discusión sobre el desarrollo de AZX-Monstrum 512K, su compatibilidad de hardware, opciones de procesador y posibles mejoras en gráficos y sistema operativo.
- Desarrollo de SPECTRUM
Discusión sobre la nueva plataforma informática de Clive Sinclair, la ZX2000, diseñada para superar a las PC con mayor velocidad, asequibilidad y eficiencia de batería.
- Desarrollo del Spectrum - Андрей Савичев
Examen de la evolución y la relevancia continua del procesador Z80 y su papel en los sistemas embebidos. Comparación del Z80 con sus sucesores, destacando ventajas como eficiencia energética y mejoras de comando. Resumen de CPUs integrados basados en Z80 y sus periféricos.
- Anuncio
Este artículo es un anuncio de productos de Scorpion, incluyendo hardware para ZX Spectrum y software para Amiga, junto con detalles de precios y pedidos.
- Publicidad
Colección de anuncios para hardware y software de Amiga y ZX Spectrum, con información de contacto para vendedores y detalles sobre la nueva suscripción a la revista Amiga.
- Anuncio
Anuncio de la placa de música General Sound de X-TRADE. Incluye precios, detalles técnicos e instrucciones de compra. Presenta una sección de preguntas frecuentes e información de compatibilidad.
- Sentido Sin Sentido - Viator
Reflexiones filosóficas sobre el existencialismo, la inmortalidad y el destino humano. La narrativa teje historias de ambición, la búsqueda de la vida eterna y una caída utópica. Una mezcla de introspección y ficción especulativa.
- Escena vs Profesionales
Exploración de la creatividad de la demoscene frente al desarrollo comercial de juegos. Discusión sobre el potencial para programas de calidad profesional por miembros de la escena. Llamado a la colaboración con grupos destacados de la escena.
- Crónica de la Escena - Андрей Савичев
Reflexiones sobre el atractivo perdurable del ZX Spectrum, la resiliencia de su comunidad y su posible resurgimiento en Rusia.
- Cronología de la Escena
Descripción general de las actividades del grupo Rush, incluidos proyectos pasados, esfuerzos actuales y planes futuros, con énfasis en el desarrollo de software y juegos.
- Crónicas de la escena
El artículo analiza varias noticias de la escena ZX Spectrum, incluidas lanzamientos de juegos, demoparties y actualizaciones de desarrolladores y equipos.
- Crónicas de la Escena
El artículo trata sobre el festival internacional de arte computacional FUNTOP'98 que se celebró en Moscú, destacando los eventos clave, asistentes notables y las distintas competiciones celebradas durante el evento.
- Escena Cronia
Discusión sobre el desarrollo de la escena Amiga a través de la colaboración, abordando el aislamiento del usuario y promoviendo la expansión de la red.
- Gestión de la Interfaz
El artículo describe el control de la interfaz para ZX Spectrum y Amiga, incluidos las teclas y funciones de navegación. Se mencionan características de funcionamiento en Amiga con monitores PAL y se proporciona un contacto para soporte. También se señala que los archivos de texto tienen codificación estándar MS-DOS.
