Hallo! Ich habe mit Wayback ein Projekt gefunden, es soll eine Uhr mit Nixieröhren sein. Diese soll aus einem 80C49 und 82C55 bestehen, sowie die Nixietreiber 4x 74141. Die 74141 könnte ich auch mit 4028 und einigen HV-Transistoren ersetzen, dies ist das kleinere Problem. Da die Page mit dem Uraltforum nun nicht mehr finde und auch nicht dessen Urheber kenne, wollte ich hier in der Runde mal fragen ob ihr mal über das Listing und der HEX-File drüberschauen könnt und vielleicht Fehler findet. Die Datein konnte ich noch retten, Schaltbild war nicht mehr verfügbar, sollte sich aber aus dem Listing herauslesen lassen. Warum ich das bauen möchte? Ich hab die Teile grad rumliegen und möchte diese verwenden. Sogar das 2732er-EPROM habe ich noch zum Brennen. Leider laufen meine uralten MCS-48-Softwaresammlungen nicht mehr auf Windows10 um dieses selbst prüfen zu können. Danke für eure Hilfe im Vorhinein.
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.