Ein Nixieuhrprojekt mit 80C49 & 82C55 gefunden und benötige eine Korrekturlesung.

Wirf es einfach wieder in den Müll.

Wenn du 8x51-affin bist, nimm einen 2051, und ein paar 74HC595. Eine Uhr in C/Pascal/Assembler selbst zu schreiben, ist ja keine Raketenwissenschaft.

Zur Steigerung der Schwierigkeit, wäre auch ein ST-6 Derivat gut geeignet und bereits langjährig abgehangen.

Mediafox F. schrieb:

Leider laufen meine uralten MCS-48-Softwaresammlungen nicht mehr auf Windows10

https://www.dosbox.com/

Mediafox F. schrieb:

Schaltbild war nicht mehr verfügbar

Was bindet Dich dann noch an die Teile aus dem Museum?

Nimm wenigstens eine aktuellen µC: https://github.com/mrnebbi/nixie-tube-clock

Mediafox F. schrieb:

und vielleicht Fehler findet.

Die bei INC und DEC veränderte Uhrzeit wird nur zurückgeschrieben bei Überlauf, so wie ich das sehe. Man sollte die jump-target vor das Zurückschreiben setzen.

Die Sekunden werden definiert aber nicht genutzt, könnte man streichen.

Die Tastenentprellung und -Wiederholtrate basiert auf der Langsamkeit der I2C Implementation und eben ob die veränderte Uhrzeit überhaupt zurückgeschrieben wird.

So ein 8255 hat eine erbärmlich geringe Treiberleistung, offiziell treibt der 8255 nur 2.5mA low und der 74141 zieht 3.2mA.

Mediafox F. schrieb:

fragen ob ihr mal über das Listing und der HEX-File drüberschauen könnt und vielleicht Fehler findet >

Der Assemblerquelltext ist mit großer Wahrscheinlichkeit für den 8051 oä geschrieben, nicht für den 8048, denn er enthält ua einen bedingten Sprungbefehl - cjne - den der 8048 nicht kennt. Auch Portpin-Befehle kennt der 8048 nicht.

mfg

Die MCS-48 würde ich auch nicht ohne Not vom Friedhof holen. Matt Millman hat sich das angetan: https://www.mattmillman.com/projects/an-intel-mcs-48-based-dual-temperature-sensor/

Die Hardware ist nach heutigen Massstäben schon sehr speziell und die SW nicht besser. Zitat von der Webseite: „As I worked my way through the implementation, I kept telling myself it would get easier. It didn’t.“

Das ist ganz sicher kein 80c49 Assembler Quelltext sondern 80c51. Das spielt aber keine Rolle da sowieso nicht lauffähig.

Das Hauptprogramm wird mit ORG 0 gestartet, was zur Folge hat dass die I2C Routinen überschrieben werden. Ich habe selten so einen Murks gesehen. Ohne das jetzt genauer untersucht zu haben, schaut auch der Hex Code zumindest seltsam aus.

Thomas Z. schrieb:

Das ist ganz sicher kein 80c49 Assembler Quelltext sondern 80c51.

Dann könnte man ja den AT89LP51RD2-20PU nehmen. Der hat einen UART-Bootloader, d.h. man braucht kein extra Programmiergerät dafür. Nur einen USB To RS232 TTL Converter Adapter.

https://www.amazon.de/BerryBase-USB-Adapterkabel-PL2303HX-Chipsatz-Schwarz-Rot-Gr%C3%BCn-Wei%C3%9F/dp/B09KYJZJYP?

https://www.digikey.de/de/products/detail/microchip-technology/AT89LP51RD2-20PU/3046512

Das ist kein Programm, sondern nur mal eben etwas, wo jemand schnell mal was ausprobieren wollte, zuzüglich später hinein kopierten Code, der (in eine alte Datei) schnell mal irgendwohin musste, als dieser Jemand sich anderem zuwandte.

Soweit ich mich erinnere, fing in meiner Jugend ein MCS51-Assemblerprogramm grundsätzlich mit einem "ljmp main" an, gefolgt von der mit "reti" aufgefüllten Tabelle mit den Interruptvektoren. Das vermisse ich hier.

Jch kann mich rudimentär erinnern, dass man bei MCS51 die Wahl zwischen Stackgröße und Registerbänken für einen schnelleren Kontexwechsel bei Interrupts hatte. Auch gab es so was wie direkt und nur indirekt adressierbares SRAM, das man in späteren Versionen für den Stack nutzen konnte. Lange Rede, kurzer Sinn: in einem "richtigen" Programm würde wohl irgendwo der / die Stackpointer initialisiert werden.

Bei meinen I2C-Versionen waren viele NOPs nötig, um den Datentransfer auf eine geeignete Geschwindigkeit zu reduzieren. Es geht aber, bei reduzierter Oszillatorfrequenz, wahrscheinlich auch ohne NOPs. Da es "8255" heißt, und nicht "82C55", tippe ich mal auf NMOS-Versionen von beidem. (Minimale Oszillatorfrequenz 2 MHz?) Vielleicht in einer Schaltung aus dem ganz frühen Elektor-Universum?

MOV A, #PCF8563_ADDR CALL I2C_WRITE_BYTE

Das kommt mir suspekt vor. Bei mir wäre ein 8255 im Adressraum eingebunden gewesen und mit movx angesprochen worden.

Michael schrieb:

MOV A, #PCF8563_ADDR CALL I2C_WRITE_BYTE

Das kommt mir suspekt vor. Bei mir wäre ein 8255 im Adressraum eingebunden gewesen und mit movx angesprochen worden.

Bitte streichen. Der I2C-I/O geht ja gar nicht über den 8255, sondern direkt über die Port-Pins. Denkfehler von mir.

Michael schrieb im Beitrag #7898144: ...

Jch kann mich rudimentär erinnern, dass man bei MCS51 die Wahl zwischen Stackgröße und Registerbänken für einen schnelleren Kontexwechsel bei Interrupts hatte. Auch gab es so was wie direkt und nur indirekt adressierbares SRAM, das man in späteren Versionen für den Stack nutzen konnte. Lange Rede, kurzer Sinn: in einem "richtigen" Programm würde wohl irgendwo der / die Stackpointer initialisiert werden.

...

Der 8048 hatte einen 8-Level Semi-Hardware-Stack: Ein 3-Bit SP der Teil des PSW (Status-Registers) ist und fix auf RAM-Adressen 08-23 zeigt, mit dem einzigen Unterschied zum klassischen PIC, dass man ihn theoretisch durch Neuladen des PSW überschreiben kann.

Hier das Manual zum MCS-48 https://bitsavers.trailing-edge.com/components/intel/8048/9800270D_MCS-48_Family_Users_Manual_Jul78.pdf