30 Bytes und schonmal korrekte Unterscheidung vom @ Zeichen.
Allerdings ist noch Murks in der Schleife...
Hallo Besucher, der Thread wurde 43k mal aufgerufen und enthält 111 Antworten
letzter Beitrag von fireworker am
Assemblercompo "Dreh das Wort"
- BastetFurry
- Erledigt
-
-
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
-
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 -
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
WTF?! Genau so eine Lösung wollte ich auch posten! Du warst allerdings schneller...
Hier meine Lösung:
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 SYSTEMDas 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 SYSTEMDas 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 -
ich hab 64 byte für das Programm:
- Wörter == Zeichenketten A-Z, alles andere wird ignoriert
- Begrenzung auf eine Zeile
das wird wohl eher größer als kleiner -
21 Bytes + Ladeadresse. Dreht zwar noch alles, aber terminiert sauber. Muss mit SYS 4096+14 gestartet werden.
CodeDas 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 !" -
-
So, 40 Bytes inklusive Startbytes und sollte eigentlich alle Anforderungen erfüllen :
(Wenn Klammeraffe ein Buchstabe wäre, dann nur 38 Bytes)Code -
So, 40 Bytes inklusive Startbytes und sollte eigentlich alle Anforderungen erfüllen :
(Wenn Klammeraffe ein Buchstabe wäre, dann nur 38 Bytes)Äh, also Deine erste Variante hat bei mir hier auch schon entgegen eigener Aussage mit Klammeraffe funktioniert...
-
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?Code- 1000 A0 D7 LDY #$D7
- 1002 9A TXS
- 1003 C8 INY
- 1004 48 PHA
- 1005 F0 0B BEQ $1012
- 1007 BF 28 03 LAX $0328,Y
- 100a CA DEX
- 100b E0 1A CPX #$1A
- 100d 90 F4 BCC $1003
- 100f 8D 00 01 STA $0100
- 1012 68 PLA
- 1013 8D 28 04 STA $0428
- 1016 EE 14 10 INC $1014
- 1019 BA TSX
- 101a D0 F6 BNE $1012
- 101c C8 INY
- 101d 30 E5 BMI $1004
- 101f 02 JAM
-
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.
Code -
-
Roland:
VICE sagt einem das bei Adresse $foo ein JAM steht.
ja....und wie sag ich dem VICE, dass er das nicht machen soll? der echte c64 macht sowas ja auch nicht. der bleibt einfach schön stehen. -
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!
Das ist 'ne coole Idee, aber ohne ROM-Aufruf geht es 1 Byte kürzer: