Beiträge von Hoogo im Thema „Sammelthread: Lernen aus Fehlern“

    Ok, böse. Aber dann würde ich mal konstatieren: Man kann sich den ganzen Horror sparen, wenn man nur EINE IRQ-Quelle hat :biggrin:

    Genau :thumbup:

    Bei Deiner Kooperativen Idee sehe ich noch die Lücke, wie man die Zeit zwischen "Flag setzen" und "IRQ wechselt zum anderen Thread" füllt. Oder am Besten die Rechenzeit einem anderen Thread überlässt. Da hängt noch was an Problemen dran.

    Wenn ich mich irgendwann wirklich aufraffe, dann werde ich definitiv erstmal Tests schreiben und CIA wahrscheinlich rauswerfen.

    Mit BRK dazu können die dann aber auch zu früh kommen.

    Das hab ich noch nicht ganz gefressen. Setzt BRK etwa nicht das I-Flag?

    Doch, tut es.
    Aus dem Gedächtnis:

    Einfachster Fall. nur VIC:

    Rasterzeile kommt, und Du kannst ganz normal abzählen, wie viele Takte verbraucht werden, bis wirklich der Stable Raster losläuft. Ich zähle 29 Takte. Plus Jitter, plus 6 für den IRQ selber.

    Komplizierter Fall, CIA+VIC ungefähr gleichzeitig

    22 Takte, bis CIA erkannt und das CLI ausgeführt wurde. Sofort (oder 1 Befehl danach?) kommt dann noch ein IRQ. Das wären dann so ca. 30 Takte, die der Stable Raster später als im einfachen Fall losläuft.

    Böse Falle, BRK + VIC

    An der Stelle bmi CIAIRQ passiert der VIC-IRQ. 19 Takte + 6 Takte für den BRK sind schon gelaufen, nach nur 10 Takten wird der stable Raster aufgerufen. Statt 35, also bis zu 25 Takte zu früh.

    Dieser konkrete Fall ist tatsächlich gar nicht problematisch, denn der BRK wird ja dann nach der Ausführung des IRQ abgearbeitet.

    Ich hab's nicht selber getestet. Verstanden hab ich jedenfalls, dass der BRK ausgeführt wird, aber sein Flag nicht setzt.

    Für diesen Fall gibt es doch bestimmt schon Testcode für den Vice.

    Ich hab mal eins gebaut, wo die Tasks dann halt allesamt im Mainloop laufen. Sprich: es wird immer nur die Returnaddresse des ansonsten nornal laufenden IRQs manipuliert.

    Hier sogar dokumentiert: Bitte melde dich an, um diesen Link zu sehen. :smile:

    Ich habe es mit TSX/TXS gemacht und für jeden Thread eigenen Speicher auf dem Stack vorgesehen. So konnte ich dann Scheibchenweise Threads mit gleicher Prio bedienen lassen.

    Entschuldige meine Naivität, aber schließt "stable Raster" nicht sowieso JEDE andere Interrupt-Quelle als den VIC aus? :nixwiss:

    Also ich hätte jetzt erwartet, ein Multitasking-System für den C64 ("kooperativ" mit BRK, oder BRK nur für "syscalls" und preemption via CIA-timer) muss sowieso auf "raster-Effekte" verzichten? :nixwiss:

    Wenn man damit rechnet, dass CIA-IRQs was am TIming verändern, dann geht es schon.

    Mit VIC + CIA muss man damit rechnen, dass VIC später kommen kann, müssten so knapp 30 Takte sein, pha, txa, pha, tya, pha, lda $dc0d, bpl xxx, cli usw. Halbe Rasterzeile verschwendet.

    Mit BRK dazu können die dann aber auch zu früh kommen. Das ganze Register-Retten ist wegen des BRK gestartet worden, just dann kommt ein IRQ vom VIC und wird sofort erkannt. Zuerst BRK über Stack erkennen müsste gehen, aber dann hat der Scheduler Prio vor dem VIC, und man muss mehrere Rasterzeilen verschenken. Taugt auch nix.

    Einfach mal 20 Jahre liegen lassen

    Perfekt :thumbsup: In SOLCHEN Kategorien muss man als "Retro-Coder" denken :thumbup:

    Nochmal mach ich das aber nicht, sonst ist das Publikum vorher gestorben.

    Wegen euch Hektikern so ein Stress wieder hier, echt ey :grab1:

    Edit: Verrätst du auch noch, wie man den "Software-Interrupt" (also BRK) KORREKT erkennt? :wink:

    Wo ist der Denkfehler?

    Ich bin noch nicht wieder in die Programmierung eingestiegen, hab den Bug also noch nicht gefixt und getestet.

    2 Probleme:

    1) Zwischen dem BRK-Befehl und der Erkennung in der IRQ-Routine vergeht Zeit. In der Zeit kann ein IRQ auftreten.

    - Der BRK wird dann geschlabbert. Ist ein Problem, wenn ein Thread nicht darauf vorbereitet ist.

    - Aus Sicht eines stable Rasters kann der VIC-IRQ zu früh kommen, kann bei Selbstmodifikation dann tödlich sein.

    - Wobei das Problem schon wegen erlaubter CIA-IRQs und VIC-IRQs existiert.

    2) BRK und IRQ können exakt gleichzeitig auftreten. Dann wird nicht mal im Statusregister das BRK gekennzeichnet.

    Wegen 2) denke ich, dass ich den BRK gar nicht sicher erkennen kann.

    Bin noch nicht sicher, was die beste Lösung ist.

    Entweder damit rechnen, dass BRK nicht verlässlich ist, was aber das Problem mit Stable Raster nicht löst.

    Oder einen Scheduler ohne BRK bauen, der aus IRQ und Hauptschleife aufgerufen werden kann, was aber vielleicht andere komischen Effekte haben kann.

    Manchmal muss man ein Programm nur eine Weile liegen lassen. Danach hat man wieder einen frischen Blick und entdeckt Fehler, über die man vorher XMal drübergeguckt hat.

    Ich hatte mal ein Multitasking mit BRK aufgebaut.

    Die Erkennung in der IRQ-Routine: Wenn kein VIC-Irq und kein CIA-IRQ, dann war es BRK.

    Das ist leider falsch. Einfach mal 20 Jahre liegen lassen, und schon ist der Fehler gefunden.

    Die Textdateien sind wohl Windows 1252, werden aber als UTF-8 interpretiert.

    Das ist... seltsam. Die kompliziertere Kodierung bei UTF-8 gegenüber 1252 oder ISO o.ä. hat nämlich auch einen großen Vorteil: Man kann sofort erkennen, dass eine Datei nicht in UTF-8 kodiert ist, denn jeder einzelne Umlaut in 1252- oder ISO-Kodierung verletzt die UTF-8-Kodierung. Es ist also sehr einfach, direkt nach dem Laden eine entsprechende Meldung anzuzeigen.

    Vielleicht gibt es da ja auch eine Option irgendwo...

    Ich habe mit vsCode ein altes PHP-Projekt geöffnet.

    Die Textdateien sind wohl Windows 1252, werden aber als UTF-8 interpretiert.

    Umlaute sehen erstmal nur falsch aus, erst beim Speichern sind sie dann wirklich kaputt.

    Über die Statusleiste kann man nach dem Öffnen die Kodierung ändern.

    Würde mich auch nicht wundern, wenn es irgendwo eine Option für den Zweck gibt.