Der MC-68000-Computer

Ich habe mich mal bei gemacht und habe den Source Code aus der mc68000 Dokumentation als Quell Listing verfügbar gemacht.

Die entsprechende(n) Datei(en) sind (nur) für Vereinsmitglieder wie folgt zu finden:

Für den Zugriff auf diesen Link ist die Information von hier notwendig.

... nur für Vereinsmitglieder.

Ich bin raus...

trazom : Hast nee PM...

hi tokabln....

bist du noch eine weile on-line ...

habe ein paar fragen, muss dazu aber einige fotos machen.

Gruss,

rolf

hallo,

habe mal eine frage.. habe fuer den mc68000-2 das monitor listing. habe im hexeditor angeschaut und habe da verstaendnis problem

dann Romsplit durchgefuehrt und bekomme Part.1 und Part.2, Nun ist mir nicht klar welches Upper und Welches Lower ist.

Gruss,

Rolf

Die Photos....

part1 ist lower (D8-D15), part2 ist upper (D0-D7)

EDIT:

Vorsicht!! Lower/Upper vertauscht. S. Post #403 zur Klarstellung.

gut, danke Dir !

Gruesse,

Rolf

Hinweis zu dem Sourelisting so wie ich es beim Abtippen erlebt habe:

Ich weiß nicht welcher Assembler urpünglich zum Einsatz gekommen ist. Bei Verwendung des „Easy68K“ Assemblers werden Fehler ausgegeben. Diese umfassen zunächst Label die im Original groß- oder kleingeschrieben sind aber unterschiedliche Aufgaben erfüllen. Beispiel: „ctrlTAB“ bzw. „ctrltab“ oder „nochange“ und NOCHANGE“ welche unterschiedliche Aufgaben abarbeiten. Der „Easy68K“ gibt hier Fehler aus (ist nicht case sensitiv). Auch finden sich im Original Source Codelisting in einigen Labels Sonderzeichen wie z.B. „>„, „§„, „^“ etc. Auch diese werden vom „Easy68K“ Assembler als Fehler interpretiert.

Mittlerweile vermute ich, das VASM als Assembler in der Vergangenheit bei der ursprünglichen Erstellung zur Anwendung kam. Das ist aber nicht bestätigt.

Ich weiß nicht genau, unter welchem OS und mit welchem Editor du die Listings erstellt hast; aber die \x92 waren wahrscheinlich mal U+2019 (Right Single Quotation Mark) und sollten wahrscheinlich eher U+0027 (Apostrophe) sein.

Zitat von tokabln

Auch finden sich im Original Source Codelisting in einigen Labels Sonderzeichen wie z.B. „>„, „§„, „^“ etc. Auch diese werden vom „Easy68K“ Assembler als Fehler interpretiert.

Ich tippe auf ein Zeichensatzproblem beim Ausdruck/Listing.

Wenn man sich die Texte im ROM ansieht, dann liegt das kleine "ü" bei 0x7D - da gibt es nicht viele Zeichensätze, kommt eigentlich nur DIN 66003 (ISo 646 Variante 21) in Frage. Dann wäre das "§" möglicherweise ein "@" (wenn ich es im Kopf nicht gerade verdreht habe).

Zitat von nicode

Ich weiß nicht genau, unter welchem OS und mit welchem Editor du die Listings erstellt hast; aber die \x92 waren wahrscheinlich mal U+2019 (Right Single Quotation Mark) und sollten wahrscheinlich eher U+0027 (Apostrophe) sein.

nicode :

Das muß ich mir mal anschauen, Danke. Das Listing wurde unter Windows 7 mit dem Easy68K Editor abgetippt. Aber das war denke ich nicht das Problem. Im gedruckten und eingescannten Sourcecodelisting der Originaldokumentation zum MC68000 sind diese Sonderzeichen bereits so enthalten... möglicherweise mit Absicht ?!?

Beispiele:

no^s2:

MOVE.L 8,§BERRSAVE

MOVEA.L §A7SAVE,A7

BSR INITVIA'S

JMP §MATRIXERW

Auch gibt es dort zwei Vektoren die keinerlei weitere Entsprechung innerhalb des gedruckten Listings aufweisen.

Beispiel "DEPACK" was möglicherweise auf Motorola's DESPACK hinweist...

MOVE.L #DEPACK,-$1C00(A0)

Das mal als Beispiele. Das INITVIA'S oder no^s2: kann man leicht entschärfen aber bei den § z.B. fehlt mir das Verständnis. Vielleicht hast Du ja einen Hinweis.

Zitat von tokabln

[...] aber bei den § z.B. fehlt mir das Verständnis. Vielleicht hast Du ja einen Hinweis.

Ich habe nochmal nachgesehen... es scheint ja ein eigener Asm-Dialekt im ROM enthalten zu sein.

ORG ist soweit klar und üblich, um die aktuelle Basisadresse festzulegen (in diesem Fall wohl ROM-Code).

Dann gibt es aber noch OBJ, ähnlich, aber hier scheint es sich um RAM-Datenblöcke zu handeln (ähnlich SECTION mit R/W).

Die § scheinen "Modul"-übergreifende Referenzen zu sein (bei anderen Assemblern würden die 'externen' Referenzen mit XREF bekannt gemacht).

141.rom (141LOW.BIN/141UPP.BIN) ->sicher, dass der Dump korrekt ist? Ziemlich früh im RESET-Code sind schon merkwürdige Bits 'gedreht', die zu ungültigem Code führen.

143.rom -> sicher, dass das Listing zum ROM passt? Grob passt es, aber einige Funktionen sehen leicht bis deutlich anders aus.

edit: letzteres hat sich erledigt, wer lesen kann ist klar im Vorteil: "Sourcelisting des mc 68.000-Monitors Version 2.2"

Zitat von nicode

Ich habe nochmal nachgesehen... es scheint ja ein eigener Asm-Dialekt im ROM enthalten zu sein.

ORG ist soweit klar und üblich, um die aktuelle Basisadresse festzulegen (in diesem Fall wohl ROM-Code).

Dann gibt es aber noch OBJ, ähnlich, aber hier scheint es sich um RAM-Datenblöcke zu handeln (ähnlich SECTION mit R/W).

Die § scheinen "Modul"-übergreifende Referenzen zu sein (bei anderen Assemblern würden die 'externen' Referenzen mit XREF bekannt gemacht).

Dokumentation lesen hilft, 5.3 Seite 3 (§ = absolute Adresse, ORG = PC+LC, OBJ = PC).

Da die Möglichkeiten der Nutzung durch Kapitel 7 eingeschränkt sind, bin ich erst mal raus (also kein öffentliches Ghidra-Projekt for BIOS und/oder Monitor in Version X).

Habe hier die Monitorversion 2.3, gedumpt unter OS9 und unter Linux bearbeitet. Bin gerade dabei das Ganze mit einem Disassembler (dis68k) zu erhellen. Dis68k ist ein git Projekt, mußte den allerdings schon an einigen Stellen korrigieren. Vorteil ist, dass auch die nicht im Dokument vorliegenden Teile berücksichtigt werden können. Ist allerdings ziemlich aufwändig und wird noch eine Weile dauern.

Zitat von tokabln

Mittlerweile vermute ich, das VASM als Assembler in der Vergangenheit bei der ursprünglichen Erstellung zur Anwendung kam. Das ist aber nicht bestätigt.

Das ist einigermaßen unwahrscheinlich. VASM gibt es m.W. erst seit weniger als 10 Jahren.

Zitat von tofro

Zitat von tokabln

Mittlerweile vermute ich, das VASM als Assembler in der Vergangenheit bei der ursprünglichen Erstellung zur Anwendung kam. Das ist aber nicht bestätigt.

Das ist einigermaßen unwahrscheinlich. VASM gibt es m.W. erst seit weniger als 10 Jahren.

Danke für diese Info, das hatte ich nicht recherchiert... ich hatte angenommen das es den schon länger gibt.

Zitat von Uwe

Habe hier die Monitorversion 2.3, gedumpt unter OS9 und unter Linux bearbeitet. Bin gerade dabei das Ganze mit einem Disassembler (dis68k) zu erhellen. Dis68k ist ein git Projekt, mußte den allerdings schon an einigen Stellen korrigieren. Vorteil ist, dass auch die nicht im Dokument vorliegenden Teile berücksichtigt werden können. Ist allerdings ziemlich aufwändig und wird noch eine Weile dauern.

Wenn man gemeinsam daran arbeiten möchte, dann kann ich meinen privaten Ghidra-Server anbieten, ghidra.nicode.net

(habe bios31.dat und mon22.dat dort geladen, aber das Projekt ist wegen der Lizenz nicht öffentlich)

Zitat von tokabln

Zitat von tofro

Zitat von tokabln

Mittlerweile vermute ich, das VASM als Assembler in der Vergangenheit bei der ursprünglichen Erstellung zur Anwendung kam. Das ist aber nicht bestätigt.

Das ist einigermaßen unwahrscheinlich. VASM gibt es m.W. erst seit weniger als 10 Jahren.

Danke für diese Info, das hatte ich nicht recherchiert... ich hatte angenommen das es den schon länger gibt.

Hab' noch mal nachgeguckt - vasm gibt es tatsächlich seit 2002, das paßt aber trotzdem nicht.

hallo,

habe leider eine schlechte Nachricht. Meine 6 Monatige Arbeit ist leider nicht erfolgreich....

Nach sehr kurzzeigem Zugriff auf die Rom's geht die ZPU auf HALT ... das war's dann mal.

Gruesse,

Rof

Zitat von rolfp

habe leider eine schlechte Nachricht. Meine 6 Monatige Arbeit ist leider nicht erfolgreich....

Nach sehr kurzzeigem Zugriff auf die Rom's geht die ZPU auf HALT ... das war's dann mal.

Das heisst aber nicht, das deine Arbeit nutzlos ist. Wenn eine solche komplexe Fädelkarte auf Anhieb funktioniert, ist das einem Lottogewinn gleichzusetzen.

Anhand deiner letzten Frage zu den EPROM (upper, lower) hast du wahrscheinlich eine bestehende Software benutzt.

Zur Fehlersuche würde ich eigene Software schreiben, die immer nur genau ein (Funktions-)Teil prüft. Und dann eben Stück für Stück durcharbeiten.

Ich weiss, das dauert. Aber nur so ist Fehlersuche erfolgreich.

Viel Erfolg

Zitat von rolfp

hallo,

habe leider eine schlechte Nachricht. Meine 6 Monatige Arbeit ist leider nicht erfolgreich....

Nach sehr kurzzeigem Zugriff auf die Rom's geht die ZPU auf HALT ... das war's dann mal.

Gruesse,

Rof

Alles anzeigen

Hallo Rolf,

ich nehme einmal an, dass du das Kapitel 4 des Handbuchs schon gelesen hast. Ich hatte auch mal Probleme mit meinem System, da hat mir der Hardware Singlestep einigermaßen weitergeholfen. Die EPROMS sitzen im richtigen Slot? Upper/Lower des EPROMS ok ? Upper/lower korrekt? Hast du Monitor oder Terminal angeschlossen?

Das wird schon

Gruß Uwe

Zitat von Uwe

Zitat von rolfp

hallo,

habe leider eine schlechte Nachricht. Meine 6 Monatige Arbeit ist leider nicht erfolgreich....

Nach sehr kurzzeigem Zugriff auf die Rom's geht die ZPU auf HALT ... das war's dann mal.

Gruesse,

Rof

Alles anzeigen

Hallo Rolf,

ich nehme einmal an, dass du das Kapitel 4 des Handbuchs schon gelesen hast. Ich hatte auch mal Probleme mit meinem System, da hat mir der Hardware Singlestep einigermaßen weitergeholfen. Die EPROMS sitzen im richtigen Slot? Upper/Lower des EPROMS ok ? Upper/lower korrekt? Hast du Monitor oder Terminal angeschlossen?

Das wird schon

Gruß Uwe

Hallo Uwe,

Terminal und OnBord geht nicht... Upper und Lower sind korrekt. ..

hatte noch mal meine Verdrahtung geprueft und drei probleme aufgespuert. 1. Blatt 10 Parallel KBD unten das Signal SERKBD/Low ... ganz Toll das kann NIE high werden, weil das IC86 / LS14 den Pegel immer auf LOW held.

2. Blatt 6 / 7 Signal CRTC/LOW da stimmt etwas mit der Blatt zuordnung nicht .

3. Blatt 11, die beiden VIA's da ist die DATEN zuordnung LSID0.... LSID7 ist falsch ! IC56 VIA mit muss mit LSID8 bis LSID15 verdrahted sein. Habe ich nachtraeglich korrigiert.

der ADDRES DECODER wir nicht programmiert weil die CPU auf HALT / LOW geht. Aus diesem Grund functioniert auch der Stngle Step nicht....

Gruesse,

Rolf

Alles anzeigen

Hallo Uwe,

Terminal und OnBord geht nicht... Upper und Lower sind korrekt. ..

hatte noch mal meine Verdrahtung geprueft und drei probleme aufgespuert. 1. Blatt 10 Parallel KBD unten das Signal SERKBD/Low ... ganz Toll das kann NIE high werden, weil das IC86 / LS14 den Pegel immer auf LOW held.

2. Blatt 6 / 7 Signal CRTC/LOW da stimmt etwas mit der Blatt zuordnung nicht .

3. Blatt 11, die beiden VIA's da ist die DATEN zuordnung LSID0.... LSID7 ist falsch ! IC56 VIA mit muss mit LSID8 bis LSID15 verdrahted sein. Habe ich nachtraeglich korrigiert.

der ADDRES DECODER wir nicht programmiert weil die CPU auf HALT / LOW geht. Aus diesem Grund functioniert auch der Stngle Step nicht....

Gruesse,

Rolf

Zitat von rolfp

Hallo Uwe,

Terminal und OnBord geht nicht... Upper und Lower sind korrekt. ..

hatte noch mal meine Verdrahtung geprueft und drei probleme aufgespuert. 1. Blatt 10 Parallel KBD unten das Signal SERKBD/Low ... ganz Toll das kann NIE high werden, weil das IC86 / LS14 den Pegel immer auf LOW held.

2. Blatt 6 / 7 Signal CRTC/LOW da stimmt etwas mit der Blatt zuordnung nicht .

3. Blatt 11, die beiden VIA's da ist die DATEN zuordnung LSID0.... LSID7 ist falsch ! IC56 VIA mit muss mit LSID8 bis LSID15 verdrahted sein. Habe ich nachtraeglich korrigiert.

der ADDRES DECODER wir nicht programmiert weil die CPU auf HALT / LOW geht. Aus diesem Grund functioniert auch der Stngle Step nicht....

Gruesse,

Rolf

Alles anzeigen

Hallo Rolf,

wie auf Seite 3/4.3 beschrieben ist der Adressdekoder beim Reset nicht eingeschaltet. Wie auf Seite 4/4.2 Checkliste i) beschrieben müßte das Laden des SSP im Singlestep zu beobachten sein wie beschrieben müßten nacheinander 00FF,C400,00FF,0020 und 6000am Datenbus erscheinen.Der Adressdekoder wird erst später eingeschaltet und programmiert

Gruß Uwe

Uwe, das nuetzt alles nicht's wenn der Singel Step nicht funct .... einen Logic Analizer habe ich nicht. Auf dem Scope kann ich nur sehen das ein

sehr kurzer zugriff auf die Rom's statt findet und die CPU auf HALT geht....

Rolf

Wird Dtack irgendwann low?
Ansonsten wartet die CPU einfach...

Zitat von trazom

Wird Dtack irgendwann low?
Ansonsten wartet die CPU einfach...

ja, wie bei den Rom's das ist mit dem Scope nicht nachzuvolziehen welcher zeitliche Abstand besteht..

Das Hanbuch System 2 habe ich leider nicht ... habe gesucht auf den Rechnern aber nichts...

Das Handbuch ist bei CENARIO abgelegt: https://www.cenarioworld.de/mc…68000%20Dokumentation.pdf. Schau dir da mal die Singlestep Logik an.