HP75000 Series C (Agilent E8401A) VXI Mainframe

The text below describes a HP75000 Series C mainframe. I also have a file describing a HP75000 Series B mainframe.

Meanwhile this beast occurred in my lab…

This is a large, noisy, but super-flexible VXI solution. All 14xx modules from HP and all older 13xx modules (with adapters) can be used inside this mainframe.

HP 75000 in general

The HP75000 is a VXI mainframe. A VXI mainframe is a standardized infrastructure where individual measurement devices can be simply plugged in and used. This is only possible because the two important areas of standardization have been addresses by VXI:

  • Hardware: VXI defines the physical layer where devices, even from different vendors can be integrated. The hardware layer includes electrical characteristics, wire protocols and such.
  • Software: VXI defines the software related characteristics to access and control the devices plugged into a mainframe.

By having standardized both software and hardware characteristics, devices can be developed by big Vendors like HP and used in any VXI infrastructure.

Each HP75000 mainframe has a backplane offering several slots to plug in devices.  A mainframe needs a controller („command module“) which coordinates the devices plugged in and which communicates with the outer world, e.g. with a PC connected.

HP75000 were sold in three versions, named  „Series A“, „Series B“, and „Series C“.

HP 75000 Series C

The HP75000 series C is a VXI mainframe offering 13 „C-size“ slots for modules.
There is no built-in command module (like in Series B). A Command module must be added in Slot 0. This module can be a command module with RS232 and GPIB input or a specialized single board computer that fits into a Series C slot. The module in Slot 0 is responsible to control the devices and to communicate with the outer world.

For HP75000 Series C, the following features are important:

  • Devices like Multimeters, Frequency Generators, Digital I/O Boards and Switch-Boxes (Multiplexers) can be inserted
  • Access from PC to the VXI mainframe is (for the HP75000) via multiple ways like LAN or RS232

Details on slots: 13 C-Size slots, all with P1 and P2 connectors.


HP Agilent E8401A C-Size VXI Mainframe

Up to 13 modules can be inserted. The Mainframe supervises power condition. For example, I soldered my AUI transceiver adapter cable together in a wrong way, thus shorting the +12V and GND lines :-((( . This was no problem at all, the mainframe came up with SYSFAIL condition and nothing else happened…


HP E1498A Controller

This is a real beauty on its own. The HP E1498A is a complete VME-Slot-sized  UNIX workstation. Inside there is a single CPU (PA-7100LC, PA-RISC version 1.1c 32bit) with 100Mhz and up to 128MB RAM.

Regarding names The CPU and/or Board occurs in documents as „s700“. The board seems also often to be called V743 or V743i. But, at least I have seen a board called also v743 in B size formfactor.The hardware offers the usual connectivity like:

  • Keyboard, Mouse (standard PS/2 connectors)
  • Video
  • Network (AUI)
  • SCSI (50 pin HD connector)

Because its an VXI controller we also have:

  • GPIB
  • several system clock and trigger connectors

The operating system is a real UNIX from the old days, namely HP-UX 10.2.

Below are some pictures of the HP E1498A.

Right : CPU with cooler. Mid: 4 RAM modules 4x32MB=128MB.




PA-7100LC CPU @ 100Mhz

SCSI cable, some socketed PROMs containing the Boot code




There are two multi-pin connectors for mezzanine cards



NVRAM/RTC battery


3 big FPGAs are doing the peripheral work like SCSI, network etc.


Boot ROMs





HP-UX 10.2

Note that HP-UX 11.x will not run on the CPU.

HP-UX 10.2 is from the late 1990ies. But no worries. I have used Linux the last 25 years and also Solaris, AIX and even HP-UX on 9000-workstations. From today, it’s fascinating how modern the HP-UX 10.2 is. If you’re familiar with Linux command line, you can use it right away. Some things are different, but not too different. After having worked several days now with HP-UX 10.2 I think it’s a pity that it was not free in the 1990ies. Many people would have liked to work with it, remember that Linux was then in it’s very early days and not as much comfortable as HP-UX 10.2 then was.

A bad thing from today’s hobbyist perspective is that all connectors of the E1498A (besides: Keyboard, Mouse and SCSI) are of a very special form factor. All are „Micro Sub D“.

Some of those Micro Sub D connectors. You can see that the complete RS232 connector contact area is about 5mm size

HP sold in the old days adapter cables (I suppose 1 adapter cable for a large gold nugget 🙂 ) and you can today buy those connectors from various sources.  If you’re a millionaire or otherwise crazy, this is an option – a single connector is not below 40 Euros!!!

I created the connectors I required myself from scratch…

Dimensions of the RS232 connector in mm.

Each DIY connector consists of the correctly sized small plates (from PCB material). They are glued together, between them the pins are hold in place by the glue. For the pins itself I used transistor pins.

DIY connector with 9 pins for RS232

After the successful creation of a 9 pin connector (RS232) I built the 15 pin one (LAN connector).

The connectors I created have no screws to mount them to the E1498 connectors, so they require a friendly environment 🙂

Standard transistors (e.g. BC557) have 1.27mm pin pitch. So I glued 3 transistors together on a plate. They are the 8 pin line of the 15 pin connector after 1 pin (leg) was removed.
A second plate was glued on top of the transistor pins for fixation.


Three further transistors with 2 legs removed were glued on the other side of the inner plate and fixed with a third plate.


I would not fly to the moon with these connectors but for installation and friendly use its stable enough.


Set up HP-UX 10.2 Operating System

My HP E1498A came from USofA without anything. No cables, no software, no nothing. So I ordered old HP-UX 10.2 installation disks via eBay – from Australia. HP licensed per machine/CPU in the old days, so if you have the hardware you’re safe. From those disks, a „cold install“ can be done.

First boot, without disc or anything attached. I just put the oscilloscope probe to the RS232 Tx pin and switched my Rigol to RS232 decoding. The E1498A dumps ~360 bytes which I can read before its hanging waiting for boot devices. The decoded line here (green) says „All rights reserved“. So it’s working 🙂

A SCSI disk must be attached as installation target and a SCSI CD drive as installation source (there are other options like network installation but I decided to keep it simple).

The mainframe, on top of it SCSI CD-ROM and harddisk. Network connectivity via AUI-Transceiver.

Installation arrangement: SCSI CDROM drive plus self-made external SCSI harddisk.

At the beginning of installation, the partition sizes (logical volumes) can be define. The default values are crazy small, some megabytes here and some megabytes there. You must change these values, otherwise it will give very soon problems when adding OSS software etc. I made partitions not smaller than 512MB, for /usr, /opt and /home several GB sizes. There are some volume group parameter values to tweak in the installation gui for such large sizes named pe_size and max_pe, see here.

After the base installation from a single CD, other applications can be installed from software depots (CD-ROMs, files, network).

Online software depots are almost gone for HP-UX 10.2. There are still some ftp Servers offering compiled packages for gcc, bash, bzip2 and more.

Using the „sam“ tool, many administration tasks can be executed.

CD-ROM mount

Checking all disk devices:


% ioscan -fnC disk

Class     I  H/W Path   Driver      S/W State   H/W Type     Description
disk      0  2/0/1.4.0  sdisk       CLAIMED     DEVICE       HP 18.2GST318406LW
                       /dev/dsk/c0t4d0   /dev/rdsk/c0t4d0
disk      1  2/0/1.5.0  sdisk       CLAIMED     DEVICE       YAMAHA  CDR400t
                       /dev/dsk/c0t5d0   /dev/rdsk/c0t5d0

The mount command is then

mount -o ro /dev/dsk/c0t5d0 /cdrom

# df

/cdrom               (/dev/dsk/c0t5d0     ):        0 blocks         0 i-nodes 
/home                (/dev/vg00/lvol4     ):  7385992 blocks    673591 i-nodes 
/opt                 (/dev/vg00/lvol5     ):  3520138 blocks    335703 i-nodes 
/tmp                 (/dev/vg00/lvol6     ):   882914 blocks    237891 i-nodes 
/usr                 (/dev/vg00/lvol7     ):  3179068 blocks    324120 i-nodes 
/var                 (/dev/vg00/lvol8     ):  1558032 blocks    469323 i-nodes 
/stand               (/dev/vg00/lvol1     ):   424334 blocks     41070 i-nodes 
/                    (/dev/vg00/lvol3     ):   890816 blocks     80391 i-nodes

Mount harddisk in mainframe slot

HP offered 1-slot modules with harddisk+floppy. I used an B-Size – To – C-Size Adapter and mounted there a harddisk inside. The P1 connector of the adapter has the required voltages for the harddisk (5V, 12V and GND). I connected the harddisk there and a SCSI cable connects the harddisk with the V743 module.

As soon as NFS works, the external  CD ROM is not really required anymore.

Software installation

The command swlist lists all installed packages. Below is the output after base installation:

# swlist
# Initializing...
# Contacting target "vxi1"...
# Target:  vxi1:/
# Bundle(s):
#  B3782EA               B.10.20        HP-UX Media Kit (Reference Only. See Description)
   HPUXEngCR700          B.10.20        English HP-UX CDE Runtime Environment

The command swinstall serves to install software. Start it with a source argument or without any arguments and enter interactively the required values. Finally the command can be started from inside sam.

 swinstall -s <hostname>:/<source-path>

If the user is not allowed to install software (I had this for root at some point) you can extend the „Software Access Control List“ with swacl.

Export current ACL to a text file:

swacl -l host > swacl.host

Add with an text editor a line for the user that should be added to the ACL, e.g.:


Re-import extended file to ACL system:

swacl -l host -F swacl.host

Adding of patch bundles and other software

There are many patches for HP-UX 10.20. Some of them are patch bundles containing hundreds of patches in one big chunk. Bundles can be installed like any other software using the swinstall tool. Look for the „General release“ and „ACE“ bundles.

Patches I installed:

      • XSW700GR1020 (more than 100 products)
      • ACE workstation (updating ~116 products, i.e. packages)
      • ACE networking (seems to be contained more or less 🙂 in the workstation patch bundle)

I hoped the ACE patches raises nfs to v3, but it does not.

After base installation I have installed several things:

      • Java (JRE+JDK)  (super-old version 1.0.3),
      • A Patch bundles named „XSW700GR1020“ (General Release Patches for HP-UX 10.20 Workstations)
      •  B6378DA:Networking ACE and B6193EA Workstation ACE patch
      • E2091F: HP  I/O Libraries (see below)
      • Several OSS tools like bash, gcc etc.
 # Initializing...
 # Contacting target "vxi1"...
 # Target:  vxi1:/
 # Bundle(s):
 B3782EA                       B.10.20        HP-UX Media Kit (Reference Only. See Description)
 B5455AA_APZ                   B.01.03        HP-UX Development Kit for Java* (S700)
 B5457AA_APZ                   B.01.03        HP-UX Virtual Machine for Java* (S700)
 B6193EA                       ACE.199912.01  Workstation ACE for HP-UX 10.20 (December 1999)
 B6378DA                       ACE.199912.01  Networking ACE for HP-UX 10.20 (December 1999)
 E2091F                        G.01.02        HP I/O Libraries for HP-UX
 HPUXEngCR700                  B.10.20        English HP-UX CDE Runtime Environment
 XSW700GR1020                  B.10.20.33     Extension Software Patch Bundle
 # Product(s) not contained in a Bundle:
 bash                          4.3.30         bash
 binutils                      2.9.1-1        GNU binutils
 bzip2                         1.0.6          bzip2, bunzip2 - a block-sorting file compressor
 gcc                           4.2.2          gcc
 grep                          2.21           grep
 gzip                          1.3.9          gzip
 lsof                          4.80           lsof
 tar                           1.20           tar


Set Up Networking

HP E1498A contains everything required for network access. It has a 15 pin AUI connector in the Micro Sub D form factor (female).

Get a male connector for that and a female 15 pin Sub D connector. Wire pin numbers 1:1 together. Then an AUI-Transceiver can be connected to the female connector. The other side of the AUI Transceiver is 10Base-T, which can be connected to any modern network. AUI-Transceiver pin numbering is standardized, so you can use every transceiver you want.

My used CentreCOM 210TS AUI-Transceiver, bought from China for ~6 Euros.
On the left you can see the yellow 10Base-T cable, on the right the 15 pin connector. The transceiver is powered via the 15 pin connector from the E1498A.

Using sam, the LAN interface („lan0“) can be configured with an IP address, DNS server etc. Having done this, the interface is immediately up and running.

HP-UX can run several network services, e.g. telnet or nfs (v2), automounter can be used out of the box.

Note: Change nsswitch order (in sam, to take /etc/hosts first). Otherwise the machine may not find itself 🙂

ntp time synchronization

When trying to set up ntp, the client program refuses to synchronize to my time server (a fritz box which synchronizes itself from a public time server). During installation, it was not possible to enter a date behind 1999 and so I entered a date from 1996 (today-20 years). When later setting up ntp, xntpd did not like this and prints out:

Aug 28 01:10:49 vxi1 xntpd[5826]: Clock appears to be 631564685 seconds slow, something may be wrong

Aug 28 01:10:49 vxi1 xntpd[5826]: system event 2: System or hardware fault.

To overcome this a sync can be forced using this command:
     ntpdate <time_server_ip_address>

After that the system clock is correct and will be correctly synchronizing in the future.

Set up X Windows

The HP E1498A runs X11R6. If a keyboard and a mouse and a monitor is attached to it, the X X Server is started. Otherwise  X clients can only be used with a remote display (i.e. X Server). The base installation has only a few x clients to run.

On OpenSuse Leap 42 I was not able (easily) to let the X Server  listen to port 6000, which is required for X clients without a ssh connection. I use a socket forwarding command like this:

socat -d -d TCP-LISTEN:6000,fork UNIX-CONNECT:/tmp/.X11-unix/X0

After this, clients can connect in this way:

export DISPLAY=my-pc:0.0

Error messages: /var/dt/Xerrors

Set up VXI software

To control VXI devices from the HP E1498A, two things are needed:

  • Hardware:
    • Either a GPIB controller that fits into the mainframe. This thing is called HP E1406A.
    • Or use the VXI backplane together with ISCPI interface (see below)
  • Software: HP provided all the required software on a CD called „E2091F I/O Libraries for HP-UX 10.20“.

This software is not anymore provided by Keysight. You have to buy it somewhere else, eBay is your friend here.

After install, use the tool iosetup (an X Windows client) to configure the VXI- and the HPIB device inside the V743 board. iosetup will reconfigure those as new interfaces and recompile the Kernel. After a reboot, note that /dev/sicl is populated with many new devices.

Also, add ISCPI (Interpreted SCPI) as an interface. This allows to control HP measurement devices directly via VXI backplane, even without the need for a command module. This approach translates transparently SCPI commands to register-based calls.

iosetup GUI after adding vxi, hpib and iscpi interfaces (Click image to enlarge)

After having all done this, devices in the mainframe can be accessed. The following C code accessed my HP E1411B digital multimeter at logical address 8 (code taken from HP documentation). It uses the ISCPI interface by using the device address „iscpi,8“ .

#include <sicl.h>
#include <stdio.h>

void main()
INST dvm;
char strres[20];

/* Print message and terminate on error */
ionerror (I_ERROR_EXIT);

/* Open the multimeter session */
dvm = iopen („iscpi,8„);
itimeout (dvm, 10000);

/* Initialize dvm */
iwrite (dvm, „*RSTn“, 5, 1, NULL);

/* Take measurement */
iwrite (dvm,“MEAS:VOLT:AC? 1, 0.001n“, 23, 1, NULL);

/* Read measurements */
iread (dvm, strres, 20, NULL, NULL);

/* Print the results */
printf(„Result is %sn“, strres);

/* Close the multimeter session */

Compile this with HP’s cc or gcc.
gcc vximesdev.c -o vximesdev -L /opt/sicl/lib/ -lsicl

Output looks like this:
bash-4.3$ ./vximesdev

Result is +1.220703E-002


Installation and Configuration Guide for Linux I/O Libraries (41 pages, for Linux, but you get idea for HP-UX too)

HP E1411A Digital Multimeter

This is like the HP E1326A but in a C-sized form factor.

Jumpers for GPIB secondary address (here: 8) and IRQ (here: 1).


HP E1411A Service Manual


  • Micro D / Micro D-Sub / Micro Sub-Dmale layouts document
  • Micro D / Micro D-Sub / Micro Sub-D 9 female pin layout document
  • Micro D / Micro D-Sub / Micro Sub-D 15 female pin layout document

Further readings

http://www.datadisk.co.uk/html_docs/hp/hpux_cs.htm – HP-UX Cheat Sheet

Gigabit-Netzwerk mit Linux

Dies ist ein historischer Artikel von ca 2010.

Ein Upgrade auf Gigabit-Ethernet mit Linux gestaltet sich sehr einfach.

Ich habe folgende Geräte umgestellt:

  • OpenSuse 10.2 auf ASRock P4V88 Board mit Pentium 4 Prescott 3Ghz und internem LAN-Karte 100MBit/s
  • OpenSuse 10.0 auf IBM Netvista PC mit Pentium 4 Northwood 2,26 Ghz und internem LAN 100 MBit/s
  • knoppmyth Linux mit mythtv auf Siemens Scovery XS Mini-PC mit Pentium 3 866Mhz und internem LAN 100 MBit/s

Was benötigt man?

  1. Von Linux unterstützte Gigabit-Netzwerkkarten. Ich habe irgendwelche genommen, die den RealTek Chip RTL8169 nutzen. Hierfür hat Linux Treiber im Kernel.
  2. Gigabit Switch
  3. Kabel, die Gigabit-Ethernet transportieren sollen, müssen Cat 5e oder höher haben.

Zu der Norm „Cat x“ gibt es bei Wikipedia gute Infos. Hier eine knappe Zusammenfassung:

Norm Betriebsfrequenz [Mhz] Max. Übertragungsrate
full duplex/half duplex [MBit/s]
Max. Kabellänge [m] Genutzte Adernpaare Übertragungsrate pro Adernpaar [MBaud]
Cat 5 100 ?/100 100 2 50
Cat 5e (auch 5+) 100 250/500 100 4 250
6 250 500/1000 100 4 250
6a 500 ?/10000 100 4 ?
7 600 ?/10000 100 4 ?

Ich habe ein Cat 5-Kabel probiert, der Switch hat damit aber nur 100MBit angeboten. Mit Cat 5e-Kabeln ging es dann. Alle Kabel haben übrigens dieselben Stecker, erst bei Cat 7 werden andere Stecker verwendet (die allerdings kompatibel zu den alten sind, d.h ein Cat 7-Stecker passt auch in eine alte Buchse).

RJ45 Stecker
Ein RJ45 Stecker an einem Cat5-Kabel


Besonderheiten, die zu beachten sind:

  • 1000 MBit/s entsprechen 125MByte/s. Der PCI-Bus des PCs kann diese Transferrate geschwindigkeitsmässig nicht bedienen, d.h. man wird die theoretischen 1000 MBit mit PCI nicht erreichen. Desweiteren sind übliche Platten mit 50-80MByte/s ebenfalls deutlich unter der theoretisch möglichen Geschwindigkeit des Netzes. Unabhängig davon wird man aber Transferraten erreichen, die deutlich über denen eines 100MBit-Netzes sind (siehe weiter unten).
  • Es braucht keine Crossover-Karten mehr, da alle Gigabit-Switches schon Auto-MDX beherrschen
  • Eine Mischung 10/100/1000 Geräte am selben Switch ist kein Problem, alle laufen mit der höchsten Geschwindigkeit

Die Umstellung

Ich habe die Linux-Rechner vor dem Hardware-Tausch hochgefahren und im BIOS die interne LAN-Karte disabled, um  Konflikte zu vermeiden. Nach dem Herunterfahren wurden die Karten ausgetauscht.

Gigabit Ethernet-Karte mit Realtek 8169 Chip (Links eine Boot-PROM-Fassung)
Gigabit Ethernet-Karte mit Realtek 8169 Chip
für den PCI-Bus (Links eine Boot-PROM-Fassung)

Nach dem Hochfahren ist erwartungsgemäß kein Netzbetrieb mehr möglich, denn die bekannte Netzkarte wurde deaktiviert, die neue Karte wurde noch nicht konfiguriert. Trotz disablen der onboard-Karte hat der Kernel auf allen PCs die Karte bemerkt.
Startet man auf den OpenSuse Rechnern Yast und geht dort in den Bereich Netzwerkgeräte -> Netzwerkkarte, wird dort neben der alten nun auch die neue Karte angezeigt. Diese kann dann einfach mittels Bearbeiten konfiguriert werden. Vorher habe ich aber noch die alte Karte bearbeitet, deren Netzwerkadresse geändert (die neue Karte soll die alte IP-Adresse übernehmen) und die Aktivierung der alten Karte auf „manuell“ umgestellt. Für die neue Karte sind die typischen Dinge (eigene IP-Adresse, Netzmaske, DNS-Server, Default-Gateway) einzustellen. Yast beenden und die neue Karte funktioniert. Bei mir wurde die neue Karte als „eth1“ eingebunden.

Transferraten von Gigabit Ethernet

Um Gigabit Ethernet auszureizen, benötigt der PC RAID-Systeme und eine schnellere Anbindung des Plattenzugriffs an die Netzwerkkarte als es PCI bieten kann. Mit einem Wald-und-Wiesen-PC wie ich ihn habe, kann man nur ein Bruchteil der möglichen Leistung erreichen.

2008: Mit dem Gigabit Ethernet ergeben sich beim Transfer deutlich höhere Werte als mit dem 100MBit-Netzwerk. Bei ersten Messungen kam ich auf ca. 230MBit/s. Die interne Plattengeschwindigkeit wird nicht erreicht. Trotzdem werden Daten fast Faktor 4 schneller übertragen. Es macht einen deutlichen Unterschied, 1 Minute statt 4 Minuten auf die Übertragung einer 4GByte Video-Datei zu warten.

2012 wurde die Messung mit neueren Geräten wiederholt und dabei 65MByte/s erreicht, mit 517MBit/s immerhin rund die Hälfte der theoretisch möglichen Geschwindigkeit.

Jahr der messung Medium Quelle Medium Ziel Verbindungstechnik Volumen
dauer [s]
2008 interne SATA-1
Linux ext3 Quellrechner: Pentium 4 3Ghz, 2GByte RAM, OpenSuse 10.2
externe HD via NFS
Linux ext3 Zielrechner: Pentium 4 2,26 Ghz, 1GByte RAM, OpenSuse 10.0
Switch: TP-Link TL-SG 1008D
Netzwerkkarten: LogiLink Gigabit Ethernet PCI Adapter – Giga LAN Card
Gigabit Ethernet 2672 97 27,3
2012 interne SATA-2
Linux ext4
Quadcore Q6600 2,4Ghz, 6GByte RAM, OpenSuse 12.1
Built in LAN Karte (Gigabyte Board)
externer PC via NFS, Linux ext4

Prentium 4,  2,4Ghz, 2GByte RAM, OpenSuse 12.1

Netzwerkkarten: LogiLink Gigabit Ethernet PCI Adapter – Giga LAN Card

Gigabit Ethernet 9500 147 64,6



Transferraten mit USB, SATA, LAN und intern

Dies ist ein historischer Artikel von ca. 2010.

Wer sich mit dem Gedanken trägt, Backups auf einem externen Gerät durchzuführen, hat die Wahl zwischen externen  Platten, die mittels USB, LAN oder SATA angebunden werden können. Hierfür existieren spezielle Leergehäuse. Die LAN-Gehäuse kosten dabei deutlich mehr als die anderen Varianten. Alternativ ist auch die Nutzung eines zweiten Mini-PCs via LAN  möglich, den man im Internet günstig ersteigern kann.

Im folgenden sind unterschiedliche Szenarien gegenübergestellt, bei denen Dateien kopiert werden und die Transferraten gemessen wurden. Mit externen SATA-Platten wurde keine Messung gemacht mangels SATA-Gehäuse.


Während beim internen Kopieren (also von Harddisk zu Harddisk innerhalb eines Rechners) fast 60 MByte/s erreicht werden, fallen alle anderen Technologien deutlich ab.

Die als externe Harddisk angeschlossene 2,5“ USB-Disk kommt mit 8,7MByte/s nur auf einen Bruchteil (knapp 10%) der theoretisch möglichen 60MByte/s (entspricht 480MBit/s). Da ist sogar die extern gemountete LAN-Platte des Mini-PCs schneller, die mit 10,5MByte/s immerhin 84% der theoretisch möglichen 12,5MByte/s (entspricht 100MBit/s) erreicht. Eine externe, LAN-fähige Platte kommt da auch nicht mit und erreicht sogar nur 3.5MByte/s. Diese Platten werden z.B. von Longshine angeboten und beinhalten einen Microcontroller, auf dem ein proprietäres Betriebssystem oder auch Linux (bei Longshine) läuft. Durch die niedrige Taktrate des Controllers ist für die Transferrate wohl mehr als der Wert, den ich in Foren im Internet gefunden habe, nicht drin.

Nachtrag 2007: Mit einer externen, über USB angeschlossenen 3,5“ Harddisk wurden deutlich höhere Werte als mit der 2,5“ Notebookplatte erreicht. Die verwendete 3,5“ Platte war ein 20GByte Seagate Baracuda Modell aus 2001, ATA4-fähig, also nicht ganz neu und von daher eher langsam. Dennoch wurden 28MByte/s Transferrate erreicht. Die früher getestete Notebookplatte fällt daher mit ihren 8,7MByte/s vermutlich aus dem Rahmen, sie ist besonders langsam. Dies ist vermutlich dem gewünschten niedrigen Stromverbrauch und der möglichst geringen Lautstärke von Notebookplatten geschuldet.

Ich habe in 2007 mein LAN auf Gigabit umgestellt und auch Messungen gemacht. Dies habe ich hier beschrieben.

Nachtrag 2008: Auf einer etwas neueren Plattform habe ich 2008 Messungen mit einer externen, über E-SATA angeschlossenen Harddisk gemacht. SATA bietet die Möglichkeit, neben internen Platten auch externe anzuschließen. Dafür gibt es spezielle, abgeschirmte Kabel, bei denen Längen bis ~2m möglich sind. Ich habe ein externes Gehäuse gekauft, dass 2 SATA.-Platten aufnimmt. Das Fantec MR-35DUS2 hat einen eigenen internen SATA-Controller. Dieser kann eine oder zwei eingesteckte, schnell und ohne Schrauben wechselbare Platten verwalten. Er kann die Platten in verschiedenen Modi betreiben ( RAID0, RAID1, BIG, JBOD).

Das Fantec MR-35DUS2 für 2 SATA-Platten mit E-SATA und USB Anschluss

Ich habe nur eine Platte eingesteckt und gemessen. Es sind im Schnitt über 60MByte/s möglich. Damit ist E-SATA bei meinen Tests der klare Sieger und genauso schnell wie interne Platten. Ein einem anderen Bericht im Internet habe ich gelesen, dass jemand mit zwei Platten in RAID0 sogar 110 MByte/s erreicht hat.


Somit erscheint die Variante mit einem externen E-Sata Laufwerk optimal. Als zweitbeste Lösung erscheint ein Mini-PC. Mini-PCs gibt es z.B. von Siemens (Scovery) oder von HP. Der Mini-PC lässt sich problemlos mit einer leichtgewichtigen Linux-Distribution (z.B. Zenwalk) bestücken.
Mit Gigabit-Ethernet wird die LAN-Variante weiter an Attraktivität gewinnen. Der begrenzende Faktor bei Gigabit-Ethernet wird dann wieder die Platte selbst sein, so dass Transferraten wie intern möglich sein sollten.
Externe Harddisks sind dann vorzuziehen, wenn Mobilität gefragt ist.

Medium Quelle Medium Ziel Verbindungstechnik Volumen
dauer [s]
interne HD
UDMA 133
Linux reiserfs3
interne HD
Linux reiserfs3
intern (SATA/IDE) 1079 18,9 57
interne HD
UDMA 133
Linux reiserfs3
externe HD 3,5“
USB2 (Externes Festplattengehäuse: Power Mobile Harddisk. Chip: Cypress Semiconductor Corp. USB-2.0 IDE Adapter) 2045 73 28
interne HD
UDMA 133
Linux reiserfs3
externe HD 2,5“
mount mit „async“
USB2 (Externes Festplattengehäuse: No Name. Chip: Genesys Logic, Inc. USB 2.0 IDE Adapter) 1950 223 8,7
interne HD
UDMA 133
Linux reiserfs3
externe HD via NFS
Linux reiserfs 4
mount mit „sync“
Fast Ethernet 100MBit/s 1079 308 3,5
interne HD
UDMA 133
Linux reiserfs3
externe HD via NFS
Linux reiserfs 4
mount mit „async“
Fast Ethernet 100MBit/s 1079 103 10,5
interne HD externe LAN-fähige
Linux ext3
Fast Ethernet 100MBit/s unbekannt unbekannt 3,5
(Wert aus Internet)

Getestet wurde mit folgenden Geräten:
CPU: Intel Pentium 4 3.0 Ghz, RAM: 1024 MB PC400 DDR, Board: ASRock P4V88 (SATA RAID 8xUSB). Betriebssystem: OpenSuse 10.0.
CPU: Intel Celeron 900Mhz, RAM: 512MB PC133 SDRAM, Board: Siemens Scovery XS D1215. Betriebssystem: Zenwalk Linux 2.0.1.


Medium Quelle Medium Ziel Verbindungstechnik Volumen
dauer [s]
interne HD
Linux OpenSuse 11.0
externe HD
E-SATA verschiedene Dateien von 0,2-2,8GB unterschiedlich 60,5 im Schnitt (45..77)

Getestet wurde mit folgenden Geräten:
CPU:Intel Quad Core 2,4GHz, RAM: 2048 MB PC400 DDR. Betriebssystem: OpenSuse 11.0.


VirtualBox unter OpenSuse 11.x

Dies ist ein historischer Artikel von 2010.

Von VMWare zu VirtualBox…

VMWare läuft gut unter Linux. Es ist schnell und bindet sich gut in die vorhandene Hardware ein. Ich konnte sogar auf die vorhandenen seriellen Schnittstellen zugreifen.

Nachteil von VMWare war aber immer, das die VMWare Server Version, die bei VMWare herunterzuladen ist, meist nicht zum vorhandenen OpenSuse Kernel passt. Der Kernel ist meist „zu neu“ für VMWare. Dies hat den Effekt, dass VMWare bei der Installation, die manuell erfolgen muss, Kernel Module neu compilieren muss. Die kann man mal machen, ist eigentlich nicht so schlimm.

Leider muss diese Prozedur immer wiederholt werden, wenn beim einem Systemupdate eine neue Kernelversion mitkommt. Dies führt dazu, dass ich alle paar Wochen die manuelle Installationsprozedur von VMWare Server starten musste. Am Ende muss dann auch immer noch der (kostenlose) Lizenzkey eingegeben werden, alles in allem eine nervige und aufwendige Prozedur.

In den letzten drei Jahren kam es leider auch mehrfach vor, dass VMWare eine Zeitlang gar nicht installierbar war, weil es bei der Nachcompilierung zu Fehlern kommt und die Kernelmodule nicht erstellt werden können. Es gibt dazu die inoffiziellen(?) „any-to-any“-Patches, die VM-Ware für neuere Kernel-Versionen fit machen. Das Beschaffen der Patches und das Checken, ob sie für Kernel+VMWare Version ordentlich passen, ist dann immer eine Bastelarbeit.


Im Frühjahr 2010 trat die Situation wieder auf, ich konnte die neueste VMware Version nicht auf meinem OpenSuse 11.2 installieren.

Diesmal habe ich VirtualBox eine Chance gegeben.

Vor einiger Zeit hatte ich das schon mal probiert, aber damals musste man die Netzwerk-Konfiguration des Host-Rechners verändern, um unter dem Gast Networking verwenden zu können, was ich damals nicht tun wollte.

Dies ist in der aktuellen Version 3.2.6 vom VirtualBox nicht nötig. Unter OpenSuse kann einfach via YasT nachinstalliert werden. Nach der Installation hat man eine Verwaltungsfenster, in dem die Virtuellen Maschinen sichtbar sind und von dort aus gestartet, gestoppt und verändert werden können.

Import vorhandener VMware VMs

Vorhandene VMWare-VMs können tatsächlich importiert werden. Das Import-Format ist OVF, soweit ich verstanden habe eine Art Standard, um eine VM strukturiert zu verpacken. Es gibt von VMWare einen Skript, OVFTOOL, den man sich bei vmware herunterladen kann. Nach Start des heruntergeladenen sh-Skripts entpackt sich das Tool und installiert sich in ein wählbares Verzeichnis. Eine vorhandene VMWare-VM kann dann mittels ovftool /dir-der-vorhandenen-vmware zieldatei in das Standardformat konvertiert werden.

VirtualBox bietet einen Punkt „Importieren“ an, der das Importieren der VM im Standardformat erlaubt. Ich habe dies für eine VM gemacht und es hat gut funktioniert.


Das Handling ist genauso bequem wie mit VMWare Server. In untigem Bild wird gerade OpenSuse 11.3 64 Bit installiert.

Gast Erweiterungen

<noch offen>


Mit meinen beiden ersten VMs (Windows XP Professional) habe ich keine Abstürze oder anderen unangenehmen Effekte gehabt. Das ganze wirkt sehr stabil.

Konvertierung von VirtualBox VMs nach VMware VDMK

Warum braucht man das? Ich arbeite zuhause mit virtualbox, muß aber bei meinem Arbeitgeber VMware nutzen. Daher brauche ich auch den Weg von Virtualbox VM (im .vdi-Format) zum .vmdk-Format oder irgenbdwas anderem, was VMware versteht.
Laut Internet Foren soll das mittel VBoxManage. Beispiellink:

VBoxManage clonehd          <uuid>|<filename> <outputfile>
[–format VDI|VMDK|VHD|RAW|<other>]
[–variant Standard,Fixed,Split2G,Stream,ESX]
[–type normal|writethrough|immutable]
[–remember] [–existing]

Evtl. auch
VBoxManage export           <machines> –output|-o <ovf>
[–vsys <number of virtual system>]
[–product <product name>]
[–producturl <product url>]
[–vendor <vendor name>]
[–vendorurl <vendor url>]
[–version <version info>]
[–eula <license text>]
[–eulafile <filename>]

<noch auszuprobieren>


VirtualBox ist mittlerweile ausgereift und kann ganz simpel installiert werden. Es sind keine Nacharbeiten nötig. Es ist besser in das Linux-Restsystem integriert als VMWare Server, insbesondere treten beim Wechsel des Kernels nicht die VMware-üblichen Probleme auf. Ich habe nach einiger Zeit die Reste von VMware aus meinen Linux-Installationen entfernt.

VMWare Server 2.0 unter OpenSuse 11.0

Hinweis: Dies ist ein historischer Artikel. Mittlerweile empfehle ich eher die Nutzung von VirtualBox. Siehe Beitrag VirtualBox

Seit einiger Zeit arbeitet VMWare an der 2.0-Version des VMWare Servers. Diese bietet eine verbesserte Nutzung der Ressourcen des Hosts durch den Gast und kommt mit einer neuen Administrationsoberfläche, die nun webbasiert ist.

Da in meiner Konfiguration (OpenSuse 11.0 mit KDE4 auf Quad Core CPU) der Betrieb von VMWare sehr instabil war, habe ich die 2.0 Beta Version ausprobiert. Die Instabilität kommt übrigens von der Nutzung von KDE4. Auf dem Rechner ist parallel auch KDE 3.5 installiert, damit gibt es keine Probleme. Da ich aber auf KDE4 umgestiegen bin, ist das für mich keine Lösung.

Installation des VMWare Servers 2.0 Beta RC2

Man kann sich bei vmware ein RPM (oder auch ein tar.gz)-File herunterladen. Dieses lässt sich mittels    rpm -ivh VMware-server-2.0.0-110949.x86_64.rpm installieren. Vorher ein evtl. vorhandenes altes Paket deinstallieren (rpm -e VMware-server-1.0.6-91891 o.ä.). Nach Installation muss VMWare Server konfiguriert werden, dies geschieht mittels des üblichen Perl-Skripts von VMWare:

Wie immer passt keines der vorhandenen Kernel-Module, so dass VMWare mehrere Module compiliert. Es gibt auch Warnungen:
WARNING: „VMCIDatagram_CreateHnd“ [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
WARNING: „VMCIDatagram_DestroyHnd“ [/tmp/vmware-config0/vsock-only/vsock.ko] undefined! WARNING: „VMCI_GetContextID“ [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
WARNING: „VMCIDatagram_Send“ [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!

Ansonsten bleibe ich überall bei den Defaults, nutze nur Bridged Networking und erhalte einen lauffähigen Server, der sich sofort startet.


Die Fat-Client-Anwendung VMWare Server Konsole ist durch eine webbasierte GUI ersetzt. Der zugehörige Webserver läuft unter den Ports 8222 (http), 8333 (https) und 902 (für remote Connections, vermutlich mit dem alten Fat Client?, habs nicht probiert).

Nach dem Aufruf der URL erhält man folgende GUI. Die Optik ist der der alten Konsole durchaus ähnlich:

Die webbasierte Administationsoberfläche von VMWare Server 2.0. (Nein, ich habe keinen Rechner mit 6,4GHz. Eventuell
werden die gerade aktuellen GHz-Werte des Quad-Cores aufaddiert oder die Zahl ist einfach falsch)

Unter dem Reiter „Console“ kann auf die VM zugegriffen werden. Die Webanwendung möchte dazu ein Plugin im Firefox installieren, was ich gemacht habe. Direkt danach kann man auf die VMs zugreifen. Das Handling ist gefühlt deutlich besser.

Hier habe ich zwei VMs gestartet, meine Windows XP-Installation und eine gerade laufende OpenSuse-Server-Installation.
Wie man am ksensors-Fenster erkennen kann, brauchen 2 Gäste und der Host zusammen nur 1097MB Speicher.

Erstes Fazit

Der RC2 vom VMWare Server 2.0 Beta läuft bei mir problemlos. Es gab keinerlei Abstürze, Einfrieren von VMs etc. Diese hatte ich unter KDE4.0 mit VMWare Server 1.0.6 am laufenden Band.

Anschluss eine WLAN-Routers an ein existierendes kleineskabelgebundenes LAN<

Im folgenden wird beschrieben, wie an ein existierendes kabelgebundenes LAN mit Verbindung via Router ins Internet ein WLAN-Router angeschlossen wird.

Prinzipiell kann man den vorhandenen Router einfach durch den WLAN-Router ersetzen. Dies wollte ich aber nicht, denn ich möchte das WLAN nur eingeschaltet haben, wenn ich es auch benutzen will. Mein WLAN-Router erlaubt zwar, per Web Administration das WLAN-Teil des Routers abzuschalten, dies ist aber aufwendig. Daher wollte ich den WLAN-Router einfach per Ein/Aus-Schalter abschalten können. Dann kann er aber nicht den vorhandenen Kabelrouter (den ich nie abschalte) ersetzen. Somit muss man zwei Router in einem LAN unterbringen. Dies erfordert eine spezielle Router-Konfiguration.

Im folgenden ist die Ausgangssituation beschrieben (rein kabelgebundenes LAN) und die Erweiterung des LANs um den WLAN-Router.


Der kabelgebundene DSL Router hat nur einen LAN-Ausgang. Dieser ist mit einem Switch verbunden. Am Switch hängen PC, Drucker und evtl. ein Notebook.

Der DSL Router ist ein Fritz!Box SL von AVM, der Switch ein Longshine 100/10 Mbit 8-fach Switch mit Auto-MDI (LCS 883R SW 800M+). Auto-MDI bedeutet, dass man in jedes Port beliebig normale und Crossover-LAN Kabel stecken kann. Der Drucker ist ein netzwerkfähiger HP Laserjet 2100 mit 10 Mbit LAN-Karte. PC und Notebook haben jeweils 100MBit LAN-Karten.

Das vom Router gebildete LAN hat die IP-Adresse 192.168.178.*. Der Router selbst ist in seinem LAN unter sichtbar. DHCP ist eingeschaltet. Der Drucker ist auf fixe IP-Adresse gestellt, so dass er im Netz unter einer festen Adresse gefunden werden kann.

Netz mit integriertem WLAN-Router

Das oben beschriebene Netz wurde erweitert um den WLAN Router. Die Konfiguration des vorhandenen Netzes und des DSL Routers muss dazu nicht verändert werden.

Der WLAN Router wird mit seinem LAN-Anschluss (!) an den Switch angeschlossen. Der DSL-seitige Anschluss (“WAN-Anschluss”) dieses Routers wird nicht benutzt. Der WLAN wird nun auf feste IP-Adresse konfiguriert und eine solche eingegeben. Diese muss aus dem vom kabelgebundenen DSL Router aufgebauten Netz kommen, z.B. Der DHCP Server auf den WLAN-Router muss abgeschaltet werden, es kann nur einen DHCP-Server in einem LAN geben. Das WLAN wird nach “üblichem” Vorgehen konfiguriert. Am Beispiel sind also folgende Werte einzugeben:

  • WLAN Router LAN Adresse:
  • WLAN Router LAN IP Mask: die Maske des DSL Routers nehmen
  • WLAN DHCP Server : aus

Danach am besten alle Geräte abschalten und wieder einschalten, so dass aktuelle IP-Adressen vergeben werden können. Wenn Probleme auftauchen, kann man das Problem eingrenzen. Dazu versuchen, ob man vom Notebook an den WLAN-Router kommt (mittels ping oder Aufruf des Admin Web Servers des WLAN Routers). Wenn das schon nicht geht, ist das WLAN falsch konfiguriert. Danach den DSL Router anpingen oder dessen Admin Web Server aufrufen. Wenn das nicht geht, muss die LAN-Einstellung des WLAN-Routers verkehrt sein.

Danach eine Internet Adresse anpingen. Wenn dies nicht geht, muss ein Problem im DSL Router vorliegen. Dieser sollte so eingestellt sein, dass er automatisch eine Internet-Verbindung aufbaut.

Security-Einstellung des WLANs

Falls man sich aussuchen kann, was die WLAN-Geräte leisten (z.B. Beim Neukauf), sollte man folgendes wählen. Kurz gesagt sollte man ein Gerät mit dem besten im Homebereich bezahlbaren Security-Protokoll kaufen, das am Markt angeboten wird. Standards sind WPA2, WPA und WEP.

WLAN Router sollte WPA2 können, mindestens aber WPA. Das veraltete WEP ist relativ einfach zu knacken. WPA/WPA2 ist relativ schwer zu knacken. Die Geschwindigkeit sollte nicht unter 54 Mbit/s betragen (Es gibt auch 11MBit, 108MBit und 152MBit-Geräte).

Die WLAN-Karte fürs Notebook sollte zum Router passen, also auch WPA2, mindestens aber WPA beherrschen etc.

Zu WPA/WPA2 ist zu sagen, dass nur Windows XP dieses Verfahren out-of-the-box beherrscht. Andere Windows Versionen können mit einem freien Tool (Windows Security Guard) WPA/WPA2 fähig gemacht werden. Achtung, das Tool selbst kostet Geld, darin sind aber Treiber enthalten, die kostenlos genutzt werden können.

Bei der Konfiguration des WLAN-Routers empfiehlt sich bei WPA oder WPA2 einen möglichst langen Schlüssel zu verwenden. Dieser sollte am besten aus zufällig gewählten ASCII-Zeichen bestehen und auch Sonderzeichen enthalten. Der Schlüssel ist sowohl auf dem Router als auch auf dem Notebook (Konfiguration WLAN Karte) einzugeben.

Außerdem kann man den WLAN Router so konfigurieren, dass er nur festgelegten Geräten eine Einwahl erlaubt. Dies wird über die MAC-Adresse festgelegt. Da ich nur ein WLAN-Gerät habe, habe ich auch nur genau dies in der Konfiguration des WLAN-Routers angegeben. Es kann sich auf diese Art kein weiteres Gerät ins Netz einwählen.

Preise: Einen WPA2-fähigen WLAN-Router bekommt man für 50-150 Euro, je nach Ausstattung und Hersteller. Eine WPA-fähige WLAN-Karte für 20-60 Euro. Der erwähnte Switch ist für weniger als 20 Euro erhältlich.


Im selben Zimmer, ca 2 Meter Abstand zwischen Rechner und Router:

Bei FTP-Übertragung von 330 Mbyte: 2,25MByte/s also 18MBit/s

In anderen Zimmer, dieselbe Datei wird nochmals übertragen.

1 Zwischenwand, ca. 12 Meter Abstand: 1,53 MByte/s, also 12 Mbit/s.

Atari Mega STE

Durch Zufall kam ich an einen „Opa“ der PC-Welt, einen zwanzig Jahre altenAtari Mega STE der mittlerweile vom Markt verschwundenen Firma Atari. Mit dem Gerätetyp verbinden mich wesentliche Erinnerungen, da ein sehr ähnliches Gerät (der Atari 1040 STF) mein zweiter Computer überhaupt war (der erste war ein C64).

„Mein“ damaliger Atari 1040 STF hatte einen Verwandten, den Atari 1040 STE und dessen Nachfolger ist der hier beschriebene Atari Mega STE.

Dem Atari Mega STE war kein großer Erfolg beschieden. Er sollte im „Business-Bereich“ seine Kunden finden…. gegen die aufkommende Intel/Windows-Welle.
Die 1040er Serie wurde für Home-User eingeführt und kam zu einer Zeit auf den Markt, als 8086- und bestenfalls 80286-PCs verfügbar waren. Der 1040er war da mit seiner 68000-CPU mit 8Mhz von der Rechen-Power klar überlegen (beim 8086) oder in etwa gleichwertig (beim 80286).
Dies kann man für die Mega ST Serie nicht mehr sagen, da mittlerweile 80386-PCs verfügbar waren, deren CPU einfach leistungsfähiger waren, auch wenn der Mega STE schon mit 16Mhz getaktet wurde.

Dem 68000 werden bei 8Mhz 1 MIPS bescheinigt. Bei 16Mhz habe ich Werte um 1,5 MIPS im Internet gefunden (Quelle1 Quelle2). Der 8086 war mit 4,77 und später mit 8Mhz getaktet und klar unterlegen (0,33 bzw. 0,66 MIPS LOL). Der 80286 wurde ebenfalls bis 16Mhz getaktet. Bei 12Mhz schaffte er 1.8…2.6 MIPS (je nach Quelle1 Quelle2).
(Nebenbei erwähnt war der 68000 damit fast drei mal schneller als die VAX-11/780 CPU mit nur 0,5 MIPS. Und die VAX war so groß wie eine (oder auch zwei) Tiefkühltruhe(n) und hat Strom verbraucht wie ein E-Herd (Wikipedia-Artikel zur VAX 780 mit Bild) … aber jetzt schweife ich wohl zu weit ab … zurück zum Thema …). Zum Abschluss dieses Gedankenstrangs: Eine schöne Tabelle zu der MIPS-Geschichte bei Wikipedia.

Die 68000 CPU wurde bereits 1979 (!) am Markt eingeführt und war damit zum Zeitpunkt des Verkaufsstarts des MEGA STE (1991) eigentlich schon ein Oldtimer. Sie war aber sehr fortschrittlich entworfen und daher auch Anfang der 90ern noch eine Option zur Verwendung in kleineren Computern.

Warum reite ich so auf dem Thema herum? Ganz einfach: Auf dem Atari habe ich alle Programmieraufgaben im Studium, von Pascal bis C, programmiert und zahllose Programmierbasteleien durchgeführt. Für diese Geräte gab es in den 90ern massenhaft Software, vor allem freie, mit der man tolle Sachen machen konnte. Mit dem Atari ST habe ich praktisch das Programmieren gelernt und die Grundlage für mein ganzes Berufsleben gelegt. Wenn ein AVR Controller für 3 Euro heute 20 MIPS bringt und damit 10 mal die Performance vom 68000 hat, merke ich, wie viel Zeit vergangen ist…

Also war klar, dass ich den Mega STE wiederbeleben wollte, eine Frage der Ehre 🙂 Leider war er ewig nicht mehr genutzt, stark vergilbt und alle Kabel fehlten. Kabel, die nicht entfernbar waren, hatte der Vorbesitzer bei der geplanten Entsorgung mit dem Seitenschneider abgezwickt.

Mein Gerät von 1991 hatte von Atari 4 MByte RAM und eine 40 MByte Harddisk eingebaut. Ein deutscher Distributor hat den Rechner mit einer größeren Harddisk versehen und verkauft. Dabei ist ein Monitor SM146 sowie eine Tastatur/Maus-Kombination, die vermutlich nicht original ist, sondern wahrscheinlich von einem Atari Mega ST stammt. (Die Tastaturen waren untereinander austauschbar.)
Die eingebaute Harddisk entpuppt sich bei genauerem Nachforschen als eine 345MB Maxtor 7345S.

Im folgenden sind die einzelnen Schritte der Wiederbelebung beschrieben.

Wiederbelebung der Maus

Atari hat für alle Modelle dieselbe eckige Maus genutzt.
Diese Maus ist ziemlich rudimentär aufgebaut. Die Bewegung des Mausballs wird über zwei Drehbewegungsaufnehmer verfolgt. Diese Aufnehmer wandeln das Drehsignal durch die Nutzung von Lochscheiben in Rechteckimpulse um. Je schneller man die Maus bewegt, desto höher ist die Frequenz der Rechteckschwingung. Je weiter man die Maus wegbewegt, desto mehr Impulse werden erzeugt. Dies wird sowohl für die X- als auch für die Y-Achse gemacht.

Die Bewegungsrichtung (links-rechts bzw oben-unten) wird wie folgt bestimmt: Pro Drehbewegungsaufnehmer wird das Signal an zwei Lichtschranken aufgenommen. Je nachdem, an welcher Lichtschranke zuerst eine Signalflanke auftritt, ist es entweder rechts oder links (bzw. nach oben oder nach unten).

Die Maus ist mit 8 Signalleitungen mit dem Atari verbunden, der die Auswertung der Maussignale vornimmt.

Maus: Unterseite, Kabel leider abgeschnitten


Maus: Oberseite


Geöffnete Maus


Das Maus-Innere: Die vier rechteckigen Löcher in der schwarzen Plastikabdeckung enthalten die 4 Lichtschranken (je zwei Pro Koordinatenachse X und Y)


In diesem Bild sind die Leuchtdioden der Lichtschranken gut zu sehen.
Die schwarzen Drehräder (Lochscheiben) welche das Drehsignal in Lichtimpulse umsetzen, sind ebenfalls zu sehen.

Der LM339 ist ein 4-fach Komparator. Die vier Ausgangssignale (XA, XB, YA, YB) werden durch ihn bereitgestellt. Unten links und rechts die beiden Taster für die Maus-Buttons.

Zur Wiederbelebung wurde die Platine aus der Maus entfernt, um ein neues Kabel anzulöten. Das Kabel muss 8 Adern haben. Der Stecker ist ein 9-poliger SUB-D Stecker, der eine „female“ Ausprägung haben muss.

Die Steckerbelegung der Atari-Maus kann im Internet beschafft werden, z.B. im HardwareBook.

Die Abbildung der Steckerbelegung auf die Platinenpins musste durch Analyse ermittelt werden. +5V und GND ist einfach, da diese Pins auch in das IC hineingehen. Die Buttons sind auch einfach, da jeweils ein Button-Kontakt direkt herausgeführt wird (der andere ist an GND angeschlossen). Bleiben noch die Bewegungssignale. Diese werden irgendwie angeschlossen und, wenn dann alles zusammen läuft, auf Korrektheit überprüft. Kaputtgehen kann nichts, wenn diese vier Signale untereinander vertauscht sind.

Hier zur Info der momentane Stand:

Pin Mausfunktion Platinenpin
1 XB 3
2 XA 2
3 YA 5
4 YB 6
5 n.c.
6 Leftbutton 7
7 +5V 1
8 GND 4
9 Rightbutton 8


Die Platine. Man sieht hier die Lichtschranken (bestehend aus je einer LED(transparent) und einem Fototransistor(rot-transparent)) sehr gut. In den Aussparungen laufen die Räder (Lochscheiben).



Als nächstes wurde gemäß obiger Tabelle ein neues Kabel angelötet.

Hier die Mausplatine mit neuem Kabel.

Nach dem Anlöten wurde die Maus mit einem Oszilloskop getestet. Wenn +5V und GND angelegt sind und die Maus bewegt wird, entstehen die erwarteten Signale am Mausstecker. Sieht also gut aus.

Mega STE

Hier einige Bilder vom eigentlichen Gerät.
Der ATARI-Monitor passt auf die linke Fläche, in die er genau einrastet. Die rechte Klappe verbirgt die Harddisk.

Ansicht von vorn


Die eher langweilige Seite ohne Anschlussmöglichkeiten


Anschlüsse des Geräts auf der Rückseite.
Von links: Floppy, Monitor, TV Out, ACSI, Drucker, 2 x seriell, ganz rechts Stereo Audio Out.
Die Klappe oberhalb der Drucker-Buchse ist ein Slot für einen VMEBus-Einschub. Ohne Einschub hat man hier einen weiteren seriellen Anschluss.


Anschlüsse der Geräts an der Seite:
Reset-Taster, „Netzwerk“, 2 x MIDI, Bus Extension, Tastatur/Maus

„Netzwerkbuchse“ klingt spannend, es handelt sich aber leider nicht um Ethernet. Ich meine irgendwo was von RS42x gelesen zu haben. Dieser Anschluss ist aber angeblich nicht in das OS integriert und damit ziemlich nutzlos.

Bus Extension in Großaufnahme. Rechts davon die Buchse fürs Tastatur/Maus-Kabel.




Das Geräteinnere, Gesamtansicht


Herstellungsdatum: 05. Februar 1991 !

Linke Seite: RAM-Bänke, SCSI-Controller, ganz oben Lithium-Batterie


So gehören Lithium-Batterie und die Power-LED angeschlossen


Die linke Seite, hier von hinten aufgenommen. Die Blechabschirmung für den VME Slot wurde entfernt.


Diverse ATARI Custom Chips (welche?), der 68901 (USART-Chip), ganz links der Yamaha Soundchip YM2149F. Ganz rechts die Buchse für den VME Slot.


Der SCSI-Controller von ATARI. Nicht ganz kompatibel, von ATARI daher zur Sicherheit „ACSI“ genannt. Nicht alle SCSI-Harddisks liefen mit dem ACSI-Protokoll.

In obigem Bild ist auf dem ACSI-Controller ein Mäuseklavier zu sehen (rot, auch DIP Schalter genannt). Dieses Mäuseklavier hat folgende Funktion

Schalter-Nr. Funktion
1-3 Bitposition 0,1 und 2 der SCSI-Adresse des Controllers. Bei mir sind alle drei Bits=1, also ist die Adresse des Controllers 7.


Die RAM-Bank mit 4×1 MByte und den beiden ROMs, die das Betriebssystem TOS enthalten. Ich vermute es ist eine 2.05 Version.

In obigem Bild ist ein weiteres Mäuseklavier zu sehen (rot).
Dieses Mäuseklavier hat folgende Funktion

Schalter-Nr. Funktion
1-6 keine Funktion
7 HD-Floppy im Formatierdialog möglich (nur bei TOS 2.06)
8 DMA-Sound Hardware An/Aus


In der Mitte die 68000 CPU. Kühlung ist hier ein Fremdwort, für heutige Verhältnisse unglaublich. Die 4 Bausteine unten links und die beiden darüber kann ich nicht deuten. Die drei rechts sind GALs. Der freie Sockel ist für die 68xxx FPU.

Als nächstes ein Blick auf die eingebaute Harddisk.

Die Harddisk kann durch Lösen einer einzigen Schraube entfernt werden. Dazu muss das Gehäuse nicht geöffnet werden. Wäre für heutige Gehäuse auch wünschenswert…


Die Harddisk Maxtor 7345S (auch wenn 7345SR draufsteht). Sie hat 345 MB.


Bei meinem Exemplar war auf dem SCSI-Controller ein Pin weggebogen. Ob das so sein muss oder ein Fehler ist, muss ich noch rausfinden. Habe ihn erst mal wieder geradegebogen.
(War Absicht und ok so, siehe weiter unten im Abschnitt „Harddisk“).

Wiederbelebung des Monitors SM146

Der SM146 war wie der SM124 und SM125 ein monochromer schwarz/weiss-Monitor. Der SM146 ist ein 14“ Monitor (der SM124 hatte nur 12“). Er hat eine sogenannte „hohe Auflösung“ von 640×400.

Im folgenden einige Bilder vom Monitor


Alles etwas verstaubt…


aber nix auffälliges auf der Platine.


In der Bildmitte der Stecker P001, mit dem das Monitorkabel an das Gerät angeschlossen ist.

Am Monitor waren ebenfalls beide Kabel mit dem Seitenscheider abgeschnitten. Das Netzkabel war schnell wieder angelötet.

Die Belegung des Monitor-Steckers kann man ebenfalls im Internet finden, auch wieder im HardwareBook:

Der verwendete Stecker ist ein „Mini Diodenstecker 13 polig“, also ein Stecker aus der DIN-Serie. Bei Reichelt ist dieser Stecker im Angebot.

Zur Info mein Informationsstand als Tabelle. Fettgedruckt die Pins, die beim Monochrome-Monitor eine Rolle spielen: Die Pin-Nummern des Steckers gelten, wenn man auf die Stiftseite/Verbindungsseite des Steckers schaut.

Die Belegung des Steckers P001 habe ich für den SM146 nicht finden können. Sie unterscheidet sich von der des beim SM125 auch vorhandenen P001. Für den SM125 habe ich übrigens im Internet sowohl das Service-Manual als auch das Schaltbild finden können. Mit den folgenden Überlegungen/Messungen konnte ich aber die Pinbelegung für die Buchse auf der Platine herausfinden:

  1. Audio kann ermittelt werden, indem alle Pins nacheinander angefasst werden. Bei Pin 3 ist ein Brummen zu hören, dies ist also der Audio Eingang.
  2. „Monochrome Detect Signal“ bedeutet, dass monochrome Monitore dieses Signal auf GND ziehen. Damit erkennt der Atari, dass ein monochromer Monitor angeschlossen ist. Ich finde zwei Pins an P001, die auf GND liegen (2 und 6). Diese können für dieses Signal verwendet werden.
  3. Laut Service Handbuch haben die Sync-Eingänge eine Impedanz von 2 KOhm. Einen solchen Wert (genauer: 2,26 und 2,3 KOhm) messe ich an den Pins 4 und 8. Dies sind also die Sync-Eingänge. Durch Ausprobieren am laufenden Gerät kann ich dann VSYNC und HSYNC ermitteln
  4. In der Reihenfolge der Signale finde ich nun doch eine Übereinstimmung zum SM125. Damit steht dann auch das Signal „Monochrome Video“ fest.
Stecker-Pin Funktion Platinenpin (Stecker P001)
1 Audio Out 3
2 Composite Video
3 Clock Select
4 Monochrome Detect/Clock In wahlweise 2 oder 6
5 Audio In
6 Green
7 Red
8 +12V (520ST: GND!)
9 Horizontal Sync 4
10 Blue
11 Monochrome Video 5
12 Vertical Sync 8
13 GND 1 und 2 und 6

Nach diesem Schema muss das Monitorkabel mit Stecker angelötet werden.

Stecker ist bestellt…

Erstes Einschalten

Noch ohne Tastaturkabel und ohne Monitorstecker wurde das Gerät eingeschaltet.

Dazu wurde der Monitor vorübergehend mittels Laborkabel und Lötstiften an das Gerät angeschlossen.

Nach dem ersten Einschalten macht die Harddisk initiale Kopfpositionierungen. Danach weißer Bildschrim. Immerhin funktioniert also die Monitoransteuerung, denn nur mit funktionierender horizontaler + vertikaler Ablenkung kommt überhaupt ein weißer Bildschirm zustande.

Während ich beim weißen Bildschirm schon rätsele, was das Problem sein könnte, kommt plötzlich nach einigen Minuten das Startbild von GEM. Die Kiste funktioniert also schon mal, soweit ich das bis jetzt prüfen kann. Warum das Booten solange dauert ist mir unklar. Vielleicht ist das Problem, dass ich mangels Kabel Tastatur und Maus nicht anschließen kann. Die Harddisk wird allerdings nicht erkannt, kann auch ein Grund für die lange Bootdauer sein.

Sieht doch schon mal nicht so schlecht aus, oder? Eingeben kann man mangels Tastaturkabel nix. Die Maus ist via Tastatur angeschlossen, also kann man auch den Mauszeiger nicht bewegen…
Die Harddisk wurde nicht erkannt (sonst wäre nämlich mindestens ein C:-Icon da…)


Laboraufbau von der Seite. Laborkabel am Monitor, genaues weiß man nicht…

Harddisk wird nicht angesprochen

Obwohl ich noch keine Maus und keine Tastatur habe, schaue ich mir das Thema „Harddisk“ an. Diese initialisiert sich beim Einschalten selbst (kurzes Rattern, LED leuchtet kurz auf). Danach wird die HD nicht mehr angesprochen. Funktioniert also erst mal nicht.

Ich besaß einstmals die externe Harddisk „Atari Megafile 30“ und habe keine Erfahrung mit internen Harddisks und deren Controllern.

Daher beschäftige ich mich zunächst mit den Jumper-Stellungen der HD. Man kann die SCSI-Adresse einstellen (steht auf Adresse 0), festlegen woher die Terminator Power kommt (steht auf „from Drive“, möglich ist auch „from Bus“), eine Power-up Option (laut Hersteller nicht veränderbar, Jumper soll immer stecken, was er auch tut) und Parity Enable/Disable (steht auf Disable).

Laut diverser Foren und Atari-Doku gilt:

  • Der eingebaute ACSI-Controller von Atari kann kein Parity verarbeiten; diese daher disablen
  • Der eingebaute ACSI-Controller von Atari kann nur eine Harddisk ansprechen, und diese nur unter der SCSI Adresse 0 (mit Hardware-Modifikation kann er zwei Harddisks ansprechen, was bei meinem Gerät aber nicht gemacht wurde)
  • Terminierung durch die Platte soll abgeschaltet werden (eigentlich Quatsch für SCSI, aber für ACSI durch Atari selbst empfohlen).

Der Reality-Check zeigt, dass platten-seitig die SCSI-Adresse 0 eingestellt ist. Parity ist disabled. An der Terminierung kann man bei dieser Harddisk nichts verändern, ich lasse „Terminator Power “ auf „from drive“. Also alles bestens :-;

Da die Platte weiterhin nicht erkannt wird, suche ich im Netz weiter und werde irgendwann fündig (Link):

Die MAXTOR-Festplatten vom Typ 7213, 7245, 7290 UND 7345 funktionieren im MEGA STE und der STACY nur dann am original ATARI Hostadapter wenn die Resetleitung (Pin 40) unterbrochen wird!

Ich habe ja gerade die Maxtor 7345. Unglaublich, ein solches Detail für eine „tote“ Hardware-Plattform im Internet zu finden…
Und aha, das war der weggebogene Pin am Controller, der mir am Anfang aufgefallen war und den ich geradegebogen hatte. Ich biege Pin 40 weg, stecke alles wieder zusammen, und was passiert nach dem Booten? Siehe folgendes Bild!

Die Platte wird wieder erkannt und als Laufwerke C: bis H: eingebunden.
(Für Ungeduldige vielleicht noch wichtig: Der Atari braucht einige Zeit, bis er vom „weißen Bildschirm“ ins Booten von HD übergeht. Schätze so eine Minute muss man warten…)

Da der Atari nun auch annähernd die korrekte Uhrzeit anzeigt (Siehe im letzten Bild oben rechts), bedeutet das, dass auch die Batteriepufferung noch funktioniert. Kann man nach 20 Jahren eigentlich nicht mehr wirklich erwarten, ist aber so…

Anschluss der Tastatur

Die Tastatur wird mittels handelsüblichem RJ12 Kabel angeschlossen, Stecker an beiden Enden (Westernkabel; Alle 6 Pole dieses Kabels sind 1:1 durchgeschaltet; diese Beschaltung wird auch „6P6C“ genannt).

Der Anschluss des Kabels für Tastatur und Maus ist damit eine triviale Sache.


Ja, äh, also die Nutzung dieses Geräts. Heute. 2011.
Obwohl ich -in den 80/90ern- jahrelang täglich einen Atari genutzt habe, ist das Handling die erste halbe Stunde extrem „strange“. Vom aktuellen Ordner zum übergeordneten Ordner kommt man mit dem „Schließen“-Icon des aktuellen Fensters – wie bitte? Und wie beendet man eine Anwendung – öh, das ist je nach Anwendung ganz unterschiedlich… Die Menüleiste, die man heute kennt (Datei – Bearbeiten – Ansicht – …) gibts so nicht, wegen Pixelmangel. War das damals wirklich so kompliziert und vor allem: unlogisch? Wenn man die Maus ganz nach oben drückt, taucht diese Menüleiste plötzlich auf, … versteht eigentlich noch irgendjemand, was ich schreibe 🙂 Wie auch immer, man gewöhnt sich nach einer halben Stunde oder so daran.
Da ich bei der oben erwähnten Plattengröße viele Partitionen (C:, D:, E:, F:, G:, H:) habe, dauert es länger bis ich weiß was ich „for free“auf der Platte habe:

  • 1st Word Plus (ganz nette Textverarbeitung)
  • Tempus (sagenhaft guter und rasend schneller Texteditor, auch wenn ihn heute keiner mehr kennt)
  • Calamus (DTP Programm würde man heute sagen)
  • GFX Basic (zwei Kreuze)
  • Diderot (Zeichenprogramm)
  • Ein paar Fonteditoren
  • Leider kein C-Compiler 🙂

Wie geht es weiter?

„Offiziell“ ist die Plattform Atari+68000+TOS tot. Seit mehr als 10 Jahren.
Eine Suche nach einschlägigen Themen fördert heute noch zahlreiche Anlaufstellen im Web zutage. Nachdem Atari, das Betriebssystem TOS und die Atari-TOS-kompatiblen Systeme weitgehend Geschichte sind, ging die Geschichte nutzer-getrieben einfach weiter.
Es gibt heute Atari-Emulatoren in Software, die unter Windows und Linux laufen, weiterentwickelte, rasend schnelle Hardware-Clones, auf der die alten TOS-Programme immer noch laufen, und auch aktuelle Hardware, die den ursprünglichen Gedanken („68xxx CPUs sind eine geniale Plattform für die Entwicklung von Software“)  seitdem weiterentwickelt haben:

  • Die Firma Freescale hat die Idee der „altlast-freien“ CPU seitdem weiterentwickelt, das aktuelle, daraus resultierende Produkt trägt den Namen „Coldfire“
  • Die alten Software-Provider für die TOS-Plattform existieren heute nicht mehr oder haben sich anderen Gebieten zugewandt. Oft wurde aber „rechtzeitig“ die damals kommerzielle Software in Open Source Software überführt, so dass diese heute noch immer (und vor allem: im Source-Code -und oft verbessert) verfügbar ist
  • Die -von mir schon mal jetzt als legendär eingestufte- GNU Suite wurde auf die 68k-Plattform übertragen
  • Von Atari angestoßen, entstand die (Multitasking-fähige) MiNT-Plattform als Nachfolger von TOS (das ehrlicherweise nur Single-Task-fähig war)

Aus praktischer Sicht: ein beachtlicher Anteil der für die TOS/68K-Plattform wichtigen Software ist heute noch verfügbar! Eine kurze Suche bringt neben den bereits erwähnten Themen:

  • Uniterm – das damals beste Terminal-Programm
  • gcc – GNU C Compiler
  • Diverse Shells (golem, mupfel, …)
  • AHCC Compiler, dieser Compiler wird auch zur Entwicklung auf Coldfire verwendet und weiterentwickelt
  • Pure C – C Compiler, die Weiterentwicklung dieses Compilers wurde in den 90ern eingestellt, der Compiler ist aber in einer Binary-Variante im Netz verfügbar
  • Zahlreiche Assembler

Beispielhaft hier ein Screendump vom AHCC C Compiler.

<to be continued>

Datenaustausch vom/zum Mega ST

Ideal wäre eine LAN-Verbindung, die der Atari aber nicht hat. Allerdings gibt es in Netz diverse Selbstbauanleitungen zu LAN-Adaptern, die z.B. am ROM-Port betrieben werden können mit fertigen Treibern für TOS.

Ein Austausch mit Disketten ist simpel. Da Disketten heute rar sind -ich habe keinen Rechner mit Floppy-Laufwerk mehr- kann man dies via Uniterm-Programm mittels des kermit-Protokolls machen.
Für Uniterm/kermit braucht man nur ein Nullmodemkabel und kann dann mit 38,4KBaud Daten übertragen. Der Mega STE könnte deutlich mehr (habe was von 115,2KBaud gelesen) aber das kann man mit Uniterm leider nicht einstellen. Kermit muss dann PC-seitig als „Server“ gestartet werden („kermit -x“), Uniterm-seitig muss man das Übertragungsprotokoll „kermit“ einstellen. Danach mit get/put von Atari aus Daten hoch und herunterladen. Leider ist diese Verbindung nicht sonderlich stabil, liegt eventuell an meinem schlampig zusammenglöteten Nullmodemkabel.
Ich probiere dann mit dem rzsz-Paket herum „rz“ und „sz“ sind Linux-seitige Programme zum empfangen und Senden von Daten über das ZMODEM-Protokoll. rzsz ist unter OpenSuse einfach per YasT nachinstallierbar. (Link zu diesem Thema hier).

Die Nutzung von rzsz mit dem Atari besteht aus den folgenden Schritten

1) Installation des Pakets rzsz unter Linux

2) Terminalprozeß auf einem seriellen Port laufen lassen (getty Prozess)
Dazu die folgende Zeile (bzw. eine mit passenden Parametern) in /etc/inittab an der passenden Stelle eintragen (bei den virtuellen Konsolen):
S0:2345:respawn:/sbin/agetty -L 19200 ttyS5 vt100

3) Atari starten, Terminalprogramm starten, Baudrate auf 19200
stellen (8 Bit, no parity, kein Stopbit, Flow=XON/XOFF, Mode=FULL)
Terminalfunktion starten, evtl. <return> eingeben.
Unter Uniterm Transfer auf YMODEM stellen (ZMODEM gibts da nicht).
Es sollte ein Linux Login-Prompt kommen. Dort einloggen.

4a) Senden von Linux -> Atari
Auf Linux Rechner eingeben:
sz <dateiname> <datei2> …
Auf Atari Empfangsdialog öffnen.(Bei Uniterm: Alt-T eingeben).
Im Dialog dann „Empfangen“ wählen. Die Datei(en) wird/werden dann auf den Atari übertragen.

4b) Senden von Atari -> Linux
Auf Linux Rechner eingeben:
rz –ymodem
Auf Atari Sendedialog öffnen. (Bei Uniterm: Alt-T eingeben).
Im Dialog dann „Senden“ wählen. Die Datei(en) wird/werden dann auf den PC übertragen.

Die Verbindung mit rzsz ist wesentlich flotter und auch stabiler.

Weiterführende Infos

Innenansicht Sharp CS2151 Tischrechner

Frühe 1970er Jahre. Schon mit mit grünem Fluoreszenz Display.

Top mechanische Qualität. Verarbeitung und Tasten wirken völlig unbeeinflusst vom Zahn der Zeit. Es wirkt so stabil, dass es auch einen Sturz vom Tisch überleben könnte…

Zustand bei Eingang, ungereinigt, Display zeigt nichts an


Blaue Tasten für den Speicher)



Made in Korea


Deckel abgenommen



Blick auf die 13-stellige Anzeige. Davor die Logik-Platine, davor die Tastatur-Mechanik. Die Kunststoffdämpfung an den Tasten hat sich weitgehend zu Staub zersetzt.




Das Druckwerk






Das Oberteil lässt sich einfach zur Seite klappen



Hier wurde die Tastatur bereits gereinigt


Sieht sie nicht toll aus, diese Anzeigeröhre 🙂


Die Anzeigeröhre im Detail

Die verwendete Anzeigeröhre ist schon was besonderes. Daher hier ein paar Detailaufnahmen.

Der Chip „D223C“ von NEC ist vermutlich die „CPU“ des Tischrechners.






Der Chip „D507C“ von NEC dient vermutlich der Ansteuerung des Druckwerks.


Detail zur Ansteuerung des Druckwerks,


  • Eintrag bei  Schlepptops.de – http://www.schlepptops.de/wiki/index.php?title=Sharp_CS-2151

Qumetrak 842 – 8 Zoll Floppy Laufwerk, 1982

Als Student arbeitete ich in einem Forschungsinstitut. Dort lief Ende der 80iger  Jahre noch die eine oder andere VAX (an einer VAX 750 habe ich noch gearbeitet). Eines Tages wurden diverse Altgeräte entsorgt und standen ein paar Stunden auf dem Flur herum. Leider hatte ich da keinen Lastwagen 🙂
Immerhin habe ich mir eines der 8 Zoll Laufwerk mitgenommen, die an den VAXen hingen und stelle dieses Laufwerk hier vor.

Das Laufwerk ist ein QumeTrak 842. Es wiegt etwa 6 Kilogramm und hat die Abmessungen 370mm (Tief) x 217mm (Breit) x 117mm (Hoch). Das Laufwerk ist zum damaligen Quasi-Strandard Shugart SA850 kompatibel. (Hintergrundartikel zu Floppies bei Wikipedia)

Eine 8 Zoll Floppy fasst immerhin 1,2MBytes bei Double Density und Double Sided Nutzung. Die Floppy wurde bei einer Geschwindigkeit von 360 U/min eingesetzt und erlaubte Transfer-Raten von 500KBit/s.

Das Laufwerk verbraucht im Betrieb laut Handbuch maximal 55 Watt (kein Witz!).

Ansicht von vorn. Einschublade geschlossen.




Ansicht von vorn. Einschublade geöffnet.


Eine 8 Zoll Floppy.


Eine Schachtel, in die 10 8 Zoll Floppies passten.


Ein paar 8 Zoll Floppies habe ich auch retten können…


Maxell FD2 XD M 1200.
With W.P. Notch
Double Sided
Double Density.


So wird die Floppy in die Lade geschoben…


hier ist die Floppy eingeschoben ….


… und die Lade verschlossen.



Ansicht von oben.


Die Steuerplatine. Komplett mit 74xx-ICs aufgebaut.


Der Schrittmotor für die Kopfpositionierung. Ein Riesenteil, aber der Motor für die Rotation der Floppy ist noch viel größer (siehe weiter unten)…


Elektromagnet, der den Auswurf der Floppy/Öffnen der Lade steuert


Der Lese/Schreibkopf ist hier in der Bildmitte zu erspähen


Unterseite mit eingeschobener Floppy.


Blick auf eine Lichtschranke (hier wird der Schreibschutz der Floppy gelesen. Desweiteren ist in der Floppy ein Loch, mit dem das Laufwerk eine komplette Drehung erkennen kann).


Blick auf Lese/Schreibkopf (Unterseite)


Positionierungdes Lese/Schreibkopfs


Der Motor, der die Umdrehung der Floppy steuert. Dies ist kein Schrittmotor.


Detail der Kopfpositionierung. Das handschriftlich notierte Datum
ist 27. April 1982 („4/27/82“)


Nochmal die Lichtschranken…


Hier ganz nah die Leuchtdioden (oder waren das damals noch Glühlampen?) Anschlüsse

Das Qumetrak 842 besitzt zur Verbindung mit der Außenwelt drei Anschlüsse:

  • DC Connector
  • AC Connector
  • Signal/Daten-Anschluss

Die Signal/Daten-Anschlüsse des Qumetrak sind TTL-kompatibel und Active-Low.

Anschlussbuchse1 von 3
Dies ist der „DC Connector“ und dient der Versorgung des Geräts mit
+5V/+24V. Er besitzt 6 Pole (0V/+24V/0V/+5V/2xungenutzt).

Die +5V werden laut Handbuch mit maximal 1,3A belastet. Die +24 V werden mit max. 1A belastet.

Anschlussbuchse2 von 3
Dies ist der „AC Connector“ P0/J0 und dient der Versorgung des AC Motors
mit Netzspannung (230V). Der Connector hat 3 Pins (AC, Gerätemasse, AC).

Die 200/230V werden mit maximal 0,4A belastet.

Anschlussbuchse3 von 3
Dies ist Connector J1 im Handbuch.

Der Datenanschluss Connector J1 besitzt 50 Kontakte, die auf der Controller-Platine beidseitig aus je 25 Kontakten gebildet werden.

Anschlussbuchse 3 von 3, Blick von Oberseite


Diese Buchse aus meinem Fundus passt genau auf den Anschluss 3 …



Auf der Controller-Platine finden sich diverse Jumperleisten um das Laufwerk in unterschiedliche Rechnerumgebungen integrieren zu können.

Diese Jumperleiste … (muss ich noch rauskriegen)

TP Testpunkt (?)

Der „Programmable Shunt“ (Bildmitte).

Der Shunt besteht aus 8 Drahtbrücken, die einfach unterbrochen werden können (eine der Brücken, wohl die ganz rechts, ist ungenutzt). Wie man sieht, sind drei der Brücken unterbrochen worden.

R READY alternate output pad
I INDEX alternate output pad
HL Stepper power from HEAD LOAD

Auch diese Jumperleiste gehört zu den „Optional I/O“ Einstellungen.

Diese Jumperleiste … (muss ich noch rauskriegen)

DS Stepper power from DRIVE SELECT(?)

Die „Drive Select“ Jumperleiste.

Mittels der Drive Select Jumperleiste kann die Verwendung mehrerer Laufwerke an einem Computer gesteuert werden. Bis zu 8 Laufwerke können in zwei  „Daisy Chains“ a 4 Laufwerke verwendet werden. Dazu existieren 4 Drive Select Pins DS1-DS4, (aber nur) aus drei dieser Pins kann die Laufwerksnummer gebildet werden. Im Bild hat das Laufwerk die Drive Nummer 1  (es gab also vermutlich noch mindestens ein weiteres Laufwerk, das Laufwerk 0  an der Maschine).

DS1 Drive Select 1
DS2 Drive Select 2
DS3 Drive Select 3
DS4 Drive Select 4

Die „Optional I/O“ Jumperleiste.

Diese Jumperleiste … (muss ich noch rauskriegen)

2S Alternate Output DISK 2 SENSE (?)
DC Alternate Output DISK CHANGE (?)
D Alternate Input IN USE(?)
C Alternate Input HEAD LOAD(?)


Zerlegung Notebook Paradigma

Hier sind einige Bilder von der Zerlegung eines Notebooks der ersten Generation(en), von etwa 1993/94. Das Paradigma Notebook hat eine 80486 DX2-er CPU mit satten 🙂 66Mhz, 4MB RAM, 330 MB Platte, ein monochromes Display mit 640×480 Pixeln und wurde mit Windows 3.0 ausgeliefert. Ich habe es 2009 entsorgt und vorher zerlegt.

Laut Typenschild handelt es sich um ein Paradigma efn4m/4. Es bootete vor der Zerlegung noch, allerdings war die Pufferbatterie mittlerweile defekt, so dass ein paar Einstellungen (u.a. Uhrzeit verloren gegangen waren).

So sieht’s aus wenn man das Notebook bootet, noch im BIOS bzw. DOS-Modus…

und hier dann im Windows 3.11 for Workgroups angekommen.

So sieht das Notebook vor der Zerlegung aus.

ein kleines LCD_Display informierte damals über Akku-Ladezustand etc.

Anschlussmöglichkeiten: VGA, Parallel, Seriell. PS/2, Netzteil und (vermutlich) Docking-Station. USB war noch nicht erfunden.

Entfernen der Tastatur

Entfernen des Trackballs…

und der 330MByte-Harddisk.

Bild nach Entfernen der oberen Plastikabdeckung. Links (weiss abgedeckt) die CPU, unten ist Platz für Einschübe (Akkus, Floppy-Laufwerk, …)

Der PC-Karteneinschub.

Details der Peripherie um die CPU herum (die CPU ist noch weiß abgedeckt). Rechts der 4MB RAM Baustein. Das aufgesteckte Teil links kann ich nicht deuten, es enthält aber   xRAM- oder xROM-Bausteine.

Hier die CPU-Platine von der Restplatine abgenommen, die weisse Abdeckung wurde entfernt.

Und zum Schluss die Unterseite des Motherboards.