EDA-Dateien bearbeiten

rename <filename>.eda <filename>.z80

Oder was war die Frage?

Oliver

Von Z80 finde ich nichts

1. .eda ist ein Diskimage von Ensoniq/E-MU "Kopie einer Festplatte für das Ensoniq Advanced Sampling Recorder (ASR) digitales Musikproduktionsstudio formatiert"

2. EDA wird für eine Leiterplattensoftware EasyEDA benutzt "Electronic design automation"

aber Oliver hat recht, umbenennen dürfte das einfachste sein.

AssenblerListings sind gerne nicht nur Prozessor- sondern auch Assemblerabhängig insbesonders bezüglich der Assemblerdirektiven wie bspw. .org .def oder .equ . Oder macro-definition, man vgl. bspw. TASM und MASM (nicht Z80, https://de.wikipedia.org/wiki/Turbo_Assembler#MASM-Modus)

Grad historisch gibt es da viel mehr als GNU. https://ftp.gnu.org/old-gnu/Man

Es scheint sich um ein Assemblerlisting im 8080-Code zu handeln. Wie kann > ich das in ein Z80-Listing

Zilog Z80 verwendet trotz Binärkompabilität zum intel 8080 andere mnemonics.

https://de.wikipedia.org/wiki/Zilog_Z80#Unterschiede_zum_Intel_8080

ein Assemblerlisting im 8080-Code

ist das ein Quelltext oder das binary, z.B. in Intel-Hex-Format?

in ein Z80-Listing bzw. in eine Z80 Datei umwandeln

Am einfachsten das binary mit einem Z80-Disassembler ausgeben, die Kommentare von Hand aus dem Original-Quelltext dazufügen wenn der vorhanden ist.

Christoph db1uq K. schrieb:

ein Assemblerlisting im 8080-Code

ist das ein Quelltext oder das binary, z.B. in Intel-Hex-Format?

in ein Z80-Listing bzw. in eine Z80 Datei umwandeln

Am einfachsten das binary mit einem Z80-Disassembler ausgeben, die Kommentare von Hand aus dem Original-Quelltext dazufügen wenn der vorhanden ist.

Hallo, ich denke das es ein Quelltext ist, da ich ihn mit einem Texteditor öffnen kann. Ich würde diese aber gern in einen Z80-Quelltext wandeln.

VG Dietmar

Die Datei hier hochladen ist keine Option? Andere könnten rein schauen und dir dann sagen was es ist.

Jens K. schrieb:

Die Datei hier hochladen ist keine Option? Andere könnten rein schauen und dir dann sagen was es ist.

Hier mal die Datei als Anhang.

VG Dietmar

Folgend ein Code-schnipsel aus der Datei:

1

L1CBA    INC    HL

2

         INC    DE

3

         mov     A,E

4

         OR     D

5

         SCF

6

         RET    Z

7

         PUSH   HL

8

         mov     HL,[D18F8]

9

         XOR    A

10

         SBC    HL,DE

11

         POP    HL

12

         RET

13

14

L1CC5    call    PRINT

15

         db   "1   Programmieren"

16

         db   "   +080

17

         RET

18

;

19

L1CD7    call    PRINT

20

         db   "2   Lesen"

21

         db   "   +080

22

         RET

23

;

24

L1CE1    call    08H

25

         cmp     05F

26

         RET    Z

27

         cmp     07F

28

         RET    Z

29

         cmp     05A

30

         jmp     Z,L1CF9

31

         cmp     051

32

         RET    NZ

33

         POP    HL

34

         RET

Wegen der Regesiterbezeichnung "HL" und dem "mov" statt "LD" könnte man auf 8080 mnemonics tippen.

• http://popolony2k.com.br/xtras/programming/asm/nemesis-lonestar/8080-z80-instruction-set.html

Die könnte man mit search/replace (bspw. per sed) in Zilog Z80 mnemonics umwandeln. Wegen dem Autorennamen ("Ludwig/J.Beisler) könnten man auf einen programmer für den Amateurcomputer AC1 tippen. https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21818

Der AC1 hatte eine Z80-Nachbau-CPU:

• http://www.kc85emu.de/scans/fa0489/AC1.htm
• https://hc-ddr.hucki.net/wiki/doku.php/homecomputer/ac1

Also wäre das Listing schon für den Z80.

Die File-extension .EDA wird wohl auf den Editor-Assembler EDAS4 verweisen: http://www.ac1-info.de/literatur/fa_87_01_2.htm

Ich vermute (nach Durchsicht der EDA-Datei) da hat jemand ein EPROM-File einfach de-assembliert.

Problem: Wurde da der falsche Kern genutzt, ist das Dekompilat fehlerhaft.

Jens K. schrieb:

Ich vermute (nach Durchsicht der EDA-Datei) da hat jemand ein EPROM-File einfach de-assembliert.

Gegen "einfaches" Dis-assembling sprechen:

• die vielen Kommentare
• lesbare db-AsCII
• lesbare CALL Addressen auf Firmware (Monitor)-routinen

Siehe diesen Abschnitt, der wohl Zyklenanzahl und Geschwindigkeit beim EEPROM-brennen einstellen könnte:

1

L1B0C    call    PRINT

2

         db   00E

3

         db   "2708Programm.NOR"

4

         db   "MAL/SCHNELL   [N/S"

5

         db   "]:   "

6

         db   002+080

7

         CALL   L1CE1

8

         jmp     Z,L1AD5

9

         mov     HL,00DD3

10

         cmp     04E

11

         jmp     Z,L1B45

12

         cmp     053

13

         jmp     NZ,L1B0C

14

         mov     HL,00047

15

L1B45    mov     [D18F4],HL

16

         call    10H

17

L1B49    call    PRINT

Problem: Wurde da der falsche Kern genutzt, ist das Dekompilat fehlerhaft.

Gibt es für den ursprünglich verwendeten Assembler überhaupt einen entsprechenden Dissassembler-Kern? In der verlinkten Doc zum AC1 wird erwähnt, das wohl ein anderer Assembler als der von Zilog (der ZEAP 2.0 der Firma NAS - Elektronische Halbleiter GmbH) "Vorlage" für den U880-Assembler des AC1 war. musste ja in 4k ROM passen. Das würde die Unterschiede im Syntax erklären.

Manual zum ZEAP 2.0 da: http://www.nascomhomepage.com/pdf/zeap.pdf Manual zum EADS hier wiederholt: http://www.ac1-info.de/literatur/fa_87_01_2.htm

Das Problem des TO könnte jetzt sein, das er den zum Listing passenden Assembler nicht hat und es mit einem anderen Z80-Assembler versucht, der sich aber am Listing verschluckt und dem eventuell noch ein paar Label-definitionen unbekannt sind. Der AC1 ist immerhin über 40 Jahre alt.

IMHO wäre Infos vom TO bezüglich der geplanten Verwendung des Listings und dessen Ursprung hilfreich. Wahrscheinlich müsste man das Listing manuell (Syntax-Anpassungen) an den heuer benutzen Assembler anpassen, weil damals kein konverter für sowas entwickelt wurde. Aber auch bei 500 LoC sollte das nicht übermäßig lange dauern, search and replace ist in python schnell geschrieben.

"Eprommer 2716-27512 V.22 1.4 [c]87/89 E.Ludwig/J.Beisler" der wird hier besprochen: https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21818&replyto=238522&time=0&pagenum=lastpage

"Hallo Dietmar, das Programm EPROMMER V1.4 von E.Ludwig/J.Beisler (SCCH) belegt von 1900h bis 1D77h und läßt sich mit den Kennbuchstaben * starten. Möchest Du diesen Programm und seine Quellcode (in 8080er Code) haben? Viele Grüße Babette"

Bradward B. schrieb:

Gegen "einfaches" Dis-assembling sprechen:

Naja, gerade das Beispiel sieht so aus, als wäre es aus einem --wenn auch recht guten-- Disassembler gefallen.

Weder kann ich mir vorstellen, daß jemand die willkürlichen Stringkonstantentrennungen so hinschreiben würde, noch, daß jemand diese Label verwenden würde, die ja wohl recht eindeutig einfach nur Adressen mit einem vorangestellten L sind.

Ja das ist eine typische Ausgabe eines "intelligenten" Disassemblers, der alle Sprungadressen in Labels umwandelt, und nicht als Programmbestandteil zuzuordnende Daten als Bytes mit "db" auflistet. Wenn der Disassembler auch noch Adressbereiche des "Betriebssystems" kennt, kann es die auch noch zuordnen. Am Ende hat noch jemand ein paar Kommentare zugefügt. Das kann man aber durch einen beliebigen Z80-Assembler laufen lassen und bekommt dann hoffentlich lauffähigen Code. Der lässt sich dann soweit kompatibel auch als 8080-Code disassemblieren, wenn man den besser versteht.

Hier wäre mal ein Anfang (Ein paar "Suchen und Ersetzen" im Editor). So sollte es fast durch einen "herkömmlichen" Z80-Assembler gehen.

1

         ORG    01900

2

;

3

         db   "1   2716   *   2   2732   "

4

         db   "*   3   2764   *   4   271"

5

         db   "28   *   5   -256   *   6   -512"

6

;

7

         db   0,9,18,27,36,45

8

;

9

L1931    ld      A,08F

10

         OUT    (P0A),A

11

L1939    ld      si,01900

Wenn man si durch IX oder IY ersetzt, würde es einen Sinn ergeben.

Und dann fehlt noch das H hinter den meisten Hex-Zahlen, wie in der Zeile mit dem Label L1931.

ich würde das ganze einfach durch einen 8080 Assembler schicken

Christoph db1uq K. schrieb:

Ja das ist eine typische Ausgabe eines "intelligenten" Disassemblers, der alle Sprungadressen in Labels umwandelt, und nicht als Programmbestandteil zuzuordnende Daten als Bytes mit "db" auflistet. Wenn der Disassembler auch noch Adressbereiche des "Betriebssystems" kennt, kann es die auch noch zuordnen.

OK, soviel "Intelligenz"/"Komfort"/"Kenntnisse" hätt ich bei einem 8 bit Dissassembler für den HOME-Computer-Gebrauch nicht erwartet.

Das kann man aber durch einen beliebigen Z80-Assembler laufen lassen und bekommt dann hoffentlich lauffähigen Code.

Da der 8080 Code binärkompatibel zum Z80 ist, könnte man doch auch das Ganze ohne den Schleife HEX -> Dissassembler -> Assembler -> HEX laufen lassen ?! Außer, man will den Code auf eine Maschine mit anderem Memory-Space, Einsprungaddressen zur Firmware/Betriebssystem bringen.

Eventuell hat es auch nie gut dokumentierten Quell-code im heutigen Sinne gegeben. Wenn so ein Editor nur wenige k RAM für den Text zur Verfügung hat, dann kann er eben nur wenige Zeilen (bspweilsweise (25 Zeilen a 40 Zeichen = 1k) speichern und muesste immer wieder vom externen Speichermedium nachladen. Aber nicht jedem Amateur Rechner stand ne Floppy oder wenigstens ein Tape zur Seite. Und auf einem Tape immer zum richtigen Abschnitt spulen ... Da der Maschinencode einigermassen logisch strukturiert ist: da die bits für den OPcode, dort die Bits für die registeradressierung... https://media.bizj.us/view/img/2667281/howtostevewozniak.jpg

Programme wurden auch gern als reines Hex-Listing zum Abtippen verbreitet, manche "Helden" assemblierten ihren Code per Hand auf Karo-Papier. Anpassung (Hacks/Cheats) wurden direkt im bin-Image appliziert. https://youtu.be/NhjvJhJMprY?t=204

Wenn man da heuer Sources in einer komfortablen Versionsverwaltung haben will (in der man bspw. die Unterschiede zwischen 1.3 und 1.4 schnell erkennt) bleibt halt nur reverse Engineering mit "händischen" Aufhübschen. Oder ist ChatGPT inzwischen af Niveau "Computerkid der 80er" angekommen

Hallo, ich habe zu dem Listing schon die fertige .Z80 Datei. Mir ging es darum das ich eine .E80 Assemblerdatei generieren kann die ich dann im EDAS4 (Editor,Assembler für Z80)generieren kann. Da ich im programmieren noch Anfänger bin, verstehe ich die Assemblerlistings für Z80 besser.

Vielen Dank für eure Ausführungen.

Welchen Assembler kann ich denn für die 8080-Datei verwenden?

VG Dietmar

Soweit ich weiß, hat 8080 einen Teilbereich der Z80-Befehle. Also kann man ein 8080-Programm auch auf dem Z80 ausführen, aber nicht unbedingt umgekehrt. Ich habe nur einmal ein Z80-Assemblerprogramm geschrieben, Ende der 70er auf dem TRS80 von Radio Shack / Tandy. Den hatten wir in der Uni KA.

Das Programm scheint laut Robotron-Forum für den AC1 zu sein https://de.wikipedia.org/wiki/AC1 "auf dem Prozessor U880 basiert"

https://de.wikipedia.org/wiki/MME_U880 "Der U880 ist ein nicht lizenzierter Nachbau des Prozessors Zilog Z80. Die Unterschiede zum Zilog Z80 beschränken sich auf spezielle Details wie ein nicht gesetztes Carry-Flag bei dem OUTI-Befehl."

Also sollte das eine echte Z80-Datei sein.

Das Unterprogramm CALL PRINT ist ein alter Trick, der Text steht unmittelbar dahinter als .db Daten. Das Unterprogramm (an Adresse "18") scheint die Rücksprungadresse ins Hauptprogramm passend zu inkrementieren, damit es nach dem Text weiterläuft.

Dietmar B. schrieb:

Welchen Assembler kann ich denn für die 8080-Datei verwenden?

https://www.ticalc.org/archives/files/fileinfo/250/25051.html

Der kann auch mit dem 8080 umgehen. Es ist eine 32 Bit App kann also direkt unter Win auf der Komandozeile aufgerufen werden.