Wie kann ich 6 einzelne TOS Rom BIN Dateien zu einem TOS.IMG zusammenfügen?

  • Aufgabe:

    6 einzelne 32kb TOS ROM BIN Dateien zu einem TOS.IMG zusammen fügen, um dieses TOS.IMG in Hatari als TOS Rom zu verwenden.


    Bitte keine Hinweise, das man so etwas fertig herunter laden kann - das weiß ich selbst.


    Ich suche aber eben genau obigen Weg/Tool/Vorgehensweise.


    (Idealerweise unter Linux - aber kein Muss)


    VG Peter

    github.com/petersieg

  • 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

  • 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.

    1ST1

  • 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:

    merge of TOS ROM bin files

    und

    ROM merge program ?

  • 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

  • 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).

    Dateien

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • ngc224: Danke! Das war der richtige Tipp.

    hzs90: Ja. Danke für die korrekte Erläuterung.


    Wenn man die TOS Roms ausliest hat man 6x 32kb Dateien.

    Nennen wir sie: 1L, 2L und 3L und 1H, 2H und 3H

    L = LOW Bytes; H=HIGH Bytes.


    Dann kann man ein einzelnen L und H einfach binär hintereinander kopieren.

    Das geht unter DOS z.B. mit copy /b ...

    Unter Linux mit (dd ginge auch):

    cat <1L >low.bin

    cat <2L >>low.bin

    cat <3L >>low.bin

    und:

    cat <1H >high.bin

    cat <2H >>high.bin

    cat <3H >>high.bin

    und danach mit romwak:

    ./romwak /m high.bin low.bin TOS.img


    Gerade getestet und läuft.


    Besten Dank!


    VG Peter

    github.com/petersieg

  • 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

  • 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.

    Das Genie beherrscht das Chaos

  • 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? :grübel:

    Das Genie beherrscht das Chaos

  • 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.