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-
Gast
#7142936
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
Gast
#7143056
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.
Gast
#7143073
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".
Gast
#7143098
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.
Ist ein wirklich geiles Gerät: https://xdevs.com/fix/r6581t/ mfg
... 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
Gast
#7143365
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.
Gast
#7143418
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.
Gast
#7143432
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.
Gast
#7143449
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.
Gast
#7143487
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.
Gast
#7143526
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-
Gast
#7143937
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.
Gast
#7143957
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 ...
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!
Angehängte Dateien:
-
Doofimat.jpg
(49 KB)
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-
Gast
#7144073
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
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.
Gast
#7144155
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.
Gast
#7144188
(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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
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. ;-)
Gast
#7144209
(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.
Gast
#7144312
Christoph db1uq K. schrieb: > Nicht durchsuchbar. OCR sollte damit schon klarkommen.
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-
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-
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"
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.