Assemblercompo "Dreh das Wort"

Mafiosino: so wie es aussieht (habs nicht ausprobiert), wirds aber probleme geben, wenn in der 1. zeile auf pos. 40 ein buchstabe steht, und die 2. zeile auch mit einem buchstaben beginnt (z.b. der sys 4096).
dann wird die 2. zeile mit ins wort-drehen mit einbezogen (durch den lax auf $033c, bzw. ab $043b)

Da scheinst du Recht zu haben Roland. Ich hab's grad im Vice ausprobiert.

Dann muss ich noch weiter frickeln, damit die Version gültig ist.

Das war unter anderem der Grund, warum ich bei rückwärts geblieben bin ...
An der Speicherstelle $03ff kriegt man nur mit "Gewalt", sprich mit einem Poke, einen Buchstaben hin.

Vorwärts brauchte man immer eine Sonderabfrage.

ich hab noch ne 25 byte version, die die 1. zeile unbrührt lässt:
(nur direkt nach reset anwendbar)

@edit: hmmm... da schein ich wieder probleme mit unterschiedlichen start-stack-pointern zu haben (lag wohl am modul).
hab aber auch version wo es ohne modul geht... kommt gleich.

@edit2: hmmm..scheint nicht am modul zu liegen, sondern wenn ich was lade?! Nach RESET und dann start (also ein sys) ist stackpoint auf $f7, wenn ich was lade und dann den sys machen ist er auf $f6.

@edit3: hier die version, die man laden kann und dann starten kann (ohne reset)

peiselulli: Wird dann mit deiner 24 byte version ohne dem txs wohl das selbe problem sein, oder?

Zitat von peiselulli

Die Doppelverwendung habe ich ja auch nur gepostet um das ganze ein bischen zu variieren.
Eventuell gibt das ja Anstöße für neue Ideen.

Hatte ich auch schon mal in einer meiner hier nicht veröffentlichten 37 Byte-Lösung. Sowas finde ich extrem cool !

Zitat von peiselulli

Stell jetzt einfach Deine saubere 20 Byte Lösung ein und mach dem Spuk ein Ende, ich bin kurz vorm Durchdrehen von dem Kram ;->

Ich glaube, Roland wartet damit noch ein paar Tage. Immerhin fängt er jetzt langsam mit Sprüngen mitten ins ROM an!

Zitat von Mafiosino

Hallo ich wollte eigentlich auch bei der Compo mitmachen, aber zu mehr als zu peiselullis 27byte "sauberer" Version hat's bei mir von alleine nicht gereicht. Deshalb schnorre ich jetzt bei euch ein bisschen. Hier ist eine "dreckige" 24-Byte-Version aus den anderen zusammengestrickt:

Schöner Einstand!

Zitat von Roland

Nach RESET und dann start (also ein sys) ist stackpoint auf $f7, wenn ich was lade und dann den sys mache ist er auf $f6.

Überprüft, stimmt. Aber warum?! Verschwendet das ROM irgendwo ein Byte? Und wenn ja, wo? Und warum passiert das nur einmal? Wenn man 2x was lädt und dann ein SYS macht, ist der SP immer noch auf $f6.

Zitat

peiselulli: Wird dann mit deiner 24 byte version ohne dem txs wohl das selbe problem sein, oder?

Vermutlich ja. Ich habe sie aber immer nur geladen, da ich immer mit Vice probiert habe. Der Stackpointer war immer auf $f6, daher Adresse $035b ($0351 + $0a).

Zitat von ssdsa

Überprüft, stimmt. Aber warum?! Verschwendet das ROM irgendwo ein Byte? Und wenn ja, wo? Und warum passiert das nur einmal? Wenn man 2x was lädt und dann ein SYS macht, ist der SP immer noch auf $f6.

finde ich auch extrem merkwürdig.

hätte vermutet, dass ein basicaufruf (also der LOAD) auch immer sauber terminiert, also mit dem stackpointer zurückkommt, wie man es aufgerufen hat.
wenn ich aus assembler die loadroutine aufrufe, muss das ja auch gehen (sowas wären hinterher alle RTS zum scheitern verurteilt).
und eben dass es bei 2x auch auf $f6 bleibt... vielleicht macht da irgendwas ein ldx #$f6 txs

wäre mal interessant, ob das noch weitere befehle betrif (ausser LOAD)

Zitat von Roland

finde ich auch extrem merkwürdig.

hätte vermutet, dass ein basicaufruf (also der LOAD) auch immer sauber terminiert, also mit dem stackpointer zurückkommt, wie man es aufgerufen hat.
wenn ich aus assembler die loadroutine aufrufe, muss das ja auch gehen (sowas wären hinterher alle RTS zum scheitern verurteilt).
und eben dass es bei 2x auch auf $f6 bleibt... vielleicht macht da irgendwas ein ldx #$f6 txs

wäre mal interessant, ob das noch weitere befehle betrif (ausser LOAD)

Die RESET-Routine macht erst mal LDX #$FF, TXS. Daher kommt letztendlich wahrscheinlich bei uns SP #$F7 zustande.

Der CLR-Befehl (Routine ab $A663) hat eine Subroutine ab $A67A, die den SP auf #$FA setzt, und dabei aber vorher die Rücksprungadresse sichert, so dass sie zum Aufrufer mit RTS zurückkehren kann. Dies führt dann wohl bei uns zum SP #$F6.

Ich nehme an, dass LOAD intern CLR aufruft. Auch die Warmstart-Routine ab $E37B ruft diese o.g. Subroutine auf. Daher ist auch nach Runstop+Restore der SP bei uns nicht mehr auf #$F7, sondern auf #$F6.

Hallo!

Wünsche Euch allen hier auf diesem Wege noch ein entspanntes Weihnachtsfest.
Und ich weiß - bin mit dieser Nachricht wohl ein paar Jahr zu spät dran (Deadline ...).
Aber ich fand diese Compo so toll, dass ich das Programm auch mal schreiben wollte.
Wenn jemand Lust drauf hat, kann er ja mal seine Meinung, Kritik, Verbesserungsvorschläge
zu meiner Version abgeben.

Die Routine (PRG-Datei) ist 30 Bytes groß und hat die folgenden Einschränkungen:

- Benötigt ein BASIC-Programm zur Vorbereitung seiner Umgebung.
- Hat Probleme mit Bildschirmzeilen, die nicht mit einem Buchstaben [A-Z] enden.
- Hängt sich nach erledigter Arbeit auf (läuft also nur einmal durch).

Dafür denke ich (hoffe ich), dass es den Anforderungen durchaus genügt:

- residiert ab Speicherstelle 4096
- ist startbar per SYS4096

Allerdings habe ich es bislang nicht auf einem echten Brotkasten getestet. Da es sich bei
dem Routinchen aber nicht um Zauberei handelt, sollte das kein Problem darstellen.

Geschrieben habe ich die Routine mit dem Dreamass. Getestet unter WinVICE 2.2 UNSTABLE win64.
Man muss zuerst das BASIC-Programm "DREHENV.PRG" ausführen. Es schreibt den umzukehrenden
Satz in die erste Bildschirmzeile und macht noch ein paar wichtige zusätzliche Pokes.
Danach dann "DREH.PRG" (30 Bytes) laden und per SYS4096 ausführen (dabei dann aufpassen, dass die erste
Zeile nicht wieder oben aus dem Bildschirm raus geschoben wird).

Nachdem man "DREH.PRG" per SYS4096 ausgeführt hat, meldet WinVICE, dass er einen JAM erkannt hat.
In diesem Dialog dann bitte auf Abbrechen klicken, damit man das Ergebnis noch auf dem Monitor
sehen kann.

Hier der BASIC-Code:

Hier der Assemblercode:

Alles in allem:

Der Thread kommt mir irgendwie abgehakt vor: Es gibt leider keine Ergebnisse anderer Leute zu
sehen. Würde mich freuen, wenn ich mal ein Routinchen sehen könnte, was es in noch weniger
Bytes halbwegs stabil hinbekommt.

Bin auf Feedback gespannt!

Wünsche Euch jetzt erstmal einen guten Rutsch.

Viele Grüße
fireworker

Sorry, hatte aber übersehen, dass sich der Thread ja bereits über mehrere Seiten erstreckt und es auch schon so manchen Code zu sehen gibt.
Über Feedback würde ich mich aber trotzdem freuen.

Hallo nochmal,

hier die aktualisierte D64-Datei. Bei der von vorhin habe ich versehentlich das falsche PRG angehängt.