Memory constraints were a problem with most applications, and it might be necessary to either switch to a processor with more memory or limit the features to be implemented. The program for Beocord 5000, which was part of Beosystem 5000, was written by Klaus Gorm Jensen. Since it was only a few bytes too large for the processor, we sat down together and went through the program line by line. And then it was a matter of exploiting all the space-saving methods available. Although they probably bent the rules of good programming practice a bit. However, we managed to save enough space for the program to use the chosen processor, and with all the required functionality.
Due to the very limited resources of the microprocessors used, there was no capacity to run a ready-made real-time system. Everything had to be programmed from scratch, with interrupts of various types (timer, counter, remote and similar), and with prioritisation of tasks as required. Most programs I wrote had a timer interrupt function that interrupted the program every 1.04 msec, and which performed the time-critical functions such as reading and sending remote control codes, multiplexing display digits, reading the keypad, updating the clock and counters. Most other functions which were not so time critical were performed in a longer loop which was either repeated immediately after each run, or started with a fixed time interval from the previous iteration. A complete loop could typically be completed in less than 5 msec.
For those familiar only with more modern development tools, it may be difficult to imagine how programming and testing were done, and what limitations had to be lived with in the infancy of the microprocessor. You were tied to the development systems that vendors could offer, and they were all different and very expensive, with prices well over $100,000 not uncommon. All programs were written in assembler, and there was an art to saving program space in ROM and data in RAM to get as many functions as possible into the available memory.
As mentioned previously, many of the development systems had very noisy fans for cooling, so I was often placed in a small enclosed room so that the others in the project team would not hear the noise, or tucked away in a corner as far away from the others as possible. On the Rockwell systems, Tom Jelsing made a modification so that the fans ran at half speed. There were never any problems with them getting too hot, but the noise was reduced to an acceptable level.
For programs with 3,000 or more lines of code, such as in the Beocenter 7000 program, making changes can be a slow process, especially when the program is stored on cassette tape as in the TI terminal. The program is printed and the changes are noted in the program list. Then the changes are made consecutively by deleting the original line(s) and inserting the new ones or replacing text in a line with new text. The edited program is written to a new cassette and assembled and tested before repeating the process. This was somewhat faster with screen-based editors. The large 8″ floppy disks did not have a very high capacity, but they were considerably faster and easier to use than cassette tapes. And a screen editor such as Credit could save considerable time compared to a line-based one. The Rockwell system used 5.25″ floppy disks. The Philips system was the first development system we had with a hard disk.
It could also be a time-consuming process to burn an EPROM version of a program. The EPROM writer for the Intel equipment had different expansion cards, depending on which chip you wanted to burn. The burn itself could take several minutes, and usually both the processor and external memory chip had to be burned. And in the Beocord 9000 case both the processor chip and the two external memory chips.
The development systems were delivered with an In-Circuit Emulator (ICE) for the processor used. An ICE consisted of a plug-in card in the development system, a thick long cable to an external box and from there a short cable or ‘umbilical’ to a connector, corresponding to the pins of the microprocessor. The emulator was controlled from the development system and one could insert breakpoints, single step, trace, read and edit RAM and ROM contents and perform various other functions to speed up the development process. However, there were also some limitations, especially when interrupt routines were used in the programs. Although the Intel 8048 and 8049 processors were almost identical except for RAM and ROM space, they used different ICE modules.
The functions in 8048 and 8049 programs were mostly placed manually within 256-byte pages to make the best use of space. If you happened to insert code so that a routine spanned two pages, you could almost be certain that the assembler would come up with errors because there was a conditional branch instruction to an address in another page. A single inserted instruction could result in an assembly with hundreds of errors.
Mask programming of the processor and external memory was a lengthy and costly process. We had to be very sure that the program worked correctly when it was shipped. It was shipped in hex code (hexadecimal code) on a floppy disk and in an EPROM. A few weeks later, a printout of the program in hex code arrived in the mail, and you could then go through and check each line (every 16 bytes) to make sure that the checksum matched what you had sent. After approval, a few more weeks passed before the first mask samples arrived. These then had to be thoroughly tested before they were approved and mass production could begin. There was a large price difference between an EPROM version and a mask production version, but as far as I remember the first Beocord 9000 sets were produced with EPROM versions.
At that time there was a rather high import tariff in Denmark on some electronic components, including microprocessors. There was a significantly lower tariff on microcomputers. So it would be cheaper to import a circuit board with components mounted than it would be to import the components and mount them in Denmark. B&O considered that a single-chip processor, i.e. a component with all the features of a small microcomputer, such as logic, program memory, data memory, and input and output capability, should be classified as a microcomputer and not a microprocessor. I made a presentation, including references from Intel documentation, that referred to their 8048, 8049, and 8051 as microcomputers and not microprocessors. Together with B&O’s customs expert Niels Eriksen I went to Copenhagen in an attempt to convince the Danish customs. As I recall, some time later B&O ended up being allowed to import them as microcomputers with the lower tariff rate, but only 8- and 16-bit versions. 4-bit microcomputers apparently continued to be classified as microprocessors. It seemed rather illogical that it would be cheaper for B&O to have Intel (or other suppliers) mount our components on a circuit board before they were shipped, disassemble them, and then mount them in the product than it would be to import them as components.
Software development was done in parallel with electronics and mechanical development, so there could be limitations on what was available for functional testing of the software. A chipboard setup was usually built, which could be as simple as some LEDs to display output values and push or toggle buttons to set inputs with only the necessary components required for the microprocessor to run. Printed circuit boards and mechanical parts such as tape recorder drives could then be added as they became available. Pictured is a chipboard model that was used to develop the Beocenter 7000 program.
The first few assembled devices, called lab samples, presumably from when the product development department was called the laboratory, could be used to test all the functions. They ran EPROM versions of the microcomputer and program memory. Next came the first trial production run, again in limited numbers, and again with EPROM versions of the program. Later came the second test production run followed by the final production with mask programmed ROM versions from the microprocessor supplier. When no longer needed, lab models and devices from the first trial production were often given to project staff on the condition that they were never sold or given away or repaired at a dealer, and that they were used for long-term testing and troubleshooting.
In 1983, Søren Borup Jensen wrote a comprehensive 72-page document Micro processor software development methodology. As the summary of the document says:
“The report is addressed to designers as well as coordinators and project managers of products incorporating micro processors, and specifies a number of methods that can (and should ?) be used in the development of these systems.
In principle, the S/W documentation structure given can be used for other than microprocessor projects.”
The document (in Danish) was adopted for software development from 1984, and can be found on the Danish version of this chapter.
Next chapter: Input and output
Microprocessors in B&O consumer products 