Diskussion:Rasterzeileninterrupt
Geschwindigkeit
Der Text ", und das ganze in einer Geschwindigkeit, die andere IBM-kompatible Computer erst in etwa mit Einführung des Pentium-Prozessors erreichten." ist schlicht und ergreifend falsch! Vor etwas zehn Jahren gab es ein Buch "PC Underground", diesem war eine CD beigelet welche ein mehr als beindruckendes Demo enthielt, welches auf einem 386er mit 16Mhz und VGA-Graphik mehr als flüssig lief. Die Tatsache das viele Entwickler erst zu Pentium-Zeiten eine flüssige Graphik hinbekommen haben liess eher auf einen Mangel an Kenntnis der entsprechenden Architektur schließen.
- in der angegebenen quelle ist davon ebenfalls nichts zu finden. desweiteren ist MOS Technology 6569 und Der Prozessor des C64 kannte keine Optimierungen wie Branch-Prediction, unbelegt. kann bitte jemand vom fach das noch mit quellen belegen, damit es so im artikel bleiben kann. gruss -- Knoerz 11:33, 10. Sep. 2008 (CEST)
- man braucht nicht für jeden kleinkram belege. guck dir das datenblatt zum 6502 an, wenn du es unbedingt ganz genau haben willst. für jemanden, der die prozessoren aus dieser zeit kennt, ist das genauso offensichtlich, wie dass es damals noch keien GHz-CPUs gab. sorry, aber ich glaube, du willst hier nur jemanden ärgern. Rasterzeileninterrupt 13:15, 12. Sep. 2008 (CEST)
- den satz Die Rasterzeileninterruptprogrammierung wurde vor allem auf den Heimcomputern der 80er Jahre (besonders dem Commodore C64) angewendet und war ein in der Demoszene beliebter Trick. betrifft dies auch. wenn der trick so beliebt war, duerften sich ja recht einfach quellen finden lassen, fuer jemand der sich auskennt. -- Knoerz 11:41, 10. Sep. 2008 (CEST)
- dazu müsste man in alte 64er magazine gucken, ansonsten hilft schnelles googlen. ich denke nicht, dass dafür ein beleg notwendig ist, auch dafür, dass der 6502/6510 im C64 steckte, hab ich gerade keinen "beleg" zur hand, der dir genehm wäre, geschweige dann dafür, dass es den C64 überhaupt gab. ich versteh ja deine sorge um die seriösität der wikipedia, aber wenn dir diese einfachen dinge strittig vorkommen (siehe Wikipedia:Belege), schlage ich vor, dass du erstmal sagst, warum. Rasterzeileninterrupt 13:15, 12. Sep. 2008 (CEST)
- Zur Geschwindigkeit: Das sollte man evtl. etwas schwächer formulieren, etwa "Geschwindigkeit, wie sie bei üblichen Anwendungen auf IBM-kompatiblen Computern zu der Zeit unbekannt war" oder so. - Zu "keine Branch-Prediction": Dass etwas fehlt, kann man ganz schlecht per Quelle belegen, es kommt im 6502-Datenbuch einfach nicht vor. Man muss bedenken, dass der 6502 (wie seine Abkömmlinge) zu den alleresten Mikroprozessoren überhaupt gehörte. Branch-Prediction war da noch nicht auf dem Radar. Der 6502 hatte immerhin als allererster Mikroprozessor eine (winzige) interne Befehlspipeline, ohne sie wäre er unrettbar langsam gewesen im Vergleich zur Konkurrenz. --PeterFrankfurt 01:28, 11. Sep. 2008 (CEST)
- naja, man könnte es belegen, in dem man das erste auftauchen der branch-prediction in einer mainstream-cpu findet, und dann feststellt, dass der 6502 ja älter ist. aber ich halte die einwendungen von knoerz für kleinkrämerisch, vermutlich wegen der auseinandersetzung um den artikel Autoreply. Da will jemand die WP kaputtverbessern. Rasterzeileninterrupt 13:15, 12. Sep. 2008 (CEST)
- Im Handbuch des 6502 steht zu jedem Befehl die Anzahl der Takte, die er zu Ausführung benötigt. Für den Programmierer ist somit die Anzahl der Takte einer Schleife deterministisch. --Fomafix 18:59, 11. Sep. 2008 (CEST)
- Zur Geschwindigkeit: Das sollte man evtl. etwas schwächer formulieren, etwa "Geschwindigkeit, wie sie bei üblichen Anwendungen auf IBM-kompatiblen Computern zu der Zeit unbekannt war" oder so. - Zu "keine Branch-Prediction": Dass etwas fehlt, kann man ganz schlecht per Quelle belegen, es kommt im 6502-Datenbuch einfach nicht vor. Man muss bedenken, dass der 6502 (wie seine Abkömmlinge) zu den alleresten Mikroprozessoren überhaupt gehörte. Branch-Prediction war da noch nicht auf dem Radar. Der 6502 hatte immerhin als allererster Mikroprozessor eine (winzige) interne Befehlspipeline, ohne sie wäre er unrettbar langsam gewesen im Vergleich zur Konkurrenz. --PeterFrankfurt 01:28, 11. Sep. 2008 (CEST)
Sorry, der komplette Artikel ist eigentlich bloß fantastischer Unsinn von jemandem, der offensichtlich überhaupt keine Ahnung vom Thema hat. Allein damit, den Blödsinn im Artikel aufzuzählen könnte ich Seiten füllen. Müsste mal am besten komplett neu geschrieben werden, ne Löschung wäre auch okay, weil der Raster-IRQ kein Stück wichtiger oder bedeutungsvoller ist als die anderen IRQs oder der NMI. -- DeeKay64 15:30, 27. Okt. 2009 (CET)
- Das ist Unsinn, da steht nirgends, dass der wichtiger sei oder sowas. --PeterFrankfurt 01:58, 29. Okt. 2009 (CET)
- Der eigentliche Unsinn ist leider wirklich der Artikel selbst. Das beginnt in der ersten Zeile, ein Raster-IRQ ist weder ein "Trick" noch ein "Hack", und auch nicht beschränkt auf die 80er Jahre oder den C64. Die technische Beschreibung des "Hacks" ist Unsinn, da keineswegs die Laufzeiten des Programms vorberechnet werden müssen. Die Verschiebung von Grafikblöcken, das Erzeugen von Mischfarben und das ominöse "Zeichensatz-Scrolling" am C64 haben reichlich wenig bis gar nichts mit dem Raster-IRQ zu tun. Bereits frühe VGA-Karten ermöglichten Hardware-Scrolling und Sprites, dies wurde auch von einigen Spielen genutzt, die keinesfalls eine Pentium-CPU benötigten. --WiDDY64 12:17, 29. Okt. 2009 (CET)
Löschantrag
Diesen unsinnigen Löschantrag können wir doch wohl umgehend wieder entfernen, nicht? --PeterFrankfurt 01:57, 29. Okt. 2009 (CET)
- Habe den LA entfernt. --Fomafix 08:59, 29. Okt. 2009 (CET)
Ich melde mich hier jetzt nicht an (und nein, ich war nicht derjenige der den LA reingemacht hat), und mir ist es prinzipiell auch wurscht wie viel unsinn hier verbreitet wird, aber in diesem "Artikel" ist ca in jedem satz ein fundamentaler fehler. der VIC kann nicht "angehalten" werden. "farbüberlagerungen" haben exakt nichts mit dem rasterzeileninterrupt zu tun, sowie alle anderen beispiele die bequem auch ohne erreicht werden können. und ein "hack" ist er schonmal überhaupt garnicht, sondern eine dokumentierte funktionalität, die übrigens in den meissten videochips dieser (und sogar heutiger) zeit vorhanden ist. allgemein ist die fokussierung auf den C64 quatsch, und maximal als anwendungsbeispiel geeignet (und sollte auch als solches klar erkennbar sein). allgemein könnte der komplette artikel zu einem satz reduziert und der rasterzeileninterrupt als eine von vielen möglichen interruptquellen im allgemeinen interruptartikel genannt werden. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:57, 29. Okt. 2009 (CET))
- Also ich habe den Artikel nicht geschrieben und kenne mich ehrlich auch nicht im Detail mit der Materie aus. ABER: Dass ein Rasterzeileninterrupt bei heute üblichen Grafikchips möglich sein soll, ist mir neu. Das wird uns von der Commodore- und Amiga-Fraktion von den PC-Fanatikern seit 20 Jahren vorgehalten, dass der bei den schnellen PC-Grafikkarten gar nicht nötig sei, weil man einfach immer ein komplettes Bild schreibe. Und das ganze kann dort auch schlecht gehen, da ein PC-Programm auf den unterschiedlichsten Karten mit variierenden Taktfrequenzen und in den verschiedensten Displaymodi mit verschiedensten Auflösungen laufen können muss, also mit grundverschiedenen Timings. Und der "Hack" kam wohl auch aus jener Ecke. Das irritiert mich jetzt alles. --PeterFrankfurt 02:46, 30. Okt. 2009 (CET)
- Vorsicht, nicht rasterstrahlsynchrone programmierung mit dem rasterzeileninterupt verwechseln (so wie es auch in diesem artikel geschieht). ersteres hat mit letzterem wenig bis nichts zu tun, und letzteres ist auch ohne ersteres (per polling) möglich. gängige PC hardware und vor allem software (betriebssysteme) sind ein schlechtes beispiel - die chips können das zwar, aber keins der gängigen betriebssysteme (windows/linux/osx) nutzt ihn (BEOS zb tut dies aber durchaus, und auch ein paar scenedemos für DOS). Ein besseres beispiel sind konsolen, bei denen das eine teilweise essentielle tecnnik ist. viele bekannte effekte auf dem MD/SNES/mastersystem/gameboy usw basieren darauf. (und all diese "können" das sogar besser und ausgefeilter als ein C64 oder amiga. der chip im gamecube/wii hat zb vier davon, die sich nicht nur auf eine vertikale sondern sogar pixelgenau auf eine horizontale position legen lassen) und das mit dem "hack" - das sollte eigentlich jedem klar sein das das keiner sein kann, denn für einen rasterzeileninterrupt muss die entsprechende funktionalität im videochip vorhanden sein, ich wüsste nicht wie man die da rein hacken können sollte. (um mal beim beispiel des VIC zu bleiben - einfach mal in die datenblätter gucken, oder den programmers reference guide. da steht alles drin was man zu dem thema wissen muss. man konnte also schon 1982 bei erscheinen des c64 nachlesen wie das funktioniert, ein "hack" ist für mich was anderes.). -- 62.143.153.84 07:39, 30. Okt. 2009 (CET)
- ach ja, der artikel in der englischen wikipedia ist - wie so oft - sehr viel näher an der wahrheit: http://en.wikipedia.org/wiki/Raster_interrupt -- 62.143.153.84 14:03, 30. Okt. 2009 (CET)
- Ich finde es ja gut, dass Du Dein Wissen einbringen willst, aber ein paar Belege wären schon nett. Die Raster-IRQ-Programmierung war IMHO schon ein Hack, da in der offiziellen Doku nicht vorgesehen. Ich meine mich zu erinnern, dass das erst nach und nach "entdeckt" wurde, und dann in die Programmierbücher kam. Aber wenn Du entsprechend alte Datenblätter hast - imme rher damit. Rasterzeileninterrupt 20:39, 1. Nov. 2009 (CET)
- erkläre doch mal wie man deiner meinung nach in einen videochip den für einen rasterzeilenirq nötigen komperator inklusive der nötigen logik und register in einen chip reinhackt. schreibs am besten gleich in den artikel, dann liegt die versammelte demoscene entgültig im dreck. belege kannst du dir auch mal fein selber ergooglen, ich wüsste aber nicht warum jetzt grade ich welche liefern soll wo der praktisch dein ganzer text aus nicht belegbarem unsinn besteht.
- Ich finde es ja gut, dass Du Dein Wissen einbringen willst, aber ein paar Belege wären schon nett. Die Raster-IRQ-Programmierung war IMHO schon ein Hack, da in der offiziellen Doku nicht vorgesehen. Ich meine mich zu erinnern, dass das erst nach und nach "entdeckt" wurde, und dann in die Programmierbücher kam. Aber wenn Du entsprechend alte Datenblätter hast - imme rher damit. Rasterzeileninterrupt 20:39, 1. Nov. 2009 (CET)
- Wie Widdy weiter unten schrieb: "Commodore 64 Programmer's Reference Guide" von Commodore selbst, 1983, Seite 151. Du "meinst dich erinnern" zu können, willst aber Edits von Leuten rückgängig machen, die es besser WISSEN und das Gerät HEUTE auch noch programmieren? Sag mal was maßt du dir eigentlich an? Was du einfach nicht zu kapieren scheinst ist, dass die ganzen VIC-Tricks (die wirklich nach und nach entdeckt wurden, die meisten übrigens von meinem Gruppenmitglied Roland Tögel aka Crossbow!) *NICHT* auf den Rasterzeileninterrupt angewiesen sind. Man kriegt *alles* auch ohne RasterIRQ hin (manches geht sogar nur ohne mit reinem Speedcode, weil keine Rasterzeit für so Kappes wie nen IRQ bleibt!), kriegt allerdings wahrscheinlich Hirnblutungen beim Timing (frag mal Graham wegen Risen from Oblivion VDC, da hat der sein Rastertiming selber programmiert (der VDC hat keinen RasterIRQ) und musste einen Timing-Loop am Anfang machen, damit das auf den verschiedenen VDC-Versionen stabil lief!) -- DeeKay64 11:18, 2. Nov. 2009 (CET)
- der VIC kann nicht "angehalten" werden - Najaaaa...Auf dem C128 mit dem 2Mhz-Bit in $d030 schon, siehe die Intro von Risen From Oblivion, die ist ohne VIC! ;-) -- DeeKay64 19:54, 30. Okt. 2009 (CET)
- nein kann er nicht. der VIC zeigt in dem fall zwar schrott an, aber er läuft natürlich weiter. da der VIC auch für den ram refresh zuständig ist wäre es auch ziemlich fatal den "anzuhalten". grandiose verschlimmbesserung des artikels btw, nun sind die details zwar (fast) richtig, aber auch bzgl des lemmas komplett irrelevant, da C64 spezifisch :) (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 20:29, 30. Okt. 2009 (CET))
Änderungen von DeeKay64 und Revert 01.11.2009
Nach den Änderungen von DeeKay64, mit denen der angebliche "grobe Unfug" entfernt werden sollte, wurde der Artikel komplett unverständlich für Normalsterbliche und sprachlich auf niedrigem Niveau. Daran ändern leider auch die nachfolgenden Ergänzungen und Korrekturen nichts. Der Artikel ist auf den C64 zugeschnitten, ja, aber für alles andere gibt es keine Belege. Auch muss der Artikel nicht erklären, was ein Interrupt ist. Die Erklärungen zum deterministischen Verhalten sind wichtig und sollten daher nicht mit der Begündung, sie seien "Unfug" gelöscht werden. Ich schaue jetzt, ob ich ein paar Anregungen von DeeKay64 einpflegen kann. Rasterzeileninterrupt 20:36, 1. Nov. 2009 (CET)
- Haha, Junge, Ich verdien mein Geld mit Schreiben, soviel zum sprachlich niedrigen Niveau (finde ich übrigens ganz famos, wie du deine wichtigen Passagen immer in Fett schreibst, das fördert ungemein den Lesefluss! 8). Dein Artikel ist schlichtweg technischer Unfug, so ist es halt nunmal leider, wieso glaubst du nicht Leuten, die es besser wissen, die Praxiserfahrung haben und die auch an der ein oder anderen Demo mitgearbeitet haben? -- DeeKay64 11:04, 2. Nov. 2009 (CET)
interessantes Detailwissen
Dieser Abschnitt erscheint mir interessant, müsste aber irgendwie belegt werden und vor allem verständlich ausformuliert:
Ein Grundproblem für C64-Programmieranfänger ist, dass der IRQ von Haus aus nicht stabil ist. Damit ist gemeint, dass wenn in der IRQ-Routine ein Register mit sichtbarem Einfluss (beispielsweise die Hintergrundfarbe) geändert wird, dieser Effekt in der ersten Zeile horizontal flackert (Jitter). Der Grund: Bei einfacher IRQ-Programmierung wird die IRQ-Routine bei jedem Durchlauf an einer etwas anderen Stelle begonnen, da der Prozessor vor Ansprung der IRQ-Routine zuerst den momentan ablaufenden Befehl zu Ende abarbeitet. Und da die Befehle der 6510-CPU des Commodore 64 zwischen 2 und 8 Taktzyklen brauchen, flackert der Beginn des IRQ in dieser Größenordnung. Um den IRQ zu stabilisieren, gibt es mehrere Varianten, die populärste ist dabei wohl der geschachtelte Doppel-IRQ, in dem in einem IRQ gleich ein zweiter programmiert wird für die darauffolgende Rasterzeile und danach nur noch NOP-Befehle (2 Zyklen) ausgeführt werden, so lange, bis der zweite IRQ eintritt. So ist sichergestellt, dass die Varianz nur noch maximal einen Taktzyklus groß ist, da der Prozessor auf jeden Fall bei Start des zweiten IRQ ein NOP ausführt. Die Ein-Zyklus-Varianz kann durch einen Vergleich der Rasterzeile am Ende der Zeile mit einem Verzweigungs-Kommando (BEQ), das bei Eintreffen der Bedingung drei und bei Nicht-Eintreffen zwei Taktzyklen braucht, auf null reduziert werden.
Himmel, das versteht niemand, und es ist teilweise auch einfach falsch. Jitter ist kein Zeilenflackern, sondern das Zeilenflackern entsteht durch einen Jitterfehler. Lieber lasse ich halbes Wissen im Artikel als Halbwissen reinzunehmen. Rasterzeileninterrupt 20:51, 1. Nov. 2009 (CET)
Links
Die letzten drei Links sind zwar "nur" technische Doku, aber als weiterführende Infos sicher interessant für Freaks, deswegen nehme ich sie mit rein. Rasterzeileninterrupt 20:57, 1. Nov. 2009 (CET)
Falsche Fakten
Jetzt ist der Artikel aber trotzdem wieder noch falscher. 8-/ Prinzipiell kann der gesamte Artikel aus einem einzigen Satz bestehen, "Der Rasterzeileninterrupt ist ein Interrupt, der beim Erreichen einer bestimmten Rasterzeile ausgelöst wird."
Die krampfhafte Fixierung auf den C64 ist, wie mehrfach erwähnt, schlicht und einfach Blödsinn. Ebensogut kann man den Artikel "Musik" in eine Abhandlung über den SID-Chip verwandeln.
Da hier großer Wert auf Belege gelegt wird, würde ich auch gerne welche für die "Farbüberlagerungen mittels Rasterzeileninterrupt" sehen, dafür wird es definitiv keine geben.
Der grobe Unfug mit dem sogenannten "Hack" ist auch wieder drin. Der Rasterinterrupt wird im "Commodore 64 Programmer's Reference Guide" von Commodore selbst beschrieben. In Ausgabe von 1983 befindet sich der entsprechende Abschnitt auf Seite 151.
"Jitter" bedeutet in der Demoscene-Lingo übrigens tatsächlich das Flackern eines nicht stabilisierten Rasters, hier war lediglich die Verlinkung auf den anderen Artikel unsinnig.--WiDDY64 10:41, 2. Nov. 2009 (CET)