Danke, hast du ein Tool um die 4 Roms wieder zu einem Guss zu verschränken? Im Hex-Editor sehen die 4 Teile am Ende so aus, als ob sie dort irgendwelche Meldungstexte oder sowas enthalten könnten.
Wo stünde denn die Versionsnummer ? Wenn du die lokalisieren könntest, das wäre super.
Hallo Besucher, der Thread wurde 6,6k mal aufgerufen und enthält 34 Antworten
letzter Beitrag von GenerationCBM am
Generelles Thema: OS-ROMs mit Eprommer auslesen
- eisdielenbiker
- Erledigt
-
Danke, hast du ein Tool um die 4 Roms wieder zu einem Guss zu verschränken?
Da dauert das Suchen ja länger als das selberschreiben...
Gezippt ist die Datei immer noch über ein Megabyte groß, daher kann ich sie nicht hier hochladen.
Wo stünde denn die Versionsnummer ? Wenn du die lokalisieren könntest, das wäre super.
Es sind diverse Datumsangaben von April 1992 zu finden, damit sollte man die Version herausfinden können.
-
Meine "weapon of choice" ist Standard-C, in Python oder Perl oder wasweißich geht das sicher auch in weniger als zehn Zeilen. Hier hast Du:
Alles anzeigenC- #include <stdlib.h>
- #include <stdio.h>
- #define MAX_FILES 16
- FILE *streams[MAX_FILES];
- int main(int argc, char *argv[])
- {
- int files,
- ii,
- eofs,
- byte,
- lengths_err;
- if (argc < 2) {
- fprintf(stderr,
- "gather - joins several files on a per-byte basis.\n"
- "Usage:\n"
- "%s INPUTFILES... > OUTPUT\n",
- argv[0]);
- exit(EXIT_SUCCESS);
- }
- files = argc - 1;
- if (files > MAX_FILES) {
- fprintf(stderr, "Error: Too many files given.\n");
- exit(EXIT_FAILURE);
- }
- // open files
- for (ii = 0; ii < files; ++ii) {
- streams[ii] = fopen(argv[1 + ii], "rb");
- if (streams[ii] == NULL) {
- perror("Could not open file");
- exit(EXIT_FAILURE);
- }
- }
- // loop over bytes
- eofs = 0;
- lengths_err = 0;
- do {
- for (ii = 0; ii < files; ++ii) {
- byte = getc(streams[ii]);
- if (byte == EOF)
- ++eofs;
- else
- putchar(byte);
- }
- if ((eofs > 0)
- && (eofs != files)
- && (lengths_err == 0)) {
- lengths_err = 1;
- fprintf(stderr, "Error: Files have different lengths!\n");
- }
- } while (eofs != files);
- return EXIT_SUCCESS;
- }
-
Das ist ein Versionstext im BIN:
RISC OS3.10 (30 Apr 1992)Das steht mittendrin:
Help! Help! We are being held prisoner in a software factory!Das steht am Ende:
Mac Bacon: Schönes Programm. Hätte ich in der Tat quick and dirty (auch in C) gemacht.
-
Das steht mittendrin:
Help! Help! We are being held prisoner in a software factory!
Das ist wohl original so, habe ich von gehört. Komme jetzt bloß nicht darauf, wie man das Easteregg startet.
Dieser String ist der Default-Inhalt eines Feldes in einer Fensterdefinition. Im Betrieb bekommt man den meines Wissens nicht zu sehen, da muss man schon absichtlich im ROM-Dateisystem die entsprechende Fensterdefinitionsdatei mit einem Template-Editor öffnen.
Bei einer späteren Desktop-Version (mit grafischer Hervorhebung) wurde das dann noch geändert zu "We are being held prisoner in a software factory, in 3D!"
-
Mac Bacon: Schönes Programm. Hätte ich in der Tat quick and dirty (auch in C) gemacht.
Danke für die Blumen. Leider kann das Programm bei unterschiedlich langen Dateien in eine Endlosschleife geraten, daher hier noch schnell die reparierte Version.
-
Damit man beim nächsten mal nicht suchen muss: byteshuf aus dem (leider verschütt gegangenen) command line pack von Neill Corlett kann sowas, wie der geneigte ROM Hacker weiss.
-
Um mehrere Files zusammenzufügen, gabs doch einen ganz enfachen copy-batch Befehl. Komme jetzt nicht drauf.
Edit: copy *.bin gesamt.bin
-
Hier geht's nicht um zusammenkopieren (cat), sondern um byte-weise zusammenmischen. Byte 1 aus File 1, Byte 1 aus File 2, Byte 1 aus File 3, Byte 1 aus File 4, Byte 2 aus File 1, Byte 2 aus File 2, usw...
Wenn ich das mit gather mache, sind im destination file ganz brav alle 0x0a in 0x0d 0x0a erweitert. Das ist ... ungut. Liegt das am Quellcode von gather, oder hab' ich das falsch kompiliert?
-
Ach so, ok.
-
Wenn ich das mit gather mache, sind im destination file ganz brav alle 0x0a in 0x0d 0x0a erweitert. Das ist ... ungut. Liegt das am Quellcode von gather, oder hab' ich das falsch kompiliert?
Keins von beiden, das (Windows-)Problem liegt außerhalb: Im Quellcode öffne ich die angegebenen Dateien mit dem "Binary"-Flag, damit dieses CRLF-Konvertierungsgedöns nicht stattfindet. Aber als Eingabe bei "scatter" und als Ausgabe bei "gather" benutze ich stdin/stdout und überlasse es dem Benutzer, diese Streams mit "<" bzw. ">" auf Dateien umzuleiten. Diese Umleitungen werden von der Shell eingerichtet, und wenn die das so macht, dass da Konvertierungen stattfinden, ist das natürlich blöd...
Möglicherweise kann man das mit fcntl() o.ä. zur Programmlaufzeit dann tatsächlich wieder anders einstellen, aber auf die Schnelle hab ich nichts Passendes gefunden (das mag daran liegen, dass Linux-manpages keine Windows-Workarounds beschreiben
).Was aber auf jeden Fall gehen sollte, ist: In beiden Programmen den fraglichen Stream durch eine explizit angegebene Datei ersetzen.
In "scatter.c":In "gather.c":
Wenn man die entsprechende Zeile direkt hinter den Variablendeklarationen in main() einfügt, sollte(tm) das Problem gelöst sein - nur ist dann jeweils ein Dateiname hardcoded.
Um es "schön" zu machen, könnte man Kommandozeilenargumente hinzufügen ("--outfile DINGS" oder so), oder einfach festlegen, dass das erste/letzte Argument die Einzeldatei sein soll - aber irgendwie widerstrebt es mir, sowas nur für Windows einzubauen, wenn ordentliche Kommandozeileninterpreter doch bereits einen passenden Mechanismus mitbringen...
-
benutze ich stdin/stdout und überlasse es dem Benutzer, diese Streams mit "<" bzw. ">" auf Dateien umzuleiten
Aaaah na klar...
Das erklärt es natürlich, danke. Sollte ich abstellen/umgehen können. Fall gelöst.
