Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » P8000: Wiederherstellung WEGA Sourcecode » Themenansicht

Autor

Thread - Seiten: -1-

000
09.11.2026, 16:43 Uhr
Olli

Moin zusammen,

ich dachte - ich berichte einfach mal hin und wieder wo ich stehe bei meinem Projekt P8000 Wiederherstellung Originalquellcode WEGA. Vielleicht interessiert es ja den ein oder anderen

Nutzen tu ich Claude Code (2 Pro Accounts) Modelle sind entweder Claude Sonnet 5.5 oder wenn es komplizierter wird Claude Opus 5.5

Ziel ist es: Die Originalquellen wiederherstellen, die 1:1 den WEGA 3.1 Installationsstand erzeugen können. Originalquellen ist etwas zu hochtrabend - es werden Quellen erzeugt die genau das ausgelieferte Binärprogramm erzeugen - ob die Quelle 100% genau so im Original aussah bleibt ungeklärt.

Was direkt aufgefallen ist - die Programme in WEGA wurden alle mit unterschiedlichsten Ständen des Compilers und seiner Hilfsprogramme (Parser, Code-Generierer, Optimierer, Assembler) geschrieben. Auch alle diese Compiler-Stände werden rekonstruiert. Es hat sich gezeigt das wirklich eine 100%ige Binärgleichheit erreicht werden muss um wirklich sicherzustellen, dass die Quellen korrekt sind. Eine "Funktionsgleichheit" reicht nicht.

Aktueller Stand:

Die ganze Compilerfamilie (mit Ausnahme PLZ/ASM, PLZ/SYS) steht inzwischen. Es gibt auch schon einige "historische" Compilerstände.
Auch habe ich den ausgelieferten Compilerstand als Crosscompiler funktionsgleich unter Linux erstellen lassen. Ich kann also WEGA binaries aus C-Source unter Linux compilieren, assemblieren und linken - sprich erzeugen.
Der Kernel ist 100% in Quellcode vorliegend (da hatte ich ja 2008 schon viel Vorarbeit geleistet - damals noch alles 'zu Fuß'). Die libc ist auch rekonstruiert - auch wieder alle historischen Zwischenstände die mir bisher über den Weg gelaufen sind.

Die KI hat viel Prüflogik (sogenannte Corpus) geschrieben die den aktuellen Stand der Programme gegen den ausgelieferten Stand prüft (z.B.: Kann der rekonstruierte Assembler alle Mnemonics umwandeln und die eigene Optimierung von jp/jpr call/calr genauso wie der ausgeliefert). Das ist natürlich am Ende, wenn man ein 100% identisches Binary erreicht hat nicht mehr so wichtig, aber auf dem Weg dahin schon - und vor allem auch bei späteren Weiterentwicklungen.

Wer sich im Detail informieren will: Hier gibt es ein Dokument mit allen Files aus der Standard-Installation von WEGA und wie viele bzw. welche davon schon "exakt" rekonstruierbar sind:

https://github.com/OlliL/P8000/blob/toolchain/WEGA/src/COVERAGE.md

heute habe ich den Kernel zu ende gebracht, aktuell versuche ich noch den C-Assembler auf "exakt" zu bekommen (aktuell ist er nur funktionsgleich) und danach mache ich vermutlich mit Programmen aus /bin weiter.... mal schauen

Stay tuned!

--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
09.11.2026, 18:04 Uhr
Bert

Zitat:

Olli schrieb
Ziel ist es: Die Originalquellen wiederherstellen
...
Was direkt aufgefallen ist - die Programme in WEGA wurden alle mit unterschiedlichsten Ständen des Compilers und seiner Hilfsprogramme (Parser, Code-Generierer, Optimierer, Assembler) geschrieben.

Schöne Idee. Damit kann man möglicherweise Rückschlüsse ziehen, welche Systeme zum Entwickeln der Software genutzt wurden, falls das nicht schon bekannt ist.
--
Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
09.11.2026, 18:05 Uhr
Enrico
Default Group and Edit

Zitat:

Olli schrieb
Moin zusammen,

ich dachte - ich berichte einfach mal hin und wieder wo ich stehe bei meinem Projekt P8000 Wiederherstellung Originalquellcode WEGA. Vielleicht interessiert es ja den ein oder anderen

....

Ja, aber nix verstehn...
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
09.11.2026, 18:11 Uhr
HeikoS

Zitat:

Ja, sehr gerne ! Vor allem Erfahungen mit den einzelnen KI-Modellen wären interessant. Das BASIC-T hatte ich am WE in ca. 45 min so analysieren lassen, dass man das Notwendigste erkennt und mit einem Assembler wieder zusammenbauen kann. Ist ja ein ähnliches Projekt, aber lange nicht so komplex, wie den WEGA-Code wiederherzustellen.

Grüße, Heiko

Dieser Beitrag wurde am 09.11.2026 um 18:16 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
09.11.2026, 18:12 Uhr
kaiOr

Das ist schon Datenforensik „Next Level“. Ehem. Mitarbeiter von EAW fangen an zu bangen, ob/wann und wen deine KI demnächst als "Verursacher" auflistet, inkl. aller gefundenen Sicherheitslücken.

Da fällt mir ein, ich hatte doch mal Liste aller leitenden EAW-Mitarbeiter inkl. Adresse, Zweitwohnsitz, Ferienhaus gesichert. *hrhr*

Grüße,
Kai

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
09.11.2026, 18:16 Uhr
HeikoS

Zitat:

kaiOr schrieb
Das ist schon Datenforensik „Next Level“. Ehem. Mitarbeiter von EAW fangen an zu bangen, ob/wann und wen deine KI demnächst als "Verursacher" auflistet, inkl. aller gefundenen Sicherheitslücken.

Da fällt mir ein, ich hatte doch mal Liste aller leitenden EAW-Mitarbeiter inkl. Adresse, Zweitwohnsitz, Ferienhaus gesichert. *hrhr*

Grüße,
Kai

:-)))

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
09.11.2026, 19:36 Uhr
Olli

Die KI findet fleißig Fehler in den Original-Binaries

stehen hier:
https://github.com/OlliL/P8000/blob/toolchain/WEGA/host/KNOWLEDGE.md#bugs-and-quirks-of-the-originals

(Achtung, die Datei wächst und wächst..... die ist eher zum suchen als zum durchlesen gedacht, steht halt alles drin was die KI so rausgefunden hat während der Vorgänge)

Bert: es sind eher verschiedene Stände des gleichen Compilers (zumindest bisher). Man hat - so habe ich mir das mal von alten Leuten erklären lassen

bei einem Release einer neuen Version nicht das gesamte Betriebssystem neu generiert, sondern nur die Binaries die auch Änderungen in der Version haben. So findet man in WEGA (was ja eigentlich ein altes ZEUS ist) Objekte aus verschiedenen Zeiten. das Älteste was einen Zeitstempel hat ist von 11/09/81 - das neuste von 02/28/84 - irgendwann danach muss dann die S8000 ihren Weg in die DDR gefunden hat. Peter Hoge berichtete mir ja mal wie die da mit der Entwicklung am Original Zilog System begonnen haben.

Und zwischen diesen Jahren gab es halt verschiedene Versionen in dem Verwendeten C-Compiler und seinen Passes.... aktuell habe ich - wenn ich mich richtig erinnere - 12 verschiedene Versionen der libc und 7 verschiedene Compiler-Versionen (+den in WEGA selbst enthaltenen)
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
09.11.2026, 19:51 Uhr
Olli

Aber ansonsten.... man bekommt schon große Augen.
Ich habe selber ja viele Objekte des Kernels aus disassemblierten wieder in C-Code gebracht der bytegleich compiliert. Aber - das war eine recht mühsame Aufgabe.

Hier mal ein Beispiel wie ich das mit einem libc-Objekt seinerzeit ganz ohne KI gemacht habe:
http://www.pofo.de/blog/index.php?/archives/115-Rebuilding-WEGAs-libc.html
Oder hier am Kernel - wobei ich da nur ein ASM file wiederhergestellt habe.:
http://www.pofo.de/blog/index.php?/archives/101-Kernel-sources.html

Zu sehen, wie die KI genau weiß in welchem Compiler-Pass welche Änderung gemacht werden muss, damit eine "alte Compilerversion" genau den Assembler-Code erzeugt den man mit dem aktuellen Compiler nicht mehr hinbekommt.... das finde ich schon atemberaubend. Quasi anhand der Binaries den alten C-Compiler wiederherstellen..... krass. Da hätte ich Jahre für gebraucht.
Klar - bei nur wenigen "Zeugen" sind diese Anpassungen am Compiler auch nur ein Ratespielchen - es könnten auch andere Anpassungen gewesen sein - oder doch anderer Quellcode im Source der nur nicht gefunden wurde.... alles ist möglich

Dennoch atemberaubend.

Ich nutze ja auch schon seit geraumer Zeit KI auf Arbeit. Aber die Modelle von Anthropic sind einfach sensationell. Opus 5.5 ist top. Für die einfachen Arbeiten nutze ich Sonnet 5.5 - einfach weil es weniger Tokens verbraucht. Aber Opus.... wow.... haut mich immer wieder vom Hocker wenn ich denke wie lange ich für diese Dinge gebraucht hätte (einfach weil mir auch das Detailwissen fehlt - was sich die KI aber einfach selbst erarbeitet. Ist ja nun nicht so, das mega viel zu Z8000 Assembler im KI-Kopf vorhanden ist).
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 09.11.2026 um 19:54 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
09.11.2026, 21:32 Uhr
HeikoS

Danke für den kurzen Einblick. Ja, staunen kann man da immer wieder. Vor allem wie schnell diese Modelle lernen und dann immer komplexere Aufgaben rasend schnell erledigen.

Ich benutzte Reasoning- und Code-Modelle wie Gemini 3.7 Flash oder auch Modelle aus der Anthropic Claude-Familie. Für die Software-Entwicklung bieten sich auch immer mehr Meta-KI-Agenten an, die dann anhand der Aufgabe entscheiden, welches Modell sie nutzen.

Alles verrückt, aber auch faszinierend, gerade wenn man Software auch selbst entwickelt hat. Da kommen dann auch immer neue Ideen, die man früher niemals auch nur im entferntesten in Betracht gezogen hätte, zu realisieren. WEGA-Wiederherstellung ist auch so ein schönes Projekt.

Dieser Beitrag wurde am 09.11.2026 um 22:15 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
Heute, 15:50 Uhr
Olli

Frisch aus dem C-Rekonstruktionslabor...

Das ist so abgefahren... die KI hat heute ne Lösung gefunden, da wäre ich im Leben nicht drauf gekommen. Jetzt wirds technisch..... ?

Im disassemblierten Code findet man das Laden einer Konstanten in ein Register.

Quellcode:


    ldk r2,#4 - lade dezimal 4 in das Register r2

Das geht aber so direkt in C natürlich nicht. Vor allem - dieses Register wird danach gar nicht mehr verwendet. Es ist völlig ohne Funktion.

Claude Opus sagt: Das muss irgendeine Logik im Optimizer sein - wir müssen den Optimizer anpassen - er findet aber einfach keine Regel die das bewirken könnte. In allen WEGA Objekten gibt es diese ldk Logik auch nur im Quellcode des Assemblers selbst - an 2 Stellen. Sonst nirgends...

Das absolute Top Modell von Anthropic - Claude Fable hat die Lösung gefunden..... Im C Code steht ein switch/case auf eine Konstante (was ja gar kein Sinn macht, die ist halt konstant - was willst du da switchen... Fable fand raus - der switch-Wert wird dann in r2 geladen damit er danach ausgewertet werden kann über ne Sprungtabelle für die einzelnen case-Blöcke. Da es aber nunmal eine Konstante ist, wird die gesamte Switch-Case-Sprung-Logik danach vom Optimizer weg optimiert - das Laden in Register r2 bleibt aber noch im ASM übrig. Also sowas hier in C:

Quellcode:


    switch (sizeof(struct irow *)) {
    case 4:
        return((struct irow *)igetl());
    case 2:
        return((struct irow *)igetw());

sizeof diesen Struct-Pointer ist in der Architektur immer 4. Das ist konstant. das sizeof lädt er noch in das Register r2, den ganzen Kram danach optimiert er weg und es bleibt nur der Aufruf von igetl() übrig...

Quellcode:


        ldk     r2,#4
        callr   _igetl
        ldl     rr0,rr2
        and     r0,#%7f00  -- sicherstellen, dass die in der Adresse kodierten Segmentnummer 127 nicht überschreitet
        ldl     rr2,rr0
        ret

Man muss dazu wissen - _igetl liefert seinen return in rr2 (und befüllt das wiederum aus einem anderen Register - r2 wird also nie ausgewertet.

Darauf zu kommen..... total abgefahren. Das hätte ich mein Leben nie rausgefunden.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 10.11.2026 um 16:19 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]