###   Projekte und Informationen rund um den KC85   ### 

Nun wird ein permanenter Zugang des KC85-Systems zum Internet langsam Pflicht. Die Default-Konfiguration des folgenden Programmes benötigt Zugriff auf einen Internet-Zeitserver, mit dessen Hilfe ab sofort Datum und Uhrzeit des KC unter CP/M automatisch gestellt werden können.

Mit der Umsetzung von NTIME.COM für CP/M kann ich den nächsten Punkt von meiner Software-Wunschliste für Netzwerk und Internet streichen. Herausgekommen ist wieder ein kleines Programm, welches beim Systemstart in einen Start-Submit verpackt (natürlich erst nach NCFG.COM), automatisch die Systemuhr des KC stellt. Es ist zwar zweimal im Jahr zur Sommer- bzw. Winterzeitumstellung noch etwas nachzuhelfen aber bis Ende 2077 muss man sich normalerweise nicht mehr um die RTC oder CTC-Uhr kümmern. Voraussetzung dafür ist, dass die Zeitserver auch nach 2036 wie gewohnt weiterzählen, da gibt es den ersten richtigen Überlauf des Sekundenzählers auf 0 ...

Ein MLDOS ohne RTC hat damit nun die Möglichkeit, die DateStamper-Funktionalitäten komfortabler bereitzustellen (ein M052 wird natürlich dafür benötigt), da man die CTC-Uhr nicht mehr nach jedem Systemstart per Hand stellen muss. Unter MikroDOS wird zumindest die Uhrzeit der CTC-Uhr gestellt, dort ist ja keine Verwaltung des Datums vorgesehen. In NTIME.COM hat der KC eine ganze Menge zu rechnen. Diese Rechenaufgaben und die möglichst RFC getreue Umsetzung der Netzwerk-Funktionen haben diesmal den Hauptanteil der Entwicklungszeit in Anspruch genommen, welche aber mit einigen Wochen immer noch gut überschaubar geblieben ist, auch durch die Nutzung von Quellen anderer CP/M-Programmierer.

An dieser Stelle deshalb vielen Dank an Mario Leubner für den Code in CCP.MAC, welcher sich im MLDOS um Anzeige, Eingabe und das Stellen der Systemzeit kümmert. Weiterhin geht ein grosses Dankeschön an Werner Cirsovius, siehe CP/M Links, welcher mir mit den 32 Bit Arithmetik-Funktionen seiner BASELIB sehr viel Arbeit erspart hat!

Funktionsweise

Es gibt mehrere Möglichkeiten, die Uhrzeit per Netzwerk heraus zu bekommen. Die einfachste Variante wird in RFC 867 mit dem "Daytime Protocol" beschrieben, welches in einer Zeile ASCII-Text die Zeit im Klartext zurückgibt (UDP/TCP Port 13) und meist nur in LAN's verwendet wird. Eine weitere Variante gibt es in Form des "Time Protocol" entsprechend RFC 868, dort wird UDP/TCP Port 37 verwendet. Das funktioniert auch per Internet, es wird eine Zahl zurückgegeben, welche den vergangenen Sekunden seit dem 01.01.1900 00:00:00 Uhr GMT (UTC) entspricht. Die Umrechnung in das aktuelle Datum und die Uhrzeit muss der Computer selbst vornehmen. Beide Varianten sind veraltet und die Anzahl der frei verfügbaren Zeitserver nach RFC 868 nimmt kontinuierlich ab.

Heute ist NTP das Standardprotokoll zur Zeitsynchronisierung über das Netzwerk. Allerdings benötigt auch der KC keinesfalls die hohe Genauigkeit von NTP bis in den Nanosekundenbereich, da die Systemuhr ja nur eine Sekunden-Auflösung besitzt. Für einen einfachen Uhrenabgleich gibt es deshalb das SNTP Protokoll, welches als Teilmenge von NTP aufzufassen ist und 1992 in RFC 1361 vorgeschlagen wurde. NTIME.COM wurde auf der Basis des aktuellsten RFC 4330 (Januar 2006) geschrieben und entspricht damit dem "Simple Network Time Protocol" Version 4 (SNTPv4).

Die grundsätzliche Funktion entspricht nahezu dem veralteten "Time Protocol", allerdings wird immer UDP auf Port 123 verwendet. Der KC sendet als UDP-Client (unicast) eine Anfrage an einen NTP-Server und erhält eine Antwort, welcher er neben der Zeit, noch weitere Angaben zum Zeitserver und dessen Referenz-Uhr entnehmen kann. Datum und Uhrzeit werden vom NTP-Server als 64 Bit Zeitstempel zurückgegeben, wobei die ersten 32 Bit für die vollen Sekunden und die restlichen 32 Bit für den Sekundenbruchteil seit 01.01.1900 00:00:00 Uhr UTC verwendet werden. Den KC interessieren nur die ersten 32 Bit, die hinteren 32 Bit werden nicht berücksichtigt.

Mit dem verbleibenden Zeitstempel in vollen Sekunden kann ein normal sterblicher Mensch immer noch nicht viel anfangen - dezimal ist das eine ziemlich grosse Zahl mit 10 Stellen vor dem Komma. Um die aktuellen lokalen Zeitdaten für ein CP/M System auszurechnen sind nun mehrere Zwischenschritte bzw. Umrechnungen notwendig.

Zunächst muss der Beginn der Zeitzählung auf CP/M-Zeit normalisiert werden. Vom NTP-Server kommen die gezählten Sekunden seit 01.01.1900 00:00:00 Uhr UTC. CP/M-Zeitstempel beziehen sich auf den 01.01.1978 00:00:00 Uhr UTC. Das entspricht unter Berücksichtigung von Schaltjahren genau 2.461.449.600 Sekunden, welche subtrahiert werden. Da es an dieser Stelle einfacher ist, werden anschliessend gleich noch Zeitverschiebungen zu UTC berücksichtigt, welche sich durch die lokale Zeitzone und Sommer- bzw. Winterzeit ergeben, beispielsweise gilt in Deutschland UTC +1 Stunde (+3600s) und während der Sommerzeit muss noch eine Stunde (+3600s) dazugezählt werden. Um universell zu bleiben, muss an dieser Stelle auch subtrahiert werden können, da es auch Zeitzonen mit negativer Zeitverschiebung zu UTC gibt.

Nun ist die recht grosse Anzahl an Sekunden zwar schon etwas kleiner geworden aber man weis immer noch nicht, wie spät es ist. Deshalb zerlegt das Programm anschliessend die bereits an dieser Stelle aktuelle lokale Zeit in Sekunden nacheinander in seine einzelnen Bestandteile von gross nach klein, also Jahr -> Monat -> Tag -> Stunde -> Minute -> Sekunde. Dabei müssen sowohl Schaltjahre als auch die unterschiedlich langen Monate richtig berechnet werden, sonst stimmt am Ende weder das Datum noch die Zeit. Wenn das erledigt ist, hat es der KC fast geschafft. Die Zeitstempel unter CP/M werden nicht binär gespeichert, sondern im gepackten BCD-Format. Diese Konvertierung wird nun abschliessend noch erledigt und damit kann dann endlich die Systemuhr gestellt werden:

  • unter MikroDOS (nur KC85) wird die Systemzeit gestellt (keine Verwaltung des Datums vorhanden)
  • unter ZSDOS/ZDDOS wird die Systemzeit mit BDOS-Funktion 99 gestellt
  • unter CP/M Plus und höher wird die Systemzeit mit BDOS-Funktion 104 gestellt

Für andere Systeme muss der Code für das Stellen einer Hardware- oder Software-Systemuhr selbst eingefügt werden. Im Quelltext ist das entsprechend gekennzeichnet.

NTIME.COM

Als Autor hat man es ja in der Hand, wie sich ein Programm in seiner Grundkonfiguration verhält. NTIME.COM ist daher auf MET, die "Middle European Time", voreingestellt und befragt standardmässig bis zu 4 NTP Zeitserver aus dem deutschen Serverpool von pool.ntp.org, wobei der konkrete Server über eine DNS-Abfrage ermittelt wird. Während der normalen Zeit in Deutschland (Winterzeit) muss man also gar keine Parameter in der Kommandozeile angeben, Beispiele siehe unten.

Das Programm setzt ein korrekt konfiguriertes Netzwerk-Interface voraus, was beim Start auch überprüft wird. Wenn der KC nicht an das Netzwerk angeschlossen ist oder die Konfigurationsdaten fehlen, gibt es entsprechende Fehlermeldungen. Da standardmässig Server im Internet befragt werden, müssen nun auch der Gateway und DNS-Server richtig konfiguriert sein und dem KC muss der Zugriff auf das Internet gestattet werden.

Wie es sich aber für ein universelles Zeitprogramm gehört, kann es per Kommandozeile oder Veränderung der internen Voreinstellungen weltweit benutzt werden. Wie üblich zeigen die beiden Optionen -v die Version und -h eine Hilfeseite zum Gebrauch von NTIME.COM an:

NTIME10 Version und Hilfe

 

Wer es ganz genau wissen will, gibt die Option -f an. Dann liefert das Programm ausführliche Informationen zum antwortenden NTP-Server, seiner Referenzuhr, seiner letzten Synchronisierung mit dieser Referenz und quasi ein Bildschirmprotokoll der oben beschriebenen Schritte, siehe auch folgendes Bild. Ohne -f wird nur das Datum und die Uhrzeit ausgegeben und ob die Systemuhr erfolgreich gestellt werden konnte.

Für ganz gewissenhafte Netzwerkbenutzer gibt es die Option -r. Normalerweise wählt das Programm die intern bzw. extern angegebenen Serveradressen chronologisch für die Abfrage aus. Für eine bessere Verteilung der Netzwerklast, sollten aber Anfragen gleichmässig auf die zur Verfügung stehenden Server verteilt werden. Mit der zufälligen Auswahl der Adresse wird dem gewissermassen Genüge getan, obwohl die 40 KC's mit M052 auch bei gleichzeitiger Abfrage des gleichen Servers wohl das NTP-System nicht zum Absturz bringen werden :-). Durch den vorgeschalteten Pool von ntp.org bekommt man darüber hinaus so gut wie nie den gleichen Server per DNS zugewiesen.

Wer die intern voreingestellten NTP-Server nicht verwenden möchte oder kann, gibt andere Adressen einfach extern an, bis zu 4 sind möglich. Der Server kann sich auch im LAN befinden. Wenn diese Möglichkeit besteht, ist sie sowieso zu bevorzugen, da die Antwort zuverlässiger und i.d.R. auch schneller eintrifft.

Falls das Programm nicht in der MET-Zeitzone benutzt wird, kann man extern eine Zeitverschiebung von +/- 0 bis 13 Stunden angeben. Davon getrennt lässt sich auch noch ein zweiter Parameter von +/- 14 bis 780 übergeben, welcher als Minutenangabe für die zusätzliche Zeitverschiebung zur Sommer- bzw. Winterzeit interpretiert wird.

Ganz wichtig - wenn man extern Zeitverschiebungen oder Serveradresse(n) angibt, werden immer die internen Voreinstellungen deaktiviert, wenn man also nur 1 externe Adresse angibt und von dort keine Antwort bekommt, erhält man auch keine Uhrzeit. Die internen werden also durch externe Angaben grundsätzlich überschrieben bzw. deaktiviert.

NTIME10 in Aktion

 

Anwendungsbeispiele

Nachfolgend dann ein paar Beispiele für die Nutzung von NTIME.COM:

NTIME

So wird das Programm aufgerufen, wenn sich der KC in der MET-Zeitzone, also in Deutschland befindet, die Uhrzeit aus dem Internet bezogen werden soll und gerade Normalzeit (Winterzeit) aktuell ist.


NTIME +60

Das gleiche Szenario wie in Beispiel 1 aber es ist gerade Sommerzeit, also MEST (Middle European Summer Time).


NTIME +0 +60 0.uk.pool.ntp.org 1.uk.pool.ntp.org 2.uk.pool.ntp.org

Hier steht der KC in Grossbritannien, bezieht die Zeit aus dem Internet von englischen Zeitservern und es ist gerade Sommerzeit, dort heisst das BST (British Summer Time).


NTIME +3 192.168.0.1

In diesem Beispiel steht der KC in Moskau, es gibt einen NTP-Server im LAN (192.168.0.1) und es ist Moskauer Standardzeit, MSK (Moscow Standard Time).


Wie man den ersten beiden Beispielen entnehmen kann, ist das Programm derzeit noch nicht in der Lage, automatisch die Sommer- bzw. Winterzeitumstellung zu bestimmen, so dass man eine ev. Batchdatei zweimal im Jahr per Hand ändern muss. Das ist erstens nicht ganz trivial in Assembler zu programmieren, zweitens national unterschiedlich geregelt und drittens ändern sich die betreffenden Regeln auch gar nicht so selten.

Das hätte jedesmal auch eine Änderung am Programm zur Folge. Ich habe deshalb vorerst darauf verzichtet, obwohl man dafür im Internet entsprechende Algorithmen problemlos findet. Ein noch nicht zuende gedachter Lösungsansatz über die Berechnung des "Julianischen Tages", mit dessen Hilfe man relativ einfach feststellen kann, ob Sommerzeit ist oder nicht, befindet sich am Ende des Quelltextes als Kommentar ...

Anpassung der internen Voreinstellungen

Die Voreinstellungen des Programmes lassen sich einfach verändern, indem man im Quelltext NTIMExx.MAC an den entsprechenden Stellen die gewünschten Werte bzw. Serveradressen einträgt und das Programm neu übersetzt. Es gibt auch Zeitzonen, wo die Zeitverschiebung nicht volle Stunden beträgt. Dann sollte man das intern erledigen, da dort Sekunden eingetragen werden müssen und so jede beliebige Zeitverschiebung definiert werden kann.

Nachfolgend die Symbole im Quelltext für die Festlegung von Zeitzone, Sommer- bzw. Winterzeitverschiebung und die bis zu 4 vordefinierten NTP-Server Adressen.

TimeZone:

T_ZSGN:    DB    '+'                   ;MET offset sign
T_ZOFS:    DB    0,0,00EH,010H         ;MET offset = 3600s (32Bit NOrder)

Daylight Savings Time:

T_DSGN:    DB    '+'                   ;Daylight Savings time offset sign
T_DOFS:    DB    0,0,0,0               ;Daylight Savings time offset = 0s (32Bit NOrder)

NTP server addresses:

NTP1:      DB    '0.de.pool.ntp.org',0
NTP2:      DB    '1.de.pool.ntp.org',0
NTP3:      DB    '2.de.pool.ntp.org',0
NTP4:      DB    '3.de.pool.ntp.org',0


Das Programm, die Quelltexte und eine kurze Beschreibung wurden den KCNet-Softwarepaketen hinzugefügt, welche sich im Downloadbereich befinden - viel Spass beim Ausprobieren!