Discussion:
Disassembler für Intel 8088
(zu alt für eine Antwort)
Ralf Kiefer
2021-06-23 18:44:15 UTC
Permalink
Hallo,

ich habe hier ein 4kB-langes Firmware-Image von einem 8088-basierten
Rechner aus den Frühzeiten. Ich möchte zuerst wissen, ob das valider
8088-Code ist, und zweitens, was ungefähr drin steht. Also brauche ich
einen völlig trivialen Disassembler. Der kann online sein, aber besser
unter Windows XP oder Linux laufen. Monster-Pakete wie IDA oder GDB/DDD
sind unhandlich oder im Fall von DDD sogar untauglich. Die können
Millionen Sachen, die ich nicht brauche, aber die ich beachten muß, und
dann kann GDB beispielsweise nicht mal ein ROM-Image einlesen.

Für 8-Bitter gab's Dasm. Für 8-Bitter!

Gibt's Empfehlungen oder Tips?

Gruß, Ralf
Bernd Laengerich
2021-06-23 18:56:17 UTC
Permalink
Post by Ralf Kiefer
Für 8-Bitter gab's Dasm. Für 8-Bitter!
Gibt's Empfehlungen oder Tips?
https://onlinedisassembler.com/odaweb/ ?

Bernd
--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen.
P.Liedermann in defa
Ralf Kiefer
2021-06-23 21:59:09 UTC
Permalink
Post by Bernd Laengerich
https://onlinedisassembler.com/odaweb/ ?
Auf den war ich zuvor bereits gestoßen. Ich hab's nach Deinem Hinweis
intensiver probiert: die Benutzeroberfläche ist *hüstel* "modern", also
untauglich. Ich sehe nicht mal die Möglichkeit die Startadresse des
Codes aus der Binärdatei nachträglich zu ändern. Ich sehe als Ergebnis
ausschließlich Hex-Darstellung, weil er angeblich keinen Code findet.
Ich hab's alternativ mit einem mir bekannten 6502- (taucht nicht mal
richtig in der Liste auf, nur "w65", was immer das sein könnte) und mit
einem 68000-ROM probiert: dasselbe Ergebnis. Der disassembliert nichts.

Die vom SW-Entwickler nach eigenen Vorstellungen gestaltete Oberfläche
erschwert die Bedienung weiter. Das Eingabefeld für Hex-Darstellung
funktioniert nicht wg. Unicode, oder so. Achso, die Online-Hilfe
funktioniert auch nicht.

Aber vielleicht liegt's auch einfach nur am aktuellen Firefox von dieser
Woche, der gleich mal bei einer Ebay-Web-Seite seine Sorgen ausgekotzt
hat und mir ein leeres TAB zeigte. Erwähnte ich schon mal "moderne"
Software ... ?

Gruß, Ralf
Bernd Laengerich
2021-06-24 17:12:33 UTC
Permalink
Post by Ralf Kiefer
einem 68000-ROM probiert: dasselbe Ergebnis. Der disassembliert nichts.
Hmm, habe ihm gerade mal ein Mini-DOS-Programm aus meiner Anfangszeit
vorgeworfen, wurde disassembliert. Siehe
https://onlinedisassembler.com/odaweb/6w8dwIck/0

Zum vergleich noch ein device-driver getestet, da wird der Einsprungspunkt
nicht gefunden. Kurz an einer Stelle kurz hinter dem Anfang (0xff ist kein
gültiger opcode des 8086) mit Rclick data->code umgestellt und es geht auch hier.

https://onlinedisassembler.com/odaweb/rjVgyrJ0/0
Post by Ralf Kiefer
Die vom SW-Entwickler nach eigenen Vorstellungen gestaltete Oberfläche
erschwert die Bedienung weiter. Das Eingabefeld für Hex-Darstellung
funktioniert nicht wg. Unicode, oder so. Achso, die Online-Hilfe
funktioniert auch nicht.
Die Hexeingabe funzt hier, die Onlinehilfe ist nicht verfügbar.

Bernd
Gerald E:scher
2021-06-23 21:06:30 UTC
Permalink
Post by Ralf Kiefer
ich habe hier ein 4kB-langes Firmware-Image von einem 8088-basierten
Rechner aus den Frühzeiten. Ich möchte zuerst wissen, ob das valider
8088-Code ist, und zweitens, was ungefähr drin steht. Also brauche ich
einen völlig trivialen Disassembler.
DEBUG.COM :-)
Post by Ralf Kiefer
Der kann online sein, aber besser
unter Windows XP oder Linux laufen.
Mit XP hast du es bereits, ansonsten in einer VM.
--
Gerald
Andreas Kohlbach
2021-06-23 21:41:08 UTC
Permalink
Post by Gerald E:scher
Post by Ralf Kiefer
ich habe hier ein 4kB-langes Firmware-Image von einem 8088-basierten
Rechner aus den Frühzeiten. Ich möchte zuerst wissen, ob das valider
8088-Code ist, und zweitens, was ungefähr drin steht. Also brauche ich
einen völlig trivialen Disassembler.
DEBUG.COM :-)
Post by Ralf Kiefer
Der kann online sein, aber besser
unter Windows XP oder Linux laufen.
Mit XP hast du es bereits, ansonsten in einer VM.
Ich hatte überlegt, einen Computer zu emulieren, der einen 8088 oder
wahrscheinlicher, Z80 hat. Das CP/M Kommando DDT sollte das können.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Ralf Kiefer
2021-06-23 22:08:04 UTC
Permalink
Post by Andreas Kohlbach
Ich hatte überlegt, einen Computer zu emulieren, der einen 8088 oder
wahrscheinlicher, Z80 hat. Das CP/M Kommando DDT sollte das können.
Z80 und 8088 unterscheiden sich nach meinem Kenntnisstand doch
erheblich. So hat der Z80 64kB Adreßraum, aber der 8088 spielt mit
seinen Segmentadressen rum und kann sogar mehr als 640kB adressieren :-)

Gruß, Ralf
Andreas Kohlbach
2021-06-24 02:24:16 UTC
Permalink
Post by Ralf Kiefer
Post by Andreas Kohlbach
Ich hatte überlegt, einen Computer zu emulieren, der einen 8088 oder
wahrscheinlicher, Z80 hat. Das CP/M Kommando DDT sollte das können.
Z80 und 8088 unterscheiden sich nach meinem Kenntnisstand doch
erheblich. So hat der Z80 64kB Adreßraum, aber der 8088 spielt mit
seinen Segmentadressen rum und kann sogar mehr als 640kB adressieren :-)
Mist, ich hatte 8080 statt 8088 (hätte man nicht 8086 schreiben können,
dass auch mir das aufgefallen wäre? ;-) gelesen.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Hermann Riemann
2021-06-24 06:11:17 UTC
Permalink
Post by Ralf Kiefer
Post by Andreas Kohlbach
Ich hatte überlegt, einen Computer zu emulieren, der einen 8088 oder
wahrscheinlicher, Z80 hat. Das CP/M Kommando DDT sollte das können.
Z80 und 8088 unterscheiden sich nach meinem Kenntnisstand doch
erheblich.
Der 8088 kann den Assembler vom 8080 noch verstehen.
Der opcode ist nicht kompatibel.
Post by Ralf Kiefer
So hat der Z80 64kB Adreßraum, aber der 8088 spielt mit
seinen Segmentadressen rum und kann sogar mehr als 640kB adressieren :-)
Es gibt noch viel mehr Unterschiede.

Hermann
der sich ( nicht sicher) an 16 32 bit Umschaltbefehl bei 386 erinnert
und nicht weiß, wie die Umschaltung von und zu 64 bit funktioniert.
Und was passiert, wenn bei alter 1 MB Adressierung
mittel Register + displacement die 1 Megabitgrenze
auf modernen CPUs überschritten wird ( A20 gate?)
--
http://www.hermann-riemann.de
Gerald E:scher
2021-06-24 00:32:22 UTC
Permalink
Post by Andreas Kohlbach
Post by Gerald E:scher
Mit XP hast du es bereits, ansonsten in einer VM.
Ich hatte überlegt, einen Computer zu emulieren, der einen 8088 oder
Eine VM, in der [M$-|DR-|Free]DOS läuft. Der IBM PC/XT hatte einen 8088
drin.
--
Gerald
Ralf Kiefer
2021-06-23 21:59:08 UTC
Permalink
Post by Gerald E:scher
Mit XP hast du es bereits, ansonsten in einer VM.
Ich habe ein ROM-Image aus dem EPROM-Programmiergerät. Und es soll
8088-Code sein, nicht irgendwelcher. Ich kenne mich mit dem ganzen
Intel-Zeug kein bißchen aus. Ich kenne keine Unterschiede zwischen 8088
und dem Code von dem AMD-Chip, der in diesem PC läuft.

Meine "prähistorische" Erwartung: ich werfe das ROM-Image einer wie auch
immer gearteten Software hin und erhalte eine Textdatei, die ich durch
einen Assembler jagen könnte, um wieder das Ausgangsprodukt zu erhalten.
Nicht mehr, nicht weniger. Der Text, der mich dabei interessiert,
enthält exakt nur 8088-Mnemmonics oder DC.B-Statements, damit ich
erkennen kann, ob das EPROM vergeßlich war, oder um Datenbereiche zu
finden. Um den Assemblertext aufzuhübschen, möchte ich dem Disassembler
Hilfestellungen mitgeben können, z.B. Datenbereiche, Strings, Tabellen
beschreiben, damit die im Text geeignet dargestellt werden. Und ich
möchte Labels definieren können, damit der Text verständlich wird.

Eigentlich(!) die Basis eines normalen Disassemblers. Der DASMx 1.4
konnte das für 8-Bitter. Mein eigener 8-Bit-Disassembler kann das auch,
nur etwas ausführlicher. D.h. ich weiß, daß das keine
Raketenwissenschaft ist. Ich habe nur gerade keine Lust einen
16-bit-Disassembler zu schreiben, weil ich einmal in meinem Leben 4kB
8088-Code als Text anschauen möchte.

Sorry, daß ich gerade etwas sauer bin, aber ich verbringe mit meiner
Fragestellung wg. 4kB Code bereits etliche Stunden ohne einen Erfolg mit
"moderner" Software in Aussicht zu sehen.

Gruß, Ralf
Gerald E:scher
2021-06-24 00:27:12 UTC
Permalink
Post by Ralf Kiefer
Post by Gerald E:scher
Mit XP hast du es bereits, ansonsten in einer VM.
Ich schränke ein, es darf kein 64-bitiges XP sein.
Post by Ralf Kiefer
Ich habe ein ROM-Image aus dem EPROM-Programmiergerät. Und es soll
8088-Code sein, nicht irgendwelcher.
Das ist mir bewusst.
Post by Ralf Kiefer
Ich kenne mich mit dem ganzen
Intel-Zeug kein bißchen aus.
Dann informiere dich bitte, insbesonders darüber, dass Intel- und
AMD-Prozessoren bis zum Erbrechen rückwärtskompatibel sind.
Post by Ralf Kiefer
Ich kenne keine Unterschiede zwischen 8088
und dem Code von dem AMD-Chip, der in diesem PC läuft.
Auch modernste x86-Prozessoren können, solange kein 64-bit-Betrübssystem
läuft, im V86-Modus 8086-Code ausführen. OS/2 Warp beherrscht es in
Perfektion, das kann darin Windoof 3.1 ausführen.
Ein 8088 unterscheidet sich vom 8086 durch kaum mehr als seinem
8-bit-Bus statt 16 bit beim 8086.
Post by Ralf Kiefer
Sorry, daß ich gerade etwas sauer bin, aber ich verbringe mit meiner
Fragestellung wg. 4kB Code bereits etliche Stunden ohne einen Erfolg mit
"moderner" Software in Aussicht zu sehen.
Ich verstehe dein Problem nicht. Vor umzig Jahren habe ich aus
sportlichem Ergeiz mit DEBUG.COM das damals beliebte Vienna-Virus
disassembliert, das sollte auch mit deinen ROM-Code möglich sein.
--
Gerald
Ralf Kiefer
2021-06-24 09:15:39 UTC
Permalink
Post by Gerald E:scher
Auch modernste x86-Prozessoren können, solange kein 64-bit-Betrübssystem
läuft, im V86-Modus 8086-Code ausführen.
Das ist mir klar. Aber mit jeder Prozessorgeneration kamen neue Befehle
dazu, die ein 8088/8086 nicht beherrscht. Wenn die auftauchen, dann ist
das im Sinne eines heutigen Intel-/AMD-Chips gültiger Code, aber im Fall
der Uralt-8088-Hardware vermutlich ein EPROM-Fehler.

Gruß, Ralf
Gerald E:scher
2021-06-24 14:24:56 UTC
Permalink
Post by Ralf Kiefer
Post by Gerald E:scher
Auch modernste x86-Prozessoren können, solange kein 64-bit-Betrübssystem
läuft, im V86-Modus 8086-Code ausführen.
Das ist mir klar. Aber mit jeder Prozessorgeneration kamen neue Befehle
dazu, die ein 8088/8086 nicht beherrscht. Wenn die auftauchen, dann ist
das im Sinne eines heutigen Intel-/AMD-Chips gültiger Code,
Nein, ein Debugger, der im zum 8086 kompatiblen Real-Mode Befehle für
den Protected-Mode von 80286 und später als gültigen Code anerkennt,
wäre kaputt.
Und bei DEBUG.COM von M$-DOS kannst du dir sicher sein, dass der nichts
anderes als Befehle für den 8086 kann. Willst du anscheinend aber
nicht.
--
Gerald
Kay Martinen
2021-06-24 17:27:49 UTC
Permalink
Post by Ralf Kiefer
Post by Gerald E:scher
Auch modernste x86-Prozessoren können, solange kein 64-bit-Betrübssystem
läuft, im V86-Modus 8086-Code ausführen.
Laufen die nicht eh im echten Realmode an - den man später nur zum V86
Modus umdeklarierte. Den gibt es m.E. auch erst seit dem 386.

Die Unterschiede mögen subtil sein. Ich meine Realmode ist ab BIOS-Start
aktiv, V86-Mode kann es im Protected Mode IMHO mehrfach geben, den RM nicht.
Post by Ralf Kiefer
Das ist mir klar. Aber mit jeder Prozessorgeneration kamen neue Befehle
dazu, die ein 8088/8086 nicht beherrscht. Wenn die auftauchen, dann ist
das im Sinne eines heutigen Intel-/AMD-Chips gültiger Code, aber im Fall
der Uralt-8088-Hardware vermutlich ein EPROM-Fehler.
Du übersiehst da glaub ich was. Du willst das EPROM Image doch nicht auf
einer neuen CPU ausführen - sondern lediglich von einem Programm
disassemblieren lassen. Da sollte es nur wichtig sein das dein Programm
der wahl die Eingabe-daten auch als 8088 oder 8086 Code verhackstückt.

Und selbst wenn du es ausführtest (ggf. mit Breakpoints): Eine aktuelle
CPU sollte im REAL Mode keine erweiterten oder neueren Befehle
ausführen. Wenn doch ist sie; oder das Design; kaputt... öhm... Tja.
Schlechtes Beispiel bei all den Mitigations. :-)

IMHO war aber noch keine dabei mit der man aus dem Real-Mode
"ausbrechen" könnte. Außer über den "offiziellen Weg" also vorbereiten
der Datenstrukturen (GDT, LDT, IDT u.s.w.) und sprung in den Protected
Mode(code). Ein Programm für einen 8088 wird diese Befehle aber weder
kennen noch nutzen!

Kennst du denn die Adresslage des EPROMs und einen Startpunkt darin?
Wird ja nicht ein einziges Großes Programm sein sondern vermutlich
diverse Subroutingen und Interrupt-Handler enthalten.

Die Startvektoren am Ende hast du wohl schon wie ich nebenan erlas.
Denkbar wäre noch das das echte System die Adressen nicht komplett
dekodiert was; wie IMHO bei CEPACs; zur Folge hätte das an verschiedenen
Adressen "Geisterkopien" des ROMs erscheinen. Dann ist die Frage ob der
Code davon gebrauch macht und ein Sprung nicht unbedingt in die oberen
4kB führen muß.


Kay
--
Posted via leafnode
Gerald E:scher
2021-06-24 21:58:24 UTC
Permalink
Post by Kay Martinen
Post by Gerald E:scher
Auch modernste x86-Prozessoren können, solange kein 64-bit-Betrübssystem
läuft, im V86-Modus 8086-Code ausführen.
Laufen die nicht eh im echten Realmode an -
Ja, tun sie noch immer.
Post by Kay Martinen
den man später nur zum V86
Modus umdeklarierte.
Nicht ganz. Der V86 virtualisiert den Real-Mode innerhalb des
Protected Mode.
https://de.wikipedia.org/wiki/Virtual_8086_Mode
Post by Kay Martinen
Den gibt es m.E. auch erst seit dem 386.
Ja. Die 80286 können, sobald sie in den Proteced Mode geschaltet sind,
nur mehr mit Verrenkungen in den Real Mode zurück, um z.B. ein
DOS-Programm auszuführen. OS/2 1.x konnte davon ein Lied singen.
--
Gerald
Stefan Reuther
2021-06-24 16:12:57 UTC
Permalink
Post by Ralf Kiefer
Post by Gerald E:scher
Mit XP hast du es bereits, ansonsten in einer VM.
Ich habe ein ROM-Image aus dem EPROM-Programmiergerät. Und es soll
8088-Code sein, nicht irgendwelcher. Ich kenne mich mit dem ganzen
Intel-Zeug kein bißchen aus. Ich kenne keine Unterschiede zwischen 8088
und dem Code von dem AMD-Chip, der in diesem PC läuft.
[...]> Um den Assemblertext aufzuhübschen, möchte ich dem Disassembler
Post by Ralf Kiefer
Hilfestellungen mitgeben können, z.B. Datenbereiche, Strings, Tabellen
beschreiben, damit die im Text geeignet dargestellt werden. Und ich
möchte Labels definieren können, damit der Text verständlich wird.
Es gab ein Tool namens "Sourcer", auf das diese Beschreibung passen
könnte. archive.org hat immerhin die Doku davon:
https://archive.org/details/SOURCERCOMMENTINGDISASSEMBLER/mode/2up?view=theater

Und hier ein paar Screenshots:
https://corexor.wordpress.com/2015/12/09/sourcer-and-windows-source/
Post by Ralf Kiefer
Sorry, daß ich gerade etwas sauer bin, aber ich verbringe mit meiner
Fragestellung wg. 4kB Code bereits etliche Stunden ohne einen Erfolg mit
"moderner" Software in Aussicht zu sehen.
Also bei schlappen 4k würde ich zumindest nicht tagelang nach einem Tool
jagen, das mir das ganze mundgerecht bereitlegt. Die paar
Assemblerbefehle sollten sich auch mit einem dummen Disassembler
rekonstruieren und manuell sortieren lassen (BTDTST).

Als dummer Disassembler taugt auch das ganz normale 'objdump' aus den
GNU binutils, man braucht also keinen alten PC mit debug.com:

objdump --disassemble-all -b binary -m i8086 file.com

Bei einem EPROM-Image wäre ich aber nicht mal davon überzeugt, dass das
tatsächlich ausführbaren Code enthält. Ist da nicht vielleicht noch ein
bestimmtes Framing drin? Oder ein mehrstufiger Lader?

Auch ist "ein Disassembler bekommt was syntaktisch korrektes raus" nur
ein schwaches Indiz, ob der EPROM vergesslich war oder nicht. Ein
gekipptes Bit macht halt aus einem 'jne' ein 'je', aus einem 'inc' ein
'dec', oder aus einem 'add' ein 'or'.


Stefan
Gerald E:scher
2021-06-24 22:08:50 UTC
Permalink
Post by Stefan Reuther
Als dummer Disassembler taugt auch das ganz normale 'objdump' aus den
Einen alten PC braucht man ohnehin nicht. IBMDOS 3.3 samt DEBUG.COM,
das garantiert nur ächte 8086-Befehle kennt, lässt sich in VirtualBox
ausführen. BTDT
Zudem lässt sich DOS auch auf modernen PCs bootem, wenn auch ohne
Floppy-Laufwerk und wegen Beschränkungen bei Festplattengrößen etwas
mühsam. FreeDOS sollte auf jeden Fall gehen.
--
Gerald
Ralf Kiefer
2021-06-23 22:34:28 UTC
Permalink
Post by Ralf Kiefer
Ich möchte zuerst wissen, ob das valider
8088-Code ist
Ich hab's jetzt von Hand probiert. Ganz 1970er ;-)

Ich fürchte, daß das EPROM bereits vergeßlich war, denn im hinteren
Bereich sieht es so aus:
<www.ralf-kiefer.de/A2/EPROM.gif>

Nach meinem kurz angelesenen Verständnis vom 8088 steht typischerweise
ab $0FF0 ein JMP-Befehl als 1.Befehl nach dem Reset, d.h. codiert
0xE9..0xEB oder 0xFF. Hier nicht.

Bliebe als letzte Idee, daß beim EPROM entweder die Datenleitungen
und/oder die Adreßleitungen "verwürfelt" angeschlossen sind, und ich den
EPROM-Inhalt zuvor zurechtsortieren muß. Das wäre nicht der erste Fall,
wo ich sowas aus den frühen 1980er Jahren mitbekommen hätte. Mal
durchpiepsen ...

Gruß, Ralf
Nils M Holm
2021-06-24 07:50:36 UTC
Permalink
Nach meinem kurz angelesenen Verstaendnis vom 8088 steht typischerweise
ab $0FF0 ein JMP-Befehl als 1.Befehl nach dem Reset, d.h. codiert
0xE9..0xEB oder 0xFF. Hier nicht.
Der reset vector des 808[86] ist FFFF:0 (physisch FFFF0). E9 und EB
sind intra-segment jumps (16-bit). EA waere ein inter-segment jump.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Markus Elsken
2021-06-24 09:08:11 UTC
Permalink
Moin!
Post by Ralf Kiefer
Bliebe als letzte Idee, daß beim EPROM entweder die Datenleitungen
und/oder die Adreßleitungen "verwürfelt" angeschlossen sind, und ich den
EPROM-Inhalt zuvor zurechtsortieren muß. Das wäre nicht der erste Fall,
wo ich sowas aus den frühen 1980er Jahren mitbekommen hätte.
Kenne ich aus dem ELKA Synthex, wurde gerne als Kopierschutz verwendet.

mfg Markus
Ralf Kiefer
2021-06-24 09:24:47 UTC
Permalink
Post by Markus Elsken
Kenne ich aus dem ELKA Synthex, wurde gerne als Kopierschutz verwendet.
... oder weil kein Platz für eine andere Anordnung der Leiterbahnen auf
der zweilagigen Platine war. Das hatten wir vor ein paar Monaten bei
z.B. Seriell- und Parallelkarten für den Applebus herausgefunden, die
als Herkunft das Kürzel NPARA(2) tragen.

Gruß, Ralf
Hermann Riemann
2021-06-24 06:03:43 UTC
Permalink
Post by Ralf Kiefer
ich habe hier ein 4kB-langes Firmware-Image von einem 8088-basierten
Rechner aus den Frühzeiten. Ich möchte zuerst wissen, ob das valider
8088-Code ist, und zweitens, was ungefähr drin steht. Also brauche ich
einen völlig trivialen Disassembler. Der kann online sein, aber besser
unter Windows XP oder Linux laufen.
Ich würde aus dem hexdump nach
http://www.mlsite.net/8086/
nach (Unterprogramm) Sprungbefehle suchen,
und beim Zielen nachschauen,
ob da ein gültiger opcode steht.
Befehle sind unterschiedlich lang.

Bei kleineren codestücken,
würde ich von Hand disassemblieren, sonst
http://www.mlsite.net/blog/?p=58
meinen Bedürfnissen anpassen.

Hermann
der früher viel Z80 6502 hex codiert
und mit eigenen Disassembler ausgedruckt hat.
--
http://www.hermann-riemann.de
Peter Heitzer
2021-06-24 07:37:32 UTC
Permalink
Post by Ralf Kiefer
Hallo,
ich habe hier ein 4kB-langes Firmware-Image von einem 8088-basierten
Rechner aus den Frühzeiten. Ich möchte zuerst wissen, ob das valider
8088-Code ist, und zweitens, was ungefähr drin steht. Also brauche ich
einen völlig trivialen Disassembler. Der kann online sein, aber besser
unter Windows XP oder Linux laufen. Monster-Pakete wie IDA oder GDB/DDD
sind unhandlich oder im Fall von DDD sogar untauglich. Die können
Millionen Sachen, die ich nicht brauche, aber die ich beachten muß, und
dann kann GDB beispielsweise nicht mal ein ROM-Image einlesen.
Für 8-Bitter gab's Dasm. Für 8-Bitter!
Gibt's Empfehlungen oder Tips?
Ist zwar auch ein grosses Paket aber IMO recht brauchbar.
ghidra (https://ghidra-sre.org/)
Das ist ein Reverse Engineering Tool der NSA Labs.
Braucht eine neuere Java JDK, aber ist recht flott. Eingebaut sind
Codeanalyser und Disassembler für viele CPUs, darunter auch Z80, 6502
oder auch 8096. x86 realmode natürlich auch. Dem Teil kann man einen
Binärklumpen oder auch ein Hexfile vorwerfen.

Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Olaf Schmitt
2021-06-24 21:06:04 UTC
Permalink
Post by Ralf Kiefer
Hallo,
ich habe hier ein 4kB-langes Firmware-Image von einem 8088-basierten
Rechner aus den Frühzeiten. Ich möchte zuerst wissen, ob das valider
8088-Code ist, und zweitens, was ungefähr drin steht. Also brauche ich
einen völlig trivialen Disassembler. Der kann online sein, aber besser
unter Windows XP oder Linux laufen. Monster-Pakete wie IDA oder GDB/DDD
sind unhandlich oder im Fall von DDD sogar untauglich. Die können
Millionen Sachen, die ich nicht brauche, aber die ich beachten muß, und
dann kann GDB beispielsweise nicht mal ein ROM-Image einlesen.
Für 8-Bitter gab's Dasm. Für 8-Bitter!
Gibt's Empfehlungen oder Tips?
Ich habe früher den da benutzt:
8086 Assembly Debugging with AFD - Advance Full Screen Debug

War immer sher hilfreich.
Aber woher man den noch bekommen kann, weiß ich leider nicht.
Das Programm hieß AFD.EXE

mfg
Olaf
Olaf Schmitt
2021-06-24 21:20:57 UTC
Permalink
Nachtrag.
Ich habe das File auf einem alten Image gefunden.
Ist 75MB groß.
Läuft nicht unter meinem 64Bit Windows.
Aber ich bin mir sicher, dass ich es früher unter WIN_NT benutzt habe.

Könnte ich dir zusenden.

Olaf

Da ist auch noch was über den zu lesen:
<https://wetolearn.blogspot.com/2013/09/8086-assembly-debugging-with-afd.html>
Wolf gang P u f f e
2021-06-26 07:41:15 UTC
Permalink
Post by Olaf Schmitt
Nachtrag.
Ich habe das File auf einem alten Image gefunden.
Ist 75MB groß.
Läuft nicht unter meinem 64Bit Windows.
Aber ich bin mir sicher, dass ich es früher unter WIN_NT benutzt habe.
Könnte ich dir zusenden.
Olaf
<https://wetolearn.blogspot.com/2013/09/8086-assembly-debugging-with-afd.html>
Geil. Einzelschrittbetrieb und Live-Registeranzeige.
Sowas hätte ich mir vor 25 Jahren gewünscht.
Statt dessen hatte ich mich damals Blind und auf Knien rutschend im
steinigen Code bewegt. Da wurde mittels Debug.com, TASM, Batchdateien,
selbst erstellten Qbasic-Hilfsprogrammen und nach der Versuch+Error-
Methode irgendwie "rumgebastelt". :-)
Hermann Riemann
2021-06-26 08:49:38 UTC
Permalink
Post by Wolf gang P u f f e
Post by Olaf Schmitt
Nachtrag.
Ich habe das File auf einem alten Image gefunden.
Ist 75MB groß.
Läuft nicht unter meinem 64Bit Windows.
Aber ich bin mir sicher, dass ich es früher unter WIN_NT benutzt habe.
Könnte ich dir zusenden.
Olaf
<https://wetolearn.blogspot.com/2013/09/8086-assembly-debugging-with-afd.html>
Geil. Einzelschrittbetrieb und Live-Registeranzeige.
Ich habe eher Maschinencodetrace verwendet
Post by Wolf gang P u f f e
Sowas hätte ich mir vor 25 Jahren gewünscht.
1996.
da hatte ich privat DX4 100 CPU 64 MB RAM insgesamt 11 GB Festplatten.
+ SCSI CD Laufwerk + 1 8? fach anderes CD-Laufwerk +
80 MB Syquest SCSI Wechselplatte.
OS/2, windows 95, Linux SuSE 4.2 -> 4.3 Anfangs noch mit X Oberfläche.
Drucker HP1200 CPS

Ich experimentierte vielleicht noch in OS/2 mit C++.
vielleicht war auch da der Versuch,
in windows mit 32 bit Visual C zu machen,
und die Entscheidung zurück von C++ auf C unter Linux.
Post by Wolf gang P u f f e
Statt dessen hatte ich mich damals Blind und auf Knien rutschend im
steinigen Code bewegt. Da wurde mittels Debug.com, TASM, Batchdateien,
selbst erstellten Qbasic-Hilfsprogrammen und nach der Versuch+Error-
Methode irgendwie "rumgebastelt". :-)
code selber habe ich auf mainframes und 8 Bit Systemen analysiert.
Bei C habe ich stattdessen mit printf gearbeitet.

Heutzutage verwende ich für Fehlersuche immer noch print,
oder schreibe Zwischenwerte in html Dateien,
wo ich dann oft gut Fehler erkennen kann.

Hermann
seit etliche Jahrzehnten nach Programmierfehler suchend.
--
http://www.hermann-riemann.de
Wolf gang P u f f e
2021-06-26 09:42:22 UTC
Permalink
Post by Hermann Riemann
Post by Wolf gang P u f f e
Post by Olaf Schmitt
Nachtrag.
Ich habe das File auf einem alten Image gefunden.
Ist 75MB groß.
Läuft nicht unter meinem 64Bit Windows.
Aber ich bin mir sicher, dass ich es früher unter WIN_NT benutzt habe.
Könnte ich dir zusenden.
Olaf
<https://wetolearn.blogspot.com/2013/09/8086-assembly-debugging-with-afd.html>
Geil. Einzelschrittbetrieb und Live-Registeranzeige.
Ich habe eher Maschinencodetrace verwendet
Post by Wolf gang P u f f e
Sowas hätte ich mir vor 25 Jahren gewünscht.
1996.
da hatte ich privat DX4 100 CPU 64 MB RAM insgesamt 11 GB Festplatten.
+ SCSI CD Laufwerk + 1 8? fach anderes CD-Laufwerk +
80 MB Syquest SCSI Wechselplatte.
OS/2, windows 95, Linux SuSE 4.2 -> 4.3 Anfangs noch mit X Oberfläche.
Drucker HP1200 CPS
Ich experimentierte vielleicht noch in OS/2 mit C++.
vielleicht war auch da der Versuch,
in windows mit 32 bit Visual C zu machen,
und die Entscheidung zurück von C++ auf C unter Linux.
Post by Wolf gang P u f f e
Statt dessen hatte ich mich damals Blind und auf Knien rutschend im
steinigen Code bewegt. Da wurde mittels Debug.com, TASM, Batchdateien,
selbst erstellten Qbasic-Hilfsprogrammen und nach der Versuch+Error-
Methode irgendwie "rumgebastelt". :-)
code selber habe ich auf mainframes und 8 Bit Systemen analysiert.
Bei C habe ich stattdessen mit printf gearbeitet.
Heutzutage verwende ich für Fehlersuche immer noch print,
oder schreibe Zwischenwerte in html Dateien,
wo ich dann oft gut Fehler erkennen kann.
Hermann
seit etliche Jahrzehnten nach Programmierfehler suchend.
Ich hatte damals nur nur hobbiemäßig mal ein paar Dinge, wo ich mit
Assembler oder auch direkt im Hex-Code etwas versucht hatte.
Ich hatte mir einige Tools gebastelt, wo man den Bootsektor von
Festplatten beliebig ändern konnte. (Stichwort Bootmanger MSDOS,
NWDOS, OS/2)
U.A. war auch eine Motivation, Guthabendisketten von Videodat
kopieren/erstellen zu können. 3,5"Disketten mit geldwertem Guthaben.
Videodat war irgendein Dienst, wo Software über ein Fernsehsignal
verbreitet wurde. Mit einem Decoder am Scartanschluss des TV-Gerätes
konnte man da die Inhalte aus dem Datenstrom dekodieren.
https://de.wikipedia.org/wiki/Channel_Videodat
Interessantes kostete aber Geld, dass man in den Kauf von diesen
Guthabendisketten investieren musste, und von der jeder Download
als Guthaben abgebucht wurde.
Aus offensichtlichem Grund ließ sich diese Diskette nicht einfach
kopieren. Logisch! ;-)
Auch die üblichen Kopierschutztools gingen irgendwie nicht.
Und da hatte ich mich an der direkten Programmierung des
Diskettencontrollers versucht. Als mir dann das Kopieren "unter
Laborbedingungen" gelang, war der Dienst bereits eingestellt worden.
Die Laborbedingungen bestanden aus dem jonglieren verschiedener kleiner
Programme, die ich mittels DEBUG, TASM und QBASIC erstellt und durch
Batchdateien verknüpft hatte.
Heute habe ich keinen Schimmer mehr, wie das damals alles genau
funktionierte.
Hermann Riemann
2021-06-26 18:21:12 UTC
Permalink
Post by Wolf gang P u f f e
Post by Hermann Riemann
Post by Wolf gang P u f f e
Post by Olaf Schmitt
Nachtrag.
Ich habe das File auf einem alten Image gefunden.
Ist 75MB groß.
Läuft nicht unter meinem 64Bit Windows.
Aber ich bin mir sicher, dass ich es früher unter WIN_NT benutzt habe.
Könnte ich dir zusenden.
Olaf
<https://wetolearn.blogspot.com/2013/09/8086-assembly-debugging-with-afd.html>
Geil. Einzelschrittbetrieb und Live-Registeranzeige.
Ich habe eher Maschinencodetrace verwendet
Post by Wolf gang P u f f e
Sowas hätte ich mir vor 25 Jahren gewünscht.
1996.
da hatte ich privat DX4 100 CPU 64 MB RAM insgesamt 11 GB Festplatten.
+  SCSI CD Laufwerk + 1 8? fach anderes CD-Laufwerk +
80 MB Syquest SCSI Wechselplatte.
OS/2, windows 95, Linux SuSE 4.2 -> 4.3 Anfangs noch mit X Oberfläche.
Drucker HP1200 CPS
Ich experimentierte vielleicht noch in OS/2 mit C++.
vielleicht war auch da der Versuch,
  in windows mit 32 bit Visual C zu machen,
und die Entscheidung zurück von C++ auf C unter Linux.
Post by Wolf gang P u f f e
Statt dessen hatte ich mich damals Blind und auf Knien rutschend im
steinigen Code bewegt. Da wurde mittels Debug.com, TASM, Batchdateien,
selbst erstellten Qbasic-Hilfsprogrammen und nach der Versuch+Error-
Methode irgendwie "rumgebastelt". :-)
code selber habe ich auf mainframes und 8 Bit Systemen analysiert.
Bei C habe ich stattdessen mit printf gearbeitet.
Heutzutage verwende ich für Fehlersuche immer noch print,
oder schreibe Zwischenwerte in html Dateien,
wo ich dann oft gut Fehler erkennen kann.
Hermann
    seit etliche Jahrzehnten nach Programmierfehler suchend.
Ich hatte damals nur nur hobbiemäßig mal ein paar Dinge, wo ich mit
Assembler oder auch direkt im Hex-Code etwas versucht hatte.
Beruflich hatte ich gelegentlich Assembler für Maschinentyp
IBM 360 verwendet.

Privat hexcode nur bei 8-bit CPUs

Beim Atari ST hatte ich ST Pascal und GST Assembler.
Die ließen sich nicht zusammenbinden.

Um von ST Pascal aus Assembler zu zu benutzen,
habe ich das Assembler Programm resistent,
und die Schnittstelle
hinter dem Bildschirmbereich kopiert,
und Adressen angepasst.

In Pascal habe ich dann mit internen indirekten? Unterprogramm
Ansprüngen irgendwie 2 Parameter angegebe,
der erste war die Adresse hinter dem Bidschimbereich
der zweite eine Struktur als Argumentliste für
den Assembler.
Im Assembler konnte ich durch Stackpointertausch erreichen,
das die Programm Ansprünge in Pascal
einen anderen verlauf hatten.
( Ein Programm rein, aus einem anderen Programm wieder raus.)
Post by Wolf gang P u f f e
Ich hatte mir einige Tools gebastelt, wo man den Bootsektor von
Festplatten beliebig ändern konnte. (Stichwort Bootmanger MSDOS,
NWDOS, OS/2)
Bootsektor habe ich nie direkt modifiziert.
OS/2 hatte noch einen guten boot Manager.
Was sonst gut war, müsste ich überlegen.

Im Gegensatz zu windows 95 konnte ich mit
OS/2 noch den MS-Flugsimulator verwenden.

Hermann
der wenn er sich in der Vergangenheit beraten könnte,
die Empfehlungen geben würde,
Atari ST bis zum Erscheinen von SuSE 4.2 noch zu behalten,
OS/2, DOS und windows zu vermeiden.
Das hätte ihm viel Zeit erspart.
--
http://www.hermann-riemann.de
Stefan Reuther
2021-06-27 06:57:35 UTC
Permalink
Post by Wolf gang P u f f e
Post by Olaf Schmitt
Nachtrag.
Ich habe das File auf einem alten Image gefunden.
Ist 75MB groß.
Läuft nicht unter meinem 64Bit Windows.
Aber ich bin mir sicher, dass ich es früher unter WIN_NT benutzt habe.
[...]
Post by Wolf gang P u f f e
Post by Olaf Schmitt
<https://wetolearn.blogspot.com/2013/09/8086-assembly-debugging-with-afd.html>
Geil. Einzelschrittbetrieb und Live-Registeranzeige.
Sowas hätte ich mir vor 25 Jahren gewünscht.
Turbo Debugger?

Hatte ich eher als afd, und damit sah afd von vornherein altmodisch aus.
(Laut Dateidatum ist afd allerdings von 1985 und damit dem Turbo
Debugger etwas voraus.)


Stefan
Marcel Mueller
2021-06-27 09:55:11 UTC
Permalink
Post by Ralf Kiefer
Gibt's Empfehlungen oder Tips?
Ich hätte jetzt nasm (bzw. ndisasm) genommen. Der disassembliert so
ziemlich alles, was irgendwie auf x86 beruht (wozu ja auch der 8088 zählt).


Marcel

Lesen Sie weiter auf narkive:
Loading...