Diría que hacía un buen tiempo que no hablábamos de cacharritos por aquí fuera de los repasos a la revista Byte [consulta sus notas: no tanto, pero no somos lo que fuimos… la anterior entrada en enero, y antes de eso, en agosto del año pasado].
Uno es, mal que le pese [nota del editor: no le pesa], un adicto a los cacharritos que suponen maneras diferentes de interactuar con la tecnología. Y últimamente han caído en el escritorio de obm un par de ellos…
Comencemos por la Tourbox Lite, que llegó antes (y no fui yo, señoría: ¡soy inocente!). La excusa (como si nos hiciese falta) es que muchos programitas de edición audiovisual ganan si les aparecen rueditas y otros botones para que podamos usar la «memoria muscular» y trabajar algo más deprisa. (En mi caso, el software es Adobe Audition, que para algo tengo un podcast.)
Y, sin alargarnos mucho, la cosa funciona. Tener unos pocos botones a los que les puedes asignar las funcionalidades más habituales, y poder usar las rueditas para cosas como zooms o los «sliders» del programa de turno, hace las cosas un poco más eficientes. Supongo que solo se justifica el gasto si haces un uso intenso de ese tipo de software, pero como a mí me salió gratis… 😅
En la foto podéis ver que el cacharro está conectado por cable, pero hay versión Bluetooth para los alérgicos a los cables. Y si echáis en falta más botones, tenéis la Turbox Elite, e incluso la Elite Plus (a mí me vienen grandes, claramente).
Y por el otro lado, el touchpad. Uno ha sido siempre de ratón, pero tenía una cierta envidia del touchpad que vende Apple para sus ordenadores… pero no la suficiente como para dejarse los 139 eurazos que cuesta. En algún momento busqué alternativas, pero lo que había en el mercado era bastante cutre (o me lo parecía a mí, como mínimo). Para mi sorpresa, hace unas semanas vi que Amazon tenía uno en su línea Basics y los menos de treinta euros del precio acabaron con mi ya de por sí no muy rígida resistencia. Y, oiga, pues será de la línea Basics, pero a mí me parece que el producto es más que decente. Como podéis ver en la foto, es enorme (6,4″ de diagonal). No podéis ver que el clic es físico, y no háptico, que es lo que se lleva ahora, pero a mí me sirve perfectamente. El soporte para los gestos «multidedo» es bueno y, a ese precio, no sé encontrarle problemas, la verdad. Podría usarlo más, ciertamente, pero, insisto, por apenas 30 euros…
Apa, eso es todo.
Bueno, no, falta una cosa: si seguís los enlaces a Amazon, sabed que son de su programa de «referrals»y que, en caso de compra, me llevaría una pequeña comisión.
Proseguimos con nuestro proyecto de leer la revista Byte, cuarenta años más tarde. El resto de entradas de la serie, como siempre, las encontrarás en la etiqueta Byte de obm. En enero habíamos hablado del Atari 520ST y este mes toca el hermano mayor, el 1040ST.
Destaco, en primer lugar, un megaanuncio de Microsoft publicitando sus lenguajes de programación.
Solo pongo la portada, porque se alarga hasta siete páginas más, que el catálogo de Redmond era extenso y su presupuesto para publicidad profundo. Sirve el anuncio, además, para ver cuáles eran los lenguajes que Microsoft consideraba importantes en la época. Arrancan con C («First with the pros«), Macro Assembler («The Quickest. Bar none«), FORTRAN («The overwhelming favorite«), COBOL («The interactive edge«), Pascal («When you’ve outgrown the others«) compartiendo página con QuickBASIC («BASIC just got faster«), que ilustraban, si no me equivoco, con una HP12, y cerraban con LISP («The language of artificial intelligence«), muMATH («Mainframe math on your PC«) y Sort («Versatility without compromise«), compartiendo página también.
¿Quién esperaba ver a FORTRAN y COBOL ahí arriba en 1986? Yo, no. Ni siquiera recordaba que Microsoft hubiese tenido un sistema de álgebra simbólica…
Y de la publicidad de lenguajes saltamos al programa que, en una realidad paralela a la nuestra, ocupa el lugar de Photoshop: el mítico Deluxe Paint (aquí, una carta de amor al Deluxe Paint III), que en aquella época no le sacaba los colores (see what I did there?) a los de Adobe… porque Photoshop 1.0 no llegaría al mercado hasta el muy lejano año de 1990.
Me paro un momento en la sección de libros para recordar al muy mítico (en aquella época) Peter Norton. Si tuviste un PC con MS-DOS, muy probablemente recuerdes sus míticas Norton Utilities (que ¡siguen existiendo!), pero a lo mejor no sabías que era un autor de «best sellers» sobre la programación del PC.
(Si tuviese más tiempo y dinero de los que tengo, seguramente haría por obtener una copia del Computer Law Annual 1985, porque por la crítica parece digno de leer con curiosidad histórica, con artículos sobre los problemas de propiedad intelectual de la ingeniería inversa, o la normativa antitrust, aunque también dicen que está escrito para juristas.)
No me alargaré mucho con el ordenador protagonista del número: a estas horas ya deberíais tener claro que el ST era mejor que el Mac (y del Windows de la época ya ni hablemos)… pero que estaba por debajo del Amiga (con la excepción de las aplicaciones musicales: ¿sabíais que Fatboy Slim sigue usando un ST?).
Los de mirada afilada habréis notado que en la portada, además del ST, había un segundo tema, el «homebound computing». ¿Que qué es eso? Nos lo cuenta el primer artículo del tema, que comienza recordándonos que el teletrabajo no lo inventó el COVID, y que ya se hablaba de ello hace cuarenta años, pero que anuncia que el tema se va a centrar en la informática como ayuda para las personas que, por el motivo que sea (una discapacidad, por ejemplo), no pueden desplazarse.
Me salto el artículo sobre síntesis de habla a partir de imágenes para pasar directamente al e-learning, que me toca la fibra especialmente.
Y es que en 1986, el año en que los módems de 2400 baudios nos parecían lo más, la educación a distancia ya no era necesariamente por correspondencia, gracias a la Electronic University Network de Telelearning. Hay más sobre el tema en Tedium.co y en eLearning Inside, pero el artículo nos explica que la cosa no era ni siquiera «lo último de lo último», porque se había fundado en el lejano 1983 y tenía programas de grado oficiales desde 1985, con 17 000 estudiantes matriculados hasta entonces. Eso sí, los materiales de aprendizaje no eran en línea: te enviaban el libro a casa. Tecnología necesaria: un IBM PC o PCjr, un Apple II o un (cómo no) Commodore 64 (el 35% de los matriculados no tenía ordenador al apuntarse). ¡Y había hasta mensajería instantánea!
Pasar a otro tema del que también, oh sorpresa, seguimos hablando hoy: envejecimiento y tecnología.
Que sí, que hace cuarenta años ya nos interesaba si las tecnologías digitales podrían ser una ayuda para una sociedad que envejecía cada vez más. Y a continuación viene el tema en que nos paramos cada vez en obm: ordenadores y discapacidad visual.
El primer párrafo se podría haber escrito hoy… Cuarenta años más tarde, las tecnologías son 10 000 veces mejores, pero los problemas, o son los mismos o hemos introducido barreras nuevas para compensar las que (afortunadamente) hemos tirado abajo.
Y una vez cerrada la sección, nos pasamos a la guerra que se mantenía entre los ordenadores con CPUs Motorola 68000: el Mac, el ST y el Amiga (en orden rigurosamente creciente). Bruce Webster, uno de los autores estrella de la revista, hacía una comparativa que se alargó tanto que en este número solo cabía la primera parte, cuya conclusión es que el Mac está más maduro (llevaba mucho más en el mercado9, el 520ST es una ganga y el Amiga se veía lastrado por los problemas de Commodore, pero era el que apuntaba más maneras…
En nuestra sección habitual, temas que ni por casualidad encontraríamos hoy en una revista de informática… ¡las ecuaciones diofánticas!
Me paro en la sección de BIX (ya recordaréis: el extracto en papel que hacía Byte de las conversaciones en su servicio en línea) para contemplar el nacimiento de IFF, el metaformato de archivos presentado por Electronic Arts que debería ser la base de cómo trabajamos hoy, y que permitía encapsular múltiples tipos de información (texto, gráficos y audio, para empezar) en un único archivo.
Y cierro con una curiosidad. A estas alturas deberíais estar tan enamorados y enamoradas de las ilustraciones de Byte como yo… y esto es tan claro que ya en aquella época la revista vendía ediciones limitadas de sus portadas:
Pero, como venimos haciendo últimamente, no nos iremos sin darle un repaso a los episodios del mes de Computer Chronicles…
El primero no es especialmente apasionante, y se dedicaba a las carreras profesionales en informática, incluyendo la emprendeduría… Una cosa a destacar es que no era totalmente necesario tener un grado en informática para encontrar trabajo en el campo: bastaba con unas cuantas asignaturas desde otros grados. Por cierto, que ya hablaban de la importancia de las competencias comunicativas… y ya se comentaba que las mujeres se iban a computer science y no a computer engineering. Tremendo, eso sí, en los breves del final del episodio, cómo AT&T presentaba un sistema de correo electrónico «de bajo coste»: ¡40 céntimos por enviar una página de texto! (Un sello costaba 22). Y con servicio de entrega en mano para personas sin correo electrónico por… ¡siete dólares y medio! ¡De la época! Todo ello mientras IBM presentaba un procesador experimental con 93 000 transistores (el procesador del iPhone 16 tiene… quince mil millones)
En el segundo episodio se hablaba de la computación en paralelo. Solo por ver un superordenador Cray de la época ya vale la pena darle al play. El H. T. Kung al que se entrevista a medio programa, por cierto, está a un grado de separación de Deep Blue, de unos de los primeros «gusanos» de internet, de la fundación de Y Combinator (una de las empresas de capital de riesgo más importantes del Silicon Valley)… y de las TPUs de Google. Se dice pronto. Y el Craig Mundie que sale justo después lideró la investigación y estrategia de Microsoft de 2006 a 2012.
Y para cerrar, dos episodios dedicados a los ordenadores y sus usos militares, otro tema del que seguimos hablando hoy. En esta primera parte se repasa la larga historia de esos usos militares, ya desde el ENIAC, y el enorme papel de DARPA en la investigación en el campo. No os perdáis las demostraciones de simuladores de vuelo de altísima tecnología que palidecen al compararlas con lo que podemos correr hoy en básicamente cualquier PC. Y la investigación en armas autónomas ya había comenzado, con el eventual premio Turing Raj Reddy.
Y en la segunda parte, sistemas informatizados en los barcos de la Armada de los Estados Unidos, capaces de disparar autónomamente (y el rechazo que provocaba la idea entre al menos parte de los militares de la época), o las «star wars» de Reagan… y menciones a coches autónomos.
Os diría que avanzaseis los deberes para anticipar el mes que viene… pero marzo fue el último mes de la temporada 85-86 del programa, y la siguiente temporada no llegaría hasta septiembre.
Y eso es todo por marzo… de 1986. El mes que viene, más.
Seguimos con el proyecto mensual de ojear la revista Byte… con cuarenta años de retraso (tenéis todas las entradas sobre el tema, que ya son unas cuantas, en la etiqueta Byte de este blog). Y febrero del 86 se dedicaba… al procesado de textos (que, spoiler, no es lo mismo que los procesadores de texto).
Y comenzamos mirando publicidad. El primer anuncio, diría yo, de un programita que seguimos usando cuarenta años más tarde: ¡Excel! Dice la Wikipedia que fue lanzado en septiembre del 85, y si vais a nuestra entrada del número de mayo del 85 (sí, llevamos ya un tiempín con esta historia de la revista Byte) encontraréis el anuncio de que lo iban a lanzar, y corregidme si me equivoco (ya podría ser, ya), pero no lo habíamos vuelto a ver por aquí.
Y si os ha llamado la atención el ratón monobotón, o el disquete de 3,5″… sí, Microsoft lanzó originalmente Excel solo para Mac.
No pongo captura, pero también merece la pena pararse en la sección de cartas (página 24 y siguientes), en que los lectores revisan el programa para calcular π (¡del número de mayo!) y explican lo lentísimo que es convergiendo (pero destacan que es muy legible y un buen ejemplo para aprender) y algunas correcciones al programa sobre la distribución normal (esta vez solo tenemos que retroceder hasta octubre). Bravo por los lectores atentos.
Seguimos, esta vez con nuestra manía de pararnos en cualquier cosa que tenga que ver con el Amiga. En este caso, se trata de una introducción al Kernel, el software de sistema contenido en su ROM, escrita nada más y nada menos que por su creador, el mítico (en círculos reducidos, cierto) RJ Mical. Si alguien quiere leer más sobre el tema, en el mismo Archive podéis encontrar su manual. #YaNoSeEscribeSoftwareAsí
Y unas páginas más adelante nos encontramos un anuncio del Amiga que es un homenaje (merecidísimo) a Denise, Paula y Agnus, los tres chips especializados en vídeo, audio y gestión de memoria, revolucionarios para la época, que eran una de las partes vitales para hacer del Amiga la maravilla multimedia que era.
Y dejamos el Amiga (hasta que nos den la más mínima oportunidad de recuperar el tema 😅) y entramos en el tema del número, el procesado de textos. Hablando con la leyenda de la informática que es Donald Knuth (se lee Kanuz, por cierto), hoy profesor emérito de Stanford, creador de TeX y autor de la magna opus The Art of Computer Programming (in progress). Por aquella época ya hacía más de una década que le habían dado el premio Turing y en la entrevista, como no podría ser de otra forma dado el tema, hablan de tipografía digital y de la creación de Metafont, un software que se sigue usando hoy y que continúa siendo una [no tan] pequeña maravilla.
Y, para hacer más énfasis en lo que decía de que procesado de texto no se refiere a los procesadores de texto (al menos, no a los que nos vienen más rápidamente a la cabeza), nos podemos dar un chapuzón en cómo estaba por aquel entonces el estado del arte de la interpretación del lenguaje natural:
(Como es costumbre de la casa, tanto Pollack como Waltz son no solo expertos, sino pioneros en la materia.)
Seguimos con el tema. Nos quejamos (con razón) de que artes y humanidades están excesivamente separadas en las cabezas de muchos, y de que esto es fuente de unos cuantos de nuestros problemas. En los ochenta ya era en gran parte así, no nos engañemos, pero de vez en cuando podíamos ver cosas como un artículo en una revista tecnológica dedicada al tema del procesado de… poesía.
No os perdáis, por favor, la discusión sobre cómo sacar la métrica de un poema automáticamente (en inglés, además, donde la cosa depende más de sílabas átonas y tónicas que en español):
Pero el colmo del friquismo, en serio, es un artículo entero dedicado a la sesudísima (solo hago un poco de broma, aquí) cuestión de si vale la pena aprender a teclear en un teclado Dvorak (#TLDR, los autores opinan que sí, si te puedes permitir el lujo de escribir siempre en un teclado Dvorak). Que el primer firmante de la pieza sea profesor emérito… de física, dedicado a la astronomía forense, es solo la guinda del pastel.
¿Había dicho yo que volveríamos al tema Amiga a la que nos dieran una oportunidad? Sí, ¿verdad? Aquí, los orígenes británicos de AmigaDOS:
Y aún una página más con contenido Amiga, aunque aquí no sea el contenido lo que quiero destacar, sino el continente. Estamos en 1986, y el mundo comienza a conectarse digitalmente. Byte, de hecho, tiene su propio servicio online, BIX (el Byte Information Exchange), que se había puesto en marcha en junio (a seis dólares de la época la hora de conexión)… pero la audiencia era tan corta (dice la Wikipedia que en el 87 llegaron a 17,000 usuarios) que la revista le daba bombo al servicio destacando un «Best of BIX» en sus páginas. Igual sí hemos cambiado un poco, en estos cuarenta años…
Antes de cerrar la sección, quiero aprovechar para recoger el obituario de Robert Tinney en Ars Technica. ¿Quién es Robert Tinney? El ilustrador de muchas de las portadas de los números de Byte que hemos recogido por aquí, que falleció este primero de febrero. Que su obituario aparezca en Ars da una idea tanto de la relevancia de la revista como del impacto visual del trabajo de Tinney en muchísima gente. Curiosamente, estamos muy cerca de llegar a los números en que la revista dejó de emplear a Tinney para pasar a usar fotos en sus portadas, como podéis comprobar en los archivos de la revista Byte en archive.org, que también podéis usar, si queréis, para avanzaros y comprobar de qué va el número «del mes que viene». Añado que Tinney tenía una tienda, todavía activa (y espero que lo siga estando mucho tiempo), y que ahora mismo estoy peleando muy fuerte conmigo mismo para no comprarme pósters del número de artes digitales de 1982, la de abril del 85, o la de «claves de la educación» de, nada más y nada menos que julio de 1980.
Y seguimos también con el repaso a los episodios de febrero del 86 de Computer Chronicles…
El primero de los episodios se dedica a operar en bolsa por ordenador, algo novedoso en la época. No me ha resultado especialmente interesante, más allá de los cacharritos para recibir información financiera vía radio FM, tanto en forma de cacharrito independiente como de accesorio para tu PC.
El segundo programa del mes va de «software psicológico», desde software para ayudar con determinadas terapias (con la sofisticación de la época, más cercana al programita con el que se juega para renovar el carnet de conducir) a tests de tipos diversos, con sus, inevitablemente, «módulos de inteligencia artificial»… y las mismas preocupaciones y las mismas salidas por la tangente que nos suenan tanto hoy.
(Y en los breves, noticias de la crisis de Commodore, que le debía doscientos millones de dólares a los bancos. La compañía no acabaría muriendo hasta el 94, pero ya comenzaba a oler a chamusquina la cosa.)
El tercer programa del mes se dedicaba al software para astronomía, tanto profesional como amateur (en este último caso, bastante reconocible para cualquiera que haya usado una app de astronomía únicamente… pero cuatro órdenes de magnitud menos potente e interfaces jurásicas). La discusión sobre astronomía «profesional»… lo de siempre: gente alucinando con lo que había avanzado la tecnología en el campo… que ahora nos parece casi de juguete.
(Y en los breves, la muerte de la mítica Osborne… cincuenta y tres millones de dólares de pérdidas de Commodore, por si los doscientos millones de deuda fuesen poca cosa… y la compra de Pixar por Steve Jobs por «varios millones de dólares».)
El 3×22, dedicado al color, lamentablemente, parece que está desaparecido. Como de costumbre, podéis chafardear lo que se viene en marzo tanto en la lista de episodios de la Wikipedia como en la playlist a la que pertenecen los vídeos de YouTube que tenéis aquí arriba.
Y con esto cerramos el mes. Dentro de unas semanas, más.
(Hoy toca batallita especialmente intrascendente, quedáis avisados.)
Dichoso primer ingeniero el que decidió que no tenía sentido poderle cambiar el disco a un portátil. Desde entonces, todos acabamos haciendo, tarde o temprano, encaje de bolillos. Porque, por enorme que te parezca un disco, dentro de dos años ya no va a ser enorme, y dentro de tres será demasiado pequeño. En Sandisk, que tienen vista, anuncian sus USB Extreme Fit (aquí la página) con esta imagen:
Vamos, el USB ideal para dejarlo conectado al portátil, y se acabó (durante una temporada) tener que, o bien preocuparse por el espacio en el portátil, o bien conectar y desconectar continuamente un «pen». Y para allá que me fui, a por mi USB de 512 gigas (ir por ir…). Y todo bien, hasta que lo he enchufado…
Mono, ¿eh? Ahora… ¿veis que deja un espacio tirando a justo para el puerto USB-C que queda justo al lado? Pues bien: para enchufar el portátil a los hubs que tenemos en la oficina, cuyos cables no son lo más ajustados del mundo, me he pasado un rato hasta que he encontrado uno que había perdido su carcasa, porque si no, no entraba de ninguna de las maneras:
Ni un milímetro de margen, oiga.
Hay cables USB-C que no dan ningún problema (el de mi «ladrón» USB, sin ir más lejos, afortunadamente). Pero. Antes de comprar un Sandisk Extreme Fit, si vuestro portátil tiene los puertos USB-C uno al lado del otro, echadle un vistazo al resto de cosas que queráis conectar antes de comprar.
Lo de siempre: seguimos con nuestro proyecto de leernos la revista Byte… con cuarenta años de retraso, y esta vez con un añadido final extra. El tema del mes… ¡la robótica! (Tema que vamos a ignorar bastante completamente, porque no me pone nada. Pero las portadas de Byte son un clásico, o sea que aquí va la del mes:
Comencemos, pues, por la editorial:
¿Creíais que Apple se quejaba solo de que Microsoft la copia? (Todo sea dicho: a lo largo de la historia Microsoft ha copiado cosas de Apple… y hasta hay casos en los que Apple ha copiado de Microsoft. Y donde dice Microsoft, puede decirse Google/Android.) Pues antes de quejarse de Microsoft y Windows, se quejaron de GEM, la capa gráfica de Digital Research para sistemas PC/MS-DOS (y no solo estos: volvemos sobre el tema más abajo). Respetando la propiedad intelectual de Apple (más que el editor de Byte, después de leerle), comparto con él que con estas cosas, entonces y ahora, el consumidor sale perdiendo bastante.
Seguimos con los «microbytes» la sección de noticias breves. En esta ocasión, por un lado, evolucionamos con algo que ya habíamos visto por aquí… a las pantallas planas LCD les llega el color:
Y por el otro (literalmente, hay que girar la página para llegar a ello), desmontamos un poco el mito de que Kodak murió por no innovar en fotografía digital:
…y es que pocas compañías investigaron e invirtieron en el campo de la fotografía digital como Kodak, que acumuló una inmensa bolsa de patentes sobre el tema. Lo que mató a Kodak (bastantes años después de 1986) fue, sobre todo, el miedo a canibalizar su mercado «químico».
Nos vamos, ahora, a la publicidad:
Sí, amigas, 1986 es el año de volar a 2400 baudios, no a los «viejos» 1200. Casi dos kilobits y medio, sí. ¿Recordáis la tortura que es tener cobertura «solo» 4G y descargar cosas a pocos megabits? (Pero no os emocionéis: no todas las líneas telefónicas de la época soportaban esa barbaridad de velocidad.)
Y seguimos mirando anuncios, con un momento histórico: ¡el primer anuncio que vemos de Windows!
No os pongo el publirreportaje entero (8 páginas tenía en total, que Microsoft ya tenía unos dineros en la época), pero sí os dejo aquí esta maravilla de gráficos:
¿Reconocéis vuestro Windows «de toda la vida»? Yo tampoco.
Hablábamos antes de GEM… y lo recuperamos aquí, porque en este número se analizaba el Atari ST, la tercera de las máquinas con procesador Motorola 68000, después del Macintosh y el Amiga (recordemos siempre: Amiga mejor que ST mejor que Mac). Y el sistema operativo del ST era, efectivamente, el GEM de Digital Research (bueno, GEM era, como con los PCs, la capa gráfica sobre TOS, el verdadero sistema operativo).
Y… ¿vamos a comparar GEM con Windows, tal y como lo presentaba la mismísima Microsoft en su campaña publicitaria?
(Eso sí: reconoceremos que el parecido con el sistema operativo de los Macintosh es más que notable. Es innegable.)
Seguimos con nuestra sección «esto no lo ponemos en una revista hoy, que nos lapidan» con un programa en BASIC para dibujar superficies 3D:
Ojo, que el programa tenía una cierta complejidad y hasta ocultaba las superficies ocultas:
(Si esto no os fuera suficiente, os podéis ir a la página 397 para ver cómo implementar el algoritmo de Euclides para calcular el máximo común divisor.)
He dicho que me iba a saltar la robótica, pero sí me quedo con uno de los artículos de la sección:
Y después de la visión venía una pieza dedicada a los sensores táctiles, otra sobre navegación autónoma y una sobre IA en visión por ordenador. De nuevo, uno no sabe si estamos en el 86 o en el 26 (y no se siente con ánimos de explicar a los autores que a la cosa aún le quedaban unas pocas décadas).
Y echamos una última mirada a la publi, y es que creo que no habíamos reflejado por aquí la maravillosa campaña «Charlot» de IBM:
Que no fue un único anuncio, os lo aseguro: años, duró la campaña, siempre visualmente maravillosa. Os dejo aquí un recopilatorio de anuncios televisivos.
Y nos vamos a ir con otro momento histórico:
Acorn RISC Machine… A, R, M. La arquitectura del chip de tu móvil. O de tu Mac, si tienes uno. Y ahí estáis, viendo, en riguroso directo, su nacimiento. Casi nada.
Y esto habría sido todo… pero el otro día me enteré de la muerte de Stewart Cheifet (hasta el New York Timesle dedicó un obituario). ¿Que quién es Stewart Cheifet? No me digáis que no habéis visto nunca su Computer Chronicles. Si Byte es, al menos para mí, uno de los recursos imprescindibles en formato prensa escrita para revisar la historia de la informática, Computer Chronicles es lo mismo, pero en formato vídeo. Los archivos del programa de la PBS, la tele pública de Estados Unidos (lamentablemente en peligro de muerte, gracias a la administración Trump y su alergia a la información de calidad), son un documento esencial si te interesa el periodo de 1983 a 2000. Y como homenaje, y como estas entradas sobre Byte <ironía>no son lo suficientemente largas</ironía>, he pensado que completarlas con el visionado de los programas correspondientes sería, cuando menos, un ejercicio curioso1. Y os dejo aquí los programas de enero del 86…
El 7 de enero el programa arrancaba con… ¡inteligencia artificial!
(¿No os ha encantado el anuncio del patrocinio de Byte? 😅)
No podemos dejar de comentar el copresentador del programa con Cheifet: nada más y nada menos que el malogrado Gary Kildall, creador de CP/M… y de GEM. Hay múltiples universos paralelos al nuestro en que amamos y odiamos a Kildall, CP/M y GEM y no recordamos quién era Bill Gates ni sabemos nada de un sistema operativo llamado Windows.
El Jerrold Kaplan que sale en la primera entrevista, por cierto, trabajaba por aquel entonces con Mitch Kapor, fundó en 1987 Go, dedicada a lo que luego se llamarían PDAs y luego fundaría el primer sitio web de subastas (cinco meses antes de eBay). Not bad. Y también podemos destacar la presencia del filósofo Hubert Dreyfus dudando fuertemente de la expertez de los sistemas expertos de la época :-).
Maravilloso también que los expertos apuntaban que 1986 podría ser el año del reconocimiento del habla 😅.
Después, el día 14, otro tema del que no se habla nada en la actualidad: seguridad informática.
…aunque en aquel momento esto se refería al uso de ordenadores para perseguir delitos, peleándose con catálogos de huellas digitales o usando sistemas de información geográficos, por ejemplo, pero también digitalizando procesos como en cualquier otra organización.
Os recomendaría, eso sí, saltar al minuto 27:30 del vídeo, en el que Cheifet habla de los gráficos de la peli El Secreto de la Pirámide… creados por un «nuevo ordenador gráfico, creado por Industrial Light & Magic, una división de LucasFilm. El ordenador se llama… «Pixar».
Apa, el mes que viene más (ya decidiremos si solo con Byte o con el añadido de Computer Chronicles).
Un ejercicio curioso que, inevitablemente, no se me ha ocurrido solo a mí: veo que alguien ha montado un computerchronicles.blog y que ya lleva nada menos que los primeros 133 programas revisitados. ↩︎
![The Atari 1040ST
A megabyte of memory for $999
Editor's note: The following is a BYTE product preview. \t is not a review. We provide an advance look at this product because we feel that it is significant. A complete review will follow in a subsequent issue.
Atari's new $999 1-megabyte 1040ST (see photo 1) establishes a price break reminiscent of the Commodore 64's. And, as table 1 shows, the 1040ST will be the first computer to begin its retail life at a price that represents less than one dollar per kilobyte. The 1040ST is clearly a bargain, with over 1 megabyte of RAM (random-access read/write memory), its operating system in ROM (read-only memory), an internal 720Kbyte double-sided drive, an internal power supply, and the same features and functionality that already make the Atari 520ST an attractive purchase. (Editor's note: See "The Atari 520ST" by }on R. Edwards, Phillip Robinson, and Brenda McLaughlin. January BYTE, page 84. |
System Description
Our coverage of the 520ST adequately describes most of the features of the 1040ST (see also the "In Brief" box on page 86). The new computer has the same keyboard, the same ports (although these are now in new locations, see photo 2), and the same architecture. We remain uncomfortable with the keyboard, but the keytops are removable. We suspect that some speedy entrepreneur will provide alternative tapered keys for the ST machines.
The most obvious changes are cosmetic: The keyboard/computer unit is 2 inches deeper and 4'/2 pounds heavier than the 520ST and the keyboard provides a much more substantial feel. The mouse/joystick ports are now located under the bottom right front of the unit, a significant improvement for left-handed users.
A number of changes are more than cosmetic. The internal power supply eliminates two of the external power supplies needed by the 520ST (wire haters rejoice). We left the unit on for five days and experienced no difficulties with overheating. There is no internal fan, but the unit appears to adequately dissipate heat. The internal disk drive supports both single and double-sided disks. An RF (radio frequency) modulator will allow you to hook up the 1040ST to a television set; you might, therefore, obtain the high-resolution monochrome system for word processing and programming without sacrificing the use of low- and medium-resolution color. However, we received a preproduction unit lacking the RF modulator that will accompany the final product; therefore, we were unable to test the television quality of the computer's output.
The megabyte of RAM in the 1040ST isn't crammed into the case. The 520ST uses a custom Memory Controller chip to handle its sixteen 2 56K-byte dynamic RAM chips. The 1040ST uses the same Memory Controller. Because the controller can handle 32 RAM chips at a time, the Atari engineers simply had to find room for 16 more 2 56K-byte dynamic RAMs on the 1040ST circuit board to pump RAM capacity to a full megabyte (see photo 3). In fact, the Memory Controller can also govern 1 -megabit dynamic RAM chips. Atari should have little difficulty designing an ST with 4 megabytes of memory. Undoubtedly, the most interesting addition to this computer, apart from the extra memory, will be an empty socket for a graphics coprocessor. Our preproduction unit also did not include the socket, and it may not be offered with the first releases of the 1040ST Phil Robinson discussed this and Atari's future plans with Shiraz Shivji, vice president of research and development for the company (see the text box "An Interview with Shiraz Shivji" on page 90).
TOS IN ROM
With TOS (the operating system for both the 520ST and the 1040ST) in ROM, the 1040ST boots more quickly than the 520ST. [Editors note: Atari is currently supplying the ROM chips to 520ST developers and will be making the chips available through users groups.] Booting with a nonsystem disk takes less than 6 seconds, down from 37...](https://i0.wp.com/obm.corcoles.net/wp-content/uploads/2026/02/image-4.png?resize=840%2C583&ssl=1)
![Diophantine Equations
A man buys some x's at $154 each and some y's at $69 each. If he spends a total of $5000, how many of each did he buy?
Although this problem appears to be from a first-year algebra text, we find that the techniques required are not usually found in a "mainstream" course in mathematics. The equation 1 54x + 69y = 5000 has infinitely many solutions. However, assuming the man bought whole-number quantities, we want integral solutions [x,y] for the equation, and now we need a method for solving such equations.
Diophantine Equations
Equations of the form ax + by = c, for integral a, b. and c and integral solutions (x.y). are called Diophantine equations. No one is certain when or where Diophantus of Alexandria was born. Sources vary from "born about A.D. 50" to "flourished about A.D. 2 50." He is called "the father of algebra," having promoted algebraic notation and algebraic treatment of mathematical problems. Previously, such work was done by "rhetorical algebra" or geometric proofs.
A variety of methods are available for solving Diophantine equations. One of these is modulo arithmetic, a powerful and fascinating concept that 1 may explore more closely in a future column.
A very simple method of solving our original problem comes to mind. Since the equation is equivalent to y = (50001 54x)/69, we can simply try consecutive values of x (from 1 to 32 only) until we get an integral value for y.
Since we are mathematically inclined, such an inelegant approach may not sit well with us. Rather, we may prefer to look for a method of solution based on general principles of mathematics. What can we say in general about integral solutions for an equation of the form ax + by = c?
First, we can readily see under what conditions the equation would have no solution. Consider the greatest common denominator (GCD) of a and b. We will call it d. If d is not a factor of c, the equation will have no integral solutions. Why? Since aid is, by hypothesis, an integer and bid is also one, the value (ald)x + (bld)y will be an integer if x and y are integers. That is, the integers are closed under addition and multiplication. Thus, if eld is not an integer, either x or y must not be an integer.
Diophantus Meets Euclid
This leads us to Euclid's algorithm, which was the subject of my last column in January (page 397). If we employ Euclid's algorithm to determine the GCD of a and b, we can immediately determine whether there are integer solutions to the Diophantine equation by dividing the GCD into c. But we can use Euclid's algorithm for much more than that. To see how, let us reexamine the algorithm with an eye toward solving Diophantine equations. Figure 1 outlines the way the Euclidean algorithm finds the GCD of 1 54 and 69. Their GCD is 1, meaning that the two numbers are relatively prime. Now, to begin our examination of the way to solve Diophantine equations, let's modify our original equation to 154x' + 69y' = 1. That is, we will begin with the case where c is equal to the GCD.
In figure 2, I have rewritten the divisions of figure 1 as equations. In order to find integer values of x' and y' that solve the equation 154x' + 69y' = 1, all 1 need to do is substitute 154-2(69) for 16 in equations 2 and 3 and 69-4(154-2(69)) for 5 in equation 3. After collecting terms, I find that 1 = 13(154)-29(69). Thus, x = 13, y — 29 will satisfy the equation 154x' + 69y' = 1. We will call (13,-29) the basic solution to 154x' + 69y' = 1. Is it the only solution?
Let us write our equation in the general form again: ax + by = c. Now, let n be any integer and d be the GCD of a and b. If we add to the left-hand side of the equation, we haven't changed it...](https://i0.wp.com/obm.corcoles.net/wp-content/uploads/2026/02/image-13.png?resize=729%2C1024&ssl=1)
![IFF Graphics Protocol
amiga/softw.devlpmt #157, from gregr [Gregg Riker, Electronic Arts]
TITLE: IFF (Information Format Files) Is Available!
I mentioned that I used IFF files with the SlideShow. Allow me to elaborate.
Electronic Arts has a general interest in promoting standards, so we knocked heads with some people at Commodore-Amiga and came up with IFF.
IFF is intended to be used by any and all interested developers. It offers a convenient way of allowing programs to exchange data with one another.
For example, Graphicraft will be able to exchange files with Deluxe Paint and other EA products. The design is extensible, in that you may add your own types to the standard. There are programs available in C (public domain!) that will read and write graphic images in IFF format.
If you're interested in a copy of the spec, please contact Rob Peck at Commodore-Amiga. He can supply you with a copy. If you have any problems or need more information, please contact Jerry Morrison at Electronic Arts, (415) 571-7171.
P.S.: IFF covers graphics, audio, and text and is expandable!](https://i0.wp.com/obm.corcoles.net/wp-content/uploads/2026/02/image-14.png?resize=726%2C1024&ssl=1)
![COMPUTER SCIENCE CONSIDERATIONS
CONDUCTED BY G. MICHAEL VOSE AND GREGG WILLIAMS
Donald Knuth speaks on his involvement with digital typography
Text processing as a computer science problem has consumed a major portion of the time and energy of Stanford professor Donald Knuth over the past eight years. Knuth authored and placed into the public domain a highly regarded typography system that he calls TeX {pronounced "tech"), along with a font creation language called METAFONT. \n conjunction with the completion of T^X, Knuth and Addison-Wesley are publishing a five-volume work entitled Computers and Typesetting. Volume I is The TeXbook, volume 2 is the source code for TeX, volume 3 is The METAFONT Book, volume 4 is the METAFONT source code, and volume 5 is Computer Modern Typefaces.
To discover what so intrigued Knuth about this subject. BYTE senior editors Gregg Williams and Mike Vose conducted the following interview with Professor Knuth at Addison-VJesley's offices in Reading, Massachusetts, on November II, 1985.
BYTE: Dr. Knuth. how did you become involved with digital typography and the publicdomain system known as Tj:X? Knuth: I got interested because I had written books and seen galley proofs, and suddenly computers were getting into the field of typesetting and the quality was going down.
Then I was working on a committee at Stanford planning an exam, and we got a hold of some drafts of Patrick Winston's book on artificial intelligence. We were looking at it to see if we should put it on the reading list for a comprehensive exam. It had just been brought in from Los Angeles where it had been done on a digital phototypesetter. This was the first time that I had ever seen digital type at high resolution. We had a cheap digital machine at Stanford that we thought of as a new toy. But never would I have associated it with printing a book that I'd be proud to own. Then I saw this type, and it looked as good as any I had ever seen done with metal. I knew that it was done just with zeroes and ones. I knew that it was bits. I could never, in my mind, ever, conceive of doing anything with lenses or with lead, metallurgy, and things like that. But zeroes and ones was different. I felt that I understood zeroes and ones as well as anybody! All it involved was getting the right zeroes and ones in place and I would have a machine that would do the books and solve all the quality problems. And, also, I could do it once and for all. I still had a few more volumes to write [of his seminal work. The Art of Computer Programming, a seven-volume series of which three volumes are finished] and](https://i0.wp.com/obm.corcoles.net/wp-content/uploads/2026/01/image-23.png?resize=749%2C1024&ssl=1)
![Machine Reading of Metric Verse
by Paul Holzer
A computer can definitively scan a line of poetry for its stress pattern principally in one of two ways: (I) an algorithm can deduce the syllabic structure and the stressed syllables from analysis of the letters that make up the word, or (2) the computer can look up every word in a dictionary database that holds the syllabification and accentuation of every word. The lookup method requires a large database, and the algorithmic approach is complex and requires a deep analysis of English phonetics and spelling.
One of the features of a poetry processor is that the poet-user can specify the meter of every line of a poem (see photo A). For example, the string .-/.-/.-/.-/.-/ represents iambic pentameter. Dots (.) indicate an unstressed syllable and dashes (-) represent a stressed one. The slash (/) indicates the end of a foot, the basic metric unit. The first line of Shakespeare's Sonnet 18
shall I comPARE thee TO a SUMmer's DAY?
is an example of a line of iambic pentameter. The stressed syllables are in uppercase.
After writing a poem, users might request a metric scan of the poem. I will describe here a method fordoing this that is not based on one of the two general solutions I mentioned in the first paragraph. Instead, the processor will break each word into its syllables and then redisplay each line, with each syllable in uppercase or lowercase according to the position of the dots and dashes in a user-specified metric form. So. were Shakespeare trying to compose trochaic pentameter, with the metric pattern -./-./-./-./-./. the processor would reply with
SHALL i COMpare THEE to A sumMER'S day?
He would read this to himself, trying to put the stress on the uppercase syllables. Noting the rhythmic clumsiness, he might rewrite his line as follows:
To a summer's day I shall compare thee
and the processor would respond:
TO a SUMmer's DAY i SHALL comPARE thee.
Sounds better!
The main task for the computer is to break each word into its syllables. The algorithm is based on a systematic application of what appear to be the general rules by which English words break into syllables. Of course, there are no fixed rules, as evidenced by the fact that different dictionaries give different syllabifications for the same word.
The following is a simple version of the algorithm:
1. Break the word up into a sequence of alternating vowel and consonant groupings. Thus microcomputer becomes micro computer. Wherever there is a vowel or group of contiguous vowels, there will be a syllable. We need only assign the neighboring consonants to the syllable on the right or to the syllable on the left.
2. If the first vowel group has a consonant group to its left, then assimilate this consonant group to the vowel group. This leads, in our example, to microcomputer.
3. If the final vowel group has a consonant group to its right, then assimilate this consonant group to the vowel group. We now get microcomput er.
4. For the remaining unassigned consonants, do the following:
. a. If the consonant stands alone, attach it to the following vowel. Thus we get mi cr ocompu ter.
b. If there are two consonants, split them. We get mic ro com pu ter.
c. If there are three consonants, then i. If there is a doubled consonant, split the pair; thus apply becomes a ppl y and finally ap ply.
ii. If there is no doubled consonant, but the first of the three consonants is n, r, or [, then split between the second and third consonants.
iii. In all other cases, split between the first and second consonants.
Before applying this algorithm, however, we must preprocess the initial string of letters in order to take into account certain peculiarities of English orthography:
1. Final e is silent (with certain exceptions); treat it as a special consonant. Thus compute becomes compu te, then compute, and finally compute.
2. Translate many two-letter sequences into special single consonants, e.g.. sh, th, gu, qu. and ck.
3. Identify common suffixes. For example, the algorithm applied to blameless would yield blameless and then bla me less. However, when less is removed as a suffix, then the e in blame to thinking of the program as something for me to use— the relational table of contents was so the user could access my work. The program was originally to have been just a floppy solution to my table-of-contents dilemma. But you don't get that involved in a software application without elaborating and generalizing. In that way software is very much like'
poetic forms. You use it for the sake of using it. It generates its own kind of trance. Poetry and programming, once you look at them in context were just made for each other.
Marriages like this one, made in heaven, often are so because they are marriages of convenience. One of the impediments to formal verse writing is the inconvenience of having to
make repeated book accesses for rhymes, just when the form has prompted some involvement. You stop and look and lose something. That's one reason people have tried to do without forms. But that's throwing out the baby with the bathwater. You don't stop measuring and sounding things out, and you don't abandon would be recognized as silent, yielding blame less.
4. Identify some prefixes. For example, if en is recognized as a prefix, then enact becomes en act, rather than e nact.
It seems to be impossible to come up with a reasonably small set of rules and preprocessing steps to guarantee correct syllabification of all words. Two examples will illustrate some of the inherent difficulties:
1. Compound words: The algorithm will not detect the silent e in snake within the compound word snakebite unless the fragment bite is recognized as a word or treated as a suffix. Avoiding the problem would require either extensive word or prefix table lookups.
2. Successive vowels in different syllables: In reach, the ea is a single vowel sound, and the algorithm would treat it correctly. In react, we pronounce the e and a separately and the correct syllabification is react. Were the algorithm modified to isolate re as a prefix, it would treat react correctly, but turn reach into re ach.
Where ambiguities can arise, the best approach is to formulate a rule that leads to the smallest number of cases requiring table lookups for resolution. The present algorithm is not perfect, but it produces a readable, if not dictionary-perfect, syllabified word 95 percent of the time.
I have provided a Pascal program that implements the syllabification algorithm and illustrates how The Poetry Processor "reads" a user's poem according to a user-specified metric scheme. Editor's note: The Microsoft Pascal source code and executable version are available from BYTEnet Listings, telephone (617) 861-9764. as SCANPOEM.PAS and SCANPOEM.EXE. The executable version requires any MS-DOS or PC-DOS machine] To run the program, prepare two files. TESTPOE must contain the lines of poetry. You can write TEST.POE as a text file with each line of the poem on a separate line. A second text file. TESTFRM. should have a line containing a string of dots (.) and dashes (-) indicating the accentual scheme that each line of poetry is supposed to follow. Slashes indicating the end of a foot are optional.
As an example, a Shakespearean sonnet (iambic pentameter) will have a TESTFRM file consisting of 14 lines of .-/.-/.-/.-/.-/. Each line in TESTFRM must end with an asterisk. After editing the TESTFRM and TESTPOE files, you can run the program by entering its name, SCANPOEM. The computer will "read" the poem, printing in uppercase the appropriately stressed syllables.
Note that the program is a prototype version of the algorithm. It will not handle text with capital letters, apostrophes, or punctuation, so be careful not to include these features in TEST.POE. When using this demonstration program, you will undoubtedly find that some words are not properly syllabified.](https://i0.wp.com/obm.corcoles.net/wp-content/uploads/2026/01/image-25.png?resize=840%2C430&ssl=1)
![Best of BIX
AMIGA
Commodore's introduction of the Amiga has produced a flurry of activity among professional developers and personal computer users within the Amiga conference. The summary this month includes discussion on cables, monitors, printers, and software fixes. One of the hottest topics in the Amiga conference is on the subject of improving the performance of the Amiga by removing the 68000 and replacing it with a 68010 or 68020.
68010/68020 Upgrade
amiga/amiga68000 #22
An Amiga conference member asked if he could just drop a 68010 into the 68000 socket. This would give a 10 to 80 percent boost in performance! He had one, just sitting up to its bottom in black foam, on the shelf. But there were all these warnings about what would happen to his warranty if he opened the case.
amiga/amiga68000 #26, from rickross [Richard Ross, Eidetic Imaging]
M68010 works! A 68010 plugs directly into the Amiga and no problems were detected in the operation of the system software. Also, for everyone like me who has been trying to judge from the BYTE review photos, the microprocessor is socketed. The performance increase gained by the switch is not phenomenal, and no benchmarks are available, but it did run perceptibly faster. The M68020 has also been tried and seems to work as well.
amiga/amiga68000 #32
A BIX user provides the following:
The company that markets the 68020 piggyback board is Computer System Associates Inc., 7564 Trade St., San Diego, CA 92121, (619) 566-3911. The prices are:
Board only $ 575
Board plus 68020 975
Board plus 68020 and 68881 1480
For more information, contact Patricia Chouinard at the address above. I believe that 68000/68010 supervisor code that handles exceptions and certain other privileged functions will have to be modified. User code should work as is.
amiga/tech.talk #39
An Amiga owner describes his adventure in opening his computer and replacing the CPU:
You just got your Amiga and it's already the slow boy on the block, right? You can plug a 68010 into an Amiga (there goes my warranty) and it does go faster My Sieve benchmark is down to 5.8 seconds from 6.1.
Note: Your warranty will most likely be dead after you do this. Also, there is a lot of RFI shielding inside the Amiga. You get to undo a lot of screws, bend a couple of tabs, and pray a lot. If you aren't a tech type, don't even think about doing this yourself. The 68000 is socketed, but it is partially under the micro-disk drive, so you have to lift it from one end and kind of levitate out the other end (use of your CHI helps). Also, you only take out the screws in the deep wells on the bottom (five in all). Then there are four places where the top grabs the base at the four corners (there were already marks on mine from where it was put together, I guess). Once you have the top off there is a big surprise waiting for you... Another big surprise is that big RFI shield. Yes, it is a $#%+& to get off! There are screws on three sides and two tabs of metal to untwist. Once the shielding is out of the way, your first sight is of the WCS [writable control store] daughterboard. The custom chips and two parallel I/O chips are made with MOS technology.
The CPU is made by Motorola. The main board looks pretty much like the BYTE review photos. The boot ROMs are 27256s! This gives a 32K-byte by 16- bit boot ROM! What are you guys hiding in there? I could put a BASIC interpreter in that much space!
If you attempt to change your CPU, don't blame me if you muff it! If you don't know about how to make yourself static-free, you could really buy yourself some trouble of the worst kind.
Compatibility: I've run all of the Workbench demos. Everything seems fine, but I'm not making any promises. . .
amiga/tech.talk #41
The adventurous Amiga owner says that yes, his Amiga boots up, squeaks and everything! All the software he has runs and works great. The only potential problem at this point is how many times the MOVE SR.dest op code is used. This is the only active op-code difference. There is a whole host of new goodies, though, some that make a . desire for an MC68881 easier to satisfy.
amiga/tech.talk #43: a comment to 39
Another BIX subscriber replied that the upgrade produced only a 5 percent increase in throughput. Perhaps fortunate, because the descriptions of the hardware here have indicated that bus bandwidth consumption by the 68000 is low enough to allow other custom DMA chips to steal enough cycles to get their work done. It would appear that inserting a 68020 in the socket would require faster bimmers, etc.
amiga/tech.talk #44: a comment to 43
Wouldn't think just putting in a 68020 would affect DMA. Same clock speed. Or does the '20 do something different cycle-wise?
amiga/tech.talk #45: a comment to 44
The author of message 43 replied that the 68020 at the same clock speed will finish an instruction or series of instructions internal to the CPU in less time and start requesting the bus for some ROM or RAM access. He assumed that the DMA chips hold a higher bus priority, so the result will be that the 68020 will often be sitting there in idle awaiting the BUSACK signal. Waste of a 68020. Perhaps that explains why there is only a 5 percent 68010 edge over the 68000.
amiga/tech.talk #46: a comment to 45
Somebody said that the 68000 only uses every other clock cycle (for memory access, that is). The DMA hardware is fast enough to do four accesses during every clock cycle. Most of the DMA accesses the bus during periods when the 68000 doesn't. If the 68020 doesn't have these quiet periods then there could be problems.
amiga/tech.talk #47: a comment to 46
Actually, there is a counterargument to that, which is that the 68020, but not the 68010, has an instruction-only cache, which would mean...](https://i0.wp.com/obm.corcoles.net/wp-content/uploads/2026/01/image-28.png?resize=774%2C1024&ssl=1)
![A Threat to Future Software
Last October Digital Research Inc. yielded to pressure from Apple and agreed to change its GEM software to decrease its resemblance to Apple Macintosh software. (GEM is an operating environment for several MS-DOS- and PC-DOS-based computers that allows a user to interact with a computer via windows and icons rather than the usual text-only commands.) Let's ignore, for the moment, the uncertain worth of a "visual copyright" (the legal term for Apple's copyrighting of the overall "look" of Macintosh software). Let's also ignore the ethics of Apple's actions. The point to focus on, instead, is that Apple's actions are to no one's benefit: Both the microcomputer industry and Apple itself will suffer from their effects.
Apple's actions will slow the growth of the microcomputer industry, which will hurt Apple by shrinking the potential microcomputer audience. Already, several small companies are worried that some project they're working on (and, often, they with it) will be cut down because it is "too Mac-like." In addition, the success of Apple's tactics may encourage other companies to try similar actions, thus increasing the paralysis and anxiety in the industry.
These actions will stifle the incremental evolution that is at the root of any significant growth in our industry. By "incremental evolution" I mean the process of gradual improvement of a product type that eventually leads to a more robust, useful product. For example, Ashtonlate's Framework did not spring full-blown from the heads of the programming team at Forefront. It had its roots in Dan Bricklin's and Bob Franston's VisiCalc spreadsheet, Sorcim's Supercalc (which added functions and sold to a market not supported by VisiCalc), Mitch Kapor's VisiPlot (which gave the distinctive highlighted menu bar now used in so many programs), the software integration of Lotus 1-2-3, and the icons, windows, and pulldown menus of— well, you get the point. If companies are afraid to go to market with what they think are incremental— but distinct— improvements on a basic design, we will become a stagnant industry bounded by the usual and comfortable.
According to Irving Rappaport. Apple's associate general counsel, Apple's intent is to prevent other companies from creating products that are easy to use because of their similarity to the Macintosh. "If people look at it and say, 'Gee. that's like the Mac— I can operate that,' when that's the result you get, it's over the line" of infringement of Apple's copyrights. The effect of this intent is to fragment the industry in the face of what was becoming a de facto standard for human-computer interaction. This lack of standardization will cause many people to stay uninterested in computers because they will have to relearn basic skills with each brand of computer they encounter. (Imagine how many people would drive cars if car manufacturers used different controls for every function in the car.)
Apple might argue that, by claiming a larger slice of a smaller pie, it will still come out ahead. We believe that it will be hurt directly by its actions and will end up with a smaller piece of a pie that is itself smaller. Apple will, in effect, build a wall around its ghetto of Macintosh products, thus limiting its own growth and encouraging people to "live" elsewhere.
Texas Instruments' TI-99/4A provides a good example. TI announced that it intended to directly profit from all software written for its machine by forcing third-party software developers to publish their products through TI. When a brave few brought out 99/4 cartridges on their own. TI added a proprietary chip to their cartridges that the computer required before it would run the enclosed software. Needless to say, the few developers working on 99/4 software wisely turned to support other computers.
The same may happen to Apple. IBM already sells over half the business computers bought today, and IBM PC-compatibles account for a fairly large slice of what's left. If Apple has been slowing the erosion of its market share to IBM with the Macintosh line (and I think it has), its current moves will alienate software and hardware developers, who will begin to lavish their creativity upon the more congenial IBM PC-compatible marketplace. And where innovation goes, the market will follow.
Consider: IBM made its software and hardware architectures open. It allowed the development of innumerable hardware clones, many far more similar to IBM products than GEM is to the Macintosh desktop; consequently, the IBM PC-compatible market far outdistanced its combined competitors in less than two years. On the other hand, Apple is actively discouraging not only copying but also borrowing from its software design. It claims the sole right to benefit from a set of ideas that Apple itself has borrowed and improved on (the most direct borrowing was from work done at Xerox PARC). Given these two opposing directions, what do you think will happen?
A Call to Action
We at BYTE call on Apple to recognize the long-term implications of its actions and limit itself to prosecuting cases where the alleged theft is not of "looks" but of actual program code. Barring that, we call on Apple to license its allegedly copyrightable interface to markets that do not directly compete with its current or planned product line— if the licensing fees are reasonable, everyone will profit.
If neither of these things happen, we call on the judicial system to hand down rulings that reflect a strict interpretation of the visual copyright laws— that is. that a product is at fault only if it shows no distinguishing characteristics in appearance or operation from the alleged original; this would protect products that show incremental evolution. We also call on the industry to do two things. The first is to stand up to Apple and see the case decided on its legal merits. The second is to develop an alternative graphic interface and allow its wide adoption throughout the non-Apple computer community; in this way. the rest of us can get on with the business of making computers— in general— good enough that everyone will want to use them.
[Editor's note: Apple maintains that the agreement covers "only three specific products," but one of them is GEM Desktop, which defines the overall GEM environment. Also, according to Kathleen Dixon of Apple, the agreement includes any custom work DRI has done, including the modified GEM software that Atari uses in its 520ST computer] ■ —Gregg Williams, Senior Technical Editor](https://i0.wp.com/obm.corcoles.net/wp-content/uploads/2026/01/image.png?resize=715%2C1024&ssl=1)
