Hatari und gepatchtes TOS

[goetz @ 3rz]

Ich habe hier ein TOS (das aus der Zeit 1.02 bis 1.04 stammen sollte), und gepatcht ist. Autor*in der Patches und Umfang sind mir nicht bekannt. Die MD5SUM ist 6691e3b42bab4be49d491b551d6dfb67, 196608 Bytes.

Kann ich das nicht in Hatari booten? Das beschwert sich auch über die unpassende Version, wenn ich das Patchen des TOS in Hatari ausschalte. Ich habe es als Parameter --patch-tos false probiert und per GUI.

"Your TOS image seems not to be a valid
TOS ROM file!
(TOS version 1e.92, address $1e921e92)"

Gibt es einen Weg mit Hatari?

[Thorsten Otto]

Vermutlich ist auch die Versions-Nummer im TOS header gepatcht, sodaß Hatari es nicht erkennt. Kannst du die Datei mal anhängen?

[goetz @ 3rz]

Anbei.

[czietz]

Anbei.

Das ist entweder ein kaputtes ROM oder ein fehlerhafter Dump. Kein gültiges TOS-ROM (was man auch daran sieht, dass es auf ca. 5 kB komprimiert werden kann).

[goetz @ 3rz]

Anbei.

Das ist entweder ein kaputtes ROM oder ein fehlerhafter Dump. Kein gültiges TOS-ROM (was man auch daran sieht, dass es auf ca. 5 kB komprimiert werden kann).

Der Atari 260ST läuft mit diesem ROM, ich habe Screenshots vom Desktop zugesandt bekommen.. Gedumpt wurde es mit dem aktuellen uDump. Was empfiehlt sich sonst als Dump-Tool?

[czietz]

Der Atari 260ST läuft mit diesem ROM, ich habe Screenshots vom Desktop zugesandt bekommen..

Also mit dem angehängten Inhalt im ROM liefe er sicher nicht. Vielleicht ist es ja auch kein Dumping- sondern Datentransferfehler (also vom Atari bis zu Dir).

Ein Foto von der uDump-Ausgabe wäre hilfreich.

[Count]

Ich kann vielleicht noch ergänzen, dass Steem die Datei auch nicht akzeptiert.

[czietz]

Ah, vielleicht ist es doch ein Dumping-Fehler. uDump will direkt aus dem ROM in eine Datei schreiben: https://github.com/mikrosk/uDump/blob/e4a9abcb7aaaea6fd11002070f11f5ffc639b3fd/udump.c#L216. Wenn das Ziel eine Diskette ist, ist TOS 1.0x glaube ich nicht so schlau, zu merken, dass der DMA das nicht kann. Das wäre dann ein Bug in uDump.

Ich habe früher TOS 1.0x mal mit dem DUMP_ROM.PRG erfolgreich gedumpt, das dem alten PaCifiST-Emulator (s. Anhang) beilag. Vielleicht mal das probieren...

[goetz @ 3rz]

Also mit dem angehängten Inhalt im ROM liefe er sicher nicht. Vielleicht ist es ja auch kein Dumping- sondern Datentransferfehler (also vom Atari bis zu Dir).

Ein Foto von der uDump-Ausgabe wäre hilfreich.

Ich schaue, das läuft über Ecken zum Besitzer des 260ST, der ihn an jemand verkauft hat (ich habe die Auktion nicht gewonnen, würde aber gerne das TOS gesichert wissen).

[goetz @ 3rz]

Ah, vielleicht ist es doch ein Dumping-Fehler. uDump will direkt aus dem ROM in eine Datei schreiben: https://github.com/mikrosk/uDump/blob/e4a9abcb7aaaea6fd11002070f11f5ffc639b3fd/udump.c#L216. Wenn das Ziel eine Diskette ist, ist TOS 1.0x glaube ich nicht so schlau, zu merken, dass der DMA das nicht kann. Das wäre dann ein Bug in uDump.

Ich habe früher TOS 1.0x mal mit dem DUMP_ROM.PRG erfolgreich gedumpt, das dem alten PaCifiST-Emulator (s. Anhang) beilag. Vielleicht mal das probieren...

Würde passen, da der 260ST nur ein DD-Laufwerk hat. Ich gebe das weiter, danke fürs mithelfen beim erhalten …

(jetzt hoffe ich dann bloß, dass es sich lohnt, d.h. da etwas spannendes/unbekanntes drin ist im patch).

[goetz @ 3rz]

So, ich habe einen neuen ROM-Dump mit dem Pacifist-Tool machen lassen (danke @czietz ), das sieht schon im Hexeditor viel besser aus. Und - es bootet in Hatari.

Auf den ersten Blick ist es ein TOS 1.02 mit anderen/fancy/lustigen Icons, und einem Vermerk "Fast-Loader" im DESKTOP-Info-Dialog. Muss mal testen, ob damit ein Nicht-Ausnullen des Speichers beim Prozesstart gemeint ist, oder „schnellere“ Floppy/HD-Routinen, oder was ganz anderes.

Anbei der lauffähige ROM-Abzug. Es meldet sich mit dem 22.4.1987 (~Blitter-TOS), GEMDOS 0.19, GEM 1.2.

[czietz]

Auf den ersten Blick ist es ein TOS 1.02 mit anderen/fancy/lustigen Icons, und einem Vermerk "Fast-Loader" im DESKTOP-Info-Dialog. Muss mal testen, ob damit ein Nicht-Ausnullen des Speichers beim Prozesstart gemeint ist, oder „schnellere“ Floppy/HD-Routinen, oder was ganz anderes.

Ebenfalls auf den ersten Blick - d.h. einfach per Binary-Compare - sind vermutlich mehrere Patches enthalten. Es gibt drei längere Sektionen die anders sind: die Ressourcen (Icons und Co.) und zwei Routinen. Dann ist aber auch mal hier und da ein Byte gepatched.

[KarlMüller]

Ebenfalls auf den ersten Blick - d.h. einfach per Binary-Compare - sind vermutlich mehrere Patches enthalten. Es gibt drei längere Sektionen die anders sind: die Ressourcen (Icons und Co.) und zwei Routinen. Dann ist aber auch mal hier und da ein Byte gepatched.

Ohne was nach geschaut zu haben, könnten die Patches sein aus der Serie "Auf der Schwelle zum Licht" von Alex Esser in der ST-Compter sein.

Ein paar Start-Adressen der Patches:
fc953a         Diskettenwechsel-Fehler
fc612b         Fehler bei 12-Bit-FAT
fc779a         Patch für TOS-Fehler in Fdatime

Der vielleicht namensgebende Patch (stammt aus "Scheibenkleister"):
fc1d8f          Fastload (Diskette) Byte 0x14 ändern in 0x10

[czietz]

Zumindest einige der von Dir Adressen findet man tatsächlich wieder:

Code: [Auswählen]

00fc04C4: 10 30

00fc1D8F: 14 10

00fc5A55: 79 78
[... bis ...]
00fc5A8D: CE CC

00fc612B: 47 4F

00fc779A: 28 4A
[... bis ...]
00fc77D7: 97 2A

00fc8852: 48 4E
00fc8853: C0 71

00fd84C7: 47 20
[... bis ...]
00fd9524: 00 FC
=> dies dürften die Anpassungen an Dialogen und Icons sein