I was employed at the same time as Klaus Gorm Jensen, in the tape recorder department. We contributed a little to the clarification of the system concept, but did not program at first.
In addition to the Master Control Panel, I made software for the one-way terminal and for the small tangential gramophone 59xx. Both of these were coded in small 4 bit processors, each with 500 nibbles of ROM. So the code was crammed in bit by bit.
The gramophone 59xx was a technical hybrid, i.e. a 4-bit National COP microprocessor-controlled mechanical thing, where all system states (cogwheel position) of the apparatus could be related to the contents of a table of legal states. The program thus became a data-driven execution with very little program logic. And optimal in terms of limited resources.
A few of the negative experiences we had were:
The evaluation equipment was typically implemented in Nmos/Pmos technology.
If the target chip was CMOS, there could be differences in the reset circuit that had to be taken into account. The I/O ports had to be specifically initialized with a value at Reset.
Applies e.g. to the NEC chip in the Master Control Panel.
The workshops were not good at locating faults in the microP system (board).
As a consequence they typically replaced the whole board, where there was for example only a bad connector. By inserting a new board the “fault was gone”, but actually it was the connector that just needed cleaning. We got the “faulty cards” back to the lab and found that there was no fault.
To improve serviceability, we built various test routines into the software that could automatically test and detect functional errors on the board.
I also created software for the first ATS (automatic test system) in production (for Stig Frøsig). A pickup test system ATS2, where Villy Hansen was the “customer”. Developed and run on HP 21 mini, and coded in a combination of Fortran and assembler. All pickups were tested by playing a reference record. Various signals could verify: output level, channel difference (balance), channel separation, trackability, amplitude response (frequency).
This system was followed by a system for use in shops, so that customers could have their pickup tested – and of course buy a new one. This was before the days of PCs so we used a Rockwell AIM 65/40 portable single-board computer. It had a small printer so the customer could get a printout of the pickup’s data/spec. The program was coded in Basic and assembler for the time critical measurements.
The bad experience you had with Texas Instrument, regarding chip delivery, we also had in TV37xx. Teletext in France was a problem, the Texas chip was delayed and could not be delivered. Jørgen Aaberg and I were in Valbonne, but it didn’t help. I don’t remember what the alternative was.
Tom mentions simulation of BM 9000 as an important means of persuading and convincing management. I remember how the integrated AV system (where TV 37xx got AV link) was welcomed by Ole Terndrup, but totally rejected by Frederik Petersen, who said: show me which plug/pin the link is, and I will personally cut it off. So there was some resistance.
We had our new code format where the device is addressed, so it was easy to enable any function in the TV as desired/needed. Which I said to Møller P.
There could be an interesting chapter on the operating philosophy, simulation, and the tools Tom had at his disposal (Mac), and the operation simulator, where Gert Lykke Møller came on the scene together with Flemming Ask Sørensen.
Gert was supposed to do a PhD in the IT department with Niels Bo Theilgaard, on a production related topic, but chose to do the project with us (crazy people!), after meeting us!
Specifically, Gert’s ideas found application:
1) at the 37xx development, where operating functions were defined in the form of tables (key tables), for direct running of software in the device. Errors were thus excluded. Tables defined by the Erik Albert Jensen and Subir Pramanik operating group.
2) Service and Installation Guide, which were some A4 folders in paper format, were replaced by a PC application with interactive selection of options. In fact a small AI system where options and combinations were always legal choices. Jens Harder from Service was our customer.
By the way, I spent some time researching alternatives on the market, such as Prolog and Lisp, and we found that with Gert’s procedures we could make real-time systems with small means, which was not the case with the above.
While working on the user interface simulator, Gert generated ideas as part of his PhD project. Basically a system with a data-driven mechanism, as described in the issued patent US6158043a “Signal Processing Apparatus”.
This and related technologies became the basis for establishing the company Beologic, for commercial use outside B&O (see attached timeline for Beologic).
Jens Bang was not a big fan of microprocessor technology in products, but it became a necessary “evil”. The “last bastion fell” when microprocessors were introduced in loudspeakers. The Penta loudspeaker got an appliance link and a display to show the current status. At the idea meeting where it was decided, I remember how Jens’s resistance was genuine, when he said “now it’s become completely crazy, a computer in a speaker?”!
We could then argue, “we’ll take it out, but then you won’t get such and such”.
Leave it in there, we concluded.
We typically used a system configuration with two circuits: a main processor and a port expander. We, myself and Jørgen Selmer, used this configuration where two processors have to run completely synchronously. This was implemented via a simple handshake protocol.
Arne you have mentioned that you do not recall defects in the products caused by s/w and that is fantastic. If you multiply the number of customers who have products with x number of processors on board, it would be fatal if fixes had to go out to customers.
We did have one error, reported by one customer. The machine, I think it was the BM 5000/5500, which started in the middle of the night and at full volume! Jan Simonsen spent most of a month in Factory 5, to provoke the error. We suspected that moonlight modulated with a little cloud cover would produce a start code. The light, manipulated slightly, from all the fluorescent tubes gave somewhat the same effect. Thus, it was not a s/w error. The solution was to adjust the AGC appropriately (reduced sensitivity).
Next chapter: Appendix 4: Contributed by Jens Harder
More documents are available for download from the Danish-language version of this chapter, including some about Beologic in English.
Microprocessors in B&O consumer products 
