Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Disassembler für Intel 8088
60 views
Skip to first unread message
Bernd Laengerich
Jun 23, 2021, 2:56:19 PM6/23/21
to
Am 23.06.2021 um 20:44 schrieb 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
> 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
Gerald E:scher
Jun 23, 2021, 5:06:32 PM6/23/21
to
Ralf Kiefer schrieb am 23/6/2021 20:44:
> 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 :-)
> Der kann online sein, aber besser
> unter Windows XP oder Linux laufen.
Mit XP hast du es bereits, ansonsten in einer VM.
--
Gerald
> 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 :-)
> 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
Jun 23, 2021, 5:41:10 PM6/23/21
to
wahrscheinlicher, Z80 hat. Das CP/M Kommando DDT sollte das können.
--
Andreas
PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Gerald E:scher
Jun 23, 2021, 8:27:13 PM6/23/21
to
Ralf Kiefer schrieb am 23/6/2021 23:59:
> Gerald E:scher wrote:
>
>> Mit XP hast du es bereits, ansonsten in einer VM.
Ich schränke ein, es darf kein 64-bitiges XP sein.
> Ich habe ein ROM-Image aus dem EPROM-Programmiergerät. Und es soll
> 8088-Code sein, nicht irgendwelcher.
Das ist mir bewusst.
> 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.
> 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.
> 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
> Gerald E:scher wrote:
>
>> 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.
Das ist mir bewusst.
> 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.
> 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.
> 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
Gerald E:scher
Jun 23, 2021, 8:32:23 PM6/23/21
to
Andreas Kohlbach schrieb am 23/6/2021 23:41:
> On 23 Jun 2021 21:06:30 GMT, Gerald E:scher wrote:
>>
>> 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
> On 23 Jun 2021 21:06:30 GMT, Gerald E:scher wrote:
>>
>> Mit XP hast du es bereits, ansonsten in einer VM.
>
> Ich hatte überlegt, einen Computer zu emulieren, der einen 8088 oder
drin.
--
Gerald
Hermann Riemann
Jun 24, 2021, 2:03:44 AM6/24/21
to
Am 23.06.21 um 20:44 schrieb 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
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
> 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
> 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
Hermann Riemann
Jun 24, 2021, 2:11:18 AM6/24/21
to
Am 24.06.21 um 00:08 schrieb Ralf Kiefer:
> erheblich.
Der 8088 kann den Assembler vom 8080 noch verstehen.
Der opcode ist nicht kompatibel.
> 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
> Andreas Kohlbach wrote:
>
>> 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
>
>> Ich hatte überlegt, einen Computer zu emulieren, der einen 8088 oder
>> wahrscheinlicher, Z80 hat. Das CP/M Kommando DDT sollte das können.
> erheblich.
Der 8088 kann den Assembler vom 8080 noch verstehen.
Der opcode ist nicht kompatibel.
> 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
Peter Heitzer
Jun 24, 2021, 3:37:34 AM6/24/21
to
Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>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, peter....@rz.uni-regensburg.de
>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
>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?
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, peter....@rz.uni-regensburg.de
Markus Elsken
Jun 24, 2021, 5:08:13 AM6/24/21
to
Moin!
Am 24.06.21 um 00:34 schrieb 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
Am 24.06.21 um 00:34 schrieb 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
Gerald E:scher
Jun 24, 2021, 10:24:58 AM6/24/21
to
Ralf Kiefer schrieb am 24/6/2021 11:15:
> Gerald E:scher wrote:
>
>> 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
> Gerald E:scher wrote:
>
>> Auch modernste x86-Prozessoren können, solange kein 64-bit-Betrübssystem
>> läuft, im V86-Modus 8086-Code ausführen.
>
> 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
Stefan Reuther
Jun 24, 2021, 12:16:48 PM6/24/21
to
Am 23.06.2021 um 23:59 schrieb Ralf Kiefer:
> Intel-Zeug kein bißchen aus. Ich kenne keine Unterschiede zwischen 8088
> 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/
> 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 wrote:
>> Mit XP hast du es bereits, ansonsten in einer VM.
>
>> 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
> 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/
> 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.
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
Bernd Laengerich
Jun 24, 2021, 1:12:35 PM6/24/21
to
Am 23.06.2021 um 23:59 schrieb 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
> 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
Kay Martinen
Jun 24, 2021, 1:30:07 PM6/24/21
to
Am 24.06.21 um 11:15 schrieb Ralf Kiefer:
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.
> 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 wrote:
>
>> 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
>
>> Auch modernste x86-Prozessoren können, solange kein 64-bit-Betrübssystem
>> läuft, im V86-Modus 8086-Code ausführen.
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.
> Das ist mir klar. Aber mit jeder Prozessorgeneration kamen neue Befehle
> dazu, die ein 8088/8086 nicht beherrscht. Wenn die auftauchen, dann ist
> 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
Olaf Schmitt
Jun 24, 2021, 5:06:05 PM6/24/21
to
Am 23.06.2021 um 20:44 schrieb 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:
> 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?
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
Jun 24, 2021, 5:20:57 PM6/24/21
to
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>
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>
Gerald E:scher
Jun 24, 2021, 5:58:26 PM6/24/21
to
Kay Martinen schrieb am 24/6/2021 19:27:
> Am 24.06.21 um 11:15 schrieb Ralf Kiefer:
>> Gerald E:scher wrote:
>>
>>> 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.
> Am 24.06.21 um 11:15 schrieb Ralf Kiefer:
>> Gerald E:scher wrote:
>>
>>> 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.
Protected Mode.
https://de.wikipedia.org/wiki/Virtual_8086_Mode
> Den gibt es m.E. auch erst seit dem 386.
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
Gerald E:scher
Jun 24, 2021, 6:08:52 PM6/24/21
to
Stefan Reuther schrieb am 24/6/2021 18:12:
> Als dummer Disassembler taugt auch das ganz normale 'objdump' aus den
> GNU binutils, man braucht also keinen alten PC mit debug.com:
Einen alten PC braucht man ohnehin nicht. IBMDOS 3.3 samt DEBUG.COM,
> Als dummer Disassembler taugt auch das ganz normale 'objdump' aus den
> GNU binutils, man braucht also keinen alten PC mit 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
Wolf gang P u f f e
Jun 26, 2021, 3:39:25 AM6/26/21
to
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
Jun 26, 2021, 4:49:40 AM6/26/21
to
Am 26.06.21 um 09:41 schrieb 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.
> 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
> Am 24.06.2021 um 23:20 schrieb 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
>>
>> Da ist auch noch was über den zu lesen:
>> <https://wetolearn.blogspot.com/2013/09/8086-assembly-debugging-with-afd.html>
>>
>
> Geil. Einzelschrittbetrieb und Live-Registeranzeige.
Ich habe eher Maschinencodetrace verwendet
>> 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>
>>
>
> Geil. Einzelschrittbetrieb und Live-Registeranzeige.
> Sowas hätte ich mir vor 25 Jahren gewünscht.
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.
> 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". :-)
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
Jun 26, 2021, 5:40:33 AM6/26/21
to
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
Jun 26, 2021, 2:21:14 PM6/26/21
to
Am 26.06.21 um 11:42 schrieb Wolf gang P u f f e:
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.)
> 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
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.)
> Ich hatte mir einige Tools gebastelt, wo man den Bootsektor von
> Festplatten beliebig ändern konnte. (Stichwort Bootmanger MSDOS,
> NWDOS, OS/2)
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
Jun 27, 2021, 3:11:30 AM6/27/21
to
Am 26.06.2021 um 09:41 schrieb Wolf gang Puffe:
> Am 24.06.2021 um 23:20 schrieb 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.
[...]
> Am 24.06.2021 um 23:20 schrieb 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.
>> Da ist auch noch was über den zu lesen:
>> <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?
>> <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.
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
Jun 27, 2021, 5:55:12 AM6/27/21
to
Am 23.06.21 um 20:44 schrieb Ralf Kiefer:
ziemlich alles, was irgendwie auf x86 beruht (wozu ja auch der 8088 zählt).
Marcel
> 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
0 new messages