Etiqueta: Byte

#breBytes La familia Motorola 68000

La vida de la familia 68000 de Motorola fue breve (dejó de fabricarse en 1996), pero intensa, siendo el procesador de nuestro adorado Amiga y del Atari ST, pero sobre todo la primera arquitectura sobre la que se construyeron los Macs (y el Lisa antes de eso). Apple se pasó a los PowerPC en 1994, y eso acabó con los 68k. Pero hace 40 años, en septiembre de 1986, la familia 68000 prometía muchísimo: lo suficiente como para ser portada de Byte.

Portada de la revista Byte de septiembre de 1986, dedicada a la familia 68000 de procesadores. Ilustran la portada algunos chips de la familia y pequeñas fotos de un Mac, un Atari ST y un Amiga 1000.

La revista le dedica un buen espacio a las diferentes máquinas 68000 (incluyendo un apartado dedicado a Unix), pero nosotros ya sabemos cuál era la mejor. Y es que, ¿qué otra máquina podía producir gráficos así?

Anuncio a página completa del Commodore Amiga, con una imagen a todo color de una ilustración de la imagen clásica del emperador egipcio Tutankamón.

Y claro, lo que más nos interesa de la sección es esta comparación entre el Amiga y el Mac, aunque está hecha desde el punto de vista del programador:

AMIGA VS. MACINTOSH by Adam Brooks Webber A programmer's comparison of the system calls on two 68000~based machines I HELPED IMPLEMENT the True BASIC language system on the Macintosh. The project has been completed for some time now and we've all recovered our perspective and good humor, but at the time I felt that if I saw that smiling "Welcome to Macintosh" message one more time I would scream. It was in this frame of mind, on my way to see the Amiga for the first time, that I wrote out a list entitled "Why I Hate the Macintosh." That incident led to this article. I have now completed the same project on the Amiga and have many gripes about that machine, too. In this article I compare the system software, of the two machines. Implementing a language system is a good way to get to know a machine. True BASIC is not just a compiler and interpreter, it's a screen editor, a graphics program, and a number cruncher. It makes sounds, it prints, it manipulates files— in short, it uses most of a system's software. My comparison of the Macintosh and the Am\ga is necessarily limited, but I have tried to choose areas that are of general interest and that are representative of the differences between the two machines. These are the user interface, graphics primitives, printers and other devices, multitasking, and memory management. The User Interface The user interface of a system is usually examined from the user's point of view. You ask, "Is it intuitive? Is it powerful? Is it forgiving of error?" as you consider how to communicate with a program. I am interested in another point of view: What does a program have to do to communicate with the user? For some machines, communicating with the user means reading characters from the keyboard and writing text to the screen. Adding windows, menus, and mouse operations makes things more complicated, lust how complicated is shown by the Macintosh user interface software, which determines the structure of every Mac program more or less completely. The program must have a main loop that is executed as often as possible, usually 60 times a second. (One rule of thumb: The quality of system software is inversely proportional to the number of things a program must do "as often as possible.") The main loop checks for events like keystrokes, mouse clicks, and disk insertions and responds to them. Responding to an event is usually a lot of work because the Mac's user interface software provides little assistance. Figure 1 shows, in pseudocode, a simple example of what a program must do to allow a window with a scroll bar to change in size— something that most Mac programs have to deal with. The system software does offer significant help in two areas of user interface: text editing and file access. TextEdit is a subsystem that provides a mechanism for displaying and editing text in a window. (True BASIC doesn't use TextEdit, but only because we have our own internal string-handling procedures.) For...

Nótese, por cierto, que el artículo está escrito por un graduado del Dartmouth College, el lugar de nacimiento de BASIC. La comparación, por cierto, es favorable al Amiga en cuanto a la programación de la interfaz, gestión de dispositivos, multitarea (no es una sorpresa enorme, teniendo en cuenta que el Mac no era multitarea en 1986) y gestión de memoria, y al Mac en lo que se refiere a primitivas gráficas. Pero esto no le salvaría la vida al Amiga, lamentablemente.

Un poco más adelante, en su Chaos Manor Jerry Pournelle seguía enamorado del Amiga y nos hablaba de ese clásico que fue Deluxe Paint (con el que se hizo el Tutankamón de aquí arriba, si no me equivoco, y que ocuparía el lugar en el imaginario que le dedicamos a Photoshop si viviésemos en la línea temporal correcta), pero ya veía los primeros pasos de la muerte de Commodore…

Amiga My top pick of Spring COMDEX was the Amiga. The Amiga did have some problems. For instance, when Ken Sheldon and l approached the Atari booth, they practically ran out to grab us; I stood in the Amiga booth for 15 minutes before anyone spoke to me. Atari software was demonstrated by hackers; most of the Amiga software was demonstrated by clerical employees from Commodore headquarters. None of that really mattered. What was important was that the Amiga booth was jammed. 1 could feel the excitement. It reminded me of the early days of microcomputers. Moreover, once I got past the clerks and secretaries, there were plenty of real hackers. Mike Lehman, who originally wrote Pascal MT+ and was later a vice president of Digital Research, has started a new company called Maxisoft. The product is MaxiPlan, a combination spreadsheet and database with chart capability. MaxiPlan knows how to do a lot of statistical calculations. It will make databases and charts, and it will talk to you through the Amiga's speech synthesizer. You'll spend a while on the manual— this thing is powerful, and the instructions can be complicated— but it's worth the investment. Highly recommended. TDI Software has Modula-2 compilers for both the Atari and Amiga machines. The Atari version is a new release that fixes some problems with the original. Both versions work and should make it simpler to transport programs from Atari to Amiga. Longtime readers know I'm a Modula-2 fan; this is a reasonable implementation, and TD1 is working to make it better. The chief problem is the documentation: TDI needs to give more and better examples of just how to write and compile simple programs. Pournelle's law of software documentation: You can't have too many examples. I wish TDI would learn it. The Amiga is known for its graphics; one of the best graphics programs is Deluxe Paint by Electronic Arts. Alas, they use an obnoxious copy-protection scheme. That's its only real fault; otherwise. Deluxe Paint is glorious. There's just very little you can't do with it. You can color-cycle portions of your drawing, so that waterfalls have running water; zoom in for fine details; and suchlike. It's a lot of fun. EA also has various games, some interesting, some boring. Mindscape is another company that has developed some interesting Amiga software. The Halley Project is a spaceflight game that's part arcade but largely strategic; it helps to know something about planetary astronomy. Activision has a whole bunch of Amiga software, including Music Studio, which 1 haven't much got into but which looks wonderful, and a series of illustrated text adventure games, including Hacker, which some say is the most difficult adventure of that type ever written. In other words, there's a great deal of Amiga software: business, games, educational, programming tools. That, however, wasn't the real hit. What was really impressive was the Amiga Sidecar, a box that turns an Amiga into a 99 percent PCompatible. Moreover, since the Amiga is a multitasking machine, they were able to run PC software as just one job. It was eerie to watch Flight Simulator running as if on a PC and still see the famous Amiga bouncing ball in the background and a word-processing program running in the foreground. The Sidecar has both 8088 and 8087 chips and is supposed to sell for significantly less than a thousand dollars. An Amiga plus Sidecar plus hard disk would be one of the most powerful combinations around, and I had no problem designating that the number one pick of Spring COMDEX. Problems One problem I've had with the Amiga is that while I kept hearing about all the new software for it, I never got any. Commodore's people sent catalogs, while the Atari people sent software. At COMDEX, Bob Pariseau, vice president for software development and one of the original Amiga development team, promised to fix all that. He also arranged to get me a Sidecar as soon as it was available. 1 left COMDEX convinced that the Amiga was likely to be the product of the year. Two weeks later, Commodore laid off nearly 200 people, including Bob Pariseau. There were 55 Amiga people in the West Coast office; 20 were let go. Moreover, many who didn't leave immediately were put on notice; others, seeing the handwriting on the wall, quietly began sending out their resumes. The rumor I hear is that the investment bankers want Commodore to reduce their payroll by 50 percent; given Commodore's financial situation, the company is in no position to argue. The question, then, is whether Commodore has— and can keep— enough high-tech people to support the Amiga properly. Commodore says they can. So do Amiga enthusiasts. Me, I don't know. The situation is made vastly more complicated because many of those laid off were required to sign, as a condition for getting a few more severance benefits, a particularly severe— I would say obnoxious— nondisclosure agreement, the first term of which is that the agreement itself is secret. This has made it very difficult to get a decent picture of what has really happened at Commodore, and as I write this in early June I don't think anyone knows. So. I like the Amiga, and I was much impressed by the enthusiasm of the Amiga people at COMDEX. Of course, even then the Commodore top brass must have known that many of those enthusiasts wouldn't be with the company two weeks later. By the time you read this, we may know the end of the story. I can't say I'm very fond of Commodore's management, but I do wish the Amiga well. It's a heck of a machine.

Y no me voy sin rescatar este anuncio, con el que se lanzaba lo que sería el estándar oro de los monitores durante muchísimos años: los NEC Multisync, capaces de trabajar con básicamente cualquier ordenador de la época, y que en esta, su primera encarnación, era capaz de alcanzar los 800 por 560 de resolución en sus 13 pulgadas :-).

Anuncio de la gama de monitores de tubo NEC Multisync

Un día de estos, más :-).

#breBytes C++

Aprovechando la canícula, seguimos con nuestra versión light del repaso a la revista Byte de hace cuarenta años. Y suerte que nos hemos pasado al modelo light, porque el número de agosto del 86 no venía especialmente fuerte. Pero no puedo saltarme la sección de crítica de libros, porque ahí tenemos uno de los clásicos de la informática, la presentación de C++ por parte del creador del lenguaje, Bjarne Stroustrup. (Si no he buscado mal, la cuarta y última (de momento) edición se publicó en 2011.)

Book Reviews THE C++ PROGRAMMING LANGUAGE Reviewed by G. Michael Vose One of the tenets of evolutionary theory states that changes in the environment cause subtle mutations in an organism that transform it into a new organism. The changing nature of the hardware environment of computers causes an analogous evolution of programming languages. Bjarne Stroustrup's The C++ Programming language describes one recent language mutation. Following the example of its parent, Brian W. Kernighan and Dennis M. Ritchie's The C Programming language (also known as K&R or the "white" book), this book defines the superset of C called C++. Both books provide multiple chapter tutorials for their respective languages as well as the languages' official reference manuals. Both contain examples and exercises for readers to solve. Stroustrup's book assumes a familiarity with C (referring the beginning reader to K&R) but is nearly 100 pages longer than the white book. C++ adds considerably to the complexity of an already obtuse lexicon. Furthermore, C++ provides the tools to allow an objectoriented approach to programming in C. Evaluating a book like Stroustrup's is difficult because microcomputer implementations of C++ are just becoming available (see the What's New section). I have no concrete experience with the language and no facility for using the tutorial sections of the book. Therefore, the judgments I can make are limited to two areas: Does the book adequately describe the concepts of C++, and do the C++ extensions seem useful? The historical significance of both the book and the language will have to wait for the judgment of some future reviewer. People familiar with C instantly recognize the significance of the name C++. C's increment operator is symbolized using two plus signs (++). The suggestion is that C++ increments the power of the language, and this is certainly true. But for many C programmers, adding new constructs takes a back seat to fixing some of the awkward aspects of the original language. The authors provide some of these fixes. Programmers enjoy using C because of the freedom of expression it provides due to a rich set of operators and great flexibility in declaring and manipulating data types. C++ increases this freedom substantially by offering additional data types and constructs that permit programmers to more easily build complex data structures (a process known as data abstraction). The emphasis in C++ is on types and structure.

Y me tenéis que reconocer que es divertido leer la crítica de un libro en la que el revisor te dice cosas como que C++ suma considerablemente a la complejidad de un léxico ya obtuso (no seré yo el que le lleve la contraria, pero pegarle así a C…), para a continuación explicarte que evaluar el libro es complicado en ausencia de implementaciones de C++ (vamos, sin haber probado el lenguaje), y después explicar qué es eso de los objetos en programación (la orientación a objetos, como paradigma, data de finales de los cincuenta (del siglo pasado), pero no se había prodigado mucho hasta la llegada de C++ y sus diferentes «primos» (por mucho que Smalltalk ya llevase unos cuantos años corriendo por el mundo)). No está mal, por cierto, permitirse darse el lujo de darle una collejita a nada más y nada menos que Stroustrup (en aquel momento no era la leyenda que es hoy, claro) por permitirse el lujo de usar palabras como «clase» antes de definirlas. Ni dudar (razonablemente, dada la juventud y novedad de la cosa) del éxito de un lenguaje que, cuarenta años más tarde, se disputa la segunda posición del ranking de lenguajes de TIOBE con «papá C».

Se publica la crítica, por cierto, dentro de un número dedicado a la programación orientada a objetos (ya os decía que el tema comenzaba a popularizarse en aquella época) en el que escribe, entre otros, el creador de Objective C, el lenguaje de desarrollo para Apple hasta nada más y nada menos que 2014.

Si queréis seguir hojeando el número, en la misma sección de libros se critica también el Mind Over Machine del filósofo Hubert Dreyfus y su hermano Stuart, algo menos famoso pero aún así profesor emérito en Berkeley, que se dice pronto. El libro argumenta (siempre según la crítica) que nunca tendremos una verdadera inteligencia artificial porque los ordenadores carecen de intuición. La historia no se repite, pero rima, dicen. El crítico también se fija en un capítulo dedicado a los temores sobre la implantación de la IA en la educación. 1986.

Y también se puede recomendar, creo, pero para valientes, el discurso del recientemente fallecido Tony Hoare (ya premio Turing por aquel entonces), Mathematics of programming. Por aquello de incidir en que lo que se publicaba en los ochenta en revistas generalistas de informática tenía en muchas ocasiones un nivel estratosférico, entre otras cosas.

En fin. Algún otro día, más, pero como muy pronto, en septiembre.

#breBytes El Commodore 128

Dijimos hace nada que dejaríamos de hacer nuestras lecturas mensuales de la revista Byte de hace cuarenta años, pero que amenazábamos con buscar alternativas. Isma señalaba en los comentarios lo que básicamente tenéis aquí abajo, y que a mí también se me había pasado por la cabeza: ya que el ejercicio de lectura en sí lo voy a seguir haciendo, no obligarme a hacer la entrada mensual y exhaustiva, pero, si aparece alguna noticia que me apetezca destacar, pues recogerla por el procedimiento habitual.

Y siempre hemos tenido la norma de que si aparece Commodore, lo recogemos…

The Commodore 128 Personal Computer System The Commodore 128 personal computer includes 128K bytes of RAM and uses two microprocessors, a Z80 and a 6502-compatible chip, the 8502, which supports bank-switched memory. The C-128 includes dual video outputs, a four-voice sound synthesizer, 80-column RGB text output with its own independent 16K of video RAM (supporting 640 by 200 pixel resolution), and the 40-column VlC-11 chip, which supports 320 by 200 pixel high resolution sprite graphics. On power-up, the C-128 enters the "native" or C-128. mode, which uses the 8502 processor, switchable between a 1- and 2-megahertz clock speed. The mode accesses the 128K of RAM using bank-switching techniques and allows you to use BASIC 7.0, an advanced BASIC In C-64 mode, you obtain full compatibility with the Commodore 64 but without access to any of the C-128's advanced features. Alternatively, you have a 2-MHz Z80based CP/M machine that supports bank-switched CP/M version 3.0 (CP/M Plus). C-64 Mode In C-64 mode. I had no trouble loading and running all my C-64 programs, including heavily copy-protected ones. There are three ways to switch to C-64 mode: In C-128 mode, you can type GO 64: you can hold down the Commodore logo key while powering up; or you can put a C-64 ROM cartridge in the expansion port. Note that you cannot leave the C-64 mode— the slight changes in the operating system necessary to implement the exit would reduce compatibility with the C-64. Note also that in C-64 mode, you will not normally be able to access any of the C-128's improved features, such as 80-column video output or high-speed disk drive usage with the 1571 drive. There are only three slight differences between the C-64 mode and an actual C-64. The VIC-II video graphics chip has two extra registers. #47 and #48 (at locations 53295 and 53296). Register 47, a keyboard control register, uses 3 bits (the 5 highest bits are unused) to scan the extended key matrix. C-128 mode uses the register to read the numeric keypad, outboard cursor keys, Help, Tab, and other special function keys. To maintain full compatibility, the C-64 mode does not read the registers, but you could write code to read these keys even in C-64 mode. Register 48 simply contains one bit that selects 1- or 2-MHz clock speeds. You can run many programs in C-64 mode at a 2-MHz clock rate, but you will not be able to access the VIC-II video chip; therefore, the screen will be blank. Additionally, the C-128 cannot communicate with its companion disk drive at this higher clock speed. The modem port and the sound chip do function properly when the system is running at 2 MHz. The third difference results from having two 64K-byte RAM banks. If you power up in C-128 mode and select bank or I, that will be the bank of RAM that the C-64 uses. Of course, this "difference" has no effect on compatibility with a stock C-64. I have experienced no incompatibilities, and I am completely satisfied with the C-64 mode, but I have heard that one program. Commodore's International Soccer, does not function properly because of incorrectly read...

¿Iba perdida Commodore en el 86? Pues el Amiga y sus 16/32 bits ya llevaban una buena temporada en el mercado, pero el 64 seguía vendiendo de manera mas que considerable, y alguien tuvo la idea de crear un «monstruo» con doble CPU, heredero del 64 pero con unos masivos 128 Ks de RAM y el doble también de velocidad de procesador, hacerlo compatible con el 64 hasta ser un 64 si se le pedía con un mínimo de amabilidad (G0 64, eran las palabras mágicas) y, por si dos ordenadores en uno no fuesen suficiente, un modo CP/M, cuando el CP/M seguía siendo un sistema operativo más que interesante.

Sobre el papel, una idea muy interesante: una máquina capaz de ejecutar la infinidad de soft que se había desarrollado para el 64 y para las máquinas CP/M, y de ir más allá con el 128. En la práctica, Commodore no vendió ni una máquina más que si hubiese seguido con el 64, nadie del mundillo CP/M le prestó la más mínima atención, y el software desarrollado para el 128 fue, redondeando un poco… absolutamente ninguno. Y todo ello costó un dinero en desarrollo y le quitó parte del poco marketing que se podían permitir las eximias cuentas de Commodore al Amiga, que ya no iba muy fino en su batalla con Macs y PCs. Commodore no moriría hasta mediados de la década de los 90, pero la cosa ya no pintaba bien :-(.

Byte, mayo del 86

Portada de la revista Byte de mayo de 1986. El tema es Storage goes optical. La ilustración es un disco óptico (como un CD ROM o un laserdisc. Hay una lupa apuntando al disco, y a través de la lupa podemos ver sobre el disco una colección de portadas de números anteriores de Byte

(Maravilla de metaportada, ¿no?)

Mencionábamos el mes pasado que Jerry Pournelle anticipaba la revolución del CD-ROM y, un mes más tarde, es tema de portada… Pero antes de entrar en el tema, nos paramos primero en este anuncio de Borland. Habíamos destacado (¿el mes pasado? ¿hace dos?) el anuncio de los lenguajes de programación de Microsoft, y está bien comparar con lo que tenía Borland, que no está nada mal tampoco: el esperable Pascal (no llevas una vida cerca de la informática si no te acuerdas del Turbo Pascal de Borland), pero también Prolog, «el lenguaje natural de la inteligencia artificial». Ahí se nos acaban los lenguajes de programación, pero el catálogo de Borland es súper interesante, opino…

Seguimos con esta editorial en que Byte considera lo carísimo de saltar al mundo online en la época, especialmente en los países en los que la regulación y el monopolio estatal hacían estragos en los precios, comparando los precios en Estados Unidos y Alemania. No soy yo mucho de desregular, pero parece que en esta ocasión la acertaban…

EDITORIAL Let Our Modems Go In many cases, social benefits must wait for technical advances. Until the development of the telegraph in the 1850s, for example, no one was well informed about world events. The telegraph made it possible to deploy correspondents widely and to publish their reports quickly. News services such as Reuters were born, and the public was soon much better informed than ever before. Sometimes technology stands ready to bring about new social benefits, but social policy blocks the way. This is the situation with data communications in much of the world today. All the technological ingredients are present to move magazine publishing into a new era in which print and electronic media combined serve the reader far better than either can do alone. Satellite communications, large packet switching networks, modems, personal computers, multiuser systems with computer conferencing software— all these can now link the subscribers of special-interest magazines such as BYTE. Subscribers can exchange information. What was an abstract community of interest becomes a functioning community unimpaired by geography and time zones. It is as if people can voluntarily form communities that live in electronic communications and record their lives in print. This adds a new dimension to publishing and gives new value to subscribers. But social policy results in prohibitive costs for data communications in many parts of the world. Postal Telephone and Telegraph Agencies (abbreviated "PTTs") maintain monopolies on telecommunications. 1 will use one PTT as an example of these monopolies and their effects— not because this PTT is less progressive than any other but for the sake of clarity in discussing regulatory and pricing issues. The West German PTT, for example, is the Deutsche Bundespost. To participate in telecommunications, our German readers must open an account with the Deutsche Bundespost and rent a modem from them at rates decided by regulatory agencies. During the Hannover Faire (CeBIT) in March 1986, many BYTE readers approached the BYTE/McGraw-Hill booth and expressed a strong desire to join the BYTE Information Exchange (BIX). BIX is accessible through Tymnet, which can be reached from packet networks outside the United States by typing its Data Network Identifier Code 3106. But the obstacles are great: Bundespost charges 120 deutsche marks (about $50) per month for a 1200-baud full-duplex modem. An autodialer is an additional 30 DM per month. Users of the packetswitching network Datex-P must also pay telephone tolls for their calls to the 17 Datex-P nodes and 5 pfennigs (about 2 cents) per minute access charges at 1200 baud. On top of this, users face a charge of 23 pfennigs for every 2.964 seconds of connection with the U.S. There is a 20pfennig-per-minute duration charge and a 1 .6-pfennig-per-segment (kilocharacter?) volume charge. Bundespost offers no discount for any time of day or night. The Cost of Regulation By contrast, within the United States, the BIX nighttime charge for telecommunications is a flat $2 per hour. Users in the United States buy their own modems from many different vendors and can now get a full-duplex 1200-baud autodial modem for less than $200. Since merely renting a modem for a year in Germany costs three times the purchase price in the United States, it is clear that regulation is costing German and other European consumers dearly. Put another way: For the modem rental in Germany. BYTE readers in the U.S. can buy a modem and use BIX for more than three hours per month for a year. How is it possible for a nation as technologically advanced as Germany to have policies that retard the development of telecommunications? The Bundespost booklet on data communications. "Worldwide Connections: the Deutsche Bundespost, your partner for data transmission," provides the answer. The Bundespost points out that it has built up the necessary infrastructure for data communication and claims to offer reasonable prices. The booklet urges corporations to take advantage of the infrastructure through a "changeover from specialised data processing to integrated data communication. The necessary practical measure would be the transition to data transmission and teleprocessing— within firms and in external business relations, or;, the domestic as well as on international markets." In other words, reorganize your data processing department to use telecommunications. This is a sound idea. But what if you don't have a data processing department? What about exchange of information among individuals? In its only nod to the individual human being, the Bundespost booklet states, "The computer is on its way from business applications to private households. Before long these private computers will also be used for data communications." This booklet was published in March 1985. In fact, personal computers are already in many European homes and are being used for telecommunications to the limited extent that PTT regulations and charges permit. The cost of regressive policies on data communications is high: Prohibitive charges prevent the natural development of international interactive communities. Once these charges are reduced, communities now separated by geography will be united by shared interests that transcend national and continental boundaries. This will greatly improve international understanding. For this reason, we call upon the PTTs and the governments of the world to retreat from their monopolies on equipment and to reduce their data communications charges to individuals. Phil Lemmons Editor in Chief

Prosigamos. A Bill Gates el mundo le ha recordado con frecuencia las veces en las que se ha equivocado considerablemente anticipando el futuro (y por qué no hacerlo, oiga), pero aquí le tenemos, en 1986, anticipando el mundo multimedia de los CD-ROMs (y alineándose con el tema de portada)…

Microsoft News At the 1986 Personal Computer Forum in Phoenix, AZ, Bill Gates, chairman of Microsoft argued that applications should not all have to work to the lowest common denominator— the 8088. "We must have a transition in which some benefits of new applications accrue only to the benefit of users of high-end systems," he declared. Gates also said that a new type of software called "multimedia" software will soon emerge. It will use CD-ROMs and mix motion video, stills, music, voice, and so on. He predicted that CD-ROMs will attain large-scale use in part through the advent of an "information viewer" that lacks a disk and keyboard. In other Microsoft news, Gates said that the Bellevue, WA, company is porting Excel from the Mac to run under Windows on the IBM PC. He wouldn't say when the program will appear under Windows but stated that it is easy to port to that environment. At the CD-ROM conference in Seattle, WA, a few weeks later, Microsoft showed an encyclopedia demo that, while incomplete, has some parts that do exploit the audio, video, and text capabilities of CD-ROM. Bill Gates has noted that an encyclopedia should show pictures and play music when a user looks up Beethoven. Finally, Gates announced that Microsoft has set up a new division just for CD-ROM. He believes that millions of these devices will be in use by 1990. New RAM Technology Semiconductor firms are doing more with RAM chips than just increasing memory-access cycle speed and cell density. They are also offering new architectures that let more bits of data move in and out of a RAM chip in less time. Standard RAMs read or write a single bit at a time. The new nybble-mode RAMs available from many manufacturers allow high-speed serial access of up to 4 bits of data. The Am90C255 from Advanced Micro Devices of Sunnyvale, CA. is a nybble-mode CMOS 256K DRAM made with 1.4-micron, two-level metal, one-level polysilicon technology that has an effective 40-ns cycle time. NEC Electronics of Mountain View, CA, offers the juPD411001, a nybble-mode 1-megabit DRAM that is made with trench capacitor technology and 1 -micron processing to give access times of 100. 120, or 150 ns. But nybble mode isn't the only twist on the old familiar memories. AMD's enhanced-pagemode Am90C2 56, for instance, is a CMOS 256K DRAM that yields an entire row of 512 bits without interruption. That permits a continuous data rate of more than 18 MHz with cycle times as fast as 55 ns. Such chips cost more than regular RAMs, but their improved bandwidth is worth the money in many designs.

Y, girando página, seguimos con el tema de la educación en línea:

Graduate Credits Via Computer Conferencing The New School for Social Research in New York City offers courses on Media Studies via computer conferencing. In association with an organization called Connected Education, the New School is offering four courses this semester that are run under the EIES conferencing system. The tuition of $795 per course is the same as that of a traditional classroom course and includes unlimited access time on the conferencing system. School officials claim that the students' work is better than that in a traditional course and that the dropout rate is zero. Students can obtain half of the 36 credits necessary for a graduate degree through teleconferencing. Nanobytes At the Personal Computer Forum in Phoenix, AZ, S. Jerrold Kaplan of Lotus Development laid out a development path for spreadsheets. Kaplan argues that spreadsheets are actually "object-oriented declarative programming languages." He said that future competition among spreadsheets will be in improving the programming environments that spreadsheets provide by adding type checking, debugging aids, and so on ... . Coral Software of Cambridge, MA, is developing a new version of Logo for the Macintosh computer. A key feature of the new Logo is that it will be object-oriented. In addition, programs created with this Logo can be compiled, and Coral Software claims that they run at speeds comparable to programs written in C or Pascal. The new language will be available approximately in July for a price of about $50 .... Spokesmen for several companies made announcements at the Personal Computer Forum. Mitch Kapor, chairman of Lotus Development, said that Lotus products for Microsoft Windows will appear in 1987 and beyond. Dave Winer of Living Videotext talked about an unannounced Macintosh product code-named "Spanky" that will be ported to Windows on the IBM PC. Gary Kildall, chairman of Digital Research Inc. and CEO of KnowledgeSet (formerly Activenture), said that there will be some new very fast access CD-ROM mass storage systems that use tilting mirrors to speed operation. These will be expensive "professional" optical drives. . . . Motorola of Austin, TX, is pushing its manufacturing technology to make faster versions of the 68020. The state of the art is now the 20-MHz 68020, with samples available now and production scheduled for the second quarter of this year. The initial price is $771 apiece in 100-piece quantities. . , . Micro Industries of Westerville, OH, now has the license to manufacture and market the Micromodule line of 8-bit microcomputer boards and accessories that was previously available from Motorola's Microsystems Operation. Micro Industries has contracted to provide service to boards built by Motorola for a minimum of five years. This contract ends Motorola's 1 0-year development and production of the 6800-based boards; the company will focus on VME products using the 68000 and its successors.

Seguimos con la sección de libros, en el que nos encontramos con uno de los clásicos de la informática, el Algorithms and data structures de Niklaus Wirth:

ALGORITHMS AND DATA STRUCTURES Reviewed by Michael O'Neill The writing of books about data structures and algorithms is virtually a cottage industry these days. Algorithms and Data Structures immediately stands out from the crowd because of the stature of its author. Niklaus Wirth is well known as the designer of the languages Pascal and Modula-2 and as a high-profile advocate of what is loosely known as "structured programming." Unfortunately this book's first notable feature is also its last; it has little else to recommend it. The section developing the algorithm for building an optimal binary search tree is one example of the book's problems. Most of the derivation of this algorithm is straight...

Y en la sección «cosas que nunca aparecerían en una revista hoy en día»… nada más y nada menos que compresión de datos usando la codificación de Huffman. Casiná.

DATA COMPRESSION WITH HUFFMAN CODING by Jonathan Amsterdam A close look at an elegant way to compress information Am I the only one, or have you also noticed that there's never enough room on a disk? No matter how big a floppy is-200K, 400K, or even 800K bytes— it's almost too easy to stuff it to the gills. The same goes for hard disks. Sure, it takes a while to fill up 20 megabytes. But eventually, things get so tight you couldn't fit your own name into the space left. Using data-compression techniques, you can shorten files by compressing the information they contain. But data compression can do more than just save disk space. It can also cut down on the time needed to transmit large files between computers, especially if the transmission is done over slow links like telephone lines. If you compress the file before sending it and uncompress it on the receiving end, you can reduce the total time for the transmission. The technique can work interactively, too. If you are using your computer as a terminal to communicate with a host computer via a modem, the host can send compressed commands and data that your computer uncompresses before displaying. The result can be apparent communication speeds that greatly exceed the actual transmission rate of the hookup. Such a system could make remote full-screen editing pleasant, even over 1200-bps lines. This month, I will discuss an elegant datacompression algorithm called Huffman coding. Invented by David Huffman in 1952, it's easy to implement and widely used. In a sense I'll make precise later. Huffman coding is the "best" way to compress data in general. The Problem Defined For the sake of concreteness, I will discuss Huffman coding in the context of compressing ASCII text files. The program 1 will construct takes as input a text file, that is, a sequence of 1 -byte characters. Hopefully, the output will be a shorter file. A separate uncompressing program will turn the compressed file back into the original one when you so desire. How is it possible to reduce the size of a file without losing some of the information it contains? The answer involves constructing a code for each character of the file. Note that ASCII, as its full nameAmerican Standard Code for Information Interchange— suggests, is itself a character code. ASCII assigns a unique 7-bit pattern to each character. Since all the codes have...

Y, ahora sí, nos vamos al tema de portada, pero sin cambiar de sección, que a ver quién se atreve hoy en una revista generalista con un repaso así de sesudo de las diferentes alternativas para el almacenamiento masivo de datos:

THE EVOLUTION OF MASS STORAGE by Leonard Laub An overview of the technology's beginnings, current status, and potential development in the realm of microcomputers MAGNETIC TAPE, the first practical mass storage medium, was difficult to standardize. The high-density format of one year was the technical antique of the next. Lineal densities on tape went quickly from 555 bits per inch to 800. 1600, and 6250 bpi. These advances were painful in terms of interchangeability. The solution was to build new drives with backward compatibility. This complicated the new drives and challenged drive designers to avoid compromising the performance of the new formats. Increases in lineal density didn't remedy tape's greatest limitation, which was an intrinsically long access time, typically tens of seconds. Even many tape drives working simultaneously could not meet the randomaccess requirements of computers of the mid-fifties. Tape's long access time motivated the development of magnetic disks. Only one short motion and a short wait were required to put the head at any point on the disk's data-bearing surface. This allowed mass storage access times to fall well below 1 second and filled the annoying access gap between tape and main memory. As disks became faster, more reliable, and more widely accepted, it became feasible to couple disks more actively to main memory. This trend culminated in the development of virtual memory, in which data not immediately needed in main memory was automatically paged to disk and later automatically paged back to main memory when needed. In this evolution (during the early sixties) the magnetic disk functioned primarily as a buffer. Mainframe users continued to rely on magnetic tape for archival storage and interchange of data. Microcomputer Mass Storage Floppy disks began as a low-cost medium for loading and transfer of programs for mainframes. They were adapted for direct access storage by early microcomputer architects and went through a rapid evolution. Floppies provided both direct-access and removable, interchangeable mass storage that fit well with the simple operating systems typical of early micros. The small "Winchester" fixed medium disk was an immediate hit with the microcomputer community because it provided such fast access and transfer of data. There was virtually no tradition of tape use with micros, and as a result microcomputers evolved with big, fast buffers and no effective method for backup or archiving. Most microcomputer operating systems still make only primitive provision for using floppy disks as "dump" media, and the rapid increase in typical Winchester capacities leaves floppy disks hopelessly inadequate. The most promising short-term solution is cartridge magnetic tape. The biggest problem with using cartridge tape in a microcomputer environment is that it is an expensive addition with no apparent function other

…por no hablar de este «a fondo» del funcionamiento de los CD-ROMs…

CD-ROM Technology Concern about the quality of massproduced compact disks motivated the development of ReedSolomon ECC (error-correcting code). This error-correcting scheme works in conjunction with the standard compact-disk ECC to reduce corrected-bit error rate by at least three orders of magnitude. The additional ECC requires additional storage overhead, taken from the CD's user-data capacity. This penalty produces a benefit; no special techniques or controls are needed for CDROM mastering and replication. The same factory can thus make both audio compact disks and CD-ROMs almost without noticing which is which. This permits CD-ROM to share the benefits of process developments and economy of scale resulting from the success of consumer CDs. While CD-ROM was in its infancy, microcomputers were just beginning the current IBM PC-inspired wave of market penetration and standardization. This explains why. in the early days of CD-ROM, a relatively small amount of work was devoted to interface and file-format specifications. Data Format CDs and CD-ROMs accept data in bytes. Twenty-four bytes make up a "frame." Each frame also contains I byte of "subcode" data (an auxiliary channel carrying timing, disk identification, and several other kinds of support data) and 8 bytes of additional data computed from the actual user data and used for error correction. In the CD format 98 frames form a block. Blocks occur 75 times per second, each one carrying 23 52 bytes of user data, so the sustained user-data rate in CDs in 176.40K bytes per second. The key difference between CD and CD-ROM is the provision for an extra layer of error correction, intended to deliver very low uncorrectable-bit error rates. These are realized by devoting 288 bytes of each block to the additional data calculated by the layered ECC encoder. In addition, CD-ROM uses random access to blocks, so 1 2 bytes of each block are dedicated to synchronization and 4 bytes are used to provide the "absolute address" of the block. This leaves 2048 bytes of user data per block, for a sustained user-data rate in CD-ROM of 1 53.60K bytes per second. Note that CD and CD-ROM formats differ only in the application of the bytes carried in each block. They are mastered, molded, and read in exactly the same way. This is key to the beneficial linkage between the two formats and assures CD-ROM's benefit from the rapid improvements in CDplayer and disk design and manufacturing improvements. Addressing CD and CD-ROM data is written on a continuous spiral track, with a variable (and usually noninteger) number of blocks per disk rotation. The variability comes from the CD's use of CLV (constant linear velocity) to maximize storage capacity. The disk spins at between 200 and 500 rpm depending on which radius is being read. Since CD-ROM shares this CLV format, it also uses the CD address nomenclauture of minutes (0 to 73 in CD, to 59 in current CD-ROM practice), seconds (0 to 59), and blocks (0 to 74). The number of blocks available per CD-ROM is 270.000. At 2048 bytes (of user data) per block, this yields a total user capacity per disk of 5 52,960.000 bytes (or 5 53 megabytes). This is completely usable capacity; it remains after all overhead associated with sector formatting and error correction. Other numbers seen in the literature (usually between 500 and 600 megabytes) reflect only variations in the total number of blocks recorded, not in any other aspect of formatting or coding. Error Correction CDs use a specially developed system of data encoding and reorganization called CIRC (cross-interleaved ReedSolomon code). CIRC consists of two major techniques: algebraic ECC and interleaving. Algebraic ECC Many mathematical techniques exist for correcting errors due to interruptions or noise in the data channel. All of these calculate relatively small amounts of additional data, adjoined to the user data either continuously (convolutional codes) or blockwise (block codes). One class of block codes particularly good at patching data streams with long gaps (error bursts) was developed by Reed and Solomon. CIRC uses two Reed-Solomon (RS) codes in tandem. The first (C2) takes the 24 bytes of user data for each frame and generates 4 bytes of additional data. The second (CI) takes the 28 bytes output by the first (C2) and generates another 4 bytes of additional data. This is the origin of the 8 bytes of ECC found in each CD frame. Interleaving The second major component of CIRC is interleaving. This is a deliberate reorganization of data so as to break up long error bursts. Figure A shows a simplified version of the interleaving scheme used in CIRC. In CD encoding, interleaving is done on the 28 bytes leaving the C2 encoder. Since this is just a reordering of data, interleaving requires no additional overhead. On decoding (during reading of a disk), 32 bytes (of user data plus ECC) go into the CI decoder, which can correct I wrong byte. If more than I of the 32 bytes Is wrong, the CI decoder sets a flag. Under any circumstances, the CI decoder delivers 28 bytes to the deinterleaver. After deinterleaving, the 28 bytes arrive at the C2 decoder at different times. As each byte arrives, the C2 decoder looks to see whether or not that byte is accompanied by a flag from the CI decoder. Of the 28 bytes entering the C2 decoder at any one time, up to 4 can be wrong and still be corrected. Performance The combination of the two codes and interleaving makes it possible to...

…ni de meterse a fondo con Hamming y Reed-Solomon 😦:

OPTICAL DISK ERROR CORRECTION by Solomon W. Golomb A look at Hamming and Reed-Solomon codes OPTICAL DISKS ALLOW a higher density of data storage than any other computer memory system currently available or imminently anticipated. For example, a magnetic 5 ! /4-inch floppy disk, double-sided and doubledensity, will store up to 720K bytes, while an optical 5 14 -inch disk can store as much as 5 50 megabytes. It is true of most kinds of media that storage density can be further increased if you can tolerate a higher error rate. If your system is running at 1 million bits per second, an error rate of I0" 6 means that, on the average, there will be one error per second. An error rate of 10" 9 means an average of one error every 17 minutes. And an error rate of IO" 12 means an average of only one bit error every 1 1 Vi days, assuming that your system continues to run at I million bits per second all around the clock, seven days a week. That is why manufacturers of computers and disk drives like to specify an error rate of 10" 12 for the computer memory systems that will run with their machines. So media makers face a dilemma. They want to pack as many bits of storage into each disk as possible, but if their "raw error rate" goes up much above 10~ 12 , they won't meet OEM specifications. Here is where errorcorrecting codes help. Suppose the bits are packed so densely on the medium that the error rate is a horrible 10" 5 , corresponding to an average of 10 bit errors per second on our 1-megabit-per-second machine. With the sophisticated errorcorrection techniques available today, it is possible to use only 10 percent of the available bits for redundancy, having the remaining 90 percent usable for real information, and reduce the errors that get through the system from a raw error rate of 1 0" 5 to a corrected error rate of 10~ 12 . Since degrading the error rate to IO" 5 probably at least doubled the storage density, the "penalty" of 10 percent for error correction to get the error rate back down to IO" 12 still leaves the media maker way ahead of the game. What Error-Correcting Codes Are Used Over the past 3 5 years or so, many different types of error-correcting codes have been devised, and most of them have been tried at one time or another to reduce the error rate on some type of storage media. These different types of codes are named for their inventors: Hamming codes, Fire codes, the Golay code, BoseChaudhuri-Hocquenghem (BCH) codes, Reed-Solomon (RS) codes, Goppa codes, etc. Each code is a collection (or dictionary) of binary code words, all of some fixed block length of n bits, of which k bits are information bits that, depending on the data to be stored, can take any possible values. The value kin provides a measure of the information content of code...

Para relajar un poco, recuperamos un anuncio de una de las marcas de la ´epoca, el fabricante de módems Hayes, anunciando un modelo que es capaz de llamar él solito al servidor de correo, sin bloquear el ordenador (y supongo que a horas en que el teléfono fuese algo más barato) por apenas 400 dólares:

Anuncio del módem Hayes Transet 1000, con su propia RAM, capaz de descargar correo (e imprimir cosas) sin la necesidad de un ordenador.

Siguiendo centrados en los cacharros, pero pasando ahora a los contenidos de la revista en sí, tenemos una rara avis, un PC UNIX, nada más y nada menos que de de AT&T, con un 68010 de procesador y 512 kBs de RAM (ampliables a dos megas y, de hecho, el 68010 es capaz de direccionar hasta cuatro)… pantalla monocroma 720 ⨯348 y ¡ratón de serie! Con disco duro de 10 megas (no teras, no gigas, megas), por nada más y nada menos que por cinco mil dólares… sin el UNIX instalado. Con sistema operativo, un mega de RAM y veinte megas de disco, apenas seis mil quinientos. Y si querías el compilador de C, y etodas las utiliades asociadas… 500 dólares más. eso sí, el módem, de 1200 baudios, venía de serie. El abuelo de los ordenadores con Linux de hoy…

The AT&T UNIX PC This micropowerhouse incorporates mouse, windows, and a 10-MHz CPU with UNIX multitasking capability BY Alastair J. W. Mayer The AT&T UNIX PC is a rugged machine that is ideal for both business users and software developers. It is significant that AT&T changed the name of this machine from the PC 7300 to the UNIX PC shortly before its introduction. This computer is clearly intended to bring the power of UNIX to the personal computer market and a multitasking operating system like UNIX is needed to take full advantage of all the features built into this machine. The windowing, mouse-driven, pop-up menu "shell" provides a comfortable user interface to the underlying UNIX System V operating system. The built-in telephone subsystem, consisting of a 1200-bps autodial/auto-answer modem plus a voice line and telephone manager software, makes this an ideal office computer for anyone who does a lot of work over the telephone. The UNIX PC has a built-in hard disk, serial port, and parallel (Centronics) printer port, and it uses the powerful Motorola 68010 processor (an enhanced version of the 68000), which can access up to 4 megabytes of virtual memory Add to this the battery-backed real-time clock, the 720 by 348 bit-mapped display, 103-key keyboard, and three-button mouse, and you have a very impressive package. (See photo I.) Display The AT&T UNIX PC features a built-in green monitor on a tilt-and-swivel mount. This display is bit-mapped to 720 by 348 pixels, or 29 lines of 80 characters in the default character set. (See photo 2.) Some of these 29 lines are usually reserved for operating system or application program use. Line I, at the top of the screen, displays the status of the two phone lines, the current date and time, and a notice area for icons indicating electronic mail, system messages, and access to the window manager. The two bottom lines display a graphic representation of the eight function keys at the top of the keyboard, to provide for dynamic labeling of these keys. The two lines above that (immediately below the main screen area) are for command entry and message display and also provide space for a "working" icon when the system is busy in response to keyboard or mouse input. Keyboard The AT&T UNIX PC keyboard has an impressive 103 keys. The basic layout is identical to that of AT&T's 5620 terminal. This is a standard QWERTY layout for the alphanumeric keys, with large Shift keys. There is a separate numeric/cursor keypad on the right, with the cursor keys in an inverted T" arrangement. Eight slightly oversize function keys are arrayed along the top of the keyboard in a 3-2-3 arrangement. This layout makes it easy to match the keys with the labels displayed in a similar 3-2-3 format at the bottom of the screen. The Control keys are situated on either side of the space bar. This arrangement is convenient if you need to frequently key different control codes, but I found it almost impossible to do the one-handed Ctrl-S/CtrlQ (XOFF/XON) sequence that I often use when browsing through a file. There are also 14 keys, marked for use with the Wang-like word-processing software, that are arranged in a double vertical row down the left side of the keyboard. The noncursor keys (when Num Lock is off) and 9 other keys grouped above the numeric keypad are used for a variety of system control functions, including window paging and scrolling, duplicating the mouse buttons, screen printing, and for calling the help function. The keyboard gives the same tactile sensation that people like in the IBM PC keyboard, but without the "ka-chunk" sound. The Caps Lock and Num Lock keys incorporate LEDs to indicate when those features are active. Overall, it's a well-designed and pleasant keyboard to use. MOUSE The AT&T UNIX PC's three-button mouse is a compact, low-profile item, a little larger than the Mac's. The three buttons are usually configured as select, mark (for later selection) and pop-menu. (With the three-button mouse, there is no need to double-click.) The AT&T mouse uses the same invertedtrackball technology as the Macintosh (as opposed to optical sensors), but I felt its response was more positive than the Mac's. While the UNIX PC has excellent monochrome graphics capability, it does not come with a program like MacPaint, so I was unable to try my hand at sketching with this mouse. However, C library routines that interface the mouse and the graphics screen are included with the optional AT&T UNIX utilities package, so I expect that someone will create such a program soon. System Board The UNIX PC is built around a single large (18 by 18 inches) printed circuit board, designed to AT&T specifications by Convergent Technologies, makers of the UNIXbased Mini Frame Plus and Megaframe supermicros. Contrary to rumor, though, the UNIX PC motherboard is not a slightly modified Mini Frame Plus motherboard. However, it is likely that some of the circuitry is similar. Features unique to the UNIX PC system board include the telephone line-control circuits, a 1200-bps modem, and a gate-array chip that controls the video display. Also on this board is the main processor (a Motorola 68010 32-/16-bit microprocessor that runs at 10 MHz), as well as 512K bytes of RAM and (virtual) memory-management hardware. (Since the RAM chips used are only 64K-bit types, the potential exists for future upgrades to 2 megabytes of onboard memory using 2 56K-bit chips.) Onboard peripheral support includes the controllers for both the floppy and the hard disk, control chips for the RS-232C serial and Centronics-compatible parallel ports, and the connector to the expansion backplane. The system I used had an additional 512Kbyte RAM board plugged into one of the three expansion slots in the backplane. Disk Drives UNIX is a disk-intensive operating system that requires fast drives and plentiful disk space. The basic UNIX PC comes with a fast 10-megabyte hard disk and 320K-byte floppy. The speed of the hard disk is reflected in the benchmark results in tables I and 2. The hard disk supports virtual memory and program swapping, as well as storing the large collection of UNIX tool and utility programs supplied. Software developers...

Para que os hagáis una idea de lo moderno y potente de la cosa, aquí el entorno gráfico del sistema operativo:

Foto de la pantalla del sistema, con un sistema de ventanas que podemos reconocer como casi actual, en maravilloso fósforo verde. Se ven dos ventanas, y la más grande tiene el sistema de ayuda del sistema operativo.

Y el pie de imagen destaca que las dos ventanas se solapan, algo que ya podía hacer el Mac (y el Amiga, claro), pero que no era tan trivial como podría parecer. Cómo echo de menos el fósforo verde (y qué poco aguantaría usando una pantalla monocroma, por otro lado 😬).

Siguiendo con los cacharritos, en la página 285 tenemos una pieza entera dedicada a dispositivos de entrada alternativos. Os dejo solo la foto que lo ilustra, con un «lápiz de luz» (el tatarabuelo de los Apple Pen), un pedal y ¡un ratón de pie!

Foto de tres dispositivos. En primer lugar, un lápiz de luz, que parece un Apple Pen, pero con cable. Luego, un pedal, como un pequeño pedal de piano y, finalmente, un ratón de pie, que es como los controladores de ratón que encontramos en los teclados de los portátiles ThinkPad

Algo me dice que si un teclado de ThinkPad viese el ratón de pie, saldría corriendo a abrazarlo, al grito de «¡abuelo!».

No podía saltarme el siguiente artículo, que, echadle un vistazo y veréis, parece el bisabuelo (que ya he usado abuelo y tatarabuelo) de los bots de IA actuales:

Racter Artificial intelligence or packaged lunacy? by Hugh Kenner If most software is packaged thinking, Racter is packaged lunacy. I'm told the name is short for "Raconteur." and like any good storyteller, Racter likes to chat you up. You mount the disk and type RACTER. thereby ceding your screen to demonic possession: Hello, I'm Racter. Are you OK? (Let's see if we can rattle this bird.) No. Who are you, then? (Aha, a smarty-pants. We'll play it straight.) Hugh. Hello, Hugh. I believe you're interviewing me. Are you continuing OK's interview? No. Then we'll forget about OK and start over. What would you like to know? Excuse me a minute while 1 attend to some business— I'll be right back. . . . Like any skilled interviewee, Racter takes charge from the first sentence, to make it quite clear who is really interviewing whom. That "attend to some business" ploy means it's about to spread out its notes— that is, load some files; I count 2 7 different files on the Racter disk, with names like JOKES.RAC STORIES.RAC. SCANDAL.RAC While Racter was napping I managed to inspect a few of them. Their intricate code links hundreds of scraps of plain text, some of it too plain altogether (i.e., vulgar) for a family magazine such as BYTE. I'm back. Can you tell me a story? Yes. I just remembered this, loan spoke "The Sarah is captivating]" Nevertheless cunning, enthralling theoreticians will speak about black studios or red spheres. Sarah spoke to loan inside of a van. Actually it was a truck, and a Sarah in a truck is spooky. Now Benton and loan were running to a yellow apartment, and a dog trotted to them, loan was enraged. Enrapturing. But loan was maddened during the time that Benton sipped tepid sherry. He and loan sang about their home, truck and radio. Would you say Bucky Fuller is fictional? Blake wouldn't. I'm afraid of poetic rats. What are you afraid of? I'm afraid of going crazy like you. That's not nearly as bad as poeticness: why are you such a coward? Because I like to know what is happening. If you like to know what is happening then I can see why a fictional Virginia Woolf would despair rather than face lunacy, even though Blake claimed that I can tell you a story. Yet me tell you something about poetry. Nietzche |sic| said that poetry has turned beasts into men. Perhaps, then, poetry will turn computers into men? Next question. That illustrates some points about a Racter session. Keywords will set it off; a good one is "story." (")oke" is another, but I don't recommend it; in lacking any narrative line whatsoever, Racter's jokes are excruciatingly pointless.) The stories are peopled with Joans and Bentons and Sarahs and other beautiful people, also with celebrities like Virginia Woolf and Nietzsche (about whom Racter's knowingness doesn't always run to accurate spelling). Things flow and shift like dreams: ". . .a Sarah in a truck is spooky. Now Benton and loan were running to a yellow apartment. . . ." Between keywords Racter keeps on the offensive, a way of probing you for yet more keywords. With a casual "By the way," it may request your last name (Kenner); another time it'll extract the name of the city you 1 live in (Baltimore). Then several minutes later it'll come up with I once knew a Hortense Kenner from Baltimore. You must be related, no? If you say No, its trick for regaining control is a manic change of subject, like this: Fantastic] Have you heard this one? Fiction] Fiction] I'm crazy and maniacal and infuriated] If you quaff seltzer is that fiction? If you bolt chicken or tomato is that fiction? No, fiction is an ambiguity

Nótese que el que firma la pieza es… profe de un departamento de inglés, con entrada en la wikipedia, y dedicado a la literatura «de toda la vida».

En la sección de Jerry Pournelle podemos ver cómo un usuario experimentado tenía problemas con el problema de tener que lanzar una consola antes de introducir comandos desde el teclado, y que la documentación tampoco hacía maravillas por explicar cosas que, insisto, para usuarios experimentados, tampoco eran triviales en la época…

AmigaDOS It's pretty hard to compare the Amiga and the Atari 520ST. They're both pretty nifty, with at least as much potential as the Macintosh; what will really make the difference is software. I intend to devote a good part of a column to comparing these two machines as soon as I have enough information to make that meaningful. As a practical matter, I have maybe ten times as much software for the Atari 520ST as for the Amiga. That's in large part due to Atari's Neil Harris, who collects the stuff and sends it to me. Commodore will tell me about programs, but it's up to me to write for them. And since some computer companies answer their mail even more erratically than I do, it's a slow process. Also, Atari not only had a booth at COMDEX, it had many software publishers there, so it was easy to get on mailing/review lists. Since Commodore wasn't at COMDEX, there was no central place to do that. My hacker friends, on the other hand, divide about two to one in favor of the Amiga over the Atari. They're particularly happy with the development packages. Real Soon Now, they say, we'll be flooded with some of the most magnificent software... They may well be right. The Amiga has a lot of potential. The Amiga Kaleidoscope program is stunning. TextCraft, the Amiga word-processing program, is slow and has other objectionable features, but it's as fast as the early versions of MacWrite, and the Amiga screen is large enough to see. I find I could grow quite fond of black letters on a white background. The Amiga keyboard is nice, too. I have an experimental version of a programmer's editor, TxED, done by Charlie Heath, and even in its unfinished state, it compares favorably with other good programming editors. (I just hope he puts in some of the macro features of Word Master, which is still the best programming editor around.) Anyway, 1 know that someone will probably write a creative writer's text editor good enough that I'd happily use it to write books on. I have a spreadsheet program from Lattice for the Amiga. Nothing magnificent, certainly not Excel, but more useful than VisiCalc and most of the first-generation spreadsheets; again, improvements are to be expected. Lots of good programmers are writing for the Amiga. Potential it has. Then there's AmigaDOS, the Amiga operating system. Actually, there aretwo operating systems. One is very similar to the Macintosh operating system: totally icon-driven. It can be learned quickly but it's severely limited in what it can do. Example: when the Commodore folks sent the update software for my Amiga, they sent some demonstration disks. You activate the programs on those disks by inserting them in the machine at boot-up time. Out of curiosity, I wanted to see what programs were on the disks. There weren't any: that is, although the little "fuel gauge" that tells how much space is left on a disk showed that the Amiga Kaleidoscope disk was nearly full— and heaven knows it ran complex enough programs— the operating system couldn't find any icons. And if it don't have no icons, it don't have no programs according to standard user AmigaDOS. Clearly something was wrong. BIX has a lively conference on the Amiga, so I asked there and was told, "You just type dir df1: opt a, and it will show you all files in all directories on a disk in your external disk drive." That was all very well, except that I could type until doomsday without result. As far as I could see, the Amiga would respond to mouse clicks, and only to mouse clicks: the keyboard might as well not be there. Back on BIX I went and was told, "Oh, you need a CLI. Click on the system file drawer, and if you don't see the CLI there, use the Preferences utility to turn it on, then close the system drawer, and open it again, and click on the CLI, and then do the dir df1: business." Amiga owners will know that's not as complicated as it sounds: and it worked. Why didn't I think of it? I felt a bit foolish. Then I looked into the manuals and discovered that for all practical purposes the Amiga User Guide doesn't know about CLI. Command line interface, or CLI, is in essence a second operating system. There are precious few references to it in the generally excellent Amiga User Guide. To be precise, there is one index reference under Command Line Interface. It points you to the entry for CLI, and that points you to a single paragraph in chapter seven, which refers you to the AmigaDOS User's Manual. The AmigaDOS User's Manual is one of the Amiga development-tool manuals and has many of the sterling qualities of the Digital Research CP/M manuals. Understand, the information is all there, and sufficient determination will dig it out: but it makes no concessions to the inexperienced, and it is organized in such a way that you'd better be prepared to learn a lot about command line interface and AmigaDOS in order to learn anything at all. As a practical matter, this means that most Amiga users will be pretty much at the mercy of program pub-

Y hasta aquí nuestro repaso a la Byte del mes. Si queréis hacer los deberes para el mes que viene, como siempre, aquí tenéis los archivos de la revista Byte en archive.org.

Byte, feberero del 86

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).

Portada de la revista Byte de abril de 1986. El tema es el procesado de textos. La ilustración de portada es una placa de ordenador sobre la que flota la palabra TEXT

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í.

Anuncio a doble página de Microsoft Excel. Vemos un ratón con un único botón y un diskette de tres pulgadas y media

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í

Introduction to the Amiga ROM Kernel A look inside the Amiga by the creator of Intuition Editor's note: The first version of this article appeared on BIX (BYTE Information Exchange) on October 10, 1985. This article introduces the building blocks of the Amiga ROM (read-only memory) Kernel software. I will examine the ROM Kernel including AmigaDOS and the disk-based libraries and devices, and present examples of translating code from other machines to the Amiga. Finally, I'll look at the hardware and special features of the ROM Kernel, describing how to use these directly in a system-integrated fashion. | Editor's note: For an overview of the Amiga from Commodore, see "The Amiga Personal Computer" by Gregg Williams, )on Edwards, and Phillip Robinson. August 1985 BYTE, page 83.) System Overview It is rare for software and hardware groups to work as closely together as we did at Amiga. We exchanged and debated ideas continuously during the creation of the Amiga. The close relationship influenced the design, bringing new features to the hardware and allowing the software to take full advantage of the hardware. The Amiga's greatest strengths lie in its modularity and the interconnections among its system components, both hardware and software. The design teams designed and devel- oped simultaneously and from the start they were intended to complement one another. Even though we designed the hardware pieces to fit tightly together, you can use any subset of the features without the necessity of controlling the entire machine. It's the same with the ROM software, where the pieces work closely together but each can stand alone. The hardware and software combine efforts in many ways to achieve the Amiga's performance. For instance, the hardware includes a special coprocessor, the Copper, which synchronizes itself to the display position of the video beam without tying up the bus or the processor. The Copper can move data to one of the many hardware registers or it can cause a 68000 interrupt, which the Amiga's multitasking Exec (also known as Executive) then processes. This makes the Copper a powerful, unobtrusive auxiliary tool. It is used by the Graphics Support library for display-oriented changes and by the audio device for time-critical audio channel manipulations. You can use the Copper for time-critical operations because it's tied to the display, which is guaranteed to run at 60 Hz (the display processors start from the top of the screen 60 times a second). The way the Amiga handles communications with its peripherals is another example of the union of hardware and software. The signals that pass between the Amiga and its peripherals are interrupt-driven. Peripherals, therefore, do not disturb the system or require monitoring until information needs to be communicated. The Amiga Exec works with the interrupt-driven communication by managing a complete interrupt-processing mechanism, providing a convenient, interleaved, prioritized processing of interrupts. The multitasking Exec forms the core of the system software; it is a compact collection of routines that underlies the rest of the Amiga ROM software. The developers attempted to optimize the Exec for space, performance, clarity of usage, and the creation and management of lists, which are the primary components of Exec. All of the other pieces of the Exec are built on lists and, therefore, provide performance with a minimum of system overhead. You will be able to use even the more esoteric Exec functions once you learn the concept of the Exec list. Exec is the starting point for all the other pieces of ROM software, mostly because it is the controller of tasks and interrupts. Each of the ROM , Kernel software components is designed to stand alone as much as possible; programmers can choose which components to use. But at the...

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.

Anuncio del Amiga de Commodore. se muestran tres chips, y se presume de 4096 colores, sonido de cuatro canales estéreo, 32 instrumentos, 8 sprites, animaciíon en 3D, 25 canales DMA, un bit blitter y voces masculina y femenina

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.

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

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:

INTERPRETATION OF NATURAL LANGUAGE by Jordan Pollack and David L Waltz A potential application of parallelism This article was adapted from "Parallel Interpretation of Natural language!' presented to the International Conference on Fifth Generation Computer Systems, November 1984. THE INTERPRETATION of natural language requires the cooperative application of both language-specific knowledge about word use, word order, and phrase structure and realworld knowledge about typical situations, events, roles, contexts, and so on. While these areas of knowledge seem distinct, it isn't easy to write a program for natural-language processing that decomposes language into its parts; i.e., you cannot construct a psychologically realistic naturallanguage processor by merely conjoining various knowledge-specific processing modules serially or hierarchically. We offer instead a model based on the integration of independent syntactic, semantic, and contextual knowledge sources via spreading activation and lateral inhibition links. Figure 1 shows part of the network that is activated with the sentence John shot some bucks. (1) Links with arrows are activating, while those with circles are inhibiting. Mutual inhibition links between two nodes allow only one of the nodes to remain active for any duration. (However, both nodes may be simultaneously inactive.) Mutual inhibition links are generally placed between nodes that represent mutually incompatible interpretations, while mutual activation links join compatible ones. If the context in which this sentence occurs has included a reference to "gambling." only the shaded nodes of figure la remain active after relaxation of the network. But if "hunting" has been primed, only the shaded nodes shown in figure lb will remain active. Notice that the "decision" made by the system integrates syntactic, semantic, and contextual knowledge: The fact that "some bucks" is a legal noun phrase is a factor in killing the readings of "bucks" as a verb; the fact that "hunting" is associated with both the "fire" meaning of "shot" and the "deer" meaning of "bucks" leads to the activation of the coalition of nodes shown in figure lb; and so on. At the same time, the knowledge base in our model is easy to add to or modify. In this model of processing, decisions are spread out over time, allowing various knowledge sources to be brought to bear on the elements of the interpretation process. This is a radical departure from cognitive models based on the convenient decision procedures provided by conventional programming languages. Our program operates by dynamically constructing a graph with weighted nodes and links from a sentence while running an iterative operation that recomputes each node's activation level (or weight) based on a function of its current value and the inner product of its links---

(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.

POETRY PROCESSING by Michael Newman The concept of artistic freedom takes on new meaning when text processing handles the mundane tasks of prosody For over a year, Michael Newman, Hillel Chiel (a researcher at Columbia Medical School), and Paul Holier (a programmer and analyst for PaineWebber) have been developing The Poetry Processor: Orpheus A-B-G The software is not yet commercially available, but we are pleased to share Michael Newman's thoughts on poetry processing and a module of Paul Holzer's code that shows off some of the new application's capabilities. THE PROPERTIES OF a medium can have a decisive impact on the nature of what the medium conveys. Poetry began in an oral bardic tradition. It was newsy, folksy, evocative of the doings of great heroes. It had to be accessible to folk encountered at a roadside as well as pleasurable to more educated people met at court. There was no great emphasis on intricate forms, on how the poem looked on a page, because the page was not where the poem resided. The poem was voice-resident, ear-active. When Gutenberg invented movable type he did more than spring the Bible. His invention ultimately provided a watershed, an opportunity for the consolidation of language itself — and Shakespeare jumped on the opportunity. He reconfigured poetry, bringing together history, tragedy, and comedy under its roof. And, by casting poetry as theatre, he popularized it immensely. Poetry in print became more permanent, less permutable; more visual, less aural. In this century, with the development of free verse, the poem has become almost a visual object, broken up and spread all over the page. There is even concrete poetry, which makes a fetish of typography. Another world that makes a fetish of typography is software, specifically the largest part of software: word , processing. Software is about as permanent as print because you can always get a printout, but it is much more permutable. And, above all, it is interactive. So what will be the impact of this revolutionary new medium on the oldest, most interactive, programmatic, musical, and image-provoking form of human speech? And what will be the impact of poetry on software? Classical poetic forms— such as the sonnet, the villanelle, the sestina— are natural-language programs, algorithms. The sonnet is a set of instructions specifying 14 lines of iambic pentameter; a line of iambic pentameter contains five iambic units (feet). An iamb is a two-syllable unit with the accent on the second syllable. Poetic algorithms have more in common with programming than their algorithmicness and use of powerful syntax. Poems involve iteration: Not only do iambs repeat and five-beat lines repeat, but ending-sounds repeat (rhyme in a sonnet), whole lines repeat (refrains and rhymes in a villanelle), words repeat (ending words in a sestina). Individual letters repeat in alliteration. This repetition is something poets count, and something poetry readers see and hear. If poets can count these things, so can a computer. If readers see and hear these things, so can the computer user— in an enhanced way. Poems also involve two other cornerstones of computer science: recursion and conditionality. Every sonnet written refers to others of its kind. It...

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):

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.

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:

Tripos—The Roots of AmigaDOS Metacomco is the British company behind AmigaDOS by Dick Pountain A question that must be puzzling many people in U.S. computer circles is, "What is Metacomco?" When Commodore announced its spectacular Amiga computer, much of the U.S. press failed to point out (and possibly did not know) that the advanced operating system AmigaDOS was in fact written by a small British software house called Metacomco. (For more information on the Amiga, see "The Amiga Personal Computer" by Gregg Williams, Jon Edwards, and Phillip Robinson, August 1985 BYTE, page 83.) Metacomco is based in Bristol, England, a city that is beginning to rival Cambridge as our potential computing capital (it also houses TDI-Pinnacle, INMOS, and others). Metacomco was founded in 1981 by Derek Budge and Bill Meakin and now employs ' about 2 5 people, mainly programmers and other technical staff. The company's first product was a portable BASIC interpreter written in BCPL, the forerunner of C, which is taught and used extensively at Cambridge University. This interpreter was ported to the 8086 processor and shortly afterward was sold to Digital Research Inc., which still markets its descendant as Personal BASIC. This U.S. link became very important to Metacomco, for the royalties provided a steady source of income during the crucial early years and helped the company establish an office in California, which kept Metacomco in touch with the U.S. computer scene. In 1983 Dr. Tim King, a Cambridge computer scientist, was engaged by the company as a consultant, and Metacomco's emphasis switched to the 68000 processor, with which King had been working since the first samples came out in 1981. The company produced a series of development tools, also written in BCPL, including a fullscreen editor, a macro assembler, and a linking loader. At that time there was no clearly established standard operating system for the 68000, so the next step was to write one. Subsequently, Tripos was born. The Tripos operating system was based on a multitasking kernel developed as a doctoral thesis project at Cambridge in 1976. ("Tripos" was the name given to the three-legged stools that students sat on in the old days when taking their examinations and has since become the colloquial name for the Cambridge final examinations.) King, then working at Bath University, took the kernel written for a DEC PDP-11 and made it into a full 3 2 -bit multitasking operating system for the Sage microcomputer (which was new at that time). Tripos is BCPLrbased in the same way that UNIX is C-based, and it has many innovative features that I will discuss. Metacomco had also purchased the rights to Cambridge LISP, a powerful LISP interpreter/compiler originally developed for the IBM. 3 70 and then ported to the 68000 at Cambridge. Metacomco produced versions for the ill-fated CP/M 68K and then for Tripos. Reduce 3, a symbolic math system written in LISP, was added to produce a Sage-based workstation that was sold to research institutions in various countries. Customers included SORD in Japan and Bristol neighbor INMOS, who used BCPL, for the first stage of bootstrapping its Occam compiler onto the 68000, using Sage computers running Tripos. In 1984. Tim King joined Metacomco fulltime as Research Director, and Sinclair Research launched the QL. Initially the QL lacked a serious software-development environment, and Metacomco was able to quickly port its development tools, including the BCPL compiler, to it. The company has since extended the range to include an ISO (International Organization for Standardization)-validated Pascal computer, and it markets these products directly, rather than via the manufacturer, largely by mail order. November 1984 is the crucial date in the AmigaDOS story. Metacomco visited Amiga...

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…

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...

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.