Using an internal battery data can be kept for up to 12 hours in RAM during a power outage (3 hours garanteed). Also, by using a turnknob, some memory areas can be locked from access by the processor, these locked out sections can then be manually addressed as private memory. By using virtual memory access, it even had some sort of memory protection.

The picture at the left shows two SICOMP M80 machines which were in operation as terminal and database servers for a laboratory of the Uni-Klinikum Erlangen 24 hours a day. The machines needed its own air conditioning system - nothing unusual back then, the CPUs drew about 2000 Watts at 220 Volts, the HD boxes about 1700 Watts at 220 Volts (thus producing up to 6660 kJ/h). The CPU and HD containers each had two powerful fans built in - yes, things were different a few years ago: consider a FD044 8" floppy drive consumed about 180 Watts...

Measuring about 55x120x80 cm they weren't small either - and surely not lightweight (about 250 kg each). Though being large does not mean being slow or unusable. The M80 was quite superior. It could manage up to 11 SCSI-I/SCSI-II harddrives, 300 MB each. It also contained a 5.25" floppy drive, a tape streamer and some MO-drive which was added later (594 MB).

There were also some interesing hardware components such as a buffered realtime clock (nothing special yet), a timer (alerting the system using interrupts) and a periodical alert used for starting system jobs which needed to be run from time to time.

A large number of the printers attached to it were DR205 types, really large beasts with sound proof casing. The DR205 was able to print up to 1760 characters per second and could also print graphics and barcodes.

The picture at the right shows a large (and unfortunately quite shaky) shot of the front panel of one of the CPUs.

Attached to those M80s were about 20 Siemens "Sichtstation DS 075 B" terminals ("Sichtstation" is a really weird and bureaucratic german translation of "video terminal"). They have quite large green screens (maybe 15") and use (at least that's how i feel) very comfortable to read fonts. They can display 128 different characters and control characters, at the bottom there were two lines which make up a status display.

Available screen colors were white, green, orange and paper white. As an option, also a graphics extension (including mouse and graphics tablet), RGB connectors, an internal magnet card reader, a barcode reader and a key switch for access control were available. There was even some DS 075 available which emulated a DEC vt220 :). The keyboards feels really good (much better then today's PC-Cherry-Keyboards some people say), though they have a _really_ ugly design.

The terminals are quite lightweight (13kg - keyboard: 1.8kg!) for their size, but seem to be incredibly clumsy and take a lot of space due to their shape and size (about 32cm high, 41cm wide, 35cm in depth). Of course this is not only a disadvantage: I was told those old Siemens terminals are very quite easy to service as everything is well accessible and easily taken apart. It's interesting to notice that they even got some screen blanker: after a few minutes of inactivity the screen goes black and can be restored by pressing any key.

It seems they can't be used with any other machines than the SICOMP-M series, as they run a highly proprietary protocol named "DK3964R" ("LAUF"-procedure) using some sort of block mode known from IBM mainframes, too. The serial lines of the terminals (V.24/V.28, X.27 or 20mA/TTY lines at up to 19200 baud) were connected to so-called serial PROMEA-MX-cards which were located in the container of the M80 itself and in some add-on box to which the system bus was extended. Due to intelligent I/O-management the subjective performance of the machine is very high. 50 terminals, 30 line printers and 40 serial ports controlling machines can be attached to an M70 without any trouble, the CPU will not hit its maximum load. Also the M80 seemed hardly bothered by many of the terminals being worked at, the CPU load always remained low. The manual says it can serve up to 80 TTYs.

Some interesting I/O cards

There also were two 10 MBit ethernet cards. One ("DU03") only was doing the OSI-1 and OSI-2 layers, the other one ("KS100") was advanced enough to also handle OSI-3 and OSI-4.

The "DU06" I/O card used HDLC (and SDLC) via V.24/V.28, V.36/V.11 and X.21/X.27 at a speed of up to 72kBit/s and could be connected to DatexP, DatexL or ISDN networks.

Other interesting hardware devices which were not part of the system I photographed were a MB60 reel tape drive for 1/2" tape (730m/150 MB, 120-470kB/s, 1800 W, 200kg) and a hard disk platter drive PS 048-B (250 MB MFM/12 platters, 1200 kB/s, 2000 Watts).

Operating Systems

The system was running the "AMBOSS 4.0" (BS4) Operating System. The userinterface and the databse of this lab system was completely written in FORTRAN, the hardcopy of the source filled numerous binders.

AMBOSS offers multitasking, 10 priorites for programs to be run at, and some sort of I/O quota. Additionally, it offers a spooling system that operates using virtual devices. At max. 4094 processes, which are identified by program names or process numbers, can be simultaneously. The process priority can be specified at program start or during execution. Without segmentation the maximum size of each process is about 130kB.

Files are identified by device and filename. Within the libraries (some sort of directories which may only contain files, but no other libraries), files are identified by specifying device, libary-type (data/text/source/...), library name, filename and version of the file (similar to VMS). Files could be protected by means of write-protection, ownership and some group mechanism.

Regarding processes, the system can give information about type, size, priority, state and segmentation. Concerning the CPU, the system gives information about CPU-consuption of the OS (system), CPU-consumtion of the user processes (user) and idleness of the CPU.

Each system has some sort of system console called "Standartmeldegeraet". You can restrict certain OS commands to this console by specifying border program numbers - programs with IDs below the border may only be run/controlled from the console. The "shell" is called "Standartbedienprogramm" (short: SBP; it means: "standart operating program"), though it's no real shell - more like a mixture of menues and forms/prompts as far as I know. Logging of errors, system calls and I/O operations (log-level can be specified) was done to a file or log printer.

The languages available for the system were, among others, assembly, C, Pearl (no typo!), Fortran and Cobol. There was some quite interesting editor named "MEDIS-M" for SICOMP-Systems. Nothin special about it, let alone the fact that there was no need to save the changes done to the file - you edit the file directly on the diskdrive, byte by byte!

Emulating SICOMP M80...

Who uses/used such a system?

According to an article which was published in "Nordbayerische Nachrichten" Wednesday, 22th of September 1999, M-machines are also used for controlling the traffic lights of Nuremberg, Bavaria. Just as in the former case, a Siemens terminal can be seen on the picture. Unfortunately, in contrast to the very friendly and openminded people at "DER SPIEGEL" and "Meldepress", the people at "Nürnberger Nachrichten" (who publish "Nordbayerische Nachrichten") did not allow me to show the picture on my webpage, i'd have had to spend quite some money in order to aquire the rights for the picture first.