Kennen Sie Robert Bemer und Werner Buchholz? Nein? Vielleicht ist dies auch besser so, schließlich sind diese beiden Herrn mit Schuld, dass Ihr digitales Modellbahn-Hobby an einigen Stellen eine Qual ist.

Bemer und Buchholz haben in den 1950er Jahren zusammen mit Kollegen bei IBM gearbeitet und im Rahmen eines Projekts festgelegt, dass bei der damals neuen IBM Maschine ein Byte acht Bit haben soll. Nach dieser IBM Entscheidung haben alle anderen Computer-Hersteller dieses System übernommen. Heute ist dies so selbstverständlich, dass bereits Kinder in der Schule diese Tatsache lernen. Das diese Einteilung aber letztendlich reine Willkür ist, macht sich heute keiner mehr bewusst. Und hätten die beiden Herren entschieden ein Byte mit 10 Bit oder 16 Bit zu definieren, wäre den DCC-Nutzern viele Ärger erspart geblieben…

Am Beispiel des Adress-Modus von Zubehördecoder möchte ich das Problem vorstellen. Im Adress-Modus können Zubehördecoder eine Adresse zwischen 1 und 511 haben. Jeder Adresse sind vier Unteradressen bzw. Funktionen zugeordnet. (Statt der Kombination aus Adresse und Unteradresse besteht auch die Möglichkeit die Zubehöradressen von 1 bis 2047 durchzunummerieren. Daruf gehe ich an dieser Stelle jedoch nicht ein.)

In einem Byte mit acht Bit lassen sich jedoch nur die Zahlen 0 bis 255 speichern. Für über 500 Adressen ist kein Platz – Dank den Herren Bemer und Buchholz. Deshalb muss die Adresse auf zwei Konfigurationsvariablen (CV) aufgesplittet werden. Bei den Zubehördecodern geschieht dies nach folgendem Muster:

Die Abbildung zeigt als erstes die acht Bit der CV #9 (grau hinterlegt). Als zweites folgen die acht Bit der CV #1. In der zweiten Zeile steht der Wert jedes Bits. Im normalen Dezimalsystem kennen wir die Stellenwerte von Hunderter (H), Zehner (Z) und Einer (E). Grundschüler müssen heute im Unterricht lernen, dass die Zahl 345 aus drei Hundertern (H), vier Zehnern (Z) und fünf Einern (E) besteht. Im Dualsystem haben die Stellen jedoch andere Werte – wie sie in der Tabelle angegeben sind.

Für Zubehördecoder im Adress-Modus werden 9 Bits benötigt. In der NMRA Spezifikation wurden diese neun Bits jedoch anders aufgeteilt: Sechs dieser Bits stehen in CV #1 und drei in CV #9. In der dritten Zeile „Adress-Wert“ habe ich die Bedeutung der signifikanten Stellen für die Adresse aufgeschrieben. Die sechs Bits in CV#1 entsprechen den normalen Bit-Werten. In CV #9 stehen jedoch die verwendeten Bits für die Zahlen 256, 128 und 64 !

Deutlich wird dies am Beispiel: In den CVs können nur die Ziffern 0 und 1 stehen. Wer die Adresse des Decoders ermitteln möchte muss alle Werte der Zeile „Bit-Wert“ zusammen zählen, in denen in der Beispiel-Zeile eine 1 steht. In der ersten Abbildung steht die Eins in den Spalten „32“, „8“ und „1“. Die Summe 32+8+1=41 ergibt somit die Adresse des Zubehördecoder in diesem Beispiel: 41.

So einfach wie im Beispiel ist es immer dann, wenn in CV #9 eine Null steht. Dann stimmen nämlich die Stellenwerte der Bits von CV #1 mit dem Wert der Adressen überein. Die größte „einfache“ Adresse ergibt sich, wenn in den sechs signifikanten Bits von CV #1 jeweils eine Eins steht:

Die Adresse ergibt sich aus 32+16+8+4+1 = 63. Möchte ein DCC-Nutzer also bei einem Zubehördecoder im Adress-Modus nur die Adressen zwischen 1 und 63 nutzen, kann er einfach die entsprechende Dezimalzahl in CV #1 und eine Null in CV #9 schreiben. Die Umrechnung in die Nullen und Einsen des Dualsystems passiert dann automatisch.

Leider ist es für die Adressen 64 bis 511 komplizierter. Dafür werden die drei Bits in CV #9 benötigt. Nehmen wir als erstes Beispiel einfach die Adresse 256. Für diese Adresse muss in der Spalte des Adress-Wert „256“ eine Eins stehen. Alles andere ist Null. Während jetzt CV #1 jedoch den Wert 0 hat, muss in CV #9 der Wert 4 reingeschrieben werden!

Dies liegt daran, dass wir nicht die Zahlen der „Adress-Wert“-Zeile addieren müssen sondern die Zahlen der „Bit-Wert“-Zeile. Dieser Umweg ist nötig, da die höchste Zahl in einem Byte die 255 ist. Durch die Zuordnung von Bit 4 zur Zahl 256 kann man diese Einschränkung umgehen – allerdings muss diese Zuordnung der Anwender selbst machen (sofern sein Digitalsystem dies nicht als Komfortfunktion anbietet).

Das letzte Beispiel zeigt die Problematik nochmal am Beispiel der Adresse 358:

In CV #9 sind die Bits 4 und 1 mit einer Eins markiert. In CV #9 wird also der Wert 4+1=5 abgespeichert, obwohl er für die Adresse 256+64=320 steht. In CV #1 sind die Bits 32, 4 und 2 markiert, die für den Wert 38 stehen. Da sich die Adresse aus CV #9 und CV #1 zusammen setzt, hätte dieser Zubehördecoder im Adress-Mode die Adresse 320+38=358.

Die in der „Adress-Wert“-Zeile mit „X“ markierten Spalten haben für die Ermittlung der Adresse übrigens keine Funktion und werden in der Regel den Wert 0 haben. Theoretisch könnte man mit diesen Bits noch die Anzahl der verfügbaren Adressen erhöhen – für den normalen Gartenbahner dürfte dies aber vermutlich uninteressant sein. Nur kurz erwähnt sei an dieser Stelle, dass die NMRA ursprünglich statt der CV #1 die CV #513 und statt der CV #9 die CV #521 für Zubehördecoder vorgesehen hatte. Daher findet man Häufig in Anleitungen beide Varianten angegeben.

In der Praxis ist es übrigens nicht notwendig diese ganzen Umrechnungen per Hand zu machen. Auf verschiedenen Internetseiten, zum Beispiel auf der Seite LGB Magnetartikeladressen von Arnold Hübsch, gibt es Tabellen in denen sich die entsprechenden Werte einfach ablesen lassen. Wer die Hauptadresse 358 aus dem letzten Beispiel in der Tabelle von Arnold Hübsch sucht, findet dort für die Hauptadresse die Werte 5 für CV #9 und 38 für CV #1 sowie in den Wert 0 in CV #33 für die Unteradresse. In der Tabelle lässt sich sogar zusätzlich ablesen, dass die Hauptadresse 358 mit der Unteradresse 0 in Systemen mit durchgehender Nummerierung die Adresse 1429 hätte.

Hätten Bemer und Buchholz damals doch mindestens 10 Bits für ein Byte genommen …

… aber dann hätten wir heute nichts zu schreiben!