Live Hack Teil I

Vor kurzem habe ich einmal wieder die Zeit gefunden meine Diskettensammlung zu sichten. Insbesondere die Originale, die ich mir seinerzeits vom Munde abgespart hatte, habe ich mir ganz genau angeschaut.

mein Ziel ist es einen Gedanken weiterzuspinnen den ich in einem älteren Blogeintrag bezüglich der Vergänglichkeit von Kopierschutzmechanismen bei der Migration von Datenträgern auf den PC – zum Zwecke der Weiteren Nutzung mit Hilfe von Emulatoren   – formuliert habe. Der Eintrag findet sich hier.

Das Video oben zeigt, wie eine Diskette (Hacker, Activison) mit einem Analyse Tool (Disk Wizzard II, CAP Software) auf der original Hardware (Atari 800XL + 1050 Disk Laufwerk)  untersucht wird. Im Ergebniss werden die Fehlerhaften Sektoren angezeigt. auf dieser Basis kann nun die Kopierschutzabfrage in der Boot Routine gesucht, gefunden und entfernt werden. Das Problem: Der Nachwelt bleibt zwar die Software erhalten, der Kopierschutz geht aber verloren, spätestens wenn die Original Diskette ihren Geist aufgegeben hat. Letzteres möchte ich verhindern, indem ich meine Disketten inklusive der Informationen zum Kopierschutz auf moderner Hardware archiviere.

Ergänzung:

Der Blogeintrag könnte zu der Annahme verleiten, meine Gedanken zum Tehma Archivierung kopiergeschüzter Disketten sind neu.

Sind Sie nicht!  Auf Atarimania gibt es unter dem Link VAPI (letzter Aufruf 03.04.2016) eine kurze Erklärung zum ATX- Image Format. Eine detaillierte Beschreibung des Aufbaus solcher Images kann man sich hier anschauen (letzter Aufruf 03.04.2016). Eine (ältere) Diskussion im Atari Age Forum zum Thema gibt es dort (letzter Aufruf 03.04.2016). ATX- Images enthalten unter anderem Informationen zu fehlerhaften Sektoren.

Last But not least ist auf der Hompage des AtariMac800 Emulators zu lesen, dass die aktuelle Version VAPI unterstütz.

 

 

 

 

 

 

 

 

Werbung

MADS => *.ATR

Toller Assembler, der MADS. Standardmäßig erzeugt der aber *.XEX Dateien. Keine schlechte Sache, an sich. Wenn man aber das SIO2USB Interface benutz und es nicht schafft genau solche Dateien damit zu starten, dann steht man vor einer Herausforderung, die man  gerne annimmt.

*.XEX sind Atari DOS 2.X (mit DOS 1.0 müsste es auch gehen) kompatible Binary’s. Ich habe noch keinen Weg gefunden solche Dateien mit dem SIO2USB zu starten.

Also, man überredet den MADS einfach dazu ein *. ATR zu erzeugen. Problem gelöst!

Wie das geht kann man sich hier anschauen:

MADS does *.ATR

*.XEX spielerisch erklärt:

Aber Hallo!

 

XEX- Das unbekannte Format

Dateien mit der Endung *.XEX sind ausführbare Dateien, für die gängigen Atari 8- Bit Emulationen, wenigstens.

Die Datei wird mit 2 Bytes $ff eingeleitet, gefolgt von der Startadresse und der Dateilänge. Danach folgen die Daten bzw. der ausführbare Objekt- Code, der/ die an der so beschriebenen Stelle in der angegebenen Länge abgelegt werden/ wird.

Stimmt’s? Geben wir doch einfach einmal die Folgenden Bytes in einem Hex- Editor ein, speichern das ganze als Hallo.xex und laden das File mit einem Atari- Emulator unserer Wahl:

Kleiner Tip, die Byte Folge $40 $9c= peek(88)+256 x peek(89)   😉

Aber Hallo!

 

Eine kurze Geschichte der Dateisysteme…

…passt ganz gut zu meinen Anstrengungen Mac OS das Lesen von 8- Bit Atari Disketten beizubringen. Informativ und Amüsant:

Zum Artikel geht es hier:

• http://arstechnica.com/gadgets/2008/03/past-present-future-file-systems/

Eine Zusammenfassung meines eigenen kleinen Projektes, und ein paar Informationen zum Atari Disk- File Format gibt es hier im Blog:

• ATR Open.
  Funktionssammlung in der Programmiersprache C zur Emulation des Atari DOS 2.x FMS.
• Diverses zum Atari DOS 2.X File Format
  Binaray File Format des DOS 2.X // Boot Sektoren..
• Inside Atari DOS
  Das Atari DOS 2.x im Detail

Viel Spass!

Atari Dos 2.x Objekt File Format

…Objekt Files werden oft auch als „Binär Files“ bezeichnet und lassen sich über die Dos Shell (Das DUP.SYS) über den Menübefehl „L“ laden und ausführen.

Haben wir uns schon einmal gefragt, woher die Laderoutine weiss, wo im Speicherbereich das Programm abgelegt und dann gestartet werden soll? Ja?

Jedes Objekt File beginnt so:

$FF, $FF   Immer!
Start Adresse  Low + High Byte
End Adresse Low + High Byte
Es folgen n (Endadresse – Startadresse +1) Datenbytes.

Das war’s

Wer sich für den Boot Sektor interessiert, der findet hier im Blog mehr.

Quelle: Atari Profibuch (ABBUC e.V. )

Viel Spass!

Boot Sektoren……

…..speziell auf dem Atari sind so eine Sache. Gerade dann, wenn man sich mit so etwas das letzte Mal vor ca. 20 Jahren beschäftigt hat.

So funktionier’s: Man schreibe das nachstehende Programm auf Sektor #1 einer Diskette und führe einen Kaltstart aus. Was wird wohl passieren? Alles ganz einfach, nicht wahr?

*-------------------------------------
* BOOT SEKTOR
* DER NACHSTEHENDE CODE DEFFINIERT
* DAS O.G.

* ES WIRD 1 SEKTOR NACH $0600 IN'S
* RAM GELADEN UND AB $0600+6
* AUSGEFUEHRT.

        ORG $0600
BOOT    DFB 0      IMMER 0!
        DFB 1      SOVIELE SEKTOREN LESEN

        DFW BOOT   DAHIN INS RAM SCHREIBEN
        DFW ST     DORT AUSFUEHREN

ST      LDA #255
        STA 712
        JMP ST

* FUER'S PROGRAMM OHNE BELANG, ABER
* INFORMATIV

        ASC "MULTIBOOT 21.5.2012"