Guten Abend, ich habe anhängenden ROM Dump und suche Hilfe beim disassemblieren. Das ROM-File stammt aus einem Advantest R6581 (Toshiba 68303 Prozessor) und Ziel ist es die SCPI Kommandos und deren Menüstruktur zu identifizieren, die undokumentierten sind und die Zugriff auf die Linearisierungskoeffizienten der abschnittsweisen INL Korrektur erlauben. Hintergrund ist, dass in den Geräten leider nur gemittelte und keine individualisierten Koeffizienten hinterlegt sind, weswegen die INL deutlich größer ist als es theoretisch möglich wäre. Hat jemand die notwendige Erfahrung mit Motorola 68k Prozessoren und kann hierbei unterstützen? Mit zufälligen Befehlskombinationen bin ich bisher leider nicht erfolgreich gewesen. Es gibt jedoch einige Befehle, die eindeutig vorhanden sind und nicht dokumentiert sind, z.B. "EEPROM:", "HOSEI:", "HOSEI?", "DEF?", "NEW?" Wäre toll, wenn jemand mit den entsprechenden Fähigkeiten unterstützen könnte und hier antwortet. -branadic-
Also wirklich reverse engineeren ist mühsam, da wird man locker einige Tage unterwegs sein. Man muss ja zumindest mal einen groben Überblick über die internen Abläufe bekommen und einen Grossteil der Unterroutinen erstmal inhaltlich einordnen. Und wenn dann noch Hardware-IO dazukommt, wirds nicht einfacher... Aber der Bereich mit Befehlen und ähnlichem war recht einfach in dem Dump zu finden. Hier alles was sinnvoll aussieht und >=2 Chars ist. Ob das jetzt aber wirklich alles Befehle sind, weiss ich nicht... *CLS *ESE *ESE? *ESR? *IDN? *OPC *OPC? *OPT? *RCL *RST *SAV *SRE *SRE? *STB? *TRG *TST? *WAI 4WCH 4WCHECK :ABOR :ABORT :ARM: :CAL: :CALC: :CALCULATE: :CALIBRATION: :CONF: :CONF? :CONFIGURE: :CONFIGURE? :CURR: :CURRENT: :DISP :DISP? :DISPLAY :DISPLAY? :FETC? :FETCH? :FORM :FORM: :FORM? :FORMAT :FORMAT: :FORMAT? :FREQ: :FREQUENCY: :FRES: :FRESISTANCE: :INIT :INIT: :INITIATE :INITIATE: :INP: :INPUT: :ITEM? :ITEMPERATURE? :LFRE? :LFREQUENCY? :MMEM: :MMEMORY: :OUTP: :OUTPUT: :PER: :PERIOD: :READ? :RES: :RESISTANCE: :ROUT: :ROUTE: :SENS: :SENSE: :STAT: :STATUS: :SYST: :SYSTEM: :TRAC: :TRACE: :TRIG: :TRIGGER: :TSYS: :TSYSTEM: :VOLT: :VOLTAGE: :ZERO: ABOR ABORT AC AC: ALL ANAL: ANALOGOUT: APER APER? APERTURE APERTURE? ARM: ASC ASCII AT AUTO AUTO? AVER AVER? AVERAGE AVERAGE? B4 BCD: BCDOUT: BCON BCON: BCON? BCONTROL BCONTROL: BCONTROL? BEEP BEEP: BEEP? BEEPER BEEPER: BEEPER? BLOC BLOC? BLOCK BLOCK? BUS CAL: CALC: CALCULATE: CALIBRATION: CAT? CATALOG? CHAN CHANNEL CHEC CHECK CLE CLEAR CLOS CLOS? CLOSE CLOSE? COL COL? COLUMN COLUMN? COMM COMMA COMP COMP? COMPLETE COMPLETE? CONF: CONF? CONFIGURE: CONFIGURE? CONT CONT? CONTINUOUS CONTINUOUS? COUN COUN? COUNT COUNT? COUP COUP? COUPLING COUPLING? CRLF CURR CURR: CURRENT CURRENT: DATA DATA: DATA? DATE DATE? DB DB? DBM DBM? DC DC: DCV DCV: DCV? DEF DEF? DEFAULT DEL DEL: DEL? DELAY DELAY? DELETE DELETE: DELI: DELIMITER: DELT DELTA DEV DEV? DEVIATION DEVIATION? DFIL DFIL: DFIL? DFILTER DFILTER: DFILTER? DIG DIG? DIGITS DIGITS? DISP DISP? DISPLAY DISPLAY? DREC DREC: DRECALL DRECALL: DST DST: DSTORE DSTORE: EEPROM: ELEM ELEM? ELEMENTS ELEMENTS? ENAB ENAB? ENABLE ENABLE? EOI ERR? ERROR? EVEN? EVENT? EXT EXT: EXT? EXTERNAL EXTERNAL: EXTERNAL? FAIL FAST FAST: FETC? FETCH? FILT FILT? FILTER FILTER? FLO FLOAT FORM FORM: FORM? FORMAT FORMAT: FORMAT? FREE? FREQ FREQ: FREQUENCY FREQUENCY: FRES FRES: FRESISTANCE FRESISTANCE: FRON FRON: FRONT FRONT: FULL GAIN? GPIB GPIB: GUAR GUAR? GUARD GUARD? HEAD HEADER HI HOSEI HOSEI: HOSEI? HX IMM IMMEDIATE INF INFINITE INIT INIT: INITIALIZE INITIATE INITIATE: INP: INPUT: INT INT: INTEGER INTERNAL: IPTS IPTS68 ITEM? ITEMPERATURE? ITS ITS90 K4 LAY2: LAY: LAYER2: LAYER: LENG LENG? LENGTH LENGTH? LEV LEV: LEV? LEVEL LEVEL: LEVEL? LF LFEO LFEOI LFRE? LFREQUENCY? LIM LIM: LIM? LIMIT LIMIT: LIMIT? LINE LOW LOW? LOWER LOWER? MAN MANUAL MAX MAXIMUM MEAS MEAS: MEASUREMENT MEASUREMENT: MEM MEMORY MID MID? MIN MINIMUM MMEM: MMEMORY: NEG NEGATIVE NEW? NONE NPLC NPLC? NPLCYCLES NPLCYCLES? NULL NULL: NUMB NUMB? NUMBER NUMBER? OCOM OCOM? OCOMPENSATED OCOMPENSATED? OFF OFFS OFFS? OFFSET OFFSET? OHM OHM: OHM? OPEN OPER: OPERATION: OTEM OTEM: OTEMPERATURE OTEMPERATURE: OUTP: OUTPUT: PASS PASS: PASS? PER PER: PERIOD PERIOD: POIN POIN? POINTS POINTS? POS POSITIVE POW POW? POWER POWER? PREC PRECALL PRES PRESET PRET PRET? PRETRIGGER PRETRIGGER? PRIN: PRINTER: PROT PROT? PROTECTION PROTECTION? PST PSTORE QN QUE: QUES: QUESTIONABLE: QUEUE: RAM RAM? RANG RANG: RANG? RANGE RANGE: RANGE? RAT RAT? RATE RATE? RATIO RATIO? READ? REAL REAR REAR: REF? RES RES: RESISTANCE RESISTANCE: RMS RMS? ROUT: ROUTE: RTD RTD: RTD? SCAL SCAL: SCALING SCALING: SCAN SCAN: SCAN? SENS: SENSE: SHE SHEADER SLOP SLOP? SLOPE SLOPE? SLOW SMO SMO? SMOOTHING SMOOTHING? SOUR SOUR: SOUR? SOURCE SOURCE: SOURCE? SPAC SPACE STAT STAT: STAT? STATE STATE? STATISTICS: STATUS: STORE STR STR? STRING STRING? SUBM SUBM: SUBM? SUBMEASURE SUBMEASURE: SUBMEASURE? SYST: SYSTEM: TEMP TEMP? TEMPERATURE? TERM TERM? TERMINAL TERMINAL? TIM TIM? TIME TIME? TIMER TIMER? TIMESTAMP TLIN TLINK TRAC: TRACE: TRAN TRANSFER TRIG: TRIGGER: TSYS: TSYSTEM: UNIT UNIT? UPP UPP? UPPER UPPER? VERS? VERSION? VOLT VOLT: VOLTAGE VOLTAGE: WR WV X? XB Y? Z? ZERO: ZERO? `SLOP dHOSEI
Hallo Georg, das ist mir auch bewusst, aber vielleicht gibt es ja jemanden der an sowas besonders viel Spaß hat. Die Befehle hatte ich auch schon extrahiert, allerdings nützen sie nichts, man braucht die Befehlsstruktur dahinter, da die einzelnen miteinander erst in bestimmter Reihenfolge kombiniert eine Funktion erfüllen und hierfür muss man die Firmware verstehen, um diese Struktur zu extrahieren. Daher hatte ich ja auch um Hilfe gefragt, weil das meinen Horizont überschreitet. -branadic-
Folgene Tools könnten dir helfen: - objdump - radare2 - IDA pro Das ist aber schon ein Brett was du dir da vorgenommen hast, gerade Mathematische operationen zurückzuwandels ist recht komplex, besonders wenn FPU emulation im Spiel ist.
Ein Dump mit dem alten strings.exe Viel Spaß beim Knobeln. Online-Disassembler brauchen einen Hex-Text, das Binärfile wollte die erste Fundstelle jedenfalls nicht einlesen: https://onlinedisassembler.com/odaweb/
meinst Du Intel-Hex? Dann könnte ich das Bin mittels der Galep-Software umwandel. mfg
Ohne die Startadresse des ROMs zu kennen, ist das nicht sehr zielführend. Zwar kennt der 68k weitestgehend relokatiblen Code, aber die diversen Vektoren haben feste Adressen.
DerEgon schrieb: > Ohne die Startadresse des ROMs zu kennen, ist das nicht sehr > zielführend. Die ist 0x400 ;-) Zwar habe ich noch einen eingemotteten 68K-Rechner und auch Disassembler und Simulator, aber die 584 kB Code passen nicht mehr in den "Kernspeicher".
m.n. schrieb: > > Die ist 0x400 ;-) Der Offset der Datei R6581_A02_sw.ROM ist 0x00000000. Ab 0x00000400 kommt dann der Code weil die ersten 0x400 die Vektoren sind. Im Übrigen ist das Ermitteln des Offset eines unbekannten 680x0 Bianary nicht so schwierig, insbesondere wenn es das komplette Binary inklusive Vektoren ist. Das R6581_A02_sw.ROM läßt sich im Disassembler auch halbwegs gut lesen, 680x0 Assembler Code ist sowiese gut lesbar. Wenn man das Ganze halbwegs sinnvoll analysieren will hat man das Gerät da stehen und prüft die Annahmen, die man aufgrund des Firmware-Disassembly macht. Damit wird der Aufwand überschaubar. Im Prinzip schaut man nur das im Firmware-Disassembly nach was man nicht durch Ausprobieren der Kommandos am Gerät herausfindet.
... und es läuft mit nem RTOS der Firma "hunter & ready inc", nicht schlecht. :-P mfg
Hallo Lotta. Der Name war mir im Strings-Text auch aufgefallen https://vtechworks.lib.vt.edu/bitstream/handle/10919/41577/LD5655.V855_1987.M577.pdf?sequence=1&isAllowed=y in dieser Master-Thesis von 1987 wird die Firma Hunter & Ready 15 mal genannt. >meinst Du Intel-Hex? soweit ich es verstehe, wollen jedenfalls die hier https://onlinedisassembler.com/odaweb/ den ganzen Hex-Code als einfachen Ascii-Text haben, also 3 Byte pro Byte. Den darf man per Copy&Paste in das Fenster links reinwerfen, nachdem man noch von I386 auf M68k umgestellt hat. Intel-Hex müsste man kräftig nachbearbeiten https://de.wikipedia.org/wiki/Intel_HEX
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Den darf man per Copy&Paste in das Fenster links reinwerfen, > nachdem man noch von I386 auf M68k umgestellt hat. > Intel-Hex müsste man kräftig nachbearbeiten > https://de.wikipedia.org/wiki/Intel_HEX Was soll denn so ein Online Disassembler bringen? Das hilft vielleicht bei einem kleinen Binary aber nicht bei halbwegs komplexen Code. Bei dem R6581_A02_sw.ROM ist z.B. die Zuordnung von GPIB Kommandos auf die entsprechende Funktion in Tabellen organisiert. So was erkennt ein "normaler" Disassembler nicht. Dafür gibt es interaktive Tools wie IDA Pro oder Ghidra. Dabei gibt man dem Tool im Prinzip Hinweise wie es was behandeln soll (Daten, Code usw.). Das ist ein iterativer Prozess, damit analysiert man schrittweise die Stellen, die einen interessieren.
Ja klar, es gibt natürlich professionelle Software. Ich wollte halt erst mal reinschnuppern. IDA hatte ich schon mal gelesen, aber die free Version kann nur x86 https://hex-rays.com/ida-free/ Ghidra scheint kostenlos zu sein, stammt aber von der NSA und ist ziemlich umfangreich. https://github.com/NationalSecurityAgency/ghidra "...help protect our nation and its allies..." die werben um Helfer.
Dieter schrieb: > Der Offset der Datei R6581_A02_sw.ROM ist 0x00000000. > Ab 0x00000400 kommt dann der Code weil die ersten 0x400 > die Vektoren sind. 68K bedingt muß ROM immer bei 0x0 beginnen. Entscheidend ist, wohin das Programm dann springt. Mit 0x400 bleibt es leider im ROM. Schön wäre es, wenn der Reset-Vektor zum Beispiel auf 0x100000 zeigen würde. Dann müßte nach dem Start ab 0x0 RAM liegen (Vektortabelle) und man könnte sich mit einem TRAPx an beliebigen Stellen einklinken, ohne den Rest anzufassen. Vermutlich wird das Programm auch auf absolute Adressen gelinkt sein. So bleibt alles im Konjunktiv.
m.n. schrieb: > 68K bedingt muß ROM immer bei 0x0 beginnen. Jein, nur die ersten 8 Bytes (SSP und PC), bei den danach folgenden Interrupt-Vektoren ist das je nach Anwendung eher störend. Beim Atari ST wurden diese 8 Bytes deshalb aus dem (ansonsten woanders liegenden) ROM eingespiegelt.
Christoph db1uq K. schrieb: > Ja klar, es gibt natürlich professionelle Software. Ich wollte halt erst > mal reinschnuppern. > Das hat nichts mit "professionell" zu tun, auch ein professioneller Disassembler kann das nicht automatisch. Es geht um ein interaktives Werkzeug zur Analyse. Damit "bearbeitet" man den disassemblierten Code (z.B. Namen an Funktionen vergeben, die man identifiziert hat) oder eben Hinweise darauf geben ob es Code oder Daten sind, auch den Typ von Daten (Strings, Zahlen, Strukturen usw.) Zum nur mal reinsehen ist so ein komplexes Teil wie R6581_A02_sw.ROM auch nicht unbedingt geeignet, dafür sollte man sich irgendein einfaches "Reverse me" Tutorial suchen.
Christoph db1uq K. schrieb: > Viel Spaß beim Knobeln. Online-Disassembler brauchen einen Hex-Text, das > Binärfile wollte die erste Fundstelle jedenfalls nicht einlesen: > https://onlinedisassembler.com/odaweb/ Ich hab das da hochladen können. Arch m68k Offset 0 Endianess default. Er zeigt dann data. an. Die Zeile mit dem Offset 0x400 anwählen und "c" drücken dann wird ab da disassembliert.
Na wenigstens ein Teilerfolg. Den Disassembler habe ich ergoogled, hatte den noch nicht gekannt. Wahrscheinlich gibt es auch da besseres. Immerhin scheint er Labels zu vergeben, also nicht die unterste Stufe in der Kategorie.
A. B. schrieb: > suche Hilfe beim disassemblieren. Hmm, Du scheiterst schon beim Disassemblieren, willst aber später dir Firmware verstehen? Meinst Du nicht, da passt was nicht zusammen? Wie stellst Du Dir das vor?
Dieter schrieb: > Bei dem R6581_A02_sw.ROM ist z.B. die Zuordnung von GPIB > Kommandos auf die entsprechende Funktion in Tabellen organisiert. Danke, das ist ein erster wertvoller Hinweis, wie mir scheint. -branadic-
Irgendeiner schrieb: > Wie stellst Du Dir das vor? Das wird A. B. schon auf die Reihe bekommen, auch wenn Du ihm völlige Blödheit unterstellen möchtest.
Dieter schrieb: > Christoph db1uq K. schrieb: >> Ja klar, es gibt natürlich professionelle Software. Ich wollte halt erst >> mal reinschnuppern. >> > > Das hat nichts mit "professionell" zu tun, auch ein professioneller > Disassembler kann das nicht automatisch. Es geht um ein interaktives > Werkzeug zur Analyse. Damit "bearbeitet" man den disassemblierten > Code (z.B. Namen an Funktionen vergeben, die man identifiziert hat) > oder eben Hinweise darauf geben ob es Code oder Daten sind, auch den > Typ von Daten (Strings, Zahlen, Strukturen usw.) Genau darum, um das Interaktive, geht es. Gut ist es, wenn man die ganzen "Schrittchen" als Script/Batch hinterlegen kann - weil eben die gleichen Schritte (segmentweise) immer und immer wieder aufgerufen werden müssen. Als Student hatte ich mal den Ehrgeiz, mich an einer elektrischen Schreibmaschine zu versuchen - dort dann den Tatstatur-Scan ausgeräumt und durch IEEE-1284 Code und Fifo ersetzt. Ich meinte, ich hätte damals den Disassembler selbst geschrieben. Liegt vergraben auf 8"-Disketten ...
Angehängte Dateien:
-
Doofimat.jpg
49 KB
K.Thaler hat recht, man kann nach der knappen Anleitung das Binary direkt hochladen, hier der Programmanfang ab 0x0400. Die gesamte Disassembly sind 17 MByte Text. Ich habe mich zu Atari-Zeiten nur kurz mal mit 68k-Assembler befasst. Immerhin meinen Ein-Nadel-Drucker Seikosha GP-100 (vom AppleII) zur Ausgabe einer Bildschirm-Hardcopy gebracht. Hier die "Profi"-Software die ich dazu gekauft habe. https://de.wikipedia.org/wiki/Unihammer "Nachteile: starke Geräuschentwicklung" das stimmt!
:
Bearbeitet durch User
Der Hinweis mit der Tabelle ist Gold wert, ich fange an die Tabelle und damit auch die Befehlsstruktur im Code zu erkennen. Der Rest ist vermutlich Fleißarbeit. Danke für den Tipp. -branadic-
Na fein: Hier mein Beitrag m68k-elf-objdump -b binary -m68010 -D R6581_A02_sw.ROM > R6581.S Man erhält ein 68k-Source file in "fieser" AT&T-Notation (mit fp=a6), das 7 MB groß ist und das ich wegen der Größe nicht posten möchte (könnte sonst ja Senge geben von einigen Sheriffs hier). Wie der Christian ja schon gepostet hat, startet der Toshiba 68303, über den ich kaum etwas gefunden habe, außer daß er ne Peripherie mitbringt, mit:
1 | 400: 13fc 0080 00ff moveb #-128,0xffff01 |
2 | 406: ff01 |
3 | 408: 33fc 200f 00ff movew #8207,0xfffc00 |
4 | 40e: fc00 |
5 | 410: 13fc 0028 00ff moveb #40,0xfffc03 |
6 | 416: fc03 |
7 | 418: 13fc 0008 00ff moveb #8,0xfffc09 |
8 | 41e: fc09 |
9 | 420: 13fc 0008 00ff moveb #8,0xfffc0b |
10 | 426: fc0b |
11 | 428: 3a3c 0001 movew #1,%d5 |
12 | 42c: 0c45 0000 cmpiw #0,%d5 |
13 | 430: 660a bnes 0x43c |
14 | 432: 13fc 0011 00ff moveb #17,0xffff01 |
15 | 438: ff01 |
16 | 43a: 6008 bras 0x444 |
17 | 43c: 13fc 0051 00ff moveb #81,0xffff01 |
18 | 442: ff01 |
19 | 444: 13fc 0005 00ff moveb #5,0xffff03 |
20 | 44a: ff03 |
21 | 44c: 33fc 7ffc 00ff movew #32764,0xfffc0c |
22 | 452: fc0c |
23 | 454: 2e7c 0021 fff0 moveal #2228208,%sp |
24 | 45a: 4eb9 0000 2660 jsr 0x2660 |
25 | 460: 4eb9 0000 26e6 jsr 0x26e6 |
26 | 466: 4eb9 0000 24ec jsr 0x24ec |
27 | 46c: 4eb9 0002 9afa jsr 0x29afa |
28 | 472: 203c 0000 0030 movel #48,%d0 |
29 | 478: 4e40 trap #0 |
30 | 47a: 0c80 0000 0000 cmpil #0,%d0 |
31 | 480: 6660 bnes 0x4e2 |
32 | 482: 33fc 7e30 007f movew #32304,0x7ffc94 |
33 | 488: fc94 |
34 | 48a: 13fc 0080 007f moveb #-128,0x7ffd8f |
35 | 490: fd8f |
36 | 492: 33fc 0000 007f movew #0,0x7ffc96 |
37 | 498: fc96 |
38 | 49a: 203c 0000 0000 movel #0,%d0 |
39 | 4a0: 223c 0000 0002 movel #2,%d1 |
40 | 4a6: 243c 0000 0002 movel #2,%d2 |
41 | 4ac: 263c 0000 0001 movel #1,%d3 |
42 | 4b2: 207c 0001 33d4 moveal #78804,%a0 |
43 | 4b8: 4e40 trap #0 |
44 | 4ba: 203c 0000 0031 movel #49,%d0 |
45 | 4c0: 4e40 trap #0 |
46 | 4c2: 4e73 rte |
Da wird anscheinend irgendwelche Peripherie im $ffffxx-Bereich initialisiert, möglw., da auch kein move #$800,sr o.ä. zu finden ist, auch die IRQ gesperrt und initialisert (?) Apropos Exception und IRQ: Fast alle enden in Endlosschleifen. Keine Autovektorirq. Erst ab Vektor $C0 finden sich weitere Einträge:
1 | 300: 0000 2878 orib #120,%d0 |
2 | 304: 0000 28d0 orib #-48,%d0 |
3 | 308: 0000 290a orib #10,%d0 |
4 | 30c: 0000 04da orib #-38,%d0 |
5 | 310: 0000 2968 orib #104,%d0 |
6 | 314: 0000 298a orib #-118,%d0 |
7 | 318: 0000 298c orib #-116,%d0 |
8 | 31c: 0000 298e orib #-114,%d0 |
Ich vermute, daß hier 8 Vektor IRQ des 68303 angesiedelt sind - von hier - wäre zu vermuten - käme man in die IRQ-Routinen: SER-RCV, PAR-SEND und was immer. Dann fällt auf, daß ja excessiv von trap #0 Gebrauch gemacht wird (Vektor $80) - der hüpft .... dann irgenwann schließlich hierhin:
1 | 53c: 0c40 0011 cmpiw #17,%d0 |
2 | 540: 6600 0088 bnew 0x5ca |
3 | 544: 5c8f addql #6,%sp |
4 | 546: 201f movel %sp@+,%d0 |
5 | 548: 2f0e movel %fp,%sp@- |
6 | 54a: 2c7a ffd2 moveal %pc@(0x51e),%fp |
7 | 54e: 2c56 moveal %fp@,%fp |
8 | 550: 2c56 moveal %fp@,%fp |
9 | 552: 2f00 movel %d0,%sp@- |
10 | 554: 40c0 movew %sr,%d0 |
11 | 556: 806e 00a2 orw %fp@(162),%d0 |
12 | 55a: 46c0 movew %d0,%sr |
13 | 55c: 201f movel %sp@+,%d0 |
14 | 55e: 4a2e 0096 tstb %fp@(150) |
15 | 562: 671c beqs 0x580 |
16 | 564: 536e 0094 subqw #1,%fp@(148) |
17 | 568: 665c bnes 0x5c6 |
18 | 56a: 2f0e movel %fp,%sp@- |
19 | 56c: 2c6f 000e moveal %sp@(14),%fp |
20 | 570: cf4e exg %sp,%fp |
21 | 572: ddfc 0000 000e addal #14,%fp |
22 | 578: 2f26 movel %fp@-,%sp@- |
23 | 57a: 3f26 movew %fp@-,%sp@- |
24 | 57c: 2f26 movel %fp@-,%sp@- |
25 | 57e: 2c66 moveal %fp@-,%fp |
26 | 580: 0c6e ffff 0018 cmpiw #-1,%fp@(24) |
27 | 586: 663e bnes 0x5c6 |
28 | 588: 2f00 movel %d0,%sp@- |
29 | 58a: 302f 0008 movew %sp@(8),%d0 |
30 | 58e: 0240 0700 andiw #1792,%d0 |
31 | 592: 6706 beqs 0x59a |
32 | 594: b06e 00a0 cmpw %fp@(160),%d0 |
33 | 598: 662a bnes 0x5c4 |
34 | 59a: 4a6e 00aa tstw %fp@(170) |
35 | 59e: 6606 bnes 0x5a6 |
36 | 5a0: 4a2e 001e tstb %fp@(30) |
37 | 5a4: 671e beqs 0x5c4 |
38 | 5a6: 302f 0008 movew %sp@(8),%d0 |
39 | 5aa: 0240 3fff andiw #16383,%d0 |
40 | 5ae: 0040 2000 oriw #8192,%d0 |
41 | 5b2: 526e 0018 addqw #1,%fp@(24) |
42 | 5b6: 46c0 movew %d0,%sr |
43 | 5b8: 201f movel %sp@+,%d0 |
44 | 5ba: 48e7 030c moveml %d6-%d7/%a4-%a5,%sp@- |
45 | 5be: 40c6 movew %sr,%d6 |
46 | 5c0: 6000 0144 braw 0x706 |
47 | 5c4: 201f movel %sp@+,%d0 |
48 | 5c6: 2c5f moveal %sp@+,%fp |
49 | 5c8: 4e73 rte |
50 | 5ca: 0c40 0016 cmpiw #22,%d0 |
51 | 5ce: 6646 bnes 0x616 |
52 | 5d0: 2f0e movel %fp,%sp@- |
53 | 5d2: 2c7a ff4a moveal %pc@(0x51e),%fp |
54 | 5d6: 2c56 moveal %fp@,%fp |
55 | 5d8: 2c56 moveal %fp@,%fp |
56 | 5da: 40c0 movew %sr,%d0 |
57 | 5dc: 806e 00a2 orw %fp@(162),%d0 |
58 | 5e0: 46c0 movew %d0,%sr |
59 | 5e2: 7000 moveq #0,%d0 |
60 | 5e4: 4a2e 0096 tstb %fp@(150) |
61 | 5e8: 6728 beqs 0x612 |
62 | 5ea: 4a6e 0094 tstw %fp@(148) |
63 | 5ee: 661e bnes 0x60e |
64 | 5f0: 526e 0094 addqw #1,%fp@(148) |
65 | 5f4: 2c6e 0098 moveal %fp@(152),%fp |
66 | 5f8: cf4e exg %sp,%fp |
67 | 5fa: ddfc 0000 0014 addal #20,%fp |
68 | 600: 2f0e movel %fp,%sp@- |
69 | 602: 2f26 movel %fp@-,%sp@- |
70 | 604: 2f26 movel %fp@-,%sp@- |
71 | 606: 2f26 movel %fp@-,%sp@- |
72 | 608: 2f26 movel %fp@-,%sp@- |
73 | 60a: 2c66 moveal %fp@-,%fp |
74 | 60c: 4e73 rte |
75 | 60e: 526e 0094 addqw #1,%fp@(148) |
76 | 612: 2c5f moveal %sp@+,%fp |
77 | 614: 4e73 rte |
78 | 616: 48e7 030e moveml %d6-%d7/%a4-%fp,%sp@- |
79 | 61a: 2a7a ff02 moveal %pc@(0x51e),%a5 |
80 | 61e: 2a55 moveal %a5@,%a5 |
81 | 620: 2c55 moveal %a5@,%fp |
82 | 622: 526e 0018 addqw #1,%fp@(24) |
83 | 626: 2e00 movel %d0,%d7 |
84 | 628: 0c47 0031 cmpiw #49,%d7 |
85 | 62c: 6200 0244 bhiw 0x872 |
86 | 630: 7000 moveq #0,%d0 |
87 | 632: 40c6 movew %sr,%d6 |
88 | 634: de47 addw %d7,%d7 |
89 | 636: de47 addw %d7,%d7 |
90 | 638: 4efb 7002 jmp %pc@(0x63c,%d7:w) |
91 | 63c: 6000 02ca braw 0x908 |
92 | 640: 6000 042a braw 0xa6c |
93 | 644: 6000 0528 braw 0xb6e |
94 | 648: 6000 056c braw 0xbb6 |
95 | 64c: 6000 0620 braw 0xc6e |
96 | 650: 6000 06a2 braw 0xcf4 |
97 | 654: 6000 070e braw 0xd64 |
98 | 658: 6000 0782 braw 0xddc |
99 | 65c: 6000 0d02 braw 0x1360 |
100 | 660: 6000 0d72 braw 0x13d4 |
101 | 664: 6000 1ad6 braw 0x213c |
102 | 668: 6000 1ada braw 0x2144 |
103 | 66c: 6000 19da braw 0x2048 |
104 | 670: 6000 0ebe braw 0x1530 |
105 | 674: 6000 0f2a braw 0x15a0 |
106 | 678: 6000 0fba braw 0x1634 |
107 | 67c: 6000 0086 braw 0x704 |
108 | 680: 6000 feba braw 0x53c |
109 | 684: 6000 1ace braw 0x2154 |
110 | 688: 6000 0ff4 braw 0x167e |
111 | 68c: 6000 108a braw 0x1718 |
112 | 690: 6000 1aba braw 0x214c |
113 | 694: 6000 ff34 braw 0x5ca |
114 | 698: 6000 142c braw 0x1ac6 |
115 | 69c: 6000 1466 braw 0x1b04 |
116 | 6a0: 6000 150c braw 0x1bae |
117 | 6a4: 6000 1624 braw 0x1cca |
118 | 6a8: 6000 16e2 braw 0x1d8c |
119 | 6ac: 6000 1714 braw 0x1dc2 |
120 | 6b0: 6000 0052 braw 0x704 |
121 | 6b4: 6000 0c4a braw 0x1300 |
122 | 6b8: 6000 0b94 braw 0x124e |
123 | 6bc: 6000 068a braw 0xd48 |
124 | 6c0: 6000 068e braw 0xd50 |
125 | 6c4: 6000 07c2 braw 0xe88 |
126 | 6c8: 6000 08be braw 0xf88 |
127 | 6cc: 6000 0036 braw 0x704 |
128 | 6d0: 6000 0e0a braw 0x14dc |
129 | 6d4: 6000 097c braw 0x1052 |
130 | 6d8: 6000 0a16 braw 0x10f0 |
131 | 6dc: 6000 0b0e braw 0x11ec |
132 | 6e0: 6000 0b64 braw 0x1246 |
133 | 6e4: 6000 0bde braw 0x12c4 |
134 | 6e8: 6000 1706 braw 0x1df0 |
135 | 6ec: 6000 1744 braw 0x1e32 |
136 | 6f0: 6000 17e4 braw 0x1ed6 |
137 | 6f4: 6000 1894 braw 0x1f8a |
138 | 6f8: 6000 1918 braw 0x2012 |
139 | 6fc: 6000 1ac8 braw 0x21c6 |
140 | 700: 6000 1d98 braw 0x249a |
Anscheinend verwendet das RTOS - wie Linux68k (war das nicht auch beim Atari so?) - den trap #0 Befehl als SYSCALL, um ins Kernelland zu kommen, wobei in D0 die Nummer des entsprechenden SYSCALL steht. SYSCALL 17 und 22 haben anscheinend eine besondere Funktion, da wird in irgendeiner struct, deren Adresse sich in $51e (?) ist wohl falsch, muß doch wohl $51c =$300100 sein, im RAM, am FP, im SR rumgespielt. Und dann kommt die SYSCALL Sprung Tabelle: D0->D7 und mit jmp %pc@(0x63c,%d7:w) dahin, welcher ca. 50 SYSCALL gewünscht war. Das geht dann aber noch in $872 weiter, wenn D7.w > 255 war. Aber hier wäre ja schonmal ein Ansatzpunkt, an dem man weiter machen könnte: die SYSCALL werden ja Schreiben/Lesen zu den peripheren Schnittstellen bereitstellen, Taskwechsel, Semaphore sperren usw. Wohl eher nicht die mathematischen Funktionen ..... Tso, das waren dann 2 KB diassembliert, bleiben noch so rund 498 KB. Gruß Olav
A. B. schrieb: > Wäre toll, wenn jemand mit den entsprechenden Fähigkeiten unterstützen > könnte und hier antwortet. naja 640kB Bincode ist der Wahnsinn. Das macht niemand freiwillig. Ich habs mal durch den IDA gejagt und als LST exportiert. IDA hat erstaunlich viele Referenzen auf die Strings schon im ersten Lauf gefunden. Ich hab nur die Vector Tabelle bearbeitet und den RomStart als Funktion deklariert Nun bist du dran.
Thomas Z. schrieb: > > naja 640kB Bincode ist der Wahnsinn. Das macht niemand freiwillig. > Ach ja? Was ist denn dann Deiner Meinung nach ein schön lesbarer Assembler? 680x0 Assembler ist doch klar aufgebaut und wirklich einfach lesbar, auch ohne dass man ständig in der Opcode Referenz nachschlägt. Um zu sehen wie die eigentlichen Kommandos (GPIB bzw. SCPI) auf die entsprechenden Funktionen abgebildet werden braucht man weniger als 15 Minuten. Wobei das natürlich noch nicht heisst dass man die Funktionen vollständig versteht aber so Dinge wie Antwort-String zurücksenden oder GPIB Fehler behandeln sind schnell sichtbar. Die eigentliche Arbeit ist das Verstehen von den komplexeren Funktionen, aber so einfache Dinge wie GPIB "*IDN?" gehen recht schnell.
Dieter schrieb: > Ach ja? Was ist denn dann Deiner Meinung nach ein schön lesbarer > Assembler? Binärcode: RCA 1802. Wenig Befehle, und die sind oft in 4 Bit Opcode + 4 Bit Register dargestellt. Sprungadressen 8/16-Bit absolut. Intel 8080 lässt sich in Oktaldarstellung mit etwas Übung auch lesen, weil weitgehend aus 2+3+3 Bits aufgebaut und ebenfalls nicht relativ adressierend. Auch 68000 gewinnt etwas durch Oktaldarstellung, weil oft in 4+3+3+3+3 Bits codiert.
:
Bearbeitet durch User
(prx) A. K. schrieb: > > > RCA 1802. Wenig Befehle, und die sind oft in 4 Bit Opcode + 4 Bit > Register dargestellt. Sprungadressen 8/16-Bit absolut. > > Intel 8080 lässt sich in Oktaldarstellung mit etwas Übung auch lesen, > weil weitgehend aus 2+3+3 Bits aufgebaut und ebenfalls nicht relativ > adressierend. > > Auch 68000 gewinnt etwas durch Oktaldarstellung, weil oft in 4+3+3+3+3 > Bits codiert. Du meinst direkt die Bytes zu interpretieren? Ich meine Assembler Code, dafür hat man ja Disassembler um nicht mehr die Bytes direkt anfassen zu müssen. Als Beispiel aus "R6581_A02_sw.ROM", man sieht in ein paar Sekunden dass die Funktion "strlen" macht:
1 | strlen: |
2 | |
3 | arg_0 = 8 |
4 | |
5 | link a6,#0 |
6 | movem.l d5/a5,-(sp) |
7 | movea.l arg_0(a6),a5 |
8 | moveq #0,d5 |
9 | |
10 | loop_334DC: |
11 | tst.b (a5)+ |
12 | beq.s exit_334E4 |
13 | addq.l #1,d5 |
14 | bra.s loop_334DC |
15 | |
16 | exit_334E4: |
17 | move.l d5,d7 |
18 | movem.l (sp)+,d5/a5 |
19 | unlk a6 |
20 | rts |
Dieter schrieb: > Du meinst direkt die Bytes zu interpretieren? Ich meine Assembler Code, Du schon, er schrieb aber von "640kB Bincode". Keine Not, mir 68000 zu erklären. Den Opcode von NOP habe ich nach 4 Jahrzehnten noch im Kopf. ;-)
:
Bearbeitet durch User
(prx) A. K. schrieb: > > Du schon, er schrieb aber von "640kB Bincode". > Ist ja schön wenn man die Bytes direkt interpretieren kann, nur sehe ich heutzutage keine Grund mehr dass man das tun muss. Vor 35 Jahren vielleicht, aber nicht mehr heute. Und selbst da gab es schon eingebaute Disassembler im ROM.
>Toshiba 68303, über den ich kaum etwas gefunden habe Datenblätter gibt es mindestens zwei: http://www.datasheet-pdf.com/PDF/TMP68303F-16-Datasheet-Toshiba-528996 https://datasheetspdf.com/pdf-file/528995/Toshiba/TMP68303/1 202 und 161 Seiten. Nicht durchsuchbar.
Mit Hilfe des Handbuchs und des Firmware-Files habe ich jetzt nachfolgende Tabelle erstellt. So ganz komplett ist die Tabelle jedoch noch nicht, ich kann die Zuordnung der Befehle: HOSEI: HOSEI? EEPROM: DEF? NEW? Ich vermute, dass sie im Layer3 angesiedelt sind, aber ich kann nicht erkennen in welchem Layer1 und Layer2 Menu sie angesiedelt sind. Meine Versuche sie als Layer2-Befehl aufzurufen waren nicht erfolgreich. -branadic-
:
Bearbeitet durch User
Hallo branadic, Ich habe mir das File von Thomas Z. (R6581_A02_sw.zip) mal angeschaut und kann bestätigen, dass es sich bei dem vorliegenden Betriebssystem-Kern um den Kernel VRTX32/68000 Ver. 1.05 von Ready Systems handelt. Hier gibt es neben anderen Dokumenten http://www.bitsavers.org/pdf/hunterAndReady/ noch ein passendes User Manual dazu: http://www.bitsavers.org/pdf/hunterAndReady/541311001_VRTX32_68000_Users_Guide_Release_1_Apr87.pdf Der Kernel hat eine Grösse von 8124 Bytes und beginnt in dem Listing auf Adresse $04FC. Das erste Byte nach dem Kernel ist auf $24B8. Auf Adresse $51E ist ein Pointer auf die Config-Table ($0100), siehe S. 4-3 im Manual. Der erste Eintrag in dieser Tabelle ist ein Pointer auf die Workspace. Der Wert $0105 auf Adresse $0522 ist übrigens die Versionsnummer (1.05). Ich habe genau diesen Betriessystem-Kern vor etwa 30 Jahren, vermutlich in einem Anflug von geistiger Umnachtung, disassembliert und kommentiert. Im angehängten zip-File ist das disassemblierte Quellprogramm (vrtx32.src) sowie 2 Include-Files mit Konstantendefinitionen und der Struktur der Workspace. Das Listing habe ich mit einem m68k-elf-as gemacht.
Ich habe gerade gesehen, dass in meinem letzten Post einige Sachen verloren gegangen sind, daher hier noch einmal in korrektem Deutsch: Mit Hilfe des Handbuchs und des Firmware-Files habe ich jetzt nachfolgende Tabelle erstellt. So ganz komplett ist die Tabelle jedoch noch nicht, ich kann die Zuordnung der Befehle: HOSEI HOSEI: HOSEI? EEPROM: REF? DEF? NEW? RAM RAM? INTEGER nicht identifizieren. Ich vermute, dass sie im Layer3 angesiedelt sind, aber ich kann nicht erkennen zu welchem Layer1 und Layer2 Menu sie gehören. Wirklich klar ist die Tabelle also doch nicht zu erkennen. Meine Versuche sie als Layer2-Befehl z.B. ":SYST:HOSEI?" oder als Layer3-Befehl z.B. ":SYST:HOSEI:HOSEI?" aufzurufen waren bisher erfolglos. Einen klassischen "DUMP?" Befehl habe ich auch nicht finden können, wie das bei anderen Geräten ja zum Teil der Fall ist. -branadic-
:
Bearbeitet durch User
Ich habe hier ein Passwort Problem bei einem anderen Advantest gerät, auf dem auch VRTX32 läuft. Vielleicht kann ein VRTX Experte mal reinschauen. Danke! Beitrag "Advantest R3273 Passwort"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.