Hallo Besucher, der Thread wurde 2,4k mal aufgerufen und enthält 10 Antworten

letzter Beitrag von Zirias/Excess am

Speyes: "xeyes" für den C64!

    Mal was völlig nutzloses für die 1351 Mouse fertig gemacht: http://csdb.dk/release/?id=161762



    Die hier angehängte Version hat ein paar Bytes mehr als die in der csdb, es wird geprüft, ob speyes schon läuft und nicht nochmal gestartet, um einen Absturz zu vermeiden :) (neu starten nach QUIT geht mit SYS49152)


    Der Code "lebt" komplett in $C000-$CBFF, ab $CC00 liegt der Bildschirmspeicher, ab $D000 eine Kopie des Char ROM und in $E000-$E180 die sprites. ZP $02 und $fb-$fe werden benutzt. BASIC sollte nichts mitbekommen, Programme die weder Sprites nutzen noch direkt im originalen Bildschirmspeicher bei $0400 "rumfummeln" laufen normal. Das "Kontextmenü" hält den Rechner an ("modal"), lässt aber die Uhr (TI) weiterlaufen.

    +1 :thumbsup:

    "Wenn du überredet, ermahnt, unter Druck gesetzt, belogen, durch Anreize gelockt, gezwungen, gemobbt, bloßgestellt, beschuldigt, bedroht, bestraft und kriminalisiert werden musst. Wenn all dies als notwendig erachtet wird, um deine Zustimmung zu erlangen, dann kannst du absolut sicher sein, dass das, was angepriesen wird, nicht zu deinem Besten ist." - Quelle unbekannt.

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


    Hab grade die Kommentare auf der csdb gelesen. Warum brauchst Du denn einen Sprite-Multiplexer? Sollten es nicht 4 schwarze Sprites und ein weißes für die Augen und 2 für den Mauszeiger sein?


    EDIT: ah, die Pupillen sind Extrasprites, was?

    Zitat von Claus

    Sollten es nicht 4 schwarze Sprites und ein weißes für die Augen und 2 für den Mauszeiger sein?

    Richtig, plus zwei für die Pupillen, macht 9 -- ansonsten müsste man die Pupillen in die erwähnten 4 schwarzen Sprites zeichnen, das wäre zu rechenaufwändig, da ist der Multiplexer einfacher :)


    Re:EDIT: genau. :)

    Zitat von RKSoft

    Unnütz eigentlich

    Stand ja schon im ersten Satz :D Aber hey, das Vorbild ist genauso unnütz ;) Danke für den netten Kommentar!


    Habe leider einen sehr selten auftretenden Bug entdeckt: Manchmal vermurkst der Code im ersten Frame den Stack was dann dazu führt, dass das "decimal" Flag aktiv ist und damit sind alle Berechnungen kaputt -- Maus und Pupillen tanzen dann wie verrückt. Das passiert nur direkt beim Start und blöderweise so selten, dass an Debuggen mittels "durchsteppen" nicht zu denken ist. Was ich herausgefunden habe ist, dass zwei Bytes zuviel auf dem Stack liegen, wenn der Fehler auftritt. Passieren muss es irgendwo hier


    Dabei zeigt der $FFFE/$FFFF im RAM auf isr_lstab (oder einige Bytes dahinter, je nachdem welches Timing gerade nötig ist wegen Badlines und Mousecursor-Sprites). Ich kann mir nicht erklären, wo da zwei extra Bytes auf dem Stack herkommen sollen. Beim "herumspielen" bin ich beim folgenden geänderten Code gelandet:

    Damit SCHEINT der Bug nicht aufzutreten. Hat jemand eine Idee dazu?


    Hänge hier mal die Version mit dem zweiten Code snippet an :)

    Also mit dem geänderten Code kann ich beim besten Willen keinen Absturz mehr provozieren. Dann nehm ich das mal so hin ohne genau zu wissen, wieso das das Problem behebt ;)


    Habe die Gelegenheit genutzt und noch eingebaut, dass auch sys 49152 das Progrämmchen sauber beendet (und auch wieder neu startet). Im Anhang also die finale Version dieses völlig nutzlosen Spielzeugs :)

    Zitat von zrs1

    Habe leider einen sehr selten auftretenden Bug entdeckt: Manchmal vermurkst der Code im ersten Frame den Stack was dann dazu führt, dass das "decimal" Flag aktiv ist und damit sind alle Berechnungen kaputt -- Maus und Pupillen tanzen dann wie verrückt. Das passiert nur direkt beim Start und blöderweise so selten, dass an Debuggen mittels "durchsteppen" nicht zu denken ist. Was ich herausgefunden habe ist, dass zwei Bytes zuviel auf dem Stack liegen, wenn der Fehler auftritt.
    ...
    Dabei zeigt der $FFFE/$FFFF im RAM auf isr_lstab (oder einige Bytes dahinter, je nachdem welches Timing gerade nötig ist wegen Badlines und Mousecursor-Sprites). Ich kann mir nicht erklären, wo da zwei extra Bytes auf dem Stack herkommen sollen.Damit SCHEINT der Bug nicht aufzutreten. Hat jemand eine Idee dazu?

    Das sieht mir aus, als ob Du CIA-Irqs ganz normal in Betrieb hättest. Ich sehe in dem Code-Schnipsel aber nicht, dass die abgeschaltet würden, oder wie die verarbeitet werden bzw. dass $dc0d der CIA ausgelesen würde.

    Zitat von Hoogo

    Das sieht mir aus, als ob Du CIA-Irqs ganz normal in Betrieb hättest.

    Das wäre dann doch zu einfach ;) Mit aktiven CIA-IRQs läuft alles immer sofort in den Wald.*


    Zitat von Hoogo

    Ich sehe in dem Code-Schnipsel aber nicht, dass die abgeschaltet würden, oder wie die verarbeitet werden bzw. dass $dc0d der CIA ausgelesen würde.

    Was daran liegt, dass das Snippet nur eine nackte interrupt service routine zeigt ;) Der ziemlich früh angesprungende Init-Code beginnt selbstverständlich so:

    Code
    1. init: lda #$7f
    2. sta $dc0d
    3. lda $dc0d


    und erst danach wird der VIC konfiguriert.


    Inzwischen interessiert es mich auch gar nicht mehr, wo manchmal die extra Bytes auf dem Stack herkamen ... die neue Version läuft absolut stabil und der Code ist ohnehin etwas simpler so, also was soll's ;)


    ---
    *) Das ist mir aufgefallen, weil der Kernal blöderweise auch mal die CIA IRQs wieder aktiviert (gefunden beim Abbrechen eines LOAD). Deshalb startet jetzt jede ISR mit dem Aufruf dieser Subroutine (sieht man auch im Snippet oben):