Posts by Claus

    Postest Du denn immer mal 'Standings'?
    Also Top3 oder 5 der bisher eingegangenen? Lediglich als Zahlen, ohne Namen oder so.
    Das faende ich spannend und waere ein Anreiz : )


    Gute Idee! Werde ich tun. Jetzt muss ich allerdings weg, heute abend gibts aber ein erstes Standing ^^

    Nachdem die letzte Compo doch recht schleppend anlief, dachte ich, es wäre schlau, das Ende jeglicher Sommerferien noch mitzunehmen. War vielleicht nicht die beste Idee, hier gehts ja gleich schon ganz schön rund :thumbsup:


    Mir stellt sich die Frage für welches System das sein soll? 6502? Oder auch Z80? In der ASM-Compo #2 wurde ja noch der 64er angegeben, bei der dreier fehlt eine Systemangabe.


    Nein, ich würde auch mit Z80 nicht mitmachen. Erstens ist sind meine Assemblerkenntnisse über 30 Jahr alt, zweitens war ich nie gut in Z80. Aber schön anzuschauen wäre es, wenn ein Z80 den 6502 schlagen würde.


    Oh, danke für den Hinweis! Dieses klitzekleine Detail ist mir doch glatt entfallen :whistling: : Es handelt sich um eine C64-Compo, da das Template darauf zugeschnitten ist. Generell sollte sie Lösung zwar wohl auf jedem 6510/6502 basierten Rechner laufen, aber da ich mich nur mit dem C64 auskenne, bleibt es jetzt mal dabei...


    Ich ergänze es mal im Ursprungspost, falls das geht.


    EDIT: geht nicht :(. Könnte ein MOD den Absatz:


    "Nachdem die Teilnehmer ja letztes Mal einige Kreativität an den Tag gelegt haben, gibt es diesmal ein etwas trockeneres Thema: es geht darum, den vorgegebenen Text auf den Bildschirm zu bringen, und zwar mit so wenig Speicherverbrauch wie möglich! Natürlich gibt es auch hier einige Nebenbedingungen:"


    ersetzen durch:


    "Nachdem die Teilnehmer ja letztes Mal einige Kreativität an den Tag gelegt haben, gibt es diesmal ein etwas trockeneres Thema: es geht darum, den vorgegebenen Text auf einem C64 auf den Bildschirm zu bringen, und zwar mit so wenig Speicherverbrauch wie möglich! Natürlich gibt es auch hier einige Nebenbedingungen:"


    Das wäre super!

    Alle Bestandteile des Templates außerhalb des Bereichs zwischen


    ;=======================================
    ; put your code here


    und


    ;=======================================
    ; *** Print code size ***
    !warn "Size is ", *-compo_entry, " bytes"


    heißt: Flossen weg ;) !

    Nachdem ich die letzte ASM-Compo gewonnen habe und damit die zweifelhafte Ehre erlangt habe, die nächste Compo auszurichten (nochmal Danke an Mac Bacon ^^) folgt hier in rascher Folge :whistling: die ASM-Compo #3!


    Nachdem die Teilnehmer ja letztes Mal einige Kreativität an den Tag gelegt haben, gibt es diesmal ein etwas trockeneres Thema: es geht darum, den vorgegebenen Text mit einem C64 auf den Bildschirm zu bringen, und zwar mit so wenig Speicherverbrauch wie möglich! Natürlich gibt es auch hier einige Nebenbedingungen:

    • Es darf nicht auf das ROM zugegriffen werden, mit der Ausnahme, dass die vorgegebene Einsprungaddresse für CHROUT benutzt werden darf
    • Auf die I/O Chips darf nicht zugegriffen werden
    • Modifizieren des vorgegebenen Codes zur Laufzeit ist verboten
    • Zugriff auf jegliches RAM ist erlaubt (das schließt das Color RAM ein, vielleicht nützt es ja jemandem was...)


    Regel-Erweiterung:


    Um mehr Diversität bei den Lösungen zu bekommen, darf davon ausgegangen werden, dass das Color-RAM zu Beginn des eigenen Codes korrekt gesetzt ist und kein Color-RAM Bug vorliegt.



    Es gibt nur eine Kategorie: Gewinner ist, wer die gestellte Aufgabe mit dem kleinsten Programm (das schließt Code und Daten ein) bewältigen kann.


    Sollte es Beiträge geben, die die obigen Regeln trickreich umgehen, ohne sie zu brechen, so wird für diese eine Extra-Kategorie erstellt.


    Deadline ist der 20. September 2014, 19:00 Uhr MEZ. Beiträge bitte als Source hier in den Thread oder per PM direkt an mich.


    Die Datei "template.asm" enthält den vorgegebenen Code sowie eine naheliegende Implementierung mit einem Speicherverbrauch von 741 Bytes, die es zu schlagen gilt.


    Zusätzlich habe ich den geforderten PETSCII-Text als Hex-Dump angehängt, um eventuelle Analysen und Verarbeitung zu vereinfachen. Falls jemand ein anderes Format bevorzugt, erstelle ich es gerne auf Anfrage.


    Für den geneigten Leser gibt es hier eine meiner Meinung nach hervorragende Einführung in Kompressionsalgorithmen von Pasi Ojala, dem Autor von PUCRUNCH: Compression Basics. Als Tipp auf den Weg geben kann ich, dass bei dieser kleinen Datenmenge die Codesize für das Entpacken eine wesentliche Rolle spielt, eine einfache Lösung wird hier also vermutlich besser sein, als einen kompletten Exomizer oder ähnliches zu verwenden. Ich habe eine eigene Lösung implementiert (natürlich außer Konkurrenz) und kann versprechen, dass man das eine oder andere Byte sparen kann ;) .


    Zu gewinnen gibt es wie immer immerwährenden Ruhm und Ehre, sowie die Genugtuung, dabeigewesen zu sein. Ach ja, und außerdem die Bürde, die nächste ASM-Compo ausrichten zu müssen...


    Viel Spaß!


    EDIT by FXXS: Bedingungen auf Wunsch vom Autor um "mit einen C64" und Erweiterungsabsatz ergänzt.

    Hi,


    ich wollte nur drauf hinweisen, dass ich auch gerade eine ASM-Compo vorbereite (in der ASM-Ecke gleich hier nebenan, das wird dann ASM Compo #3). Das wird was kleines, nur Forum64-intern und es wird eine sehr klar vorgegebene Aufgabenstellung geben. Trotzdem, falls es hier zu einer ASM-Compo käme, sollten wir uns da vielleicht abstimmen, damit das nicht gleichzeitig stattfindet ^^...

    Ganz genau betrachtet ist dann sogar am besten, uint_fast16_t Typen und Konsorten zu nehmen, die sollten dann wirklich am schnellsten sein. Ist aber vielleicht in dem Zusammenhang dann doch Korinthen und so ;)

    Hm, bzgl. MSVS meine ich gelesen zu haben, dass 2010 die älteste Version ist, die problemlos aufwärts-kompatibel ist. Aber vielleicht sollte man einfach die neuste Version nehmen, die ist dann vielleicht am zukunftsichersten?


    Jou, mein Patch ist schon ein bisschen reingefriemelt, ich wollte nur, dass es mal schnell bei mir geht ^^ . Du weißt sicher am besten, wo die Funktionalität gut aufgehoben ist. Und \x ist vermutlich die bessere Wahl (obwohl man den Backslash natürlich auch praktisch überall escapen muss). So konnte ich halt meinen cc1541-Patch eins zu eins übernehmen :whistling:


    Gibt es noch weitere Pläne mit dem Tool außer dem eigenen Dateisystem? Was ist denn da genau der Plan, ein echt inkompatibles Dateisystem, oder nur andere Strategien für die Block-Allozierung?


    Letzteres fände ich noch ganz interessant: ich frage mich, ob es was bringt, das Allozieren der Blöcke von der Reihenfolge der Dateien im Directory zu entkoppeln. So könnte man z.B. kleine Dateien möglichst nah an Track 18 positionieren, um die Zugriffszeiten auf den ersten Track/Sektor zu optimieren (die bei größeren Dateien weniger ins Gewicht fällt, weil das Laden selbst länger braucht). Oder eine "Priorität" pro Datei angeben, die die Datei entsprechend nah oder weit von Track 18 positioniert. So könnte man Dateien, auf die häufiger zugegriffen wird, näher an Track 18 positionieren. Ob sich das lohnt, weiß ich nicht, aber ein Experiment wärs vielleicht wert...