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

last post from fireworker at the

Assemblercompo "Dreh das Wort"

  • 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. 8|


    @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?

  • 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.

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


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

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


    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!


    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. 8|

    Ü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.

  • Ü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. :gruebel


    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 :D


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

  • finde ich auch extrem merkwürdig. :gruebel


    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 :D


    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:


    Code
    1. 10 for i=0 to 38: read x: poke 1024+i,x: next i
    2. 20 data 9, 3, 8, 32, 23, 21, 5, 14, 19, 3, 8, 5, 32, 5, 9, 14
    3. 30 data 5, 32, 6, 18, 15, 5, 8, 12, 9, 3, 8, 5, 32, 23, 5, 9
    4. 40 data 8, 14, 1, 3, 8, 20, 33
    5. 50 poke 780,0:poke 781,0:poke 782,213:poke 1022,0:poke 1023,0
    6. 60 poke 89,40:poke 90,3:poke 91,80:poke 92,3



    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.