Hello, Guest the thread was called26k times and contains 111 replays

last post from fireworker at the

Assemblercompo "Dreh das Wort"

  • Ich hab 'ne Lösung in 39 Bytes (incl. 2 Bytes Startadr.), die alle Fälle korrekt behandelt: Nur Zeichen 1-26 für Wörter werden umgedreht, alle anderen Zeichen werden zeichenweise kopiert; egal, wo wieviele Nicht-Buchstaben stehen; die vollen 40 Zeichen der ersten Bildschirmzeile werden behandelt.


    Den Trick mit lda ($0E),Y habe ich dabei natürlich auch benutzt.


    Ich hatte nebenbei auch darüber nachgedacht, die CHRGET-Routine (ab $0073) so zu patchen, dass sie die Zeichen 1-26 entsprechend erkennt, aber das Patchen allein verbraucht dann doch schon wieder zu viele Bytes, dass diese Idee Humbug ist. ;)

  • Jetzt hab ich insgesamt 35 Bytes. Scheint soweit korrekt zu funktionieren, wenn keine Scrncodes > 127 verwendet werden. Aber die stehen ja auch in keinem normalen Satz, oder?

  • Jetzt hab ich insgesamt 35 Bytes. Scheint soweit korrekt zu funktionieren, wenn keine Scrncodes > 127 verwendet werden. Aber die stehen ja auch in keinem normalen Satz, oder?

    Interessante Frage. Bei mir sind Codes über 127 kein Problem, allerdings werden alle als Sonderzeichen erkannt und nicht als Buchstaben. Was ist mit inversen Buchstaben?
    Kann man direkt philosophisch werden: was sind eigentlich Buchstaben? ;)
    Also bei mir sind das lediglich A-Z in Großbuchstaben im Grafikzeichensatz und a-z in Kleinbuchstaben im Groß-/Kleinzeichensatz.

  • Hmm, ich stell gerade fest, das meine Routine manchmal sehr seltsamen Zusatzkram auf den Schirm bringt. Das scheint aber nicht vom Testsatz abzuhängen, sondern von Zeit und Ort, an dem ich Sys4096 eingebe, wtf?!?


    Ich glaub ich fang noch mal ganz von vorne an - wieder einmal :wand

  • Ach... ich will mal meine 13 Byte Version posten...


    Sollte eigentlich alle Regeln erfüllen.
    Problem nur: Es dauert sicher ein paar Millionen Jahre, bis das erforderliche Ergebnis (dass in der 2. Zeile die gedrehten Wörter der 1. Zeile stehen) erreicht ist.
    Als Zugabe werden auch noch alle möglichen Zitate und andere Teile der Weltliteratur auf den Bildschirm gebracht :D


    Code
    1. 1000 DEX
    2. 1001 INC $0428,X
    3. 1004 BNE $1009
    4. 1006 JSR $1000
    5. 1009 INX
    6. 100A BEQ $1000
    7. 100C RTS
  • Hehe... Sozuagen die Infinite-Monkey-Methode ;)


    EDIT: kann man eigentlich irgendwie herausfinden ob sich noch was auf dem Stack befindet oder nicht, bzw. wie kann man das manipulieren? Benutze den Stack sonst NIE und komme irgendwie mit meinen tsx, txs Experimenten gerade nicht weiter... :(

  • Ach... ich will mal meine 13 Byte Version posten...


    Sollte eigentlich alle Regeln erfüllen.
    Problem nur: Es dauert sicher ein paar Millionen Jahre, bis das erforderliche Ergebnis (dass in der 2. Zeile die gedrehten Wörter der 1. Zeile stehen) erreicht ist.
    Als Zugabe werden auch noch alle möglichen Zitate und andere Teile der Weltliteratur auf den Bildschirm gebracht :D


    WTF?! Genau so eine Lösung wollte ich auch posten! Du warst allerdings schneller...
    Hier meine Lösung:

    Code
    1. .C:1000 A2 27 LDX #$27
    2. .C:1002 FE 28 04 INC $0428,X
    3. .C:1005 D0 F9 BNE $1000
    4. .C:1007 CA DEX
    5. .C:1008 10 F8 BPL $1002
    6. .C:100a 60 RTS


    Ist nur 11 Bytes lang, und trasht auch nicht die 3. und folgenden Bildschirmzeilen.

  • Ich habe mir das eben auch nochmal angeschaut.Mit Worten und freistehenden Zahlen, auch dem @ ist das kein Thema.
    Aber, z.B.: @64K RAM SYSTEM


    Das habe ich mal zum Testen verwendet. Da ist eine umfangreiche Behandlung notwendig. Mit ein paar Bytes dürfe das niemals machbar sein.

  • Ich habe mir das eben auch nochmal angeschaut.Mit Worten und freistehenden Zahlen, auch dem @ ist das kein Thema.
    Aber, z.B.: @64K RAM SYSTEM


    Das habe ich mal zum Testen verwendet. Da ist eine umfangreiche Behandlung notwendig. Mit ein paar Bytes dürfe das niemals machbar sein.


    Wie gesagt (siehe oben), ich habe eine Lösung in 39 Bytes (PRG-Größe, also incl. 2 Bytes für die Startadresse), die auch das kann.
    Aus @64K RAM SYSTEM
    wird @64K MAR METSYS

  • 21 Bytes + Ladeadresse. Dreht zwar noch alles, aber terminiert sauber. Muss mit SYS 4096+14 gestartet werden.




    Das Basic-Programm macht übrigens ziemlichen Mist, so dass man es kaum als Spec gelten lassen kann:
    Aus "HIER 1234 @ 123@ WOER123 123WOER!"
    wird "REIH REOW REOW @ 123 123 !"

    Menschen wurden geschaffen um geliebt zu werden. Dinge wurden erschaffen um benutzt zu werden.

    Der Grund, warum die Welt sich im Chaos befindet, ist weil stattdessen Dinge geliebt und Menschen benutzt werden.

  • So, 40 Bytes inklusive Startbytes und sollte eigentlich alle Anforderungen erfüllen :
    (Wenn Klammeraffe ein Buchstabe wäre, dann nur 38 Bytes)


  • Hier ist meine 32 Byte Version (mit Startbytes sind es 34)
    Wegen dem JAM sollte man es aufm echten C64 probieren. Oder kann mir jemand sagen, wie man den VICE dazu bekommt, sich da wie ein C64 zu verhalten?


  • Naja, ich poste dann hier auch mal meinen Ansatz. Kurz, aber immer noch falsch. Problem ist einfach, dass nach einem Buchstaben noch ein weiteres Zeichen aufn Stack gepackt wird... Ich komme zum Henker nicht drauf, ob das mit der Methode irgendwie lösbar ist ohne das Programm wahnsinnig aufzublähen.


  • Hier ist meine 32 Byte Version (mit Startbytes sind es 34)
    Wegen dem JAM sollte man es aufm echten C64 probieren.

    Das JAM ist auch nötig, denn generell muss man aufpassen, wenn man nicht mittels SEI die IRQ-Verarbeitung gesperrt hat und man den Stackpointer irgendwohin verschiebt. Die IRQ-Routine im ROM ab $FF48 macht ja ein TSX, LDA $0104,X AND #$10, und wenn da nicht 0 rauskommt, interpretiert sie das als BRK. Dadurch wird dann der Bildschirm gelöscht, und der schöne umgedrehte Satz ist wieder futsch.
    Da Deine Routine durch SYS4096 und Drücken von Return gestartet wird und dann sicherlich innerhalb von 1/60 sec bis zum JAM kommt, tritt dieses Problem bei Deiner Lösung vermutlich nicht auf, da bis dahin kein weiterer IRQ ausgelöst wird.
    PS: Echt geile Lösung!


    Code
    1. [...]
    2. . ora #$40
    3. jsr $b113
    4. bcs .s00 ; wenn ja dann nochmal


    Das ist 'ne coole Idee, aber ohne ROM-Aufruf geht es 1 Byte kürzer:

    Code
    1. [...]
    2. . beq .nichtNochmal
    3. cmp #$1B
    4. bcs .s00
    5. .nichtNochmal