About / Project80 aQute - Software Consultancy
Search
*

Projects in the 80's

HTS Alkmaar

1977-1981 Visited the HTS Alkmaar study electronics.

Product Information System

1979 - In 1979, while in school, I sold a Product Information system for a newspaper organization. The system would track the production of each page during the day. At the end of the day, the production plan was input in a Northstar Horizon computer with CP/M. When the production started, each department would enter the page production number on a terminal. The computer would then adjust the plan and calculate any delays. Throughout the building there were monitors that listed the 10 pages that were closest to their deadline. The system was originally developed in a Nascom computer, an Z80/8K RAM (after extending it) board that I had put together from a kit. Initial demos required loading the software from the tape 3 times. The keyboards had to be specifically developed. All software was written in Z80 assembly: LDIR (ED B0)!. The system was in full production until 1993 without any major changes.

NEC News Kansas City

1979-1980 - In 1979 I spent 9 months in Kansas City working for NEC, a small company developing newspaper editorial systems based on microprocessors. The architecture was quite elegant. They bought "intelligent" terminals from Beehive and replaced the on-board software with their own editing and communication software. A central router (serial rS232, not TCP/IP!) allowed the terminals to communicate with one or more storage devices. At first, I was put at repairing the Beehive mother- and IO boards, which was dreadful. After a few months an engineer visited Holland and had a wonderful time. When he returned he took me in his custody on the research and development department. There I executed a large number of projects. One skunkworks project was speeding up the traffic router. A hack increased the speed ten-fold. This did not make my boss happy because it demonstrated that the terminals crashed when they received data faster than 25% of their specced speed. Other projects consisted of interfacing to other systems and developing the hardware for a serial port multiplexer. i also prepared all the software changes for a new customer in Perth, Australia. All code I had to write in this period was assembly.

Traffic Router

1980 - After my return from the states I was asked by the importer of the NEC system to develop a new version of the traffic router. I aligned this with my final thesis work for the HTS Alkmaar. This router was based on standard CP/M hardware, albeit high-end.

NEC News Support

1980 - The importer of the NEC system ended up in bankruptcy. A collegue at that company and me decided to start our own company: Array 80. We helped existing customers and started developing our own software for an editorial system because we felt we could do the system significantly better than NEC.

Editorial Terminal

1980 - The first project for Array 80 was a replacement for the NEC terminal. The Beehive company had produced much more modern versions of the terminal with better electronics. One model had a 8085 processor, 12K of RAM, and a very interesting display processor. The display processor was loaded by a DMA controller, the unique feature was that it had special codes for the end of a line and the end of a screen. This allowed the editor to maintain a single data structure for the text buffer that was directly read by the DMA/Video processor. The result was lightingly fast screen updates and no video buffer overhead. Despite the slow CPU and lack of memory, the terminal was loved by its users for its speed. All code was written in 8085 assembler running on a Norhtstar Horizon CP/M computer.

Linotype Link

1981 - Damiate Pers wanted to link the NEC system to their Linotype typesetting system. We found out that some of the Linotype terminals were using a serial interface. We analyzed this protocol and wrote an emulator. This enabled us to send and retrieve stories from the Linotype system as well as control it. This code was written in 8085 assembly.

Editorial System

1981 - In 1981 Array[80] received an order to develop a complete editorial system with ten terminals for a location of Damiate Pers. The printing presses had been moved to a central location, requiring the editors to send their articles to Haarlem. The editorial system was intended to simplify this processs. Paul Band (co-owner of Array[80]) and I moved to a remote location in the northern part of Holland. The location did not even have roads, we had to move in the computers by boat. We spent 6 months developing a complete editorial system. The system was based on the Intel Multibus hardware. The CPU was a 12 Mhz 8086 with 32K of RAM. The IO was handled by up to 4 Multibus serial port IO cards which had their own 8085 processor. We wrote the protocol software for the terminal on the IO board and developed a memory-memory protocol to get the data in the main processor. Both the IO boards and the central processor ran a multitasking executive: RMX 88 and RMX 85. The terminal was further developed and communicated with the IO boards. The core software had to develop its own database and file system software because the RMX executives did not have a file system. The file system was based on 10 Mb winchester disks, which turned out to be extremely unreliable. All this was written in 6 months and totally in assembly. In december the system was delivered to the location. I will not deny that we had many problems but since that day the newspaper has never lost a run.

Editorial System, version 2

1981 - Array[80] was disbanded because Paul Band felt that the system was good enough to sell to other companies while I felt it needed a rewrite badly. Damiate Pers, satisfied with the first attempt, was willing to fund ongoing development. Due to a freeze in hiring, I started a new company, Micrographics that was hired by Damiate at significantly more cost than an employee.

The new editorial system was based on RMX-86, which actually had a file system and networking software. The ambitions of the new systems were significantly higher. The database became distributed, the architecture allowed up 16 systems in a cluster. Each system could backup parts of each other system. It was possible to unpower a system and within seconds the other systems would take over. When the culprit came online again, it would automatically synchronized any missed data before it would server again. The database was self-written and highly optimized to serve the articles at high speed, despite the slow hardware. The network we used was Ethernet, albeit not with TCP/IP. At that time, the politically correct network was OSI. This system was written in PL/M, a language developed by Intel, similar to C.

Justif

1982 - A key aspect of any editorial system is the Justification program. Initially we had focussed on the text processing and not on the typesetting; this aspect was handled by the Linottype systems. However, this meant we could not show the length of articles and their line endings to the end user. We therefore decided to develop an H&J program: this became Justif. The key requirement of this program was flexibility. This program had to run in the central processor because it needed to prepare the articles for the type setter as well as perform H&J tasks for terminals that did not have the power to run H&J (our 8-bit terminals). However, we had started an 80188 based terminal that could run the H&J. The program also had to handle a large number of typesetters, unlimited fonts, and it even had to be useful driving a display. Justif is probably one of my best architected designs. The core engine is completely decoupled from the article input, article output, width tables, and hyphenator. It reads a text stream and it generates an output stream with line endings, or a stream with typesetter instructions. This latter stream is easy to interface to typesetters but writing a display driver is also possible.

The H&J module was developed by Aart Arts, a student from the University of Utrecht. I had liked the hyphenation algorithm that Donald Knuth used in Tex very much and after a visit to Stanford had decided to adapt it Dutch and German. The algorithm uses statistics to find common patterns. However, the Justif program could easily work with other hyphenators.

Justif has been used in an amazing number of programs over time. In the 90's it was translated from PL/M to C. It is likely still in use today.

New Terminal

1983 - The old 8 bit terminal was starting to show its age; we needed a terminal that could run Justif locally. After researching the market we decided to develop our own terminal based on an 80188. The housing, monitor and keyboard were to be bought from Beehive. We wirewrapped a prototype (possible at those speeds) and developed the base software using RMX-88 and PL/M. The terminal was using the same video processor as the old terminal. The display was highly improved with a downloadable character generator and 16x16 matrix. We moved all the editorial software from the 8 bit assembly to PL/M.

ISIS Emulator

1984 - Our initial developments took place on an Intel ISIS (blue!) box. ISIS was the operating system. In 84 the PC started to conquer the market and we therefore quickly switched to PCs. Unfortunately, there was a lot of very good software that ran only on the blue box. I therefore wrore an 8085 emulator on an 8086 chip as well as an emulator for the ISIS operating system functions. This program was sold many times to Intel users.

Preview Terminal

1985 - The development of the new editor terminal was highly succesful. This was partly due to the excellent support we got from Koning & Hartman, the Dutch importer of Intel. This made us brave enough to develop a graphic terminal based in the same housing but with an 80186 processor, more memory, and a highly specialized graphic video processor. This video processor could use display lists anywhere from memory. The idea is similar to the character processor of our terminal but now it could handle grapics. Software was written to interface the Justf with the graphic processor. The speed was amazing for such nimble hardware.

Mediasystemen

Damiate Pers had set up a separate subsidiary for handling the editorial system after they realized that we had $4 million in orders for a department with no staff (I was consultant and had 3 trainees). The subsidiary was called Mediasystemen, I was employed as Technical Director and responsible for all R&D.

Page MakeUp Terminal, Memphis

1985 - Memphis was a formidable step. The increasing power of computers made it possible to use grapics, with as final goal the possibility to layout a complete page on a computer. The system at that time printed galleys. Long strips of paper that contains headlines, intro's, bylines, mastheads, etc. but still required a person cutting and pasting the full page together. In 1985 we decided to develop a terminal with that goal. I first spent time selecting the language because I felt PL/M had had its time. I looked at Prolog, Lisp, C, and Smalltalk and decided for the last. We created a team of students and we developed a prototype. This was not easy, because we needed at least a display of 1000x1000 and they were just not available on the PC. We had to develop our own interface from Smalltalk to the display. This prototype had lots of interesting behavior but was awfully slow. This prototype cost us a potential customer because he could not make the mental step that the real system was going to be much faster. The terminal required the development of a language, a complete graphic windowing, a script language, and an amazing amount of application software. The use of the script language (called EGO) was remarkable, it allowed us to keep a lot of custom wishes outside our core code base. Most of these requests were implementable in scripts. If not, we analyzed what core primitive we missed and then added these primitives, which could then subsequently be used in a script. Memphis has been in production for over 12 years.

CO2, C Object Oriented

1985 - The slowness of Smalltalk made it necessary to write the page makeup terminal in a faster language. However, we got hooked to the possibilities of object oriented programming. Everything in Memphis was an object. In the market there was only Objective C from Brad Cox. Unfortunately, Objective C required a pre-processor and this made it impossible to use Turbo-C, our highly preferred IDE. Objective C uses square brackets to switch between Smalltalk like syntax and C syntax. For example, [object message: 42 ], this obviously required a pre-processor. After some thinking I realized that in C the first object in a method is always the last on the stack to allow a variable number of parameters. It would be easy to vector all messages (the generic name) to a common function that would inspect the first object to see what class it was and then dispatch to the correct method belonging to the class. The messages functions could easily be generated by a program called syntor. The dispatching was highly optimized and due to some very intricate tricks had hardly any overhead. Even Brad Cox liked!

Mouse with Wheel

1985 - After heavily working with normal mouses in Smalltalk I started to feel the need to have a more analog based mouse. Page makeup requires many small adjustments: darker-lighter, bigger-smaller, more contrast-less contrast. It seemed there was a need for a mouse that had an extra dimension. After toying with this idea for some time, we decided to develop our own mouse, based on Logitech electronics. We asked a student of the Hoge School Delft Industrele Vormgeving to develop the casing. We specifically adapted the software of Memphis to support this mouse. This was not hard because the wheel mouse used the left and the right button switches when it rotated. This mouse was developed ten years before Microsoft received its patent on a mouse with wheel.

Font Editor

1985 - Fonts are a crucial aspect of a page makup terminal. Today displays have sufficient resolution to support outline fonts, in those days it was necessary to have different sized bitmap fonts. Many fonts could be bought from companies like Bitstream, Linotype or others. However, formats were wildly different. We therefore had to develop our own font editor that could read the different formats, edit the character maps and sometimes add new custom characters. This editor was written in Smalltalk. Smalltalk had turned out too slow for Memphis, but it was still much more productive than any other language.

Interestingly, after publishing an article in a magazine, a rather well known Dutch designer Petr van Blokland reacted. He had been working for a German font company and had also designed a font program for the Mac. I visited him and we have done many projects together since then.

Sports

1986 - One of our customers was publishing a sports magazine. This magazine required lots of match results to be maintained and formatted. I developed a program running in the (old) terminal that handled the results, sorted them, and layed them out.

RAS, classified ads

1988 - Some of our customers were looking for a solution to their classified ad problems. Classified ads are taken over the telephone or on the counter. This requires a complicated pricing procedure. In the end, all classified ads must be selected, sorted, and layed out. Pricing and ad taking is clearly in the administrative realm but layouting is awfully had for administrative software developers. I therefore developed a Smalltalk program with a shared database for the ad taking. The application could then layout pages from this shared database.

Cable News

1988 - In 1988 the Dutch started having cable TV. The density of the country allows up to 90% of the residents to be cabled. Damiate Pers realized the opportunity and started a newspaper on the cable. We were asked to adapt the editorial system so that it could be used for a cable newspaper. This model has obvious synergies because the same article database can be used. After some analysis we decided to use Justif as the base. Justif was easy to adapt to generate the graphics, we only needed to add a few primitives for pixel addressing and picture handling.

Copyright 2006 aQute SARL, All Rights Reserved