Noch ein paar Tips
Hallo @Y....,
auch, wenn es jetzt noch kein eins zu eins in Assembler übersetztes lauffähiges Proggi ist, hier noch ein paar Tips:
Also, ich würde vorschlagen, zunächst einmal die Adressen abzuklopfen.
Das Character-ROM sollte Dir dann alles Gespeicherte ausgeben mit dem
Programmdenkanstoß von angehängtem Proggi 4-Bit_0708.
(Da muß noch einiges auf angepaßt werden, bzw. das Label RS-Toggle muß rausgenommen werden, war sowieso nur ein Testlauf. Nehme an, es macht Dir keine sonderlichen Schwierigkeiten, die Sache anzupassen.)
Im Prinzip nichts anderes als eine Hochzählschleife, die dann den gesamten ASCII-Zeichensatz etc. abgibt.
Jetzt kannst Du überprüfen, ob alle Zeichen auch der richtigen Reihenfolge nach hintereinander dargestellt werden, oder ob irgendwo die Adresszuordnungen abbrechen und an anderer Stelle fortgeschrieben werden.
(Ist bei meinem 2x16-Display nämlich so, da die Adressen hier nicht konsekutiv dargestellt werden.)
Beim 4x40-organisierten Display sollte es eigentlich klappen, bzw. hier siehst Du dann, wo es hakelt. Dann ändere einfach die Adressen auf die richtigen ab. Hier kommt Dir noch zugute, daß Du zwar zweimal dieselben Adresszuordnungen hast, aber auch durch Möglichkeit von zwei Enableimpuls-Eingängen die jeweiligen Zeilen gezielt anzusteuern imstande bist. Sonst gäbe es ja nur Duplizierungen. Das scheint mir hierbei - glaube ich - das eigentlich nicht sonderlich schwierige aber dennoch problematische Ding bei Deinem Display zu sein.
Du siehst die "Bigfoot"-Zeichen als Zeichen insgesamt, es sind aber verschiedene einzeln zusammengesetzte, die nur dann einen Sinn ergeben, wenn sie tatsächlich genau positioniert worden sind. Auch sind normale Textbezeichnungen mit den "Bigfoot"-Zeichen kombiniert.
Wie dieses Adress-Schema aussieht, kannst Du dem Datenblatt vom DOG-M-Display (- mit freundlicher Genehmigung vorausgesetzt - abkopiert hier) entnehmen.
Dort sind dann auch die "frei" programmierbaren Adressen für selbsterstellte Characterpattern drin. Also, es sind - wenn ich es richtig gelesen habe nur ca. 7 zusätzliche Charakters möglich, denen weist Du dann einen "ASCII-Code" zu, also eine Character-RAM-Adresse, die mußt Du dann auch im Programm immer wieder verwenden.
Auch der Befehlssatz, wie man die Bigfoot-Zeichen reinbekommt ins Display, ist da irgendwo angegeben. Insgesamt sind dazu pro Charakter 8 Schreibvorgänge notwendig. Jedesmal enableimpulsgefolgt und so weiter. (Schönes Puzzlespiel!
Also, jetzt kommt für die Programmierung folgendes:
Nachdem Du nun einem "neuen" Charakter eine "freie" "ASCII-Code"-Adresse zugeordnet hast,
nehmen wir mal an Hex 01, (der ASCII-Code setzt sich ja aus Fernschreib-Steuercodes zusammen, die nicht alle "Buchstaben" und "Ziffern", bzw. "Satzzeichen" und "Sonderzeichen" enthalten, kann man bis Hex 13 - glaube ich - die Zeichenzuordnung ja anderweitig verwenden), kannst Du den neuen Charakter im Datenübernahmemodus einfach wie einen Textbuchstaben laden lassen, allerdings mit dem Hex- bzw. Binärcode diskret ausformuliert,
denn der Assembler wird jetzt im Assembliervorgang die in Anführungszeichen ' ' gesetzten für ihn "fremden" Buchstaben nicht ummodeln, da die Bigfoots keinem regulären Charakter im ROM zugeordnet sind -logisch.
Jetzt ist es für die korrekte Darstellung der "Bigfoots" aber unbedingt nötig, diese auch richtig zu positionieren. Dazu muß nun
vor jeden zu sendenden Charakter im Kommandomodus die jeweilige Display-RAM- Adresse angewählt werden. Für den Anfang also 80, für die Folgezeile (3) C0 und so weiter nach Adresscounter-Schema. (In der Tabelle steht zwar 00 und 40, aber, um den Adressbereich überhaupt anzuwählen, muß zwingend das entsprechende Steuerbit, hier Bit 7, auch gesetzt sein.) Und die richtigen Enables dann.
Dann der Charakter im Datenübernahmemodus. Der Cursor, der intern weiterwirkt, wird so einfach "übertölpelt". Man kann das prinzipiell immer so machen, nur spart man halt Programmieraufwand, wenn der Cursor im Incrementmodus automatisch immer eine Stelle weiterspringt, dazu ist der Cursor auch eigentlich gedacht. Stört hier aber gewaltig.
Auch wenn im Initialisierungs-String der Cursor abgewählt wurde, existiert nur die Auswahlmöglichkeit zwischen Increment- und Decrement-Modus, die dritte Möglichkeit,
also überhaupt keine interne Adressensteuerung, ist nicht vorgesehen. Das entsprechende Flip-Flop wird mal auf Vorwärts- bzw. Rückwärtszählen gesetzt, auf beide Flip-Flop-Ausgänge denselben logischen Pegel zu setzen, geht nicht. Da führt bislang kein Weg vorbei, dieser Adresscounter muß zwingend irgendwie gesetzt werden. Vielleicht wird das ja mal, als Anregung an die Hersteller gerichtet, in die Praxis umgesetzt.
Also, noch etwas, da Du auch "normale" Textbausteine verwendest, störte hierbei das Adresseninkrement des Adresscounters, sprich verkappter Cursor, eigentlich nicht.
Nur, hier wird gemixt. Dazu würde ich empfehlen, jedesmal die Display-Ram-Adresse im Kommandomodus vor jedem zu sendenden Charakter, sei er nun "Normaltext" oder "Bigfoot" einzeln extra zu setzen. So bist Du auf der sicheren Seite und es gibt kein Chaos auf dem Display wie jetzt, woll?
Wohlgemertkt, das ist auch nur ein Beispiel, das unter Umständen nicht eins zu eins direkt verwendet werden kann, jedoch in Analogie umgesetzt, auch bei Dir vom Prinzip her funktionieren müßte.
Nur, wird das Display abgeschaltet, gehen die RAM-Inhalte ja verloren und müssen jedesmal bei Start wieder vom Proggi neu übergeben werden.
Eine fixe Maskenprogrammierung findet also nicht statt.
Übrigens,
im Prinzip sind im oben angegebenen BASCOM-Code diese Überlegungen schon mit enthalten, es fehlen allerdings die hier einzusetzenden Adressendefinitionen und weiteren Modalitäten, die von Fall zu Fall doch ziemlich variieren können.
Viel Spaß noch, wünscht,
Oskar01
