FAQ zu "C-Control intern"

Überflieg' bitte erst kurz meine Frequently Asked Questions, bevor Du mir eine e-mail schickst. Hier sind einige Fragen aufgeführt, die mir andere Anwender bereits gestellt haben. Ein Blick in diese Liste kann Dir unter Umständen viel Wartezeit ersparen, denn es kann durchaus zwei Wochen dauern, bis Du eine Antwort von mir erhälst!

Die folgenden Fragen werden hier beantwortet:

Ist Deine Frage nicht dabei? Dann schreib mir eine e-mail und hoffe, daß ich mich relativ schnell bei Dir melde. Achte aber bitte darauf, daß der Freemail-Provider "web.de" nicht in Deiner Ignore-Liste oder im Spam-Filter steht. Sonst wartest Du vergeblich auf meine mail und ich tippe mir umsonst die Finger wund! Wenn ich nach zwei Wochen noch nichts von mir hören lasse, darfst Du einmal höflich nachfragen...


Auf welchen Internetservern ist die "C-Control intern"-Sammlung zur Zeit zu finden?
http://www.geocities.com/ccontrolintern
http://computer.freepage.de/ccontrolintern
http://members.xoom.com/ccintern

Is your information collection about the C-Control microcontroller available in english language?
No, it isn't. I have really not the time to translate it, but if you want to translate the collection: Please do!

Ich würde gern in Assembler programmieren. Kannst Du mir ein paar Tips geben?
Meiner Informationssammlung liegt ein kurzer Assemblerkurs bei, der einen kleinen Einblick in die Programmierung bietet. Es wäre nett, wenn Du mir schreiben würdest, wie Du den Crash-Kurs findest und an welchen Stellen eventuell Probleme auftauchen. Sehr gut fuer Einsteiger geeignet ist auch die Assemblerbeschreibung von Mario Boller-Olfert.

Gibt es noch einen anderen Assembler als den AS05?
Der von mir verwendete Assembler AS05 unterstützt einige Instruktionen, die nicht zum von Motorola veröffentlichten Befehlssatz einer 6805-CPU gehören. Allerdings ist er "abwärtskompatibel" und unterstützt auch die Standard-Mnemonic anderer Assembler. Dieses Feature und der Umstand, daß er kostenlos benutzt und weitergegeben werden darf, waren der Grund dafür, daß ich ihn meiner Sammlung beigelegt und seinen Befehlssatz in jedem Assemblerprogramm benutzt habe. Außerdem läßt er sich hervorragend in die DOS-IDE einbinden. Ein Anwender, der unter Windows arbeitet,  hat mir geschrieben, dass er statt dem AS05 lieber den Telemark Assembler (TASM) von Thomas N. Anderson benutzt. Der TASM kann wohl in Ultraedit eingebunden werden, wie wohl auch das gesamte andere CC-Basic-Umfeld. Allerdings handelt es sich um einen Shareware-Assembler.

Wie programmiere ich eine Interruptroutine?
Informationen, wie eine Interrupt-Routine in das System eingebunden werden kann, steht in meiner Infosammlung in den Dateien TIPSUTRI.TXT und INTERRUPT.TXT. Du kannst mir aber auch gerne eine e-mail schicken, wenn Du nicht damit
klarkommst.

Wie programmiere ich den I2C-Bus?
In der Infosammlung gibt es eine Datei namens I2C.TXT, in der erklärt wird, was ein I2C-Bus ist und wie man den Geräten am Bus eine Lese- und Schreibkennung zuweist. In der Datei HIGHENDU.ASM stehen die Subroutinen "prolog" und "epilog", außerdem werden dort die Betriebssystemroutinen I2C_Read, I2C_ReadLast, I2C_Start, I2C_Write und I2C_Stop verwendet.
Bevor man ein anderes "Gerät" als das 24C65-EEPROM ansprechen kann muß man das EEPROM zuerst vom Bus abmelden (mit I2C_ReadLast) und anschliessend die Lese- oder Schreibkennung des neuen Gerätes übermitteln (mit I2C_Start). Was danach übertragen werden muß, ist je nachdem, was man ansprechen will, unterschiedlich: Bei einem RAM-Speicher wird die anzusprechende Adresse in einem Byte übertragen (mit I2C_Write); bei einem EEPROM ist diese Adresse zwei Byte lang. Bei Speicherbausteinen werden danach die eigentlichen Daten übertragen (mit I2C_Read oder I2C_Write). Bei einem Portexpander wie dem PCF 8574 werden diese Daten direkt nach der Kennung übertragen (keine Adresse nötig). Nach dem Lesen muß die Betriebssystemroutine I2C_ReadLast aufgerufen werden, um das Gerät wieder vom Bus zu trennen. Beim Schreiben übernimmt die Routine I2C_Stop diese Aufgabe. Zum Schluß darf man nicht vergessen, das 24C65-EEPROM wieder anzumelden (siehe "epilog"), da die C-Control-Unit sonst nicht mit der Ausführung des BASIC-Programms fortführen kann.
Wem das alles zu trocken war, der kann auf der C-Control-Help-Site von Thomas Trepper vorbeischauen. Ich glaube, dort gibt es die beste Sammlung an Datenblättern, Programmen, etc. zum I2C-Bus.

Kann man ein größeres serielles EEPROM an die C-Control anschließen?
Man kann statt dem 24C65 (8 Kilobyte Speicher), den 24C256 von ATMEL einsetzen. Dieser bietet 32 KB Speicherplatz. Angeblich kann der Chip für 10,- DM pro Stück plus 4,- DM Versandkosten bestellt werden, indem eine mail an Schmidt@Moba.de geschickt wird. Zusätzliche Informationen zu diesem Thema gibt es auch unter http://home.t-online.de/home/B.Kainka.
Das Betriebssystem schert sich beim Speichern in die Datendatei (mit den "OPEN# FOR ..."- und "PRINT#"-Befehlen) übrigens nicht um die Groesse des EEPROMs. Falls ueber die gueltige Bereichsgrenze des EEPROMs hinaus in dieses geschrieben (oder aus diesem gelesen wird) laeuft einfach der interne Adresszaehler im EEPROM ueber und es wird der Beginn des EEPROMs ueberschrieben. Nur der FILEFREE-Befehl benutzt zur Berechnung des freien Speichers des EEPROMs eine feste Groesse.

Ich habe ein größeres EEPROM, kann aber keine BASIC-Programme größer als 8 Kilobyte kompilieren!
Wenn Du ein BASIC-Programm mit mehr als 8 Kilobyte Größe von der C-Control ausführen lassen möchtest brauchst Du einen BASIC-Compiler, der die 8-KB-Größenbeschränkung nicht kennt. Für die Windows-IDE gibt es dafür eine neue "CCBAS32.DLL"-Datei. Diese kann auf der Homepage von C. Edelmann heruntergeladen werden. Für die DOS-IDE habe ich den Original-CCBAS.EXE-Compiler etwas gepatcht. Diese Datei (CCBASBIG.EXE) kann als ZIP-Archiv auf meiner Internetside heruntergeladen werden.

Wieso 8 KB? Ich kann nur BASIC-Programme bis etwa 6400 Byte kompilieren!?
Dieses Problem tritt nur auf, wenn die Windows-Entwicklungsumgebung zur Programmentwicklung benutzt wird. Der Windows-Compiler fuegt offenbar in jedes BASIC-Programm zusaetzlichen Code ein, damit dieses vom Simulator geladen und ausgefuehrt werden kann. Dadurch können nicht die vollen 8 Kilobyte des seriellen EEPROMs ausgenutzt werden. Mit der DOS-IDE (kann auf dem Conrad-Server heruntergeladen werden), tritt dieses Problem nicht mehr auf und es können Programme bis 8100 Byte Größe kompiliert werden. Die DOS-IDE (CCE.EXE) kannst Du uebrigens auch unter Windows in einem DOS-Fenster sehr gut benutzen (50 Zeilen-Modus bei einer Schriftgröße von 7 x 12 und einer Screenauflösung von 1024x768 Bildpunkten oder 43 Zeilen bei 800x600 Punkten), nur das beiliegende Terminalprogramm MINITERM.EXE macht bei mir Probleme; doch dafuer kannst Du TERMINAL.EXE einsetzen. Das Programm befindet sich in meiner Sammlung.

Was ist der High-Endurance-Block?
Jede Speicherstelle im seriellen 24C65-EEPROM, das im C-Control-Minicomputer Verwendung findet, kann 100.000 bis 1.000.000 mal neu programmiert werden, danach ist die Speicherstelle hinüber. Es gibt aber einen verschiebbaren, 4096 Bit grossen Bereich, der bis zu 10.000.000 mal neu programmiert werden kann. Dieser Bereich heisst High-Endurance-Block und liegt von Werk aus (angeblich) am Ende des Speicherraums des EEPROMs. In meiner Sammlung findest Du ein BASIC- und ein Assemblerprogramm, mit denen der High-Endurance-Block verschoben werden kann.
Leider habe ich auf meiner M-UNIT kein 24C65-EEPROM, sondern ein 24C64. Dieses EEPROM hat keinen High-Endurance-Block, so daß ich die Programme leider noch nicht richtig testen konnte. Falls sie bei Dir laufen (oder auch nicht) gib' mir bitte Bescheid! Genauere Infos zum EEPROM und wie man den High-Endurance-Block verschiebt, findest Du übrigens im 24C65-Manual von der Firma Microchip.

Wieviele Speicherzyklen sind denn nun beim EEPROM möglich? 10.000, 100.000 oder 1.000.000?
Die C-Control besitzt zwei verschiedene EEPROMs. Das eine, was ueblicherweise gemeint ist, ist das serielle EEPROM mit der Bezeichnung 24C65. Dieses "haengt" am I2C-Bus der Unit. Jede Speicherstelle in diesem EEPROM kann man 100.000 oder 1 Millionen mal neu beschreiben - mehr garantiert zumindest der Hersteller nicht. Welcher der beiden Werte richtig ist, kann ich leider nicht sagen, die Daten im Manual zum EEPROM von Microchip sind widerspruechlich. Ich vermute aber, daß 1 Millionen mal neu programmiert werden kann. Zusätzlich besitzt das 24C65 den weiter oben angesprochenen High-Endurance-Block.
Ausserdem besitzt die Unit - so wie jeder MC68HC05B6-Mikrokontroller - ein internes EEPROM. Dieses liegt im Speicher von Adresse $100 bis $1ff, und dient normalerweise dazu, Assemblerprogramme aufzunehmen. Dieses EEPROM hat (laut
Motorola) eine Lebensdauer von nur 10.000 Loesch- und Schreibzyklen.

Laut "C-Control Anwendungen" ist die Ungültigkeit des DCF77-Signals am Beginn jeder Stunde gewollt!?
Im Buch "C-Control-Anwendungen" (erschienen im Franzis-Verlag, Mitautor: Martin Förster) wird beschrieben, daß es durchaus erwünscht ist, daß das DCF77-Signal in der ersten Minute jeder Stunde von der C-Control als "ungültig" angesehen wird.
Meine Meinung dazu ist folgende:
Der Herr Förster schreibt zwar, dass dieses "Feature" erwünscht ist, doch scheint mir diese Behauptung eher vorgeschoben zu sein. Hätte man die Paritätsbits des DCF77-Signals mitausgewertet und anhand dieser detektiert, ob das Signal gültig ist, würde sich auch das Problem mit der Sonntags-Anzeige in der ersten Minute nach Mitternacht an jedem Montag von selbst lösen. Außerdem hätte man einige Bytes mehr freien Arbeitsspeicher!

Ich habe meine Unit übertaktet und jetzt läuft alles zu schnell!?
Es gibt auf der C-Control-Help-Site unter der etwas falschen Bezeichnung "TURBOASM" ein kleines Programm, das sich in einen Interrupt hängt und die zeitabhängigen Funktionen des Betriebssystems korrigiert, wenn die Unit mit 12 MHz betrieben wird. Dazu gehört auch ein Downloader für die DOS-IDE, der auf die 3-fache Baudrate eingestellt ist. Wenn man die Funktion des Programms durchschaut, müssten auch andere Taktraten korrigiert werden können.

Das Wochentagsregister (DOW) zeigt falsche Werte an.
Es gibt mehrere Fehler im Betriebssytem der C-Control, die im Zusammenhang mit dem Wochentagsregister stehen. Einfache Abhilfe: Wenn der DOW in einem BASIC-Programm benötigt wird, folgende Zeile vor jeder Abfrage des Wochentags einfügen: IF DOW > 6 THEN DOW = 0

Gibt es die verschiedenen "Manuals" zum Mikrokontroller, EEPROM, u. ä. auch in Deutsch?
Leider nein. Aber zum Glück sind diese meist in "Easy English" geschrieben, so daß es eigentlich kein Problem sein sollte, zumindest die wichtigsten Dinge zu verstehen. Es gibt ein Freeware-Tool namens Babylon Translator, mit dem sämtliche englischen Texte, die auf dem Bildschirm erscheinen, mittels eines einfachen Klicks mit der Maus ins Deutsche übersetzt werden können. Das funktioniert nach einem ähnlichen Prinzip wie OCR. Damit der Translator gut mit dem Acrobat Reader zusammenarbeiten kann muß beim Reader allerdings die Funktion "Text und Bilder glätten" ausgeschaltet sein.

Kennst Du weitere Software-Tools, die bei der Assembler-Programmerstellung nützlich sein könnten? Gibt es einen besseren Simulator als den ZAP?
Meine Linkliste zum MC68HC05 (in der Datei INTERNET.TXT) stammt vom November 1999. Seitdem habe ich mich nicht mehr nach Software zum Mikrokontroller umgesehen. Damals habe ich so ziemlich alles heruntergezogen, was es nur irgendwie an Software für den 6805 gab. Trotzdem habe ich nur einen Simulator gefunden. Die "Introl-COntroller Development Environment" enthält zwar Simulatoren für diverse CPUs - aber ein Simulator für die 6805 fehlt leider. Vielleicht wurde diese Environment in der Zwischenzeit weiterentwickelt, oder es gibt einen Simulator, von dem ich keine Ahnung habe?
Für den, der viel in Assembler programmiert und vielleicht sogar einen 68HC05 mit eigenem Betriebssystem entwickeln möchte, lohnt sich vielleicht die Anschaffung eines "In-Circuit Emulator". Den kann man bei der Firma Motorola bestellen. Der In-Circuit-Emulator ist - soweit ich weiß - ein richtiger Minicomputer, der mit dem PC über die serielle Schnittstelle verbunden wird und so die Simulation von Assembler- und C-Programmen in Echtzeit (mit echten Portzugriffen) unterstützt. Mit diesem Emulator kann man sogar 6805-Chips, die statt ROM einen EPROM-Bereich haben, programmieren.

Gibt es schon Erfahrungen zum Erstellen eines neuen Betriebssystems mittels EPROM-68HC05-Kontroller?
Ich habe bisher noch keinen Versuch unternommen, ein eigenes Betriebssystem zu entwerfen. Vor einigen Wochen habe ich aber eine mail von einem Anwender bekommen, der sich einen In-Circuit Emulator von Motorola zugelegt hat. Mit diesem Emulator kann man die Chips auch programmieren. Der Anwender will mit einem MC68HC705B16 eine "eigene" C-Control-Version entwerfen. Leider weiss ich nicht, wie weit er schon ist. Der MC68HC705B16 ist - soweit ich weiss - nicht voll kompatibel zum MC68HC05B6! Er hat mehr RAM und einige Adressen sind vertauscht. Genaueres kannst Du aber im 6805-Manual von Motorola nachlesen.

Wo gibt es die fehlenden Dateien des C-Control-Betriebssystem-Quellcodes?
So direkt kann ich da leider nicht weiterhelfen, da ich keinen passenden C-Compiler besitze. Aber übernimm doch einfach Teile meines ROM-Listing im Assemblerformat. Diese müßten dem Original-Quellcode relativ problemlos hinzugefügt werden können. Falls es klappt bitte unbedingt als ZIP-Archiv zu mir oder zu einer anderen C-Control-Site schicken!

Ich habe Probleme beim Anschluß der Hardware XYZ an meine C-Control. Kannst Du mir helfen?
Normalerweise helfe ich natürlich gern, doch bitte beachte, daß ich selbst nur eine einfache M-Unit ohne jegliche "Extra-Hardware" wie Tastatur, LC-Display oder ähnlichem besitze. Außerdem enthält meine "C-Control intern"-Sammlung in erster Linie Information zur Software der C-Control; also zum Betriebssystem, zur Assemblerprogrammierung und zu Tricks & Tips bei der Programmerstellung. Für Hardware-Fragen bin ich daher nicht der richtige Ansprechpartner. Da wendest Du Dich am besten an die C-Control-Help-Site von Thomas Trepper.

Hilfe! Ich habe die Quellcodes meiner Programme verloren. Gibt es eine Möglichkeit, die Programme, die sich augenblicklich in der C-Control befinden, zum PC zurückzuübertragen?
Es gibt spezielle Befehle, die über die RS232-Schnittstelle gesendet werden können und die die C-Control veranlassen, die aktuellen Inhalte des internen und des externen EEPROMs zum PC zu übertragen. Freue Dich aber nicht zu früh: Der C-Control-Compiler kompiliert ein BASIC-Programm in sogenannte Token, die nachdem sie zur Unit übertragen wurden, von dieser ausgeführt werden. Es ist zwar möglich, diese Token wieder zum PC zurückzuübertragen, doch sind diese Token nichts weiter als Zahlen (ich bin darauf in meiner C-Control-Sammlung in der Datei CCBASTOK.TXT eingegangen), also kein lesbarer Text. Zwar kannst Du hingehen und jede einzelne Zahl wieder in einen lesbaren CCBASIC-Befehl übersetzen, doch wird das bei einem längeren Programm ganz schön lange dauern. Vielleicht kannst Du Dir ja einen "Rück-compiler" selber schreiben? Das wäre eine gute Sache, ich selbst bin leider noch nicht dazu gekommen.
Bei einem Assemblerprogramm sieht die Sache übrigens etwas besser aus: Zur "Rück-Compilierung" eines Maschinenspracheprogramms stehen Disassembler zur Verfügung. Ich empfehle den IDI05 - liegt meiner Sammlung bei.
Wie Du die CCBASIC-Token, die im seriellen EEPROM stehen, und das Maschinenspracheprogramm aus dem internen EEPROM wieder zum PC übertragen kannst steht in meiner Sammlung (siehe BEFEHLE.TXT). Dazu sendest Du einen bestimmten Code (eine Zahl) zur Unit, wenn diese im IDLE-Loop ist. Das machst Du am Besten mit dem Programm TERMINAL.EXE. Es protokolliert alles mit, was Du sendest und was die Unit daraufhin zum PC überträgt. Lies dazu einfach das Manual TERMINAL.MAN.

Wie kann ich in BASIC am einfachsten detektieren, ob ein gültiges DCF77-Signal empfangen wird?
Mit dem untenstehenden Programm kann das C-Control-Statusregister abgefragt werden. Das Register liegt an Adresse $7b und enthält zwei Bits, die zu diesem Zweck von Interesse sind: Bit 0 gibt an, ob in diesem Moment ein gültiges Zeitsignal empfangen wird und Bit 4 ist gesetzt, wenn die C-Control-Systemzeit wenigstens einmal vom DCF77-Signal oder über die RS232-Schnittstelle gestellt wurde. Wenn nur Bit 4 gesetzt ist, kann davon ausgegangen werden, daß die Systemzeit die richtige Ortszeit enthält (wenn auch eventuell mit einigen Sekunden Abweichung).
Durch eine kleine Änderung im Programm kann übrigens jedes beliebige Byte im RAM ab Adresse 1 abgefragt werden. Dazu muß man nur den Wert in der Tabelle "ccstatustab" umändern: 11*256+Adresse-1. So könnte man also für jede Adresse, die man auslesen möchte, eine eigene BASIC-Subroutine erstellen.
  
if (ccstatus and 1) then print "Es wird ein gueltiges DCF77-Signal empfangen."
if (ccstatus and 16) then print "Die Systemzeit wurde mindestens einmal gestellt."
if (ccstatus and 32) then print "Der Slowmodus ist aktiv."
end

#ccstatus
  table ccstatustab
    2938 '11*256+$7b-1
  tabend
return

Gibt es irgendwo unbenutzten Speicher im RAM?
Jawohl, so weit wie ich bisher die "Innereien" der C-Control untersucht habe gibt es folgende Möglichkeiten, etwas mehr RAM-Speicher als die 24 User-Bytes herauszukitzeln: Es gibt ein Byte an der Adresse $dc, dieses wird anscheinend von keiner Betriebssystemroutine verwendet. In Assemblerprogrammen können einige unbenutzte Bits des Statusregisters (an Adresse $7b) und die diversen temporären Bereiche (siehe ADRESSEN.TXT) eingesetzt werden. Bei letzterem muß dann allerdings vor dem Aufruf einer Betriebssystemroutine überprüft werden, ob die Routine den temporären Bereich nicht ebenfalls benutzt. Das kann am schnellsten im ROM-Listing kontrolliert werden (siehe "used"-Sektion im Header jeder Betriebssystemroutine). Wer kein Maschinenspracheprogramm mit vielen Unterprogrammaufrufen benutzt, kann ein Stück des Hardwarestacks (ab Adresse $e5 aufwärts) zur Datenspeicherung nutzen. Das RAND-Word auf Adresse $9f kann mißbraucht werden, wenn keine Zufallszahlen benötigt werden. Wenn der TCAP1-Pin auf ein festes Potential gelegt wird (an dem Pin hängt sonst ein DCF77-Empfänger), können sämtliche DCF77-Buffer benutzt werden. Es ist außerdem denkbar, einige Interrupts des Betriebssystems einfach auszuschalten (siehe Manual zum 68HC05-Mikrokontroller und ROM-Listing) oder durch eigene Assembler-Interruptroutinen zu ersetzen. Dadurch würde ein großer Teil des RAMs frei. Zum Beispiel könnte man den SCI ausschalten und so den RS232-Buffer für eigene Zwecke mißbrauchen. Der Empfang über die serielle Schnittstelle ist dann theoretisch immer noch möglich - allerdings ungebuffert. Hardcore-User schalten den TIMERCMP- Interrupt aus, oder ersetzen die entsprechenden Betriebssysteminterruptroutinen, und haben so ein wirklich großes Stück des RAMs zur freien Verfügung - siehe ADRESSEN.TXT.

Gibt es andere Mikrokontroller mit mehr RAM, mehr Ports, mehr Interrupts, Multitasking, Grafik, usw.?
Wie waere es denn, wenn Du fuer umfangreichere Projekte einen PC einsetzt? So ein alter 386'er mit 40 MHz kann problemlos ohne Tastatur, Monitor, Grafikkarte, Festplatte, CD-LW, Gehaeuse und aehnlichem betrieben werden. Das Motherboard mit Speicher gibt's gebraucht fast fuer umsonst. Man braucht  nur noch ein Netzteil, eine I/O-Karte und ein Diskettenlaufwerk; eventuell kann das Laufwerk sogar durch eine EEPROM-Disk oder eine Netzwerkkarte ersetzt werden. Der Vorteil ist der, dass dann Programme ganz problemlos unter DOS entwickelt werden koennten - egal, ob in BASIC, C, Pascal oder sonst einer Sprache. Das Freeware-Angebot ist riesig - selbst das Betriebssystem (z.B. OpenDOS, FreeDOS) gibt's für umsonst. Ausserdem koennen selbstentwickelte Karten in den ISA-Bus gesteckt werden.

Willst Du Deiner Sammlung einige von mir geschriebene Infotexte hinzufügen?
Klar. Immer her damit! Natürlich werde ich Dich als Autor nennen.

Ich habe eigene Software zur C-Control entwickelt.  Möchtest Du sie Deiner Sammlung hinzufügen?
Wenn es sich um BASIC- oder Assemblerprogramme für die C-Control handelt, dann sollten diese möglichst übersichtlich, überschaubar und gut dokumentiert sein, so daß auch Newbies etwas damit anfangen können, denn schließlich hat meine Infosammlung den Charakter eines Lehrbuches. Hilfsprogramme für die C-Control, die auf dem PC laufen (z.B. eigener Kompiler, Maschinensprache-Simulator, BASIC-Detokensierer, o.ä.), sollten möglichst in einer Sprache verfaßt sein, in der die Executables nicht zu groß sind, oder Du schickst mir den Quellcode des Programms zu. Ansonsten würde das ZIP-Archiv mit der Sammlung nämlich unerträglich groß!

Dürfen die Informationen und Programme in Deiner Sammlung kostenlos genutzt werden?
Jeder Nutzer der Sammlung sollte sich an der Weiterentwicklung beteidigen. Das kann beispielweise durch Verfassen eigener
Beiträge für diese Informationssammlung geschehen. Es ist aber auch möglich, den Autor durch Zusenden eines kleinen Geldbetrags zu unterstützen.Von dieser Regelung ausgenommen sind die beiden Disassembler DI05.EXE und IDI05.EXE, sowie der Assembler AS05.EXE. Weitere Information hierzu befindet sich in der Textdatei REGISTER.TXT.

Was gibt es Neues von der C-Control-2?
Ich bin leider kein "Insider" in Sachen CC-2. Ich kenne auch nur die Informationen und Termine, die im CC-2-Forum der C-Control-Help-Site bekanntgegeben werden.

Wen kann ich noch fragen?
Wenn Du ein Problem hast, bei dem Du nicht weiter weißt und das so schnell wie möglich behoben werden muß, dann stelle doch eine Anfrage in das CC-1-Forum. Es ist zur Zeit das am besten besuchte Forum zur C-Control. Aber beachte, daß Du Dein Problem ausreichend genau beschreiben mußt! Mitunter helfen auch alte Forums-Postings weiter. Diese können auf  der C-Control-Help-Site als ZIP-Archiv heruntergeladen werden.
 

Alles gelesen und immer noch Fragen? Dann schreib mir eine e-mail und hoffe, daß ich mich relativ schnell bei Dir melde!