Neue C64 ASM/Basic Compo : Dreh' das Sprite.

  • Fröhn schrieb:

    Ansonsten sind die Hashverfahren MD5 und SHA-1/2 eigentlich Standard, wenn es um "Dateienidentität" geht.
    Eigentlich nicht. Dieses Hashes sind dazu gedacht, einen eindeutigen Wert zu ermitteln UND die Rückrechnung möglichst zu erschweren. D.h. keine kryptografischen Schwächen plus relativ langsame Berechnung.

    CRC64 ist hingegen nur auf den ersten Punkt und eine im Gegenteil zu MD5 etc. möglichst schnelle Berechnung hin optimiert.

    Insofern wäre CRC64 eigentlich sogar passender. Aber trotzdem wird MD5 regelmäßig verwendet, wohl weil es standardisiert und überall leicht verfügbar ist.
    Have fun!
    thrust2600
  • thrust2600 schrieb:


    Eigentlich nicht. Dieses Hashes sind dazu gedacht, einen eindeutigen Wert zu ermitteln UND die Rückrechnung möglichst zu erschweren.
    Eindeutig sind auch MD5-Werte nicht, nur halt 128 Bit lang und somit gibt es sehr viel weniger Kollisionen.

    Insofern wäre CRC64 eigentlich sogar passender. Aber trotzdem wird MD5 regelmäßig verwendet, wohl weil es standardisiert und überall leicht verfügbar ist.
    Wie gesagt: Wenn Dateiidentität wichtig ist, nimmt man die Hash-Verfahren wie MD5. Wirklich langsam ist MD5 auch nicht. CRC ist eher für die Fehlererkennung gedacht.
  • Fröhn schrieb:

    Eindeutig sind auch MD5-Werte nicht, nur halt 128 Bit lang und somit gibt es sehr viel weniger Kollisionen.
    Stimmt natürlich. Ober ich bezweifele, ob das i.d.R. wirklich relevant ist. (~10^38 vs. ~10^19)

    Fröhn schrieb:

    Wie gesagt: Wenn Dateiidentität wichtig ist, nimmt man die Hash-Verfahren wie MD5. Wirklich langsam ist MD5 auch nicht. CRC ist eher für die Fehlererkennung gedacht.
    MD5 ist nur im Vergleich zu CRC langsam. Aber wieso meinst du MD5 ist besser (außer den 128 Bit)?
    Have fun!
    thrust2600
  • thrust2600 schrieb:

    Fröhn schrieb:

    Eindeutig sind auch MD5-Werte nicht, nur halt 128 Bit lang und somit gibt es sehr viel weniger Kollisionen.
    Stimmt natürlich. Ober ich bezweifele, ob das i.d.R. wirklich relevant ist. (~10^38 vs. ~10^19)

    Fröhn schrieb:

    Wie gesagt: Wenn Dateiidentität wichtig ist, nimmt man die Hash-Verfahren wie MD5. Wirklich langsam ist MD5 auch nicht. CRC ist eher für die Fehlererkennung gedacht.
    MD5 ist nur im Vergleich zu CRC langsam. Aber wieso meinst du MD5 ist besser (außer den 128 Bit)?
    Naja "besser" in dem Sinne, das es (und auch SHA1 + SHA2) für den Zweck Standard ist. Geht eigentlich weniger darum, ob man die kryptografischen Eigenschaften nun auch braucht, sondern eher darum dass es bei MD5 halt der Verwendungszweck klar ist und man überall entsprechende Tools dafür hat. Ich wüsste z.B. nicht auf Anhieb, wie ich auf diesem Rechner eine CRC64 Prüfsumme berechnen soll und vor allem weiss ich dann nicht, welches CRC64-Polynom ich wählen soll.
  • Neu

    peiselulli schrieb:

    Hab ich dir schon zugeschickt. Ich habe die Lösung schon gelöscht ...
    Danke. Hab's jetzt auch gelesen.

    Mit mutwilliger Löschung ist das Ding jetzt dadurch erstmal (leider) auf 63/65 Bytes angewachsen. Nun ja.

    Ist aber ja noch VIEEEEL Zeit... :rolleyes:

    Mit der jetzigen Routine wird das aber wohl nix/nicht mehr weniger Bytes. Da kann ich mich noch so verrenken...
    Read'n'Blast my jump'n'stop-text-sprite-scroller Select A Move

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?
  • Neu

    Jetzt hats mich auch noch gepackt, und ich hab mich heute mal ca. nen halben Tag etwas drangesetzt. Immerhin hat die erste Version nur 84 Bytes, was für mich schon völlig überraschend war, daß ich es überhaupt und in so kurzer Zeit hinbekommen habe 8)

    Naja, ob es wirklich korrekt ist, werd ich wohl erst nach der Auswertung erfahren, war aber irgendwie total spannend, knifflig und hat Spaß gemacht! Mal sehen, ob ich nun auch noch bisschen was wegoptimieren kann...

    Mac Bacon schrieb:

    Ich hab da mal ein Hilfsprogramm zusammengeschustert

    Bei mir muß ich vorher noch ein POKE 780,0 machen, da ich davon ausgehe, daß in allen Registern 0 übergeben wird, so wie das hier geschrieben wurde.

    Noch 2 weitere Fragen:

    1. Es genügt, wenn das Programm nur einmal korrekt abläuft?

    2. Auf welchem Wege lässt man dem Initiator das Programm zukommen?
    Wer die Ironie findet, darf sie behalten ^^
  • Neu

    kbr schrieb:

    Mac Bacon schrieb:

    Ich hab da mal ein Hilfsprogramm zusammengeschustert
    Bei mir muß ich vorher noch ein POKE 780,0 machen, da ich davon ausgehe, daß in allen Registern 0 übergeben wird, so wie das hier geschrieben wurde.
    Stimmt, daran habe ich gar nicht gedacht. Am Besten nach dem Starten des Hilfsprogramms einen Reset durchführen, dann ist man auf der sicheren Seite.
    Yes, I'm the guy responsible for the ACME cross assembler
  • Neu

    thrust2600 schrieb:

    Fröhn schrieb:

    Eindeutig sind auch MD5-Werte nicht, nur halt 128 Bit lang und somit gibt es sehr viel weniger Kollisionen.
    Stimmt natürlich. Ober ich bezweifele, ob das i.d.R. wirklich relevant ist. (~10^38 vs. ~10^19)

    Fröhn schrieb:

    Wie gesagt: Wenn Dateiidentität wichtig ist, nimmt man die Hash-Verfahren wie MD5. Wirklich langsam ist MD5 auch nicht. CRC ist eher für die Fehlererkennung gedacht.
    MD5 ist nur im Vergleich zu CRC langsam. Aber wieso meinst du MD5 ist besser (außer den 128 Bit)?
    CRC ist ja auch nur eine "primitive" Division des Datenstroms durch eine Konstante und deren Rest (Modulorechnung). Ob bei X unterschiedlichen Datenströmen vielleicht immer der gleich CRC (Rest) raus kommt spielt keine Rolle. Es soll nur, je nach Fehlermodell (1 Bit, 2 Bit, ... im Block oder verstreute Bits) über einen gewissen Bereich des Datenstroms erkannt werden, ob der Inhalt nicht mehr original ist. Durch die einfache Rechnenvorschrift ist es verhältnismäßig einfach für einen gleichen CRC-Wert auf einen entsprechend passenden Datenstrom zu kommen. Je Länge der CRC desto aufwändiger kann das Fehlermodell angelegt sein. Der Rückrechenaufwand ändert sich dabei aber nicht wesentlich.

    Der Anspruch bei einem Hash ist viel höher. Da ist die Rechenvorschrift so komplex, dass ein Rückrechnen schwer wird und alle möglichen Datenströme sollen auf den Hash-Wert-Bereich gleich verteilt sein bzw. möglichst wenig Kollisionen (gleichen Hash-Wert für unterschiedliche Datenströme) liefern. Mehr Bits ergeben mehr Spielraum für die Kollisionsfreiheit, die Hash-Funktion muss aber trotzdem auch entsprechend gut sein. Deswegen nützten bei MD5 auch an sich nicht mehr, es um weitere Bits zu erweitern nach dem es als "unsicher" eingestuft wurde. SHA-1 hat mittlerweile zuwenige Bits, weil die Ansätze für die Rückrechnerei schon gefährlich Nahe herankommen, weshalb mind. SHA-2 (SHA-256) als Mindestmaß der Dinge (zumindest bei der Kryptografi) gilt. Aber hier, für unsere Zwecke ist MD5 sicher gut genug, speziell auch deswegen, weil wie schon erwähnt wurde das Verfahren verbreitet ist.

    So gesehen ist und bleibt CRC immer schwach im Vergleich zu ordentlichen Hash-Verfahren.
  • Neu

    syshack schrieb:

    JeeK schrieb:

    syshack schrieb:

    Ihr könnt ja mehr als eine Lösung schicken, oder? Einfach am Schluss die richtige mitteilen.
    So war es doch bei anderen Compos.
    War oder ist es nicht so, dass es eigentlich keine Beschränkung gibt? Es steht doch nichts davon in den Regeln, dass eine Person nur eine Lösung abgeben darf. Die kürzeste von mehreren hat automatisch die besseren Chancen. Warum müsste ich da am Schluss die richtige mitteilen? Selbst wenn inkorrekte dabei wären, würden diese Lösungen einfach disqualifiziert, wohl aber nicht den Einsender selbst mitsamt aller anderen, womöglich korrekten Lösungen. Oder hab ich da irgend etwas falsch verstanden?
    Du hast natürlich recht.Aber ich meine, in den anderen Compos konnte/musste man halt die gewünschten Endversion mitteilen.
    Vermutlich auch, um den Aufwand für den Compo-Leiter zu reduzieren, alle Versionen zu testen.

    Ist auch nur fair: Warum sollte @peiselulli 5 Versionen pro Teilnehmer testen, wenn eh nur die Kürzeste zählt, die ihm der Teilnehmer mitteilen kann.
    Es geht ja nicht nur um die Grösse der Datei, der Code muss ja auch das machen, was innerhalb der Bestimmungen gefordert wurde.
    Wenn 10 Compo-TN durchschnittlich 3 Versionen abliefern, sind das immerhin 30 Versionen zum Testen, wo man es auch mit 10 Versionen testen könnte.

    Im Nachhinein gesehen, wäre es evt. sinnvoller gewesen ein Testprogramm, welches die Richtigkeit der Drehung prüft, vorab den TN abzugeben, damit so die Arbeit für den Compo-Leiter zu reduzieren.
    So würde er weniger kaputte Versionen testen müssen.
    Das ist natürlich richtig, sehe ich auch so (fairness). Wenn es im Reglement aber nicht eingeschränkt ist, bliebe dem Compo-Leiter aber freilich nichts anderes übrig, korrekterweise alles auszuwerten. Aber ich gehe auch davon aus, dass die Teilnehmer hier fair agieren werden. Wenn es ein Testprogramm gäbe, wäre es klar. Dann könnte man das auch strikt auf eine Lösung einschränken (oder eben nur die jeweils kürzeste akzeptieren). Sonst schwebt immer eine gewisse Unsicherheit mit, dass ein Beitrag vielleicht doch irgendwie nicht korrekt arbeitet oder nicht regelkonform sein könnte. Wenn den jemand überhaupt mehrere Lösungen hat, dann sollten die Einsendung von 2 schon drinnen sein. Man muss ja nicht gleich den Worst-Case als Teufel an die Wand malen. ;)
  • Neu

    Mafiosino schrieb:

    Ich habe noch zwei Fragen:

    1) Kann man davon ausgehen, dass die Register (A,X,Y) auf 0 initialisiert sind?

    2) Kann man davon ausgehen, dass bestimmte ZP-Adressen gesetzt sind? Ich denke da so an $39/$3a mit der aktuellen Zeilennummer oder $2d/$2e, die direkt hinter das Programm zeigen sollen.

    peiselulli schrieb:

    Sowas hab ich mir schon gedacht. Da ich das in den Regeln nicht berücksichtigt habe, mach ich jetzt immer folgendes:
    Testcode laden, Reset, Pre-Text starten, Testkandidat laufen lassen, Testcheck laufen lassen.

    Mit anderen Worten für 1) und 2) -> ja

    Das scheint mir doch nicht korrekt zu sein, mein erstes Programm, wo ich davon ausgegangen bin, daß im Akku eine 0 übergeben wird, hat bei Uli nicht funktioniert! Also musste ich doch noch 2 Bytes für einen LDA #0 opfern :/
    Wer die Ironie findet, darf sie behalten ^^
  • Neu

    So, ich hab gestern Abend meine letzte Version bei peiselulli eingereicht. Mehr (oder besser weniger) ist bei 57 Bytes für mich anscheinend nicht drin.

    Ich werde mir das ganze nochmal durch den Kopf gehen lassen. Vielleicht hab ich ja noch eine Idee. Aber momentan fällt mir nix mehr ein :)
    ______________________________________________
    Wenn ich posten will, werde ich Briefträger...

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

  • Neu

    TheRealWanderer schrieb:

    58? Hammer
    Aber da werd ich nicht hinkommen.
    Rund eine Woche später hast Du es dann doch hinbekommen - und sogar unterboten. Finde ich toll! Der Ansporn ist groß und man wächst so ein bisschen über sich hinaus. Auch ich bin mittlerweile an einem Punkt, den ich anfangs nicht für möglich gehalten hätte:

    YPS schrieb:

    M. J. schrieb:

    Super! Weiter so! :thumbsup: Nur leider: letzter Stand: 53 Bytes. :schande: Aber die restlichen Bytes schaffst Du auch noch. :thumbup:
    Danke für den Ansporn, aber ich fürchte, Deine 53 Bytes werde ich nicht knacken - das muss schon Roland oder jemand anderes machen.
    Um wieviel ich genau drunter liege, will ich an dieser Stelle aber noch nicht verraten... Nur soviel: Meine Lösung nutzt keine Selbstmodifikation, keine Illegalen Opcodes, keine Zeropageadressen. Naaa? Neugierig? :D
  • Neu

    Ich hab es nun auch geschafft (hoffe ich mal, dass Peiselullis Testprogramm mich passieren lässt) und zwar in Basic. Es ist ein 10-Zeiler geworden mit herausgekürzten Leerzeichen und vielen Doppelpunkten.
    Laut Windows Explorer sind es 329 Byte im prg. Die tatsächliche Größe im Basic Speicher weiß ich nicht zu ermiteln.
    Ich las hier glaube ich von unter 300 Byte in Basic im Thread.

    Jedenfalls ist es doch gut, die Aufgabe geschafft zu haben, auch wenn man nicht den kürzesten Code geschrieben hat. :)