Hallo,

einfach mal des Retro-Spielens willen .. hat jemand ein funktionierendes 68008er GOSI? Ja bringt nicht viel aber ich will mal die Sachen ausprobieren die ich mit 10 beim Vater im gelben Buch gesehen habe

In Hans-Werners Diskettensammlung ist unter "JOGISPR" "GOSI3_1" drin aber das stürzt beim Compilieren mit Adressfehler oder "FALSCHER BEFEHL" ab. Es will dabei häufig auf $x6002 zugreifen, das ist aber außerhalb der 3 ROMs. (ja die Datei hat 32kB aber die letzten 8KB sind irgendein halber Programmtext).

Oder frage ich da gerade nach einem Unobtanium? Auf der ndr-nkc.de Seite steht es auch als "verloren gegangen".

Gruß,
Christian

Moin Christian,

ich scheine auch nur die gleiche GOSI Version zu haben
Der Abbruch ist bei mir exakt wie bei dir...

-----------------------
Gruß
-=jens=-

Hallo Jens,

Wenn ich in das RAM ab $x6000 eine NOP-Rutsche schreibe läuft es die runter und crashed dann beim ersten "sinnlosen" Befehl.

Wenn ich ein RTS hinschreibe, kommt er soweit einen nahezu sinnvollen Assemblerquelltext zu erstellen, wo aber die Registernamen falsch sind.

Also:

MOVEQ.L #32,0
JSR @SCHREITE

statt:

MOVEQ.L #32,D0
JSR @SCHREITE

Da fehlt ein Unterprogramm?
Bzw. die Datei heißt GOSI3_1 aber meldet sich mit GOSI3.0

Ob das eine (angefangene) Entwicklungsversion war aus der RDK damals die entsprechende Routine "rausgebogen" hat um sie durch eine im RAM zu ersetzen?

Gruß,
Christian

So, ich hab mal einen Disassembler draufgejagt ..

An Adresse 0x5f8 steht ein:
61 00 48 0c

Das ist ein BSR.W $4E06

Bei 4E06 stehen aber Nullen, das ist aber erstmal kein Problem, da 00 00 00 00 ein ORI.B #$0,D0 ist .. also ein effektiv ein NOP bzw. eher ein TST.

Die Adresse ist Nonsens, ich schau mal was rauskommt wenn man jeweils ein Bit kippt

Nein .. war anders .. das ist das Codestück:

000005f4 10 3c 00 44 move.b #0x44,D0b
000005f8 61 00 48 0c bsr.w s__00004e06
000005fc 30 1f move.w (SP)+,D0w
000005fe c0 3c 00 0f and.b #0xf,D0b
00000602 d0 3c 00 30 add.b #0x30,D0b
00000606 61 00 fe fe bsr.w FUN_00000506
0000060a 4e 75 rts
0000060c 3f 00 move.w D0w,-(SP)
0000060e 10 3c 00 41 move.b #0x41,D0b
00000612 60 e4 bra.b LAB_000005f8

$506 ist sowas wie "schreibe das Zeichen in den Assemblertext" und $44 ist einfach ein 'D'. Wenn man die $480C durch $FF0C ersetzt, wird da auch ein BSR.W $0506 draus und es geht zumindest ein Stück weiter.

Stürzt aber nun ab bzw. hängt sich auf wenn man den "WH" Befehl nutzt.....

Und weiter .. ich habs mal (einfach aus verdacht) mit dem alten GP4.3 auf $0000 und ohne Bankboot getestet. Es braucht ewig sobald man den Befehl benutzt und meldet dann, dass der Assemblercode mit dem Stack kollidiert (die Meldungen hat es allerdings mit dem GP7.10 nicht gebracht).

Und im Assemblertext .. ja das "WH 4" wird zu

MOVEQ.L #30000000300000003000000030000000300000003 ...

Das war ebenfalls eine falsche Konstante .. so langsam riecht das nach Absicht .. ein Vergleich auf -100 statt -1 vor einer Schleife, was dann dazu führte, das bei einstelligen Zahlen er nicht 1 Stelle sondern 65536 geschrieben hat.

Jetzt scheint es zu laufen, auch im GP7.10 mit Bankboot und allem.

Ich hab noch lange nicht alles probiert, aber dennoch, falls wer Interesse hat:

gosi.bin

Gruß,
Christian

Moin Christian,

jetzt läuft es auch bei mir

Allerdings stürzt es immernoch ab wenn ich Jados im Hintergrund habe, sprich nur mit GP verlasse. Wenn ich es mit EXIT verlasse läuft Gosi.

-----------------------
Gruß
-=jens=-

Moin Moin,

wenn ich unter Jados den Editorstart auf $9000 lege, klappt es auch ohne Fehler

Jados mag es wohl nicht, wenn der Editor auf $400 beginnt.

-----------------------
Gruß
-=jens=-

Ich frage mich nur, was der Hintergrund war .. es war einmal eine falsche Adresse $480C statt $FF0C und einmal eine Konstante -256 ($FF00) statt -1 ($FFFF). Müde EPROMs würden ja eher Richtung FF kippen und nur an den zwei Stellen?

Theoretische müsste man nun alle Befehle durchtesten.

Übrigens funktioniert es dank der NSA (ernsthaft!). Damit hab ichs disassembled und analysiert:

https://ghidra-sre.org/

Gruß,
Christian

Moin Christian,

die "vermurksten" Bytes brauchen ja nicht am EPROM gelegen haben. Das Programm war ja zwischenzeitlich auch auf mindestens einer Diskette

Na so seltsam ist es mit solcheinem Programm von der NSA ja nicht (scheint ziemlich gut zu sein). Interessanter finde ich da schon ein gehärtetes Debian oder die Entwicklung des "Darknets" (TOR-Browser).

-----------------------
Gruß
-=jens=-

Das Ghidra ist recht okay, es disassembliert erstmal und macht dir dann "Pseudo-C-Code" draus .. erstmal ergibt der wenig Sinn. Ermittelt auch schon Funktionen usw.

Irgendwo fängst dann an, ich hab es bei den Wrappern für die Grundprogrammaufrufe getan. Das aktualisiert dauernd den Pseudo-Code aufgrund dieser Informationen.

Dann siehst eine Schleife mit sowas wie:

L3910:
MOVE.B (A0)+,D0
BEQ.S L3920
BSR PUTCHAR (putchar ruft CO2 auf)
BRA L3910
L3920:
RTS

Das ist natürlich klar ein PUTSTRING .. dann kannst sehen wer alles das PUTSTRING verwendet etc...

Wenn du so Label wie das obige: "s__00004e06" bekommst, ist das gleich verdächtig. Das heißt nämlich sowas wie "er springt das hier als Unterprogramm an aber das tut nix und das RTS finde ich auch nicht". Label in denen er eine Unterprogammstruktur findet heißen "FUN_xxxxx".

Wenn du das bis zum Ende treibst, hast irgendwann C-Code wie wenn er von einem menschlichen Programmierer erstellt wurde.

Als ich den -256 Fehler korrigiert habe, ist es im C-Code auch von einem do while Ungetüm in eine for-loop gesprungen, weil er nach der Korrektur das Muster einer solchen erkannt hat.

Gruß,
Christian

Ich habe jetzt mal die ganzen Beispiele aus dem dicken gelben Buch probiert und bin auf keine weiteren Probleme gestoßen.

Naja außer das mir Fließkommaarithmetik fehlt, aber das ist kein Bug

Vielleicht kann man also die oben gepostete Version irgendwo zentral ablegen?

Ich merke es mal wieder, der NKC ist eine RELATIV gute Hardware (naja DMA fehlt und das Interruptsystem ist verbesserungswürdig aber das ist Folge des Universalbusses .. ich glaube der IM2 vom Z80 ging auch nur eingeschränkt?), aber er leidet wie alle Selbstbaucomputer an nur wenig verfügbarer Software .. beim Z80 sieht es dank CP/M-80 etwas besser aus, aber das ist dann alles textbasiertes Zeug.

Gruß,
Christian