
 Ŀ
                   Bugs im C-Control/BASIC-Betriebssystem                  
 

 Es gibt wohl kein groesseres Computerprogramm das fehlerfrei ist. Auch das
 Betriebssystem des C-Control/BASIC-Chips macht in dieser Hinsicht keine
 Ausnahme. Beim Untersuchen und Kommentieren des Betriebssystems und dem
 Lesen der drei Informationsforen zum C-Control bin ich bisher auf die im
 folgenden geschriebenen Ungereimtheiten gestossen.


 Ŀ
       Fehler bei Verwendung einer BASIC-Interruptroutine (ON..GOSUB)      
 

 Der Programmierer des C-Control/BASIC-Betriebssystems hat die Funktionen zum
 Handling des Rechenstacks etwas zu gut optimiert. Um Ausfuehrungszeit zu
 sparen, existiert keine Funktion die den Rechenstack wirklich vollstaendig
 leert. Vielmehr bleibt nach einer Rechenoperation das letzte Rechenergebnis
 immer auf dem Stack stehen (als "Top-Of-Stack Word" an Adresse $91 und $92),
 was an sich noch nicht schlimm ist. Probleme tauchen erst auf, wenn in einem
 BASIC-Programm eine Interruptroutine (siehe INTERRUPT und RETURN INTERRUPT)
 verwendet wird. Fast jede noch so einfach gehaltene Interruptroutine benutzt
 die vom Betriebssystem bereitgestellten Funktionen zum Zwischenspeichern von
 Worten auf dem Rechenstack und hinterlaesst so den Stack unaufgeraeumt.

 Da das Hauptprogramm nach Abarbeitung eines beliebigen BASIC-Befehls durch
 die Interruptroutine unterbrochen werden kann, ist schnell einsichtig, dass
 wenn eine Unterbrechung auftritt waehrend gerade Berechnungen mit dem Stack
 durchfuehrt werden, diese Berechnungen zu einem falschen Ergebnis fuehren
 koennen.

 Vermutlich liest man deshalb in den verschiedenen Informationsforen zum C-
 Control Minicomputer immer wieder von Fehlern, die in den BASIC-
 Befehlskombinationen ON..GOSUB und ON..GOTO enthalten sein sollen und
 bewirken, dass falsche oder gar keine Sprungverzweigungen ausgefuehrt
 werden. Diese beiden Befehle sind naemlich besonders anfaellig fuer diese
 Art Stackfehler.

 Ein moeglicher Workaround zur Vermeidung des Fehlers koennte sein, eine
 Assemblerroutine zu programmieren, die am Ende der BASIC-Interruptroutine
 aufgerufen wird und den Stack wieder in Ordnung bringt. Dazu muesste zu
 Beginn der Interruptroutine der Stackinhalt in einem freien Speicherbereich
 zwischengespeichert werden. Eleganter (aber mit mehr Denkarbeit verbunden)
 ist es, einfach nach jedem Zugriff auf den Stack innerhalb der
 Interruptroutine das letzte Word fehlerfrei vom Stack zu entfernt. Dazu
 muesste der Adressbereich von $93 bis $9e nach $91 bis $9c kopiert werden.
 Hierfuer sind aber genaue Kenntnisse des Programms und des Stackhandlings
 des Betriebssystems und des Compilers noetig.

 Das das letzte Verfahren wirklich funktioniert (ich bin selber erstaunt ;-)
 kann anhand der Programme ONGOSUB.BAS und ONGOSUB.ASM ueberprueft werden.


 Ŀ
                    Falsche Berechnung des Schaltjahres                    
 

 Der Code zur Ermittelung eines Schaltjahres hat einen Bug der bewirkt, dass
 der Mikrokontroller ab dem 28. Februar 2004 keine Schaltjahre mehr erkennt.
 Der verwendete (fehlerhafte) Algorithmus blieb vom Entwickler des
 Betriebssystems wahrscheinlich deshalb unbemerkt, weil das aus heutiger
 Sicht naechste Schaltjahr (das Jahr 2000) richtig erkannt wird.

 Am 29. Februar 2004 (und dannach alle vier Jahre) muss das interne Datum von
 Hand korrigiert werden; es sein denn, es ist ein DCF77-Empfaenger an der
 Unit angeschlossen.

       Wer ein neues Betriebssystem schreiben moechte kann die naechste,
           kuerzere Berechnungsroutine an passender Stelle verwenden:

          lda $90              ; Jahr laden
          and #3               ; ist das Jahr ohne Rest durch 4 teilbar?
          bne keinschaltjahr   ; falls nein, dann kein Schaltjahr
          lda #29              ; Anzahl der Tage des
          sta $e3              ; aktuellen Monats gleich 29 setzen
        keinschaltjahr:


 Ŀ
                  Der Wochentag wird von 0 bis 7 gezaehlt                  
 

 Ein weiterer Bug steckt im Weiterzaehlen des Wochentags: Es wird nicht wie
 erwartet von 0 bis 6, sondern von 0 bis 7 gezaehlt. Wobei sich die Frage
 stellt, ob die "richtige" Zaehlweise nun von 0 bis 6 oder von 1 bis 7
 lautet, denn das DCF77-Zeittelegramm zaehlt die Wochentage von 1 bis 7,
 wobei 1 gleich Montag und 7 gleich Sonntag ist.


 Ŀ
     Der Dump der Datendatei ueber die serielle Schnittstelle endet nie    
 

 Vielleicht liegt der Grund dafuer, das die Funktionen des Betriebssystems
 zur Ausgabe der aktuellen Inhalte des internen und des seriellen EEPROMs
 weder im dem der Unit beiliegenden Handbuch noch in der Onlinehilfe
 dokumentiert ist, daran dass eine der Funktionen einen Bug hat.

 Wenn ueber die serielle Schnittstelle ein Byte vom PC zum Mikrokontroller
 uebertragen wird, waehrend dieser in der "MAIN-LOOP" verharrt (das ist im
 ROM-Listing der Bereich von Adresse $969 bis $989), so wird dieses Byte als
 "Befehl" interpretiert. Ueber diese Befehle koennen unter anderem die
 Inhalte des interen EEPROMS ("Systembytes"), das BASIC-Programm und die
 Datendatei im seriellen EEPROM als Dump ueber die serielle Schnittstelle zum
 PC uebertragen werden.

 Leider ist die Betriebsystemroutine, die fuer die Ausgabe des Word-Dumps der
 Datendatei im seriellen EEPROM zustaendig ist, fehlerhaft: Es fehlt die
 Abbruchbedingung, so dass nicht nur die Datendatei sondern gleich der
 gesamte EEPROM-Inhalt uebertragen wird. Immerhin kommt man auf diese Art und
 Weise recht einfach zu einem Dump des gesamten EEPROMs. Der Kontroller muss
 nach der Uebertragung des gewuenschten Speicherbereichs resettet werden um
 die Uebertragung zu stoppen.

 Weitere Informationen zu den Befehlsbyte stehen uebrigens in der Textdatei
 BEFEHLE.TXT.


 Ŀ
                       Fehler in der Divisionsroutine                      
 

 Es gibt einen Fehler in der Divisionsroutine, der bewirkt, dass Divisionen
 nur dann fehlerfrei durchgefuehrt werden, wenn der Divident Werte im Bereich
 von -32767 bis 32767 und der Divisor Werte im Bereich von 0 bis 32767
 annimmt. Die Zahl -32768 ist fuer den Dividenten genauso tabu wie negative
 Zahlen fuer den Divisor.

 Falls der Divident trotzdem die Zahl -32768 annimmt, fuehrt das zu recht
 seltsamen, unbrauchbaren Ergebnissen. Falls der Divisor negativ wird, so ist
 das Divisionsergebnis immer null, da das Vorzeichen der Zahl ignoriert wird,
 und so der Divisor aus Sicht der Divisionsroutine im Bereich zwischen 32768
 und 65535 liegt.

 Ebenfalls betroffen von diesem Fehler ist die Modulofunktion und die Routine
 zur Ausgabe einer Zahl ueber die serielle Schnittstelle (z.B. PRINT zahl).
 Die Zahl -32768 wird als -P513 ueber die RS232-Schnittstelle ausgegeben.


 Ŀ
    Das DCF77-Signal wird zu Beginn jeder Stunde als fehlerhaft erkannt    
 

 Wenn ein DCF77-Empfaenger an die C-Control-Unit angeschlossen wird, wird
 waehrend der ersten Minute einer Stunde faelschlicherweise angezeigt, dass
 das DCF77-Signal falsch empfangen wird.

 Der Grund hierfuer ist der, dass das Betriebssystem immer zwei empfangene
 DCF77-Zeittelegramme vergleicht, bevor es die interne Uhr nach der
 empfangenen Zeit stellt. Damit das DCF77-Signal als gueltig erkannt wird,
 duerfen sich die beiden Zeittelegramme nur im Minutenwert voneinander
 unterscheiden. Am Anfang einer Stunde ist aber diese "Minuten-
 Inkrement-Bedingung" verletzt und deshalb wird das Signal irrtuemlicherweise
 als falsch angesehen.

 Aus diesem Grund kann es also (wenn ungluecklich gestartet wurde) bis zu
 vier Minuten dauern, bis die interne Zeit vom DCF77-Signal gestellt wird.


 Ŀ
                Das Lesen vom I2C-Bus ist etwas zeitkritisch               
 

 Die Betriebssystemroutine zum Lesen eines Bytes von einem am I2C-Bus
 angeschlossenen Slave ist etwas zeitkritisch und es kann deshalb
 (insbesondere dann, wenn der Slave nicht schnell genug reagiert und/oder die
 Taktrate der Unit durch einen anderen Quarz hoehergeschraubt wurde) zu
 Uebertragungsfehlern kommen.

 Laut Spezifikation im 24C65-Manual von Microchip benoetigt dieses EEPROM im
 "Fastmode" nach einem SCL-Impuls mindestens 1.3 s zum Anlegen eines neuen
 Bits. Die Zeit die der Kontroller dem EEPROM laesst (max. 1.5 s) ist also
 reichlich knapp bemessen. Besser waere es, wenn in der Betriebssystemroutine
 zum Lesen eines Bytes (ab Adresse $86f im ROM) vor jedem "ldx $00" ein "nop"
 stehen wuerde. In der Art wie die Routine jetzt aufgebaut ist koennten u.U.
 ein paar Highbits als Lowbits erkannt werden, denn zum jetzigen
 Lesezeitpunkt der SDA-Leitung liegt die Ausgangsspannung des EEPROMs nur bei
 knapp 70% von VDD, was der Mikrokontroller laut Motorola-Manual gerade so
 eben als Highzustand erkennt.

 Die ermittelten Zeit- und Spannungswerte am I2C-Bus basieren auf eigenen
 Messungen mittels einer Oszilloskopkarte und koennen nicht garantiert
 werden, da Erfahrungswerte von anderen Usern fehlen.


 Ŀ
              Das interne EEPROM wird zu langsam programmiert              
 

 Eigentlich ist das kein richtiger Bug: Wenn ein Programm, das sowohl BASIC-
 als auch Assemblercode enthaelt zum Mikrokontroller gesendet und von diesem
 in das serielle und das interne EEPROM programmiert werden, werden die
 "Systembytes" nur sehr langsam in das interne EEPROM geschrieben.

 Laut Manual zum MC68HC05B6 von Motorola muessen nach dem Loeschen und dem
 Beschreiben einer Adresse des internen EEPROMs 10 Millisekunden gewartet
 werden. Das Betriebssystem des C-Control/BASIC-Chips benutzt fuer diesen
 Zweck eine kleine Verzoegerungsschleife, die aber statt der benoetigten 10
 Millisekunden eine Verzoegerung von ganzen 69 Millisekunden produziert. Das
 Ergebnis ist, das der Anwender beim Uebertragen von laengeren
 Maschinenspracheprogramme relativ lang warten muss. Wer ein neues
 Betriebssystem und einen neuen C-Control/BASIC-Chip entwickeln moechte, kann
 die zu grosse Zeitverzoegerung korrigieren.

 Immerhin wird die zu grosse Verzoegerungszeit durch den Einbau eines
 hoehergetakteten Quarzes verkuerzt. Somit steht einer Erhoehung des Taktes
 von dieser Seite aus nichts entgegen.


 Ŀ
                     Falsche Technische Daten im Manual                    
 

 Auch wenn auf der Verpackung, in der meine C-Control/BASIC M-Unit steckte,
 steht, dass diese "so oft neu programmierbar [ist] wie sie wollen" haben
 sowohl das im Mikrokontroller eingebaute interne EEPROM als auch das am I2C-
 Bus angeschlossene 24C65-EEPROM nur eine begrenzte Lebensdauer. Sie halten
 nur eine begrenzte Anzahl von Programmierzkylen aus. Wenn also sehr haeufig
 Programme zur Unit gesendet und in die EEPROMs programmiert werden, gehen
 diese kaputt. Eigentlich muesste Conrad Electronic jedem Anwender, der ein
 kaputtes EEPROM hat, dieses kostenlos ersetzen, denn der Werbespruch ist
 eindeutig!

 In den Manuals, aber auch auf den Internetseiten von Conrad Electronic zur
 C-Control-Unit wird behauptet, dass diese mit 4 MHz Takt betrieben wird. Das
 stimmt nur zum Teil. Der am Oszillatoreingang angeschlossene Quarz schwingt
 in der Tat mit 4 MHz, doch dieser externe Takt wird intern halbiert, so dass
 absolut alles, was der Mikrokontroller an Programmen ausfuehrt nur mit 2 MHz
 getaktet wird.

 Im Schaltbild meiner M-Unit (auf Seite 3 der Bedienungsanleitung) sind
 einige Anschluesse vertauscht: Der BEEP-Ausgang liegt neben SDA und am Pin
 der mit BEEP beschriftet ist liegt der TEST-Ausgang. Die
 Anschluessbezeichnungen der A/D-Wandler sind vertauscht und die
 Porteingaenge, die unten links innerhalb des Chips mit "PC7..PC0"
 beschriftet sind muessen richtigerweise "PD7..PD0" heissen.


 Ŀ
                             Ausmerzen der Bugs                            
 

 Nicht in jedem Fall gibt es fuer einen Fehler einen Workaround, doch wenn
 mit Hilfe eines Mikrokontrollers der MC68HC05-Serie, der statt ROM einen
 EPROM-Bereich besitzt, ein "eigener" C-Control/BASIC-Chip entwickelt wird,
 koennen die Bugs des Betriebssystem ausgemerzt werden.

 Falls ein Leser dieses Textes Erfahrung im Umgang mit diesen EPROM-
 Mikrokontrollern hat und/oder sein eigenes Betriebssystem in einen solchen
 Kontroller gebrannt hat, soll er sich bitte bei mir melden. Ich selbst habe
 noch keinen Versuch in dieser Richtung unternommen.


 -----------------------------------------------------------------------------
 Diese Textdatei gehoert zur Informationssammlung von Dietmar Harlos zum
 C-Control/BASIC-Chip. Die Fehlerfreiheit der Angaben kann nicht garantiert
 werden. Die kommerzielle Nutzung irgendeiner Information oder eines
 Verfahrens dieser Sammlung ist ausdruecklich untersagt! Weitere Informationen
 zum Copyright entnehmen Sie bitte der Datei INFO.TXT.
 -----------------------------------------------------------------------------

