Unter Windows würde ich es mit dem ROMWizard von mikemcbike probieren. Das kann zwar nur 4 Dateien nach Belieben zusammensetzen, aber mehrstufig geht ja auch. Vermutlich ist die Anzahl 6 die Herausforderung.
Gruß, Ralf
In Linux
cat file1 file2 > target_file
cat sollte nicht zwischen ascii oder binary unterscheiden
In Windows Shell (oder DOS?)
copy file1 + file2 targetfile /B
Alles anzeigenIn Linux
cat file1 file2 > target_file
cat sollte nicht zwischen ascii oder binary unterscheiden
In Windows Shell (oder DOS?)
copy file1 + file2 targetfile /B
Nee so nicht.
Das muss Byte für Byte gehen. Motorola ist "Big Endian", also erst High-Byte, dann Low-Byte, bis das erste ROM-Chip-Päärchen durch ist, dann das zweite, dann das dritte ROM-Chip-Päärchen.
Aber schon richtig, man kann die Dateien auch einfach runterladen. Es ist eine sportliche Aufgabe (naja, so sehr auch wieder nicht), das selbst zu machen, aber notwendig ist es nicht. Wer Original-ROMs hat, kann imho problemlos auf das online-Backup zurückgreifen.
Nee so nicht.
Das muss Byte für Byte gehen. Motorola ist "Big Endian", also erst High-Byte, dann Low-Byte, bis das erste ROM-Chip-Päärchen durch ist, dann das zweite, dann das dritte ROM-Chip-Päärchen.
OK - dann kann man sich evtl. die Tools auf den 2 folgenden Links ansehen:
und
dd if=firstfile.raw > mergedfile.raw
dd if=nextfile.raw >> mergedfile.raw
dd if=lastfile.raw >> mergedfile.raw
Korrekt, es wäre dann beim Windows Beispiel auch schon nicht gegangen.
Dann müsste man einige Zwischenschritte machen und mit der swab Option die Bytes tauschen.
dd if=unswapped.raw of=swapped.raw conv=swab
Hallo wollte auch was zu der dd Idee schreiben, aber Peter war schneller.
So wie ich es verstanden habe hat Peter 6 Roms.
Nennen wir die jetzt mal a, b ,c, d, e, f.
a und b ist ein Pärchen.
c und d ein Pärchen.
e und f ein Pärchen.
Um die img Datei zu erzeugen muss das erste Byte aus Rom a die ersten 8 Bit im img werden.
Das erste Byte von Rom b werden die nächsten 8 Bit im iimg.
Das zweite Byte aus Rom a wird das dritte 8 Bit Paket im img.
Das zweite Byte aus Rom b wir das vierte 8 Bit Paket im img.
Das geht solange bis 2 x 32 kB aus Rom a und b verarbeitet sind, anschließend obiges mit Rom c und d,
und zum Schluss mit Rom e und f.
Hoffe habe das Problem von Peter etwas ausführlicher beschrieben zu haben.
Mögliche Idee auf die schnelle wäre alle 6 Roms zusammenhängend also Rom a bis f
hintereinander In den Speicher laden.
Anschließend 1. Byte von Rom a in ungenutzten Speicher für img laden, dann Index Register + 2,
2. Byte aus Rom a geht dann an img Bereich +2, usw. bis 32 kB kopiert wurden.
Anschließend Index Register auf img Anfang + 1 setzen und mit Adressbereich von Rom b
beginnen, immer mit Index Register + 2.
Dito für die beiden anderen 2 x 32 kB Blöcke verfahren.
Grüße
Helmut
der ROM Wizard fügt auch zwei 8Bit Roms zu einem 16Bit ROM zusammen. HL und LH...
auf Bedarf programmiere ich euch auch was Anderes rein.
Ich verwende dazu immer romwak unter linux.
Moin.
Es geht auch mit Winhex, da gibt es File-Tools zum Zerlegen und auch zum Zusammenfügen ganzer Blöcke, aber auch das high und low-schubsen der einzelnen Bytes.
C-Programme mit Windows-EXE Dateien, wegen meinen Versuchen mit der Modifikation von IBM PC/AT ROMs mal schnell vor ein paar Tagen programmiert.
Die Reihenfolge der Angabe der Eingabe- und Ausgabe-Dateien legt die "Byte-Order" fest, also ob Intel oder Motorola.
Kann man bestimmt "noch eleganter" programmieren, erfüllen aber ihren Zweck. Genutzter Compiler war TCC (für Windows 32Bit).
Wäre noch interessant, ob man den letzten Schritt noch ohne romwak hingekriegt hätte:
#!/bin/sh
bytes=98303
for i in $(seq 0 $bytes)
do
dd skip=$i status=none count=1 bs=1 if=high.bin >> TOS.img
dd skip=$i status=none count=1 bs=1 if=low.bin >> TOS.img
done
Um die img Datei zu erzeugen muss
Genau so habe ich das doch schon beschrieben.
Toller Thread, klasse Infos .... Sehr wertvoll danke 
Ich find die Lösung mit dd echt cool. Wieder was Neues mit dem Ding gelernt. Jetzt müsste man nur noch die Längenermittlung generalisieren - mit fstat vielleicht.
Alternativ könnte man das auch für die Paare einzeln machen und am Schluss aneinanderhängen. Also erst 1L und 1H zu 1TOS mergen, dann 2 und 3. Danach 1TOS, 2TOS UND 3TOS zusammenfügen. (Mit cat z.B.)
Dann wären die Bytes für dd immer 2^15-1.
Aber muss natürlich nicht.
Ich würde versuchen weiter Standard Tools zu verwenden. Bei der dd Lösung handelt es sich ja mehr um ein sportliches "Pah, und es geht doch" denn Performance mässig ist das natürlich eine Katastrophe und hat gegen romwak keine Chance. Ich dachte mehr daran, dass man vor einem alten Unix System sitzt ohne C Compiler und trotzdem diese Aufgabe lösen kann. dd bei Blocksize 1 ist immer lahm und die drei Files werden 98304 mal geöffnet und wieder geschlossen.
wc kann auch Bytes zählen.
wc -c $file | cut -d " " -f1
Das versteh ich nicht romwak ist doch kein Standardtool. dd ist dagegen in jeder Distro vorhanden, oder? Oder wolltest du genau das sagen? 
Nein, romwak ist kein Standardtool und Du brauchst einen C-Complier, um es nutzen zu können. Alles was ich sagen wollte ist, dass man das dd Script schon mal nutzen kann, aber es ist nur eine Fingerübung gewesen. Es wirklich immer als Tool zu nutzen, dafür ist es zu langsam.
