Forth in Industry Guy M. Kelly Kelly Enterprises 2507 Caminito La Paz La Jolla, CA 92037 Abstract Some examples of the use of Forth in industry in which I have been involved are outlined in the hope that they will encourage others to consider using Forth for their projects. Projects The following list of projects represents some of my experiences with Forth in industry. Hopefully they will encourage others to consider Forth for their projects. Airline Ticket Vendor Bill (Currency) Validator Navigation System Food Service Package Point of Sale System Graphic Communications Program Fare Collection System Demo Toll-Road Device Simulation Descriptions Following are brief descriptions of the projects listed above. The Airline Ticket Vendor An existing product was an automated airline ticket vendor. It consisted of a credit card reader, an airline ticket printer, many large push-buttons with controllable back-lighting, a modem, control electronics, and power supplies. The vendor was on-line to an airline computer via the modem. Upon acceptance of a credit card, it allowed the selection of a destination (by pressing one of the many buttons) and then issued a ticket. The ticket vendor was expensive to produce and had limited capability. A new less expensive and more capable unit was desired. An R&D project was started to design and demonstrate a functioning model of a new unit. The unit was designed, constructed, and demonstrated to company management and marketing ahead of schedule and under budget. The approach taken was to substitute a color TV and touch-screen to replace the many large buttons, and to use it to interact with the patron. This permitted an almost unlimited set of displays and interactions and even allowed the unit, when idle, to display a video of a customer purchasing a ticket (this attracted potential customers and demonstrated the use of the equipment). The prototype was constructed from the following components: a standard color TV set (modified to accept an infra-red touch screen), the credit card reader, the ticket printer, an Intel MDS-800 computer with an added wire-wrapped custom i/o card, and a pair of 8" floppy diskette drives. The custom i/o card contained the interface to the credit card reader, the ticket printer, the touch-screen, and a TI color graphics chip with video memory and an interface to an external video signal (from a video tape player). Programming was done in a version of Forth called JKL. The application program consisted of modules to control the i/o devices and to simulate airline reservation and credit card data bases plus the main control logic for the reservation terminal. Other Forth programs were written to allow the creation of the graphic displays, the character font sets, a variety of special sprites, and the data bases (for reservations and credit cards). The design team consisted of five persons: three programmers (one of whom knew Forth) and two EEs (one of whom knew Forth and managed the team). A sixth person was occasionally available to provide ME support. Each of the programmers was given a set of tasks. One built all the data base tools and the data base module, another programmed the various i/o modules, while the third programmed the various graphics editors and compilers and the main control logic. I provided training and support to the two non-Forth programmers, designed the video i/o subsystem, and managed the team. The proof of the value of using Forth for the project was that the day before the first demo to a potential airlines customer, the marketing group decided that the descriptions of the menus and program interactions that they had provided us should all be changed to better represent the way that the particular customer did business. As manager of the team, I reminded them that we had provided exactly what they had requested and that they had been invited weekly to look at the results, and told them that there was no way to make the massive changes they were asking for overnight. Unfortunately the other Forth programmer stayed up all night and provided them with the complete set of changes. He was a hero to the marketing group, but, as far as I was concerned, he had demonstrated to them that they could put off until the last minute an accurate description of what they wanted and presto, they could get instant massive changes (a dangerous precedent -- but a great demonstration of the power of Forth). The Bill-Validator A device to accept and verify the authenticity of paper currency was needed for use in various automatic fare collection systems. No commercial bill-validator was available that would meet all the system requirements, so it became necessary to design and build one that would. Because the systems could be installed anywhere in the world, it was decided that the device should be trainable to accept any country's currency and that optical scanning would be used. It was also decided to use an Intel 8048 microcontroller to control the bill-validator and to communicate with the rest of the fare collection equipment. Studies were done on the optical characteristics of multiple bills of each of the denominations of a large number of countries' currency. Black-and-white and color Xerox copies were also studied. These studies suggested a design which involved the measurement of both the reflected and transmitted light from multiple sources (emitting in the infra-red and in the red, yellow, and green areas of the visible spectrum). A mechanical transport was constructed to feed the various bills past the several optical stations. The problem then became: how to control the transport and collect the optical data while a bill was fed through the transport? The computer available was an S100 bus CP/M system with a terminal, printer, and a pair of 8" floppy diskette drives. A CP/M loadable version of JKL was also available. The solution was to interface the S100 system to the bill- validator transport and to extend JKL to work in that environment. The bill-validator prototype electronics were constructed and a simple parallel interface card was built to plug into the S100 system bus and was cabled to the 8048 socket on the bill- validator electronics. This provided complete control of the bill-validator and enabled rapid interactive debugging of the bill-transport and its optical system. After the hardware was debugged, a database of the optical responses of all the samples of each of the various bills was obtained by identifying and feeding all the bills through the transport. Each of the sets of data for a given bill was then subjected to an analysis and the results printed (for study and to suggest further refinements to the optics and to the analysis techniques). When the prototype was operating properly and was meeting the established acceptance and rejection criteria, the appropriate parts of the Z80 Forth program were translated into 8048 assembly code. It was then a relatively simple matter to debug the assembly code since it was a translation of an already proven program that was running on debugged hardware. A few hours with an Intel development system with an ICE unit connected to the 8048 socket of the transport electronics did the job. The Forth program, the CP/M system, and the bill-validator prototype electronics were then used to train the validator for each set of new currency. The resulting decision tables were programmed into the production bill-validator PROM (customizing the validator for the required currency). The use of Forth on this project, especially during the R&D phase was of immense value as it permitted rapid prototyping and testing of the software, the optics, the control electronics, and the mechanical bill transport. Forth was also used in an emulator capacity for testing and operating the completed bill validator, as the bill validator training facility, and for further product enhancement studies. The design team consisted of three persons: a physicist to do the preliminary optical design and to establish the discrimination tests, an EE for circuit design and programming, and an ME for mechanical design. I provided Forth training and system support and managed the development team. The Navigation System The navigation system consisted of an environmentally hardened package which contained a 7" monochrome CRT, a pair of tape decks, a custom membrane keyboard, a card cage which contained a PDP-11/23 computer board and various standard and custom i/o cards, a power supply, and a sealed cooling system with heat exchanger to the outside air. The unit boot-loaded the compiled Forth application from one of the tape units and provided a variety of control, display, and data-logging functions. The primary customers were expected to be various survey ships. The first customer mounted the units in the cabs of snow-cats used for survey duty in northern Alaska (a very cold and vibration prone environment!) The unit accepted real-time input from a variety of navigational sensors including a satellite navigation receiver, and provided local and remote video display of position and steering data relative to the current and pre-planned mission paths. A complete log of the unit's course, speed, and position was stored on magnetic tape. Outputs were available for various timed and positional events. Inputs were provided for logging various predefined events. The design team consisted of between five and seven persons, a mix of software and hardware talents with many of the team members having both skills. The version of Forth was polyFORTH from FORTH, Inc. It was modified to include memory management functions for the PDP-11/23 hardware and a variety of tools were added to support the programming tasks. Full advantage was taken of the polyFORTH multitasker. The development systems consisted of two PDP-11 computers with dual 8" floppy drives and 20 meg fixed disks (with video cassette backup) and up to four attached terminals. The various i/o devices were attached to one of the computers for testing while the other computer was used for tasks that did not need interactive hardware debugging. Each programmer was given a large block of screens on the fixed disk to use for his task. The project leader was given total control of the polyFORTH system. It was his responsibility to re-metacompile as necessary and to maintain the system in as stable a state as possible -- no other programmer was to make any system-level changes. If anyone felt that changes were necessary, a group discussion would be conducted to determine the necessity, utility, and impact on existing code. The project leader would then implement any changes on one of the computers, the other programmers would make any modifications necessary to their code, and the application would be recompiled and tested. When the group was satisfied that the updated system was usable, the second computer would be updated to the new configuration. (A backup copy of each previous version of the system and the application was always archived before the second system was updated.) One of the programmers was designated the documentation librarian. He was provided with the appropriate written input from each of the other programmers and maintained the complete set of documentation. A specific programmer was assigned to maintain each of the major software tools (such as the menu system and the screen compiler). If any of the other programmers wanted changes or enhancements, they would consult with the responsible person who would consider the matter and either explain how to accomplish the desired function with no changes or would survey the group for possible objections or modifications to the request. Each programmer had a given set of programming tasks to accomplish. My tasks included writing the operator interface to the tape data-logging system and the serial interface to the satellite navigational receiver. The project had been under way for about two years before I joined the team, and the first system integration was attempted about a year after that. It took about two weeks of group effort to combine all the modules and produce a fully functional application. At release, the system and application code was over 1500 screens. The consensus was that the application would have been impossible to program in any other language given the hardware constraints (relatively slow hardware and limited available memory) and given that the marketing specifications were a moving target. The Food Service Package The food service industry is involved in the classic scenario of parts ordering, assembly specification, and production scheduling. In particular, large institutions that serve food need to design recipes, combine them into sub-assemblies (such as white sauce) and assemblies (such as Beef Stroganoff), combine the assemblies (also called menu-items) into various combinations (meals) and to estimate the number of meals to be served, scale the required recipes, gather the ingredients (AKA food-items) and assemble (cook) them. There is also the usual need to maintain stock, order missing or low items, handle vendor accounts, etc. Several years ago a local (San Diego) company decided to produce a full featured food service program to handle all the above requirements plus a few. The program was to run on an IBM PC-XT or clone. An estimate of the data base requirements was made and a survey of the existing data base programs, available on the PC at the time, revealed that none of them were capable of supporting the desired application. At about that time a paper appeared in the Rochester Forth Conference Proceedings that mentioned a commercial version of Forth which included a very capable data base language. Discussion with the author convinced us that the capabilities were there to support the application on the PC. The system was purchased and its author hired to program a prototype of the food service program. On delivery of the application, it was found to meet its design requirements and it also provided a working example of the specific use of the Forth system and data base tools necessary to allow the in-house programmers to take over the application and to change and enhance it as necessary. The program has since then been extensively revised and expanded and continues to be a viable product for the San Diego company. One of the reasons that it has been so flexible in terms of modifications and extensions is that the complete Forth system and data base language source code has been available. The underlying system has been enhanced several times by both the original author and by other programmers, and the data base language has been expanded with additional data types and to operate with multiple users on a LAN. These changes and additions were only possible because we had the complete source code, and were able to understand and successfully modify it (in spite of about half of it being in French). The design team consisted of three persons: two programmers and one food service expert. One of the programmers did all the application programming (and now also does any system level programming). The other programmer was in charge of the project and did the major part of the systems-level modifications, and with the food service expert did a major part of the application design. The Point-of-Sale System The same San Diego company decided to enhance their product line by adding a point-of-sale (POS) system targeted to include the needs of school cafeterias. The system hardware consists of a central computer (a PC-XT or better, depending upon the number of attached POS terminals) and up to 32 attached smart cash registers (each register may include a bar code or magnetic card reader and a weighing scale). The system software consists of a set of separate programs. These include the data base program, the POS communications program, the report program, the menu-editor program, and a variety of special interface, communications, and scheduling programs. All of these programs were written in two different versions of the Forth that I placed in the public domain. The design team consisted of two programmers: one did the original system design and the POS terminal programming, the other programmer did most of the rest of the system. The Graphic Communications Program This program is perhaps not an "industrial program" but it does illustrate some of the aspects of team programming in Forth and is yet another Forth application. It is completely described in a set of 1989 FORML papers. The title of the first is "Four Different Programmers, Forths, and Computers" and a complete demo version (including source code) is available on several bulletin boards or from the author. The Fare Collection Demo A different San Diego company in the automatic fare collection systems business recently developed what might be called a non-contact smart-card (tailored to the unique needs of their industry). They needed a program to demonstrate the complete capabilities of the new fare-card. They asked me to take their one page wish-list and turn it into a complete demo to run on a portable PC clone. A complete fare collection system can consist of the following components: system-level computer (to communicate with stations/equipment), ticket encoder (to initialize tickets for use in the system), ticket vendor (to sell encoded tickets to patrons), ticket accepting gates (to allow entry/exit from the system), add-fare machines (to update the value on a ticket for exit), bus fare boxes (to permit the use of the tickets in busses), and ticket readers (to inspect a ticket if the patron has a problem). The demo program emulates all of these devices, includes a data base of all card holders, and can mark any card as invalid. The program is menu driven, and after a sign-on screen, shows the main menu as a menu-bar across the top of the display. The main menu and drop-down sub-menus are shown below: Modify DataBase Use Reader Run Encoder Use System Special Add new Record Read Cards Update PRV's Gate Set S/Ns Update Record Read Data Make from DB Farebox Zero All Delete Record Parameters Parameters List Records Re-index Recs. The program has many context-sensitive help screens and provides a data base editor. It has been very useful in demonstrating the capabilities of the new fare-card and was even pronounced helpful by the most computer-phobic member of the company. The interactive nature of Forth was very helpful in interfacing to a strange serial device, in debugging the serial interrupt routine, and in understanding the ticket message protocol. The Toll-Road Device Simulation A two-way communications capability from a toll-booth to a battery operated hand-held device was desired. The stationary half of the communications link, located at the toll-booth can be considered a modem and is interfaced to a toll-booth computer through the computer serial port. The hand-held unit, carried by the driver of a car, can be considered a microprocessor- controlled modem. To develop such a device would normally require the development of the modems, the mounting of one of them with a battery and a microprocessor on a card, programming the microprocessor, and then trying the completed system. However, there are a number of parameters that must be determined "in the field" before the microprocessor can be programmed. Further, the microprocessor and other components must be determined before a battery can be chosen. It was decided that a better strategy would be to build the modems and then use them to help determine some of the critical parameters before adding the microprocessor and the battery. This requires that a portable computer be interfaced to the driver-operated modem and that the modem and its interface to the portable computer operate from a separate external battery and that the portable computer be programmed to emulate the microprocessor. This was done using Forth as the programming language. The interactive nature of both the Forth high-level words and the Forth assembler made it quite simple to change the emulation program in response to changes made to the modem during lab and field tests. Synopsis The preceding projects cover a range of categories and complexities as illustrated below: Project Type Start Time Size Team Forth Airline Ticket multi-media 79 5 mo 300 5/3 JKL Bill-Validator hardware control 79 9 mo 100 3/1 JKL Navigation real-time multi-task 80 3 yr 1500 7/6 poly Food Service multi-user data base 84 3 yr 1200 3/2 Morton Point-of-Sale real-time, data base 87 3 yr 1500 2/2 Kelly Graphic Comm. interactive comm. 87 9 mo 580 4/4 4 4ths Fare Demo system simulation 89 2 mo 330 1/1 Kelly Toll-Road portable comm. 90 1 wk 40 1/1 Kelly Start approximate year project started Time approximate weeks/months/years required to take project to first release (several projects on-going) Size approximate application size in number of screens used (navigation and food service now well over 2000 screens) Team total number of team members/number of team menbers programming It is interesting to note that the screens per programmer-month (S/P-M) for the first five projects range from 7 to 20 and the average is 15 (or about 3/4 screen/day). Not unreasonable for the typical work environment (where only about 1/2 the time is available for productive work). The sixth project (Graphics Communications) involved four different Forths, programmers, and machines. Some of the source code was in screen files but most was in text files. The total size of the various text files for the Amiga was well over 1 meg. The screen file total for the PC was about 580 screens (the smallest of the group) or a rate of about 60 S/P-M. The high rate was a result of spending at least 95% of each 12 hour/day (six-day-week) programming. The seventh project inherited most of its code from the fifth and sixth projects, which explains the 160 S/P-M rate, and the eighth project inherited most of its code from the seventh project for the same 160 S/P-M rate. (Just goes to show what kind of gains can be made by re-using lots of code!)