Danke für den Kopierschutz. Welche Spiele werden noch zerstört?

  • mrr19121970 schrieb:

    Ich habe schon gemerkt das der D64 nicht komplett sauber ist (alles ab x22068 sollte x00 sein. Eventuell auch mehr.
    Das sind Reste des Highscore-Abspeicherns. 0x22000 bis 0x220ff ist T28S0, da ist das 1-Block-File "H" also die Highscores. 0x22100 bis 0x221ff ist T28S1 und sieht nach einer vorherigen Fassung des Highscore-Files aus.
  • Mario28 schrieb:

    Verstehe ich deinen Post richtig, dass du das D64 auf Diskette geschrieben und davon dann das NIB gezogen hast?
    Ja, das ist teil richtig aber nicht ganz.

    Mario28 schrieb:

    Fehlen dann nicht die ganzen Kopierschutz-Informationen usw.?
    Track 01-35 kommen from @GenerationCBM, seine D64. Track 36 kommt von Katakis original. Auf track 36 liegt der schutz, diese ist von 1541 intern code ($0300-$07ff) abgefragt und ist 1:1 wie erwartet.

    c64preservation.com/dp.php?pg=rainbow

    Quellcode

    1. Rainbow Arts (RADWAR) Protection
    2. News: The programmer for the Rainbow Arts protection has been found by Quader! He has sent us the source for the reading/creating of the later track 18 'bad GCR' protection and is searching for the older sources. The later version of this appears to be the same protection as used in "Iron Lord" which identifies itself as "RADWAR". This seems to be called "BETASKIP" on their website.
    3. There are two main versions that I have found in the wild on this one and one variant that might be earlier is used on the original release of Turrican. This protection was used on Rainbow Arts, Magic Bytes, and Time Warp disks (all PAL releases).
    4. The first version is used on disks released in 1987-1988. It contains an aggressive sync length check on track 36. During the load, it bumps back and forth between t18 and t36, formats the disk, then resets the C64 if the correct length isn't found (unless the disk is write-protected of course).
    5. Remasters and emulators both will run these disks after the sync length is adjusted to the timing check routines. It must usually be adjusted because the length check is very exacting, and reading (or writing) an exact sync length is very tough on the belt-driven 1541 and emulators have their own timing (if they even support the method used to count it in this code).
    6. The version found on Turrican is on track 37 and locks instead of formatting the disk.
    7. The second version is used mostly on disks from 1989-1991. This protection is a bad GCR run after a series of key bytes on a sector on track 18 (the sector number varies). These disks cannot seem to be imaged properly on a 1541-II due to the way it processes bad GCR (it will basically "give up" and the rest of the track will be corrupt). When imaged with an original 1541, the images work fine remastered and in emulators that support bad GCR.
    Alles anzeigen
    UPDATE
    Eventuell funktioniert diese auch http://csdb.dk/release/?id=39648 aber ich habe das nicht probiert... funktioniert leider nicht.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von mrr19121970 ()

  • Hier meine NBZs von Starball. Weiß gar nicht, ob die "mint" sind (keine Highscore) oder nicht.
    Wahrscheinlich jedoch nicht - da ich das Original hier habe, werde ich es in der Jugend sicher ein, zweimal gespielt haben.
    Wenn die Erinnerung nicht trügt, war es jedoch ein Rotzspiel, sodass es auch sein kann, sodass ich gar nicht motiviert war es in die Highscoreliste zu schaffen.

    ( ich habe für jede meiner Originaldisks 3 Leseläufe durchgeführt, damit meine 1541-II sicher früher stirbt als nötig. )
    Dateien
    Gruß, Goethe.
    _______________
    9x C64, SX64, 3x1351, 2x 1530, 1x 1541, 5x 1541-II, 2x1581, AR6, FC3, RRNet Mk3 | 3xplus/4, 2x 1531, 2x1551 | 1xA600HD+A604n+RTC+Vampire600V2, 1xA300+A604n+ACA620
    2x Vectrex, Game Boy, Game Gear, 2xMega Drive, 2xMega CD, Genesis 32X, Multimega, Nomad, Wondermega, 2xSaturn, 2xDreamcast, XBox, PS2, PSP, PS3, Ouya, PS4
  • Goethe schrieb:

    Weiß gar nicht, ob die "mint" sind (keine Highscore) oder nicht.
    Nope, ist gespielt. Aber nicht viel. Ist auch nicht ungewöhnlich.

    Ich wollte erst tönen "läuft nicht!", doch halt, wir brauchen natürlich custom protection handler beim Konvertieren:
    nibconv -pm (nbz-source) (g64-target)

    Dann tut's.
  • Die Laufwerke hatten keinen Killerpoke.

    "Es gab auch Möglichkeiten den Schreibkopf von Commodore-Diskettenlaufwerken über Software-Befehle zu beschädigen. In der Praxis war sie durchaus von Bedeutung, da es Kopierschutzmaßnahmen, insbesondere bei Spielen, gab, die das Laufwerk teilweise in kürzester Zeit massiv beschädigen konnten. Dies ließ sich von Seiten des Users nur durch Verwendung einer gecrackten Version verhindern. Lediglich das 1571 und das 1581 besaßen einen mechanischen Schutz gegen derartige Vorfälle. Die anderen Commodore-Floppys konnten aber entsprechend umgebaut werden."

    Glaube ich nur wenn ich das selbst sehe. Das Hauen des Lesekopfs an den Rand ist zu schwach um den kaputt zu kriegen.
    Wer den C64 nicht ehrt ist des x64ers nicht wert.
  • VM, wohl zulange mit Shmendrik rumgehangen mit so vielen Wiki Links? :D

    Vernunftmensch schrieb:

    Das Hauen des Lesekopfs an den Rand ist zu schwach um den kaputt zu kriegen.
    Ich glaube das behämmerte Hämmern der Floppy an den Anschlag war durchaus alles andere als gesund für das Laufwerk.
    Wenn das mal dejustiert war, war es faktisch kaputt für die meisten User. Nicht jeder war/ist ein Bastler oder wusste sich da zu helfen.
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki
  • syshack schrieb:

    Wenn das mal dejustiert war, war es faktisch kaputt für die meisten User.
    Das würde ich aber weder als massiv beschädigt noch als beschädigten Schreib/Lese-Kopf bezeichnen. Es ist eben ein dejustierter Kopf. Natürlich ärgerlich, aber längst nicht so wild, wie der Text beschreibt.

    Allerdings gibt es auch Titel, die den Kopf am äußersten Ende parken, was dazu führt, daß erstmal keine normalformatierten Disketten mehr erkannt werden. "i" reicht da nicht mehr, um den Kopf zu befreien. Da mußte man schon den Formatierbefehl (ohne Diskette) ausführen, um den Kopf da weg zu bewegen. Wer das nicht weiß, könnte auch den Eindruck bekommen, daß das Gerät kaputt sei. In so einem Fall ist das Lichtschranken-ROM natürlich im Vorteil, weil es den Kopf bei jedem Reset bewegt.

    Was das Anschlagen betrifft: Wir wissen ja mittlerweile, daß es ziemlich viele 1541C mit deaktivierter Lichtschranke gibt, und auch 1541II gelegentlich mit dem Lichtschranke-ROM bestückt waren. Wenn das so extrem schädlich wäre, hätten die doch reihenweise wegsterben müssen.
  • Benutzer online 1

    1 Besucher