Archive for May 23rd, 2020

Gepard – Part 8: The 3rd life of the Gepard

May 23, 2020

Somewhat unexpectedly another person contacted me and told the story of the 3rd life of the Gepard. This person is Hans Carlos Hofmann. I already read his name before as it appears in copyright notices of some of the later versions of GDOS. As it turns out, he can shed some interesting light on the history of the Gepard after the phases I explained earlier. So, in the following, please find his information (translated from German by me). In the following, “I” means Hans Carlos Hofmann.

I received at that time the source code of the compiler from Mr. Müller as well as license to distribute it as a binary for computers of the Gepard architecture. The reason for that was that modifications of the compiler were needed in order to support MMUs (for the Motorola 68030) and FPUs (for the 68020 and 68030).

I, together with another student, then also developed GDOS further as I had a need for computational power. This other student was Harald Hellmann who developed the data processing for the measuring system for the ion drive at the University in Gießen.

I then used the finished system for my theses in Math and Physics so the system was also represented in the “Experimental Physics II” department (Ion drives were and are a topic in the Experimental Physics I department, translator’s note). At that time I validated a program written by Martin Berz, today a professor (at MSU, translator’s note) that calculated ion optics. The validation took place by comparing the results from his program with the ones from my independant implementation in Modula 2. Thanks to Modula, my implementation was more readable, but could not be run on a CRAY. I’m still a little bit proud in that the most errors could be found in his implementation.

The improved operating system that we called “OS/Science” (you will see in a moment why) received many, partially spectacular modules.

The first module was the interrupt handler. The original Gepards did not do interrupt handling, all the PCBs had was a simple jumper to order the CPU to get an auto vector. A program had to handle interrupts itself. If a program exited, e.g. due to an exception, an active interrupt jumped into nowhere, and you had to reboot the computer. All these problems were solved by my interrupt handler by dynamically creating machine code for the current situation. Using this handler, all the drivers were updated, one by one, so no polling was necessary anymore. This ended up that later applications could stand up to 3000 interrupts per second.

Exploiting this ability a “virtual processor” module (nowadays these would be called threads) was developed that ended up in a preemptive multitasking scheduler offering cooperative multi-user management. The latter features was added due to Modula-2 because else the compiler would have needed modification.

After the Gepard Computer company had ceased to exist, not only HS Computer built Gepard clones, but also the MediSyst company of Prof. Dr. Dimpfel (which existed until September 2005, translator’s note).

With my metrological applications I helped a lot of people to get their PhD, enabling quite spectacular presentations like these ones:

The technology of representing data by dynamically generated code was then used in other modules and applications. One of these applications was a Raytracing program from the begin of the 1990s. It computed an entire day for a single picture and heavily swapping data in and out using the MMU as there was 20 times more memory needed as existed physically. Here are some examples of the generated graphics:

Spectrum
Info Graphics
Visualisation of Atomic Force Microscopy

The “Gepards” were then built until the beginning of the 2000s. New cards were added, e.g. better graphic cards. One Atari (ST)-compatible graphics card could be used both for text and graphics, one that could switch between 1 byte color for every pixel and having 8 different, monochrome pixel layers, and one based on an Intel GDP chip that could execute graphics command in hardware. One big strength of the system was that, already in the 1990s, I could use up to four displays with realtime graphics.

Other things added were a SCSI subsystem for hard disks, tapes, floppy disk drives, optical drives, ZIP drives, CD and DVD drives, photo typesetters, a relational DB, a video subsystem, and a NFS V2 server.

Unfortunately, there was no new CPU/memory board among the new things. HS Computer did develop a Motorola 68040 prototype card, but the design turned out to be unusable due to problems that could not be solved in software. In a system like the Gepard where the bulk of the software is compiled by the onboard compiler, there is this chance to compensate for hardware bugs by centrally providing suitable code generation. The same problems occurred when a 68060 prototype was tried out. MediSyst wanted even to develop a 3 x 68030 + memory card but failed out of economic reasons.

The successor company of MediSyst, MEWICON CATEEM-Tec had the last generation of Gepard-like computers in production until early May of 2020(!). Due to the economic consequences of the Corona virus the now 75-year-old owner of MEWICON (and MediSyst), Prof. Dimpfel has now decided to close his company. Therefore, only a few weeks ago I had the honor to switch off the probably last of the Gepards in production – after over 30 years of Gepards still being used at the one or the other location.