Diskussion:Rasterzeileninterrupt

Vorbemerkungen

Ich bitte alle Diskussionsteilnehmer, Spekulationen oder Behauptungen über andere, sowie persönliche Angriffe zu unterlassen und durch inhaltliche Informationen in natürlicher Sprache (nicht: Codebeispiele) im Abschnitt "Faktensammlung" zur Verbesserung beizutragen. Geht auf den Text ein, argumentiert sauber und führt Grundsatzdiskussionen über die Wikipedia, Belege und Relevanzkriterien dort, wo es angebracht ist (nicht hier). Danke. Rasterzeileninterrupt 12:30, 4. Nov. 2009 (CET)

Bitte den Alternativentwurf beachten und daran mitwirken! Rasterzeileninterrupt 17:18, 4. Nov. 2009 (CET)

Diskussionen

Geschwindigkeit

Diskussionsstrang ursprünglich gestartet von Knoerz

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)

Interrupts gibt es ja gerade, DAMIT man die Ausführungszeiten nicht wissen muss. Und mit irgendwelcher Branch-Prediction hat das ganze überhaupt nichts zu tun, auch auf den neusten CPUs gibt es Interrupts, und die Interrupts-Quelle (in diesem Fall der Videochip) ist der CPU sowas von egal. -- 84.141.223.204 17:50, 3. Nov. 2009 (CET)

Immer diese Pauschalisierungen. Interrupts gibt es für alle möglichen Zwecke. Dass sie einem das Berechnen der Ausführungszeit ersparen, stimmt nicht immer. Wenn Du an einer bestimmte Position im Bild etwas tun willst, musst Du vom (vorhergehenden) Zeilenende aus die Zeit berechnen. Rasterzeileninterrupt 10:13, 4. Nov. 2009 (CET)

Das allerdings hat nichts mit dem Raster-IRQ zu tun. Man kann das auch ohne IRQ machen, einfach indem die CPU selber auf die entsprechende Rasterzeile wartet. Du verwechselst hier den Raster-IRQ mit synchroner Programmierung. -- 84.141.190.39 11:53, 4. Nov. 2009 (CET)

Moment, wie soll denn die CPU auf die Rasterzeile "warten"? Sie erfährt doch vom Bildaufbau überhaupt erst durch den IRQ, oder nicht?

Indem die CPU darauf wartet, dass der Videochip auf einer bestimmten Rasterzeile ist. Dafür muss die CPU nur das Rasterzeilenregister auslesen. -- 84.141.190.39 12:28, 4. Nov. 2009 (CET)

1. Ist das überhaupt "synchron" möglich, also so, dass man garantiert in genau dem Moment, wenn die Zeile beginnt, die Veränderung des Registers bemerkt? Rasterzeileninterrupt 12:42, 4. Nov. 2009 (CET)

Nein, ist es aber auch bei einem Raster-IRQ nicht, denn auch dann muss die CPU den momentan laufenden Befehl erstmal zuende abarbeiten, bevor zur IRQ-Routine verzweigt werden kann. Das sorgt für eine Verzögerung von 0 bis 7 Taktzyklen, in etwa das gleiche, was man auch bei einer Warteschleife bekommen würde. -- 84.141.190.39 12:53, 4. Nov. 2009 (CET)

2. Wenn ja, dann ist das ja schnelles Polling, was irrsinnig Leistung kostet. (Immer davon ausgehend, dass es mal zu Asynchronitäten kommen kann, sonst müsste man natürlich nur einmal den Start finden.) Rasterzeileninterrupt 12:42, 4. Nov. 2009 (CET)

Sicher. Deswegen nimmt man ja auch IRQs. Man kann sowas auch über Timer-IRQs machen. Oder auf anderen Platformen mit Vertical Blank IRQs, Display List IRQs, Copper IRQs usw. -- 84.141.190.39 12:53, 4. Nov. 2009 (CET)

Wie dem auch sei: Du brauchst Die Ausführungszeiten Deiner Assemblerbefehle, wenn Du pixelgenau arbeiten willst. Das steht so im Artikel. (Auf modernen CPUs ist sowas nicht mehr machbar.) Und man kann den RZ-IRQ nutzen, um den Zeilenanfang zu erfahren und dann deterministisch (in bekannter Laufzeit Veränderungen vorzunehmen). Ich sehe hier keinen Widerspruch zum Artikel.

(3.) Wie wäre es, wenn Du Dir mal einen Account zulegen würdest? Mit einer IP zu reden ist irgendwie... doof. Rasterzeileninterrupt 12:42, 4. Nov. 2009 (CET)

Es ist schlichtweg nicht möglich eine Rasterzeile auszulesen. Angenommen man stellt einen ausreichend großen Magneten auf das Datensichtgerät, so kommt es durch Magnetismus[1] zur Ablenkung des Rasterstrahls. Unter Umständen führt dieses Phänomen sogar dazu, dass der Computer (zum Beispiel der Commodore64[2]) bedeutend schneller läuft, da dass Bild vertikal komprimiert wird und daher weniger Rasterzeit in Anspruch nimmt. Bitte unterlasst diese Diskussionen ohne ausreichendes Fachwissen. Es führt in den meisten Fällen zu nichts. (nicht signierter Beitrag von 134.109.192.251 (Diskussion | Beiträge) 12:50, 4. Nov. 2009 (CET))

Unter synchroner Programmierung verstehe ich, was in Synchrone_Programmiersprache beschrieben ist. Was meinst Du damit? Rasterzeileninterrupt 12:14, 4. Nov. 2009 (CET)

Synchrone Programmierung ist, wenn die CPU synchron zu einem anderen Baustein programmiert wird. Das muss nicht zwangsläufig ein Videochip sein. -- 84.141.190.39 12:28, 4. Nov. 2009 (CET)

So kenne ich den Ausdruck nicht, aber zumindest weiß ich jetzt, was Du meinst. :) Rasterzeileninterrupt 12:42, 4. Nov. 2009 (CET)

Diskussionsstrang von DeeKay64

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)

Der Artikel ist nicht auf die 80er Jahre beschränkt, sondern auf PCs dieser Zeit. Die Eingangsformulierung ist aber etwas unglücklich. Die schnelle Verschiebung von (sehr großen) Grafikblöcken ist nicht mit "normalen" Mitteln möglich, sondern erfolgt, wenn ich mich recht entsinne, eben durch Aussetzen des Signals bzw. "leerlaufen lassen" des Chips. Dazu muss die Position des Strahls genau berechnet werden, sonst weiß man ja nicht, wann man das (verschobene) Bild wieder darstellen lassen soll. Und dazu addiert man die Taktzyklen zusammen. Ich habe das selbst mal in einem 64er-Heftchen gelesen, weiß aber nicht mehr in welchem. :( Rasterzeileninterrupt 00:17, 3. Nov. 2009 (CET)

"wenn du dich recht entsinnst", soso. Du scheinst dir da ja ziemlich sicher zu sein bei deinem Unsinns-Artikel, den du ständig wieder revertest, wieso lässt du den also nicht lieber die Leute schreiben, die es WIRKLICH WISSEN? Was du meinst ist kein "Leerlaufen" lassen des Chips sondern ein simpler HSP in horizontaler Richtung (auch "$d011 wanker" genannt) bzw. ein FLD oder Linecrunching in vertikaler Richtung (VSP), zusammen gerne auch AGSP (Any Given Screen Position) genannt. All das hat leider überhaupt nichts mit dem Rasterstrahl per se zu tun, denn der läuft immer weiter, völlig egal, was du machst (Ausnahme: Der VIC II im C128 mit dem 2MHz-Bit in $d030, das ist das einzige, womit du am Rasterstrahl selbst rumtricksen kannst. Geht aber NUR am C128, auch der Monitor kommt dabei schwer ans Kotzen weil das Videosignal halt extrem nonstandard ist. Ich glaub aber nicht, dass du unser C128-Demo "Risen from Oblivion", in dem wir das erstmalig gemacht haben, jemals gesehen hast). Deswegen muss auch gar nix "exakt berechnet" werden, es muss nur sauber getimed werden, damit die Registerschaltungen genau zu dem Zeitpunkt passieren, in dem sie den gewünschten Effekt erzielen. Thus is the magic of VIC-tricks... -- DeeKay64 02:12, 3. Nov. 2009 (CET)

"das schnelle verschieben von grafikblöcken" (richtigerweise: hardwarescrolling) beherrschen davon ab schon frühe vga karten (und teilweise sogar EGA karten). bei denen ist dieser effekt sogar noch viel einfacher als mit der trickserei auf dem c64, nämlich durch setzen eines einzelnen registers (dem framebuffer offset), möglich. die entsprechende passage gehört daher (wie so vieles) aus dem artikel ersatzlos gestrichen, da sie schlicht falsch und dazu auch noch bzgl rasterirq irrelevant ist. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 12:21, 3. Nov. 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 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 doch praktisch dein ganzer text aus nicht belegbarem unsinn besteht. aber gut das du bescheid weisst, du solltest ganz schnell admin werden! leute wie du brauchen löschbefugnisse! (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:51, 2. Nov. 2009 (CET))

Und hier ist der gewünschte beleg: http://zimmers.net/anonftp/pub/cbm/documents/chipdata/6567.zip - das ist ein scan des original datenblatts von commodore. auf seite 11 hat der hersteller deinen angeblichen "hack" dokumentiert. könnte ich jetzt einen beleg für "Durch geschickte Programmierung wurde dieser Determinismus ausgenutzt, und der Video-Baustein VIC für eine definierte Zeit abgeschaltet, bzw. angehalten." oder "Farbüberlagerungen wurden durch Rasterzeileninterruptprogrammierung möglich" sehen? o_O (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 13:08, 2. 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))

neuerliche Kritik von IP

Bitte bitte löscht diesen Artikel oder bearbeitet ihn mit Hilfe von Leute die Ahnung habe. Nur ein Beispiel ist, dass der RasterIRQ ein Hack sein. Ein schöner Hack wenn er selbst in der Commodore Referenz erwähnt wird, also wirklich...tztztz. Hier wir der Artikel auch schon zerrissen http://www.forum64.de/wbb3/index.php?page=Thread&postID=372379#post372379 (nicht signierter Beitrag von 87.123.114.44 (Diskussion | Beiträge) 20:09, 3. Nov. 2009 (CET))

Ich habe Deine "Kritik" mal verschoben, sie ganz oben über eine Diskussion zu hängen ist wirklich unhöflich. Was in Foren "zerrissen" wird, interessiert nicht, nur Fakten interessieren. Link auf Fakten und Erklärungen, und der Artikel wird verbessert. Bemerkungen von wegen "die da sind auch alle dagegen" gehen direkt nach /dev/null, wo sie hingehören. Rasterzeileninterrupt 10:18, 4. Nov. 2009 (CET)

Im Übrigen ist zum Thema "Hack" schon diskutiert worden, und der Artikel wird verbessert. Ich glaube, ich muss die Diskussionsseite mal ausmisten. Rasterzeileninterrupt 10:21, 4. Nov. 2009 (CET)

du solltest mal lieber den artikel ausmisten, der unbelegbare unsinn mit den farbüberlagerungen steht ja noch immer drin. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:00, 4. Nov. 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)

Wenn Du Dein Geld mit Schreiben verdienst, kannst Du Dir ja mal etwas mehr Mühe geben. Auf Fehler bist Du schon hingewiesen worden, und auf inhaltliche Schwächen auch. Wir können das gerne Absatzweise durchgehen, aber dazu nehmen wir die ursprüngliche Version des Artikels, da Dein Neuentwurf eben einfach sprachlich nicht gut ist. Der Leser wird nicht sauber an den Sachverhal herangeführt. Außerdem zuviel Geschwurbel, über Dinge, die hier nicht interessieren. Rasterzeileninterrupt 14:50, 3. Nov. 2009 (CET)

"Die Erklärungen zum deterministischen Verhalten sind wichtig" - sehr falsch. a) kann man strahlsynchron auch völlig ohne rasterzeilenirq programmieren. und b) gibt es bei jede menge platformen die alles andere als deterministische befehlslängen haben wo es auch einen rasterirq gibt (zb den gamecube bzw wii). das eine hat mit dem andren weder ursächlich noch sonst irgend etwas zu tun. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:51, 2. Nov. 2009 (CET))

Also wurde der Rasterzeileninterrupt auf dem Gamecube genutzt, um große, mit der Rechenleistung eigentlich unmögliche, Blockverschiebungen zu bewirken, ohne Berücksichtigung der Ausführungszeiten? Kannst Du das irgendwie belegen? Mir reicht eine Webquelle, sie sollte nur schlüssig sein. Rasterzeileninterrupt 14:50, 3. Nov. 2009 (CET)

nein, auf dem gamecube bzw wii wird dieser interrupt zum absenden der display liste und umschalten der framebuffer genutzt. und wie jetzt auf dieser seite schon mehrfach erwähnt gibt es die dokumentation in der das steht nur unter NDA für offizielle entwickler. oder falls du code lesen und verstehen kannst (was ich mitlerweile doch mehr als bezweifle) auch hier -> http://sourceforge.net/projects/devkitpro/files/libogc/

Entschuldigung, aber Code-lesen... das geht dann doch etwas zu weit. Wie dem auch sei: Dann handelt es sich also um durch den Hersteller vorgesehene Nutzung, ok. Dann sollte im Artikel vielleicht stehen, dass auf späteren Spielkonsolen die Nutzung des RZ-IRQ "normal" geworden war oder sowas. Und der RZ-IRQ muss in Zusammenhang gestellt werden mit anderen "Tricks". Rasterzeileninterrupt 15:30, 3. Nov. 2009 (CET)

die nutzung des rasterirqs war auch schon vor dem c64 normal und kein trick. als trick kann man höchstens die ein oder andre technik bezeichnen die *auch* (aber mitnichten *nur*) durch nutzung des selbigen erreicht werden kann. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 16:04, 3. Nov. 2009 (CET))

"Der Artikel ist auf den C64 zugeschnitten, ja, aber für alles andere gibt es keine Belege." - Ächz.

Gameboy Advance: http://www.coranac.com/tonc/text/interrupts.htm

Super Nintendo: http://en.wikibooks.org/wiki/Super_NES_Programming/SNES_Hardware_Registers

Sega Mega Drive: http://www.gamefaqs.com/console/genesis/file/916377/9755

Den für den GBA kannte ich, die anderen beiden musste ich 10 Sekunden lang googlen.--WiDDY64 21:39, 2. Nov. 2009 (CET)

10 sekunden googlen meinerseits führen zu diesen seiten (zugegeben, alles keine tollen quellen, aber wer die will kann sicher selber googlen... hoffe ich)

schneider cpc: http://nocash.emubase.de/cpcnew.htm

gameboy color: http://wiki.nycresistor.com/wiki/GB101:Working_with_Palettes (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 12:21, 3. Nov. 2009 (CET))

Da steht doch nur, dass es den Interrupt selbst dort gibt, aber welche Relevanz hat das? Der "Trick", ihn für Manipulatinen zu nutzen, war auf dem C64 am bekanntesten und beliebtesten, schon allein wegen der Verbreitung des Geräts. Gibt es in der Demoszene Leute, die mittels RZ-IRQ-programmierung Effekte auf einem Gameboy Advance erzeugen? Quelle? Rasterzeileninterrupt 14:50, 3. Nov. 2009 (CET)

"Gibt es in der Demoszene Leute, die mittels RZ-IRQ-programmierung Effekte auf einem Gameboy Advance erzeugen?" - Ja. Mich. Quelle: Ich.--WiDDY64 16:59, 3. Nov. 2009 (CET)

diesen "trick" (der keiner ist) wird nicht nur in der demoscene, sondern auch in jedem zweiten spiel benutzt. die quelle liefer ich wenn du eine für die ominösen farbüberlagerungen geliefert hast, deal ? (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 15:02, 3. Nov. 2009 (CET))

Kein Deal. Wenn Du den Artikel verbessern möchtest, hilf mit, ohne Bedingungen. Und bitte Diskussionsbeiträge signieren!Rasterzeileninterrupt 15:24, 3. Nov. 2009 (CET)

achso, ich soll also ohne bedingungen deinen unbelegten unsinn akzeptieren ? bestechende logik ! (und signieren kann der bot viel besser als ich. meine modifier keys klemmen :( ) (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 16:04, 3. 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)

Einschub: "Jitter" ist ein technischer Begriff. Ich habe große Zweifel, dass der "in der Demoszene" wirklich etwas anderes bedeutet, da sich die Bedeutung, die Du nennst, aus dem technischen Begriff ableiten lässt. Vermutlich meinen wir also dasselbe. Rasterzeileninterrupt 15:06, 3. Nov. 2009 (CET)

Ok, es mag sein, dass das der Rasterzeileninterrupt ist, aber das wesentliche an diesem ist seine Ausnutzung für ursprünglich nicht vorgesehene Änderungen des Speicherinhalts während des Bildaufbaus. (Vielleicht sollte ich diesen Satz so einbauen?)

Die Fixierung auf den C64 mag falsch sein, obwohl IMHO der C64 schon der wichtigste Homecomputer seiner Ära war, aber der Vergleich mit Musik->SID ist unpassend. Wo ist die Rasterzeileninterruptprogrammierung auf Spielkonsolen dokumentiert? Stand dazu was 64er oder in anderen Schriften? Gibt es eine Web-Quelle? Irgendwas? Mir ist halt nichts dergleichen bekannt, auch wenn ich es mir gut vorstellen könnte.

Die Farbüberlagerungen ergeben sich technisch durch schnelle Farbänderung (und somit Mischung), ich würde sagen: entweder zeilenweise alternierend oder bei je einem Bild (so dass es etwas flackert). Dazu braucht es also nicht wirklich einen Beleg, oder?

Zu dem "Hack": Das ist kein Unfug, zumindest kein grober. Commodore hatte meines Wissens ursprünglich nicht vorgesehen, dass man z.B. mehr als 8 Sprites nutzt. Dass 1983 der RZ-Interrupt im Reference Guide stand, ist natürlich ein Hinweis darauf, dass das eine Fehlannahme sein könnte. Was steht denn da genau? Sind dort die genannten Effekte erwähnt bzw. vorgesehen? Rasterzeileninterrupt 00:12, 3. Nov. 2009 (CET)

1) Hmm, ich würde mal sagen, der *einzige* denkbare Zweck, den ein Rasterzeileninterrupt überhaupt haben kann, besteht darin, zu exakt diesem Zeitpunkt (bzw. an exakt dieser Position auf dem Bildschirm) etwas zu ändern...? 8-)

eben. an der stelle wo der interrupt ausgelöst wird irgendwelche register zu ändern ist die einzige daseinsberechtigung für den rasterzeilenirq, und genau zu dem zweck wurde er eingebaut (und nicht eingehackt, LOL).

Da steht ja auch nicht, dass der Interrupt "eingehackt" wurde, das wäre natürlich Quatsch. Aus welchen Gründen der RZ-IRQ überhaupt existiert, darüber will ich nicht spekulieren, es geht einzig und allein darum, dass mittels des RZ-IRQs mehr aus dem Gerät herausgeholt wurde. Blockverschiebungen gehören dazu, Farbmischungen auch. Rasterzeileninterrupt 15:06, 3. Nov. 2009 (CET)

beweis durch behauptung? nur so als tipp: wenn überhaupt lässt sich der komplette bildschirminhalt umherscrollen (so wie es vga karten über den framebuffer offset konnten - lange vor dem pentium). und farbmischungen brauchen noch immer keinen rasterirq (wo sind da die belege auf die du die ganze zeit pochst?) (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 16:04, 3. Nov. 2009 (CET))

2) Ich habe oben 3 Quellen genannt, die belegen, daß 3 verschiedene Videospiel-Konsolen einen Rasterzeileninterrupt kennen, es sollte kein Problem sein, weitere zu finden. Meines Wissens nach kennt bereits das Atari VCS einen "echten" Raster-IRQ, das kann ich bei Gelegenheit verifizieren, ich habe die Original-Doku im Keller. Aus eigener Erfahrung weiß ich auch, daß gängige Effekte auf dem Gameboy Advance praktisch *nur* mit dem Rasterzeilen-Interrupt möglich sind, im Besonderen das, was man landläufig und falsch "Mode 7" nennt. Bereits das erste kommerzielle Spiel für den Gameboy Advance, F-Zero Advance, nutzt diesen Effekt, und ich selbst habe ein Spiel auf dem Gameboy Advance programmiert, das ihn ebenfalls nutzt. Ich muß allerdings gestehen, daß ich auf die Schnelle z.B. nichts zum Thema "Rasterzeileninterrupt auf dem Schneider CPC" gefunden habe, bin mir aber ziemlich sicher, daß auch diese Hardware ihn kannte.

evtl. eine verwechselung mit den späteren plus-modellen: http://www.kjthacker.f2s.com/docs/ints.html und http://www.kjthacker.f2s.com/docs/cpcplus.html (nicht signierter Beitrag von Classiccoder (Diskussion | Beiträge) 19:58, 4. Nov. 2009 (CET))

Im Artikel steht ja jetzt, dass es den RZ-IRQ auch anderswo gegeben hat. Für Mode 7 gibt es bereits einen Artikel, der ist aber sehr dünn und erwähnt den RZ-IRQ mit keinem Wort. Die Nutzung auf dem Gameboy wäre wegen seiner Verbreitung sicher erwähnenswert, allerdings sollte man dabei berücksichtigen, dass der C64 doch etwas früher da war. Gibt es für die Gameboy-Sache eine Quelle? (Nicht für die Existenz, sondern für die Nutzung.) Rasterzeileninterrupt 15:06, 3. Nov. 2009 (CET)

ich finde das noch immer amüsant das hier belege gefordert werden für fakten die *jeder* programmierer (java und web hempel mal ausgenommen =P) bestätigen kann, gleichzeitig aber die im artikel enthaltenen schlicht falschen und nicht belegbaren aussagen wehement verteidigt werden weil man "sich erinnert". vielleicht sollte man erstmal versuchen seinen eigenen quatsch mit belegen zu untermauern bevor man den mund so voll nimmt :o) davon ab sind *zitierfähige* belege (sprich: originalquellen) für alles was spielkonsolen angeht naturgemäss schwierig zu finden, da man wenn überhaupt nur unter NDA an solche unterlagen kommt. wenn aber "ich erinner mich" reicht, dann erinner ich mich da mal mit :o)

'Meines Wissens nach kennt bereits das Atari VCS einen "echten" Raster-IRQ' - ich nehme alles zurück und behaupte das Gegenteil, das war über Register gelöst, auf die man prüfen musste. Macht allerdings nicht wirklich einen Unterschied. 8-) --WiDDY64 11:03, 3. Nov. 2009 (CET)

Tut mir leid, aber eine unbelegte Behauptung durch eine andere zu ersetzen bringt uns nicht weiter. (Anders gesagt: Die eigenen behauptungen damit zu begründen, dass die der anderen unbegründet seien, geht nicht.) Im Zweifel müssen die unbelegten Sachen eben raus, bis eine Quelle gefunden wurde. Ich suche demnächst nochmal nach meinen alten 64er-Heftchen. Rasterzeileninterrupt 15:06, 3. Nov. 2009 (CET)

Und jetzt wirds unglaublich albern mit Eurer Beleg-Spinnerei: "2600 Programmer's Guide", Steve Wright (Atari), 1979. Ich warte nach wie vor auf einen Beleg für die Mischfarben.--WiDDY64 16:53, 3. Nov. 2009 (CET)

"Im Zweifel müssen die unbelegten Sachen eben raus, bis eine Quelle gefunden wurde." na dann mal los. da bleibt vom artikel ja nicht viel übrig :o) (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 15:09, 3. Nov. 2009 (CET))

3) Dies hat nicht das geringste mit einem Rasterzeileninterrupt zu tun. Schnelle Farbänderung (also das Alternieren zweier verschieden farbiger Pixel) muß lediglich mit dem Bildschirmaufbau synchronisiert werden, dies kann durch eine einfache Abfrage auf $D012 erfolgen. Zeilenweises Alternieren der Farben kann in der Grafik selbst erfolgen, ein schönes Beispiel findet sich z.B. hier: http://noname.c64.org/csdb/release/?id=82537 - man beachte die Mischfarben der Berge im Hintergrund, diese werden auch standardmässig in jedem Zeichenprogramm wie Koalapainter oder Amica Paint so angezeigt werden (solange diese auf einem echten C64 laufen, bzw. auf einem Emulator mit PAL-Emulation).

offensichtlichere beispiele (und mein testmaterial bei der implementation fer PAL emu in vice) -> http://noname.c64.org/csdb/release/?id=50555 und http://noname.c64.org/csdb/release/?id=50556 ... und ja, dafür das die erzeugung von mischfarben (hier ist wohl schnöder interlace gemeint) irgendetwas mit dem rasterzeileninterrupt zu tun hat bräuchte es schon einen beleg. (den es allerdings kaum gibt =P)

Das klingt plausibel. Aber ich sehe da: http://noname.c64.org/csdb/release/?id=82537 nur ein statisches Bild, keine Mischfarben? Rasterzeileninterrupt 15:19, 3. Nov. 2009 (CET)

hättest du mal das oben erwähnte "(solange diese auf einem echten C64 laufen, bzw. auf einem Emulator mit PAL-Emulation)" verstanden ... der screenshot ist schlicht ohne diese PAL emulation gemacht - und ohne PAL en- und dekoding gibts nunmal diese mischfarben nicht - denn DARAUF beruhen sie, und nicht auf dem rasterirq.

4) Gerade der Sprite-Multiplexer ist ein Beispiel auf einen im Design vorgesehenen Effekt: Soweit *ich* weiss, wurde dies in einem frühen Dokument von Bob Yannes erläutert, einen Beleg kann ich sicherlich morgen finden. Auch bilde *ich* mir ein, bereits mehr als 8 Sprites in einem extrem frühen Spiel von Commodore selbst gesehen zu haben. Das werde ich bei Gelegenheit auch verifizieren.

ja, multiplexing wird da irgendwo erwähnt. das ist neben farbbalken auch *die* klassische anwendung .... und es gab beides auch schon bei diversen automaten, vor dem c64. das spiel war wenn ich mich recht erinner das olle commodore soccer (oder basketball?) (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 08:58, 3. Nov. 2009 (CET))

Mea culpa, "Machine Language Programming for the Commodore 64" von Jim Butterfield, 1984, war das. Ich dachte übrigens nicht an Soccer/Basketball, sondern an was anderes - aber gut möglich, daß diese auch mehr als 8 Sprites verwendeten, da sie ansonsten kaum ausreichend Spieler und den Ball hätten darstellen können. --WiDDY64 11:03, 3. Nov. 2009 (CET)

Generell meinen DeeKay, "Herr 62.143.153.84" und ich das hier nicht böse, aber wir wissen ziemlich genau, wovon wir sprechen. Wir kommen alle 3 aus der Demoscene und sind schon recht lange dabei am C64 (und auf Nintendo-Konsolen). 8-) --WiDDY64 00:44, 3. Nov. 2009 (CET)

Natürlich wollen wir den Artikel verbessern. Aber DeeKay64 hat jetzt erstmal eine Sperrung kassiert, weil seine Vorgehensweise da nicht so der Bringer war.

Zurück zum Thema: Also sollte man den Artikel allgemeiner formulieren, und die Behauptung, es handele sich um eine ursprünglich nicht geplante Nutzung entfernen? Ist natürlich die Frage, worauf man sich dabei bezieht. Ich denke, die Chiphersteller hatten sowas noch nicht im Sinn, aber 1984 war es natürlich schon "Standard". (Turrican dürfte wohl zusammen mit anderen Spielen der Gipfel gewesen sein.) In Commodore_64#Grafik steht aber direkt nach Erwähnugn des RZ-IRQs:

Viele der hardwaretechnischen Einschränkungen können durch kreative Programmierung und Ausnutzung von vom Hersteller nicht explizit implementierten (sic!) Nebeneffekten umgangen werden. So lassen sich beispielsweise verschiedene Darstellungsmodi mischen (z. B. obere Bildschirmhälfte Textdarstellung mit Scrolling, untere Bildschirmhälfte Grafik) und auch die acht Sprites mehrfach in verschiedenen Bildbereichen verwenden, so dass viele Spiele weitaus mehr als acht Sprites darstellen können. Durch Ausnutzung von undokumentierten Videochip-Eigenschaften ist auch die Verwendung von zusätzlichen Videomodi möglich, die die Beschränkungen in der Farbwahl und Auflösung teilweise aufheben.

Schreibt jetzt der eine vom anderen ab, oder wie...? :-) Rasterzeileninterrupt 15:19, 3. Nov. 2009 (CET)

Download des 64'er-Magazins

• 64'er Magazin: Demo-Programmierung. Franzis Verlag, 9/1997 (Im Volltext kostenlos abrufbar über http://www.amiga-magazin.de). 

Findet hier jemand die genaue Stelle? Ich finde den Download nicht. Rasterzeileninterrupt 15:08, 3. Nov. 2009 (CET)

hier: http://www.amiga-magazin.de/64er/akheft/a97092a.htm (nicht signierter Beitrag von Classiccoder (Diskussion | Beiträge) 19:58, 4. Nov. 2009 (CET))

Faktensammlung & Diskussionen

Faktensammlung zur Verbesserung

Vielleicht sollten wir mal gemeinsam Fakten sammeln, um den Artikel zu verbessern. (Liste nach unten verschoben.)

Ich glaube es hat wenig Sinn, hier noch mitzuwirken. *Wir* (die Bösen) haben hier so ziemlich jeden einzelnen unserer Punkte belegt, hingegen lese ich nichts ausser Vermutungen und vagen Erinnerungen an die 64'er (die ich im Übrigen nicht gerade als Referenz bezeichnen würde, obwohl ich damals auch das Abo hatte). Lasst den Artikel einfach so wie er ist, er ist halt schlicht und einfach sachlich falsch, lediglich schade für diejenigen, die sich tatsächlich vernünftige Information von der Wikipedia erhoffen. Wenn ich sinngemäß lese, "daß das in der offiziellen Doku steht könnte man wohl als Hinweis sehen, daß das vom Hersteller möglicherweise doch so vorgesehen war", dann fällt mir nichts mehr ein.--WiDDY64 16:53, 3. Nov. 2009 (CET)

Lass doch einfach mal das ganze "Weinen" weg, und wir reden über Fakten.

Fakt ist, dass der RZ-IRQ natürlich fest eingebaut war (wie man auch nur auf die absurde Idee kommen kann, der Artikel sei so gemeint, dass ein Interrupt Request selbst ein Hack sei, ist mit schleierhaft, aber lassen wir das...), dass aber Effekte, die offenbar auf seiner Nutzung beruhen erst Jahre nach Erscheinen des C64 in Spielen und Demos vorkamen. Jetzt wurde ein paar mal gesagt, der RZ-IRQ stünde in diesem oder jenem Handbuch. Das ist natürlich logisch, dass der da drin steht. Was aber interessiert ist, ob z.B. der Sprite-Multipleer von Commodore so von Anfang an vorgesehen war.

Warum ist die 64'er keine Referenz? Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

wo genau steht in der 64er der unbelegbare unfug a'la farbüberlagerungen per rasterzeileninterrupt? und davon ab - nein, ein artikel in einer zeitschrift an den du dich meinst erinnern zu können und auf den du nicht verweisen kannst ist keine referenz. in punkto beleg ist er sogar komplett irrelevant. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:00, 4. Nov. 2009 (CET))

Lieber Rasterzeileninterrupt! Erstmal finde ich es sehr schön, dass Du Dir die Mühe gibst, Artikel in Wikipedia zu schreiben. Diese Diskussion hier verfolge ich nun schon ein paar Tage. Als "aktiv amtierender" Informatiker kenne ich verschiedene alte und neue Systeme und auch den C64 sehr gut, auf dem ich einige Jahre aktiv war. Leider habe ich wirklich den Eindruck, dass Du aus Stolz belegte Fakten zu ignorieren scheinst und lieber Vermutungen und Meinungen im Artikel wiedergibst. Ein Artikel in einer Enzyklopädie sollte sachlich richtig, relevant und frei von unbelegbaren persönlichen Meinungen sein. Diese drei Punkte sind unzureichend erfüllt. Fangen wir doch mit belegbaren Fakten an, auf denen der Artikel fußen sollte:

Soweit waren wir schon. Lies bitte zukünftig erst die Diskussion, bevor Du herablassend wirst und so tust, als seit Du derjenige, der jetzt mal versachlicht. Ich habe die Kritik aufgenommen und bin weiterhin offen für Diskussion. Ich bin nicht offen für Leute, die ihr Wissen mit einem angeblichen oder tatsächlichen Studienabschluss belegen wollen. Wäre schön, wenn Du das verstehen würdest, IP.

Jetzt kopiere ich Deine Liste mit dem Rest zusammen, merge es und baue ggf. Fragen ein... Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

Also der Rasterzeileinterupt:

• Wird vom VIC ausgelöst, wenn der Rasterstrahl das Zeilenende erreicht hat, ja?

nein, am anfang der zeile. die Erwähnung des VIC ist an der stelle davon ab irrelevant, da das bei jedem videochip (mit rasterirq) so ist.

• Ein Rasterinterrupt ist ein Interrupt, der ausgelöst wird, wenn der Bildaufbau ("der Kathodenstrahl") eine bestimmte Zeile im Bildaufbau erreicht.
• Tritt auf NTSC- und PAL-Geräten verschieden häufig auf

da diese verschieden viele zeilen haben, ja, logisch. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 16:04, 3. Nov. 2009 (CET))

• Kann (wie jeder Interrupt) genutzt werden, um Registerinhalte zu ändern
  • z.B. zum Sprite-Multiplexen...
  • ...?
• Die Interrupt-Serviceroutine wird oft dazu benutzt, bestimmte Grafikeffekte zu implementieren. Ein klassisches Beispiel ist das Umschalten eines Grafikmodus im oberen Bildschirmteil (Spielgeschehen) zu einem Textmodus im unteren Bildschirmteil (Punkteanzeige)
  • Funktionsbeschreibung: Rasterstrahl erreicht Zeile X, Grafik-Hardware wird im Interrupt auf Textdarstellung umgeschaltet, Interrupt-Serviceroutine wird beendet. Zweiter Interrupt am unteren Bildschirmrand an Zeile Y, Grafik-Hardware wird zurück zur Grafikdarstellung konfiguriert

Kann man damit nicht auch sowas wie Page-Flipping realisieren, also auch verschiedene Grafikabschnitte von einandner unabhängig sehr schnell verändern? Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

kann man, zwar nicht auf dem commodore c64, aber auf anderen platformen. steht auch schon weiter oben im text aber wurde scheinbar ignoriert und/oder nicht verstanden. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:07, 4. Nov. 2009 (CET))

Sachlich bleiben! Wo genau steht das? Wortlaut? Rasterzeileninterrupt 11:08, 4. Nov. 2009 (CET)

• Ein bekanntes Beispiel für Grafik-Hardware, die den R. unterstützt, ist der VIC-II, der u.a. im Commodore 64 verbaut wurde
  • (Quelle: Original-Datenblatt des VIC-II, verlinken)

Link? Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

der link wurde von mir schon geliefert und steht weiter oben im text. auch dieser wurde anscheinend ignoriert und nicht gelesen. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:07, 4. Nov. 2009 (CET))

• • Beispiel-Spiel aus dem Erscheinungsjahr des C64, in dem ein Split-Screen verwendet wird nennen?

Ja, welches denn? Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

Was absolut nicht stimmt:

• Raster-IRQs sind weder ein Hack noch ein Trick, sondern einfach von den Entwicklern der Hardware vorgesehener Mechanismus. Sonst hätten sie ihn nicht im Datenblatt beschrieben.

Das nervt. Der IRQ selbst ist NATÜRLICH KEIN HACK. Wurde schon oft genug gesagt. Ende der diesbezgl. Diskussion.' Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

• Praktisch *alles*, was man mit Raster-IRQs machen kann, kann man auch ohne sie. Oft ist es aber unangemessen aufwändig.

Das glaube ich nicht, weil die Strahllaufzeiten nicht über mehr als ein paar ms mit dem ohnehin wackeligen CPU-Takt synchron gehalten werden können. Oder andersrum. Ohne IRQ geht da nix. Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

klar geht das: Es wird zwar dann per Code auf die Rasterzeile gewartet, aber nicht mehr automatisch durch einen Interrupt. Der Vorteil eines parallel laufenden Hauptprogramms geht dabei verloren

C64 Beispiel:

sei ; Jeglichen Interrupt AUSSCHALTEN

lda #$3b

:warten

cmp $d012 ;Manuell auf die rasterzeile $3b warten

bne warten

... (nicht signierter Beitrag von 84.189.50.229 (Diskussion | Beiträge) 09:01, 5. Nov. 2009 (CET))

Was soll denn das mit dem Quellcode immer? Code ist kein Beweis, außerdem ging es mir um etwas elektrisches. Aber möglicherweise hab ich da was verwechselt, nämlich das vom Modulator erzeugte UHF-Signal mit dem 50Hz-Bild, das natürlich vom Takt des Rechners gesteuert wird, und nicht durch Netzfrequenz oder sowas. Daher: Unterpunkt abgehakt. Rasterzeileninterrupt 13:05, 5. Nov. 2009 (CET)

"Code ist kein Beweis" ? du wirrkopf. code mag ungeeignet sein zur erklärung, aber als nachweis das etwas so auf einem computer funktioniert ist er *der einzig denkbare und mögliche* beweis.

der rasterstrahl legt auf dem c64 pro cpu takt exakt 8 pixel zurück, und zwar völlig unabhängig davon ob gerade code innerhalb oder ausserhalb einer irq serviceroutine läuft. deine behauptung ist völlig unbelegbar. codebeispiele für zb rasterbalken ohne interrupt könnten bei bedarf geliefert werden, wenn das nicht sinnfrei wäre da du ja eh keinen code lesen kannst und es nicht glauben würdest. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:11, 4. Nov. 2009 (CET))

Wo habe ich behauptet, dass das davon abhinge, ob man sich innerhalb oder außerhalb einer Serviceroutine befindet? Wenn Du sowas unterstellst, obwohl es keiner gesagt hat, musst Du Dich nicht wundern, wenn man Dich irgendwann ignoriert. Wer von uns beiden besser undokumentierten Assembler-Code für eine veraltete CPU lesen kann, müssen wir hier auch nicht besprechen. Du kannst ja in natürlicher Sprache erklären, wie Dein "Rasterbalken" funktioniert, und wieso der RZ-IRQ "überflüssig" ist. IMHO wird er benötigt, um sich mit dem Bildaufbau zu synchronisieren, und dabei kommt es nunmal nicht auf die Geschwindigkeit in Pixel/Takt an, sondern auf die Frage, wo der Strahl gerade ist.

Wenn Du darauf nicht sachlich eingehen kannst und weiter persönliche Angriffe kommen, ignoriere ich Dich, und wenn Du vor Besserwisserstolz aus der Haut fährst. Rasterzeileninterrupt 11:28, 4. Nov. 2009 (CET)

Der Rasterstrahl läuft automatisch durch. Der IRQ hat jetzt den Vorteil, dass man Code ungefähr zu Beginn einer neuen Zeile (plus ein bis mehrer Zyklen) ausführen lassen kann. Das kann man genauso ohne IRQ durchführen, nur muss man dann aktiv auf das Erreichen der Zeile durch den Rasterstrahl warten (Pollen). Da bleibt dann keine Zeit für andere Dinge. Aber machbar ist es genauso. Der Raster-IRQ selbst ist ja auch nicht genau (je nachdem, wo die Unterbrechung zeitlich stattfindet).

--Georg Rottensteiner 13:15, 4. Nov. 2009 (CET)

• Raster-IRQs sind nicht C64-spezifisch
• Sämtliche anderen Informationen (!) wie Branch-Prediction etc. sollten erstmal aus dem Artikel verschwinden, bis deren Details belegt bzw. sachlich richtig sind. Ich gebe Dir auch recht, das man an der einen oder anderen Stelle nicht zu sehr in Details gehen sollte

(Und alles was ich hier geschrieben habe, müsste von den Fachausdrücken, Schreibweise etc. mit dem Rest von Wikipedia abgeglichen werden) Ich könnte noch einiges zu diesem Artikel beisteuern, dazu habe ich aber erst Lust, wenn ein sauberer "Sockel" da ist.

Die Branch-Prediction macht Taktezählen unmöglich, die festen Ausführungszeiten sind typisch für die damaligen Homecomputer. In sofern ist das schon relevant. Das ist bereits belegt (6502-Doku), aber es wird noch diskutiert, in wie weit dieser Determinismus ausgenutzt wurde. Ich halte es für recht logisch, dass man auf dem C64 Takte zählen muss, die Zeit ist knapp bei 1Mhz. Wir sollten dafür einen extra Abschnitt aufmachen. Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

Also lieber Rasterzeileninterrupt, gibt Dir einen Ruck und denke an die Qualität des Artikels, nicht an persönliche Neigungen. Und ja, die Leute, die sich wirklich damit auskennen, klingen oft etwas herablassend. Trotzdem kann es sich lohnen, auf sie zu hören. Gruß, Thomas --88.73.42.220 20:29, 3. Nov. 2009 (CET)

Bitte erst Diskussion lesen und auch, warum DeeKay64 für 24h gesperrt wurde. Dann urteilen. Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

P.S.: Quellen aus Zeitschriften und Büchern geben auch oft persönliche Meinungen wieder. Das kann man verwenden, sollte dies aber auch als subjektive Meinung darstellen. Datenblätter etc. sind als sachliche Belege höher zu bewerten. Gruß, Thomas --88.73.42.220 20:43, 3. Nov. 2009 (CET)

Stimmt. In den Datenblättern steht aber ja nicht "mit dem RZ-IRQ können sie riesige Grafik-Blöcke verschieben", sondern nur, dass es ihn gibt. Das ist aber nicht wirklich überraschend. Rasterzeileninterrupt 10:52, 4. Nov. 2009 (CET)

das das nicht da drin steht *könnte* eventuell daran liegen das man das von dir gemeinte hardwarescrolling (das wie nun schon mehrfach erwähnt keine grafikblöcke verschiebt sondern lediglich den kompletten bildschirminhalt umherscrollt) schlicht dadurch erreicht das man ein bestimmtes register zur richtigen zeit setzt. dieses *kann* in einer interrupt serviceroutine passieren (und das wird oft auch gemacht) - diese ist aber mitnichten dafür zwingend notwendig und hat auch mit dem rasterinterrupt ansich nichts zu tun. das das auch schon mehrmals hier im text erwähnt wurde muss ich anscheinend auch nochmal dran schreiben. *sigh* (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 11:43, 4. Nov. 2009 (CET))

Es geht aber nicht um Hardwarescrolling, sondern um (Grafik-)Blockverschiebungen in beliebiger Richtung. Rasterzeileninterrupt 11:47, 4. Nov. 2009 (CET)

Dem ist nichts mehr hinzuzufügen, außer vielleicht, daß wir erst dann herablassend werden, wenn einfach Fakten ignoriert werden. 8-) --WiDDY64 20:53, 3. Nov. 2009 (CET)

Kurzes Indiz am Rande dafür, dass der Hersteller (Commodore) den Rasterzeileninterrupt zur Modusumschaltung geplant hat: C16/116/Plus4 sowie C128 unterstützen in ihrem BASIC einen Splitscreen-Modus mit Grafik im oberen Bildschirmbereich und Text im unteren, der via Rasterzeilen-Interrupt realisiert wird. Auf dem C64 gibt es diese Funktion nicht, da dessen BASIC überhaupt keine Unterstützung für den Grafikmodus bot. (jetzt argumentiert bestimmt jemand aufgrund letzterem Fakt, dass der komplette Grafikmodus nicht vom Hersteller vorgesehen wäre...) --92.72.119.66 20:56, 3. Nov. 2009 (CET)

Klar gibt es einen Unterschied zwischen "nicht implementiert" und "nicht vorgesehen", letzteres ist eine Wertung. Danke für den Hinweis. Hast Du zufällig einen Beleg zur Hand...? Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

Lieber Rasterzeileninterrupt! Bitte wirf doch einen Blick auf die englische Version des Artikels. Die ist nämlich frei von Halbwissen und den von Dir erfundenen "Fakten". Selbst eine schlechte Übersetzung wäre besser als der momentane deutsche Artikel. -- Mrsid 21:03, 3. Nov. 2009 (CET)

(Ironie)Das ist ja mal eine ganz neue Idee.(/Ironie) :-\ (Sarkasmus)Vielleicht ergänzt Du in der englischen Version kurz sämtliche Fehlenden Quellen und machst aus dem Stub einen richtigen Artikel.(/Sarkasmus) Dann übersetze ich das auch gerne in nahezu perfektes Deutsch. Rasterzeileninterrupt 10:48, 4. Nov. 2009 (CET)

Es gibt leider keine Quellen die Deinen Ansprüchen genügen würden, weil Du so stur bist und die Fakten ignorierst. Gottseidank bin ich nicht auf das deutsche Wikipedia angewiesen. Aber schade drum. Viel Spass noch! -- Mrsid 11:10, 4. Nov. 2009 (CET)

weitere Diskussionen ;)

"Technik"-Kapitel

Also je mehr ich mich in die Materie einlese, desto mehr muss ich den "Rebellen" hier recht geben: Da steht Unsinn drin. Insbesondere das "Technik"-Kapitel stellt mitnichten den RZ-IRQ dar, sondern wie man ihn per getimeten Assemblerroutinen von einem Bildanfangsinterrupt ausgehend nachbasteln könnte, wenn man denn wollte oder es nötig hätte. Das muss tatsächlich radikal korrigiert werden, da es grottenfalsch ist. - Ob man den RZ-IRQ als "Hack" darstellen will und wirklich bei der Behauptung (die auch nicht per Quelle belegt ist!) bleiben will, dass das so vom Hersteller nicht vorgesehen war, sehe ich auch mit wachsenden Zweifeln. --PeterFrankfurt 02:14, 4. Nov. 2009 (CET)

Hallo Peter! Endlich jemand, der auch willens ist, sich mit den Fakten auseinanderzusetzen. Die "Rebellen" sind übrigens Leute, die tatsächlich regelmäßig mit R. zu tun haben und deshalb die nötige Fachkenntnis mitbringen, solch einen Artikel zu schreiben bzw. Fehler in einem geschriebenen zu erkennen. Als "Rebellen" würde ich eher die Leute bezeichnen, die qualitative Verbesserungen sanktionieren. Gute Ansätze für eine kompakten, verständlichen Artikel sind hier in der Diskussion bereits enthalten (u.a. - aber nicht nur - meine Vorschläge, die unter den Experten Zustimmung gefunden haben :) ) Ich würde mir wirklich zutrauen, den Artikel neu zu schreiben, habe aber keine Lust dazu, wenn ich fürchten muss, dass er dem Vandalismus Halbwissender zum Opfer fällt. Gruß, Thomas --194.115.52.3 09:23, 4. Nov. 2009 (CET)

Hallo "Thomas"! Bitte lies doch erstmal durch die (zugegeben langsam unübersichtliche Diskussion), dann siehst Du, dass ich sehr wohl Verbesserungspotential bei "meinem" achso "begluckten" Artikel sehe. (Mir geht dieses "Ich-aber-auch-Genörgel" ein wenig auf den Keks. Langsam verstehe ich die Wikipedia-Diskussionen von beiden Seiten...) Ich sehe durchaus auch einige Fehler und habe daher die Faktensammlung begonnen. Was die qualitativen Verbesserungen angeht, so empfehle ich Dir, den Artikel in der Version von DeeKay64 zu lesen. Der war (auch wenn der Ansatz, den Artikel komplett neu zu schreiben, vielleicht gar nicht so dumm erscheint) einfach so schlecht, dass er auch als Basis nicht taugt. Sowas, und die darauf folgenden Vandalismus-Vorwürfe durch DeeKay64 gehen nicht. Das sollte jedem, der hier mitwirkt, klar sein.

Und bitte bezeichne nicht irgendwelche Leute ungeprüft als Experten. Bisher haben wir da nur Selbsternennungen und Nennung von Registeradressen als "Beleg" ;). Sorry, aber das reicht einfach nicht. Rasterzeileninterrupt 11:03, 4. Nov. 2009 (CET)

Ich bezeichne sie geprüft als Experten, weil ich deren Software kenne und weiß, das sie (vermutlich im Gegensatz zu Dir) schon etliche Rasterzeileninterrupt-Serviceroutinen implementiert habe. Und ja, ich habe die Diskussion gelesen. Nur so bin ich zum Ergebnis gekommen, dass man die Fakten wiederholen und genauer erklären muss

Deine persönliche Meinung ist keine Prüfung. Außerdem erneuter PA. Rasterzeileninterrupt 12:16, 4. Nov. 2009 (CET)

Text

Da steht: "Der Grafikchip VIC (MOS Technology 6569 und ähnliche Varianten) des Commodore 64 und auch moderner Spielkonsolen kann, wenn der Elektronenstrahl in der Bildröhre des Fernsehers bzw. Monitors eine bestimmte Position erreicht, einen IRQ auslösen. Da die Computer als Bildschirm normalerweise einen normalen 50-Hz-Fernseher nutzten, konnte die Zeit, die der Rasterelektronenstrahl der Bildröhre benötigte, um an einen bestimmten Ort auf der Mattscheibe zu gelangen, relativ zum Startpunkt berechnet werden." Das steht nichts von "Bildanfangsinterrupt". Was ist also an diesem Abschnitt nicht korrekt? Zeilenweise passt das schon. Rasterzeileninterrupt 11:15, 4. Nov. 2009 (CET)

Das hier: "Der Prozessor des C64 kannte keine Optimierungen wie Branch-Prediction, so dass die Ausführungszeiten von Assembler-Befehlen konstant und berechenbar waren." ist ganz klar korrekt, der Determinismus ist beim 6502 und 6510 gegeben. Rasterzeileninterrupt 11:15, 4. Nov. 2009 (CET)

Erstens: Die Fachausdrücke nützen nunmal nichts, solange sie nicht erklärt werden. --Skoe 13:17, 4. Nov. 2009 (CET)

Dies: "Durch geschickte Programmierung wurde dieser Determinismus ausgenutzt und der Video-Baustein VIC für eine definierte Zeit abgeschaltet bzw. angehalten. Erst wenn nach Ausführung einiger, eventuell auch sinnloser, Kommandos (NOP – No OPeration, 2 Taktzyklen) der Elektronenstrahl die gewünschte Bildposition erreicht hatte, wurde er wieder eingeschaltet." ist vermutlich fälschlich. Der Satz ist wohl mit Blockverschiebungen im Hinterkopf entstanden. Ich schätze, das Signal wurde dazu nicht abgeschaltet (das wäre auch elektrisch recht heikel), sondern einfach auf schwarz gestellt. Oder es ist tatsächlich kompletter Unfug, und es wurde einfach ein Offset verändert. (Oder beides, um "Schmieren" zu vermeiden.) Das können die "Profis" hier doch jetzt mal konsistent erklären, wie man das gemacht hat. In jedem Fall ist dazu der RZ-IRQ nötig gewesen und ein genaues Timing, also Taktezählen bzw. zumindest konstante Ausführungszeiten der Routinen. Rasterzeileninterrupt 11:15, 4. Nov. 2009 (CET)

der vic kann nicht angehalten werden und bei der von dir gemeinten technik (bekannt als "wanker", "linecrunching", "agsp" - weiter oben im text schon von einem der selbsternannten experten erwähnt aber anscheinend nicht verstanden) werden durch geschickte manipulation eines registers diverse interne counter derartig beeinflusst das der komplette (!!! nicht blöcke ! steht auch schon weiter oben im text *sigh*) bildschirminhalt umhergescrollt werden kann. -> http://codebase64.org/doku.php?id=base:agsp_any_given_screen_position

Erstens: Die Fachausdrücke nützen nunmal nichts, solange sie nicht erklärt werden.

Zweitens: Wieso wird der komplette Inhalt verschoben? Das wäre doch sinnlos. Ich kenne mindestens eine Demo, bei denen Blöcke in einem Bildabschnitt umherwandern. Vermutlich ist das der Effekt, und was Du beschreibst ist die interne Wirkung, aber nur temporär.

Drittens: Du kannst nicht von anderen erwarten, dass sie Code lesen. Entweder erklärst Du schlüssig, was da passiert, in einer Sprache, die, sagen wir: ein Informatiker verstehen kann ("Ich schreibe 5 in Register X" ist keine Erklärung), oder eben nicht. Du bist kein Elite-Hacker, weil Du Assembler-Code für eine veraltete CPU lesen kannst, die Kunst liegt im Erklären.

Viertens: Du kannst den Artikel nicht verbessern, in dem Du 1. Immer wieder das selbe schreibst 2. Auf Nachfragen nicht reagierst 3. Immer wieder Behauptungen über Deine Kompetenz anstellst, die andere dann einfach bitteschön hinnehmen sollen 4. Auf Codebeispiele verlinkst. Rasterzeileninterrupt 11:44, 4. Nov. 2009 (CET)

"Grundsatzdiskussion"

Das Grundproblem an dem Artikel ist, dass der Haupt-Maintainer, wie im Verlauf der Diskussion ersichtlich wurde, über keinerlei Fachwissen und damit Kompetenz zum Thema verfügt. Der Artikel enthält so viele Fehler und Halbwahrheiten, dass sich Leute mit Ahnung, die den Artikel verbessern könnten, mit Grausen abwenden. Deshalb muss der Artikel erst auf eine solide Basis gestellt werden, bevor man weitere Änderungen macht. (nicht signierter Beitrag von Mrsid (Diskussion | Beiträge) 11:50, 4. Nov. 2009 (CET))

Verbesserung ist in Gange, kein inhaltlicher Beitrag. Rasterzeileninterrupt 11:52, 4. Nov. 2009 (CET)

Es kann ja wohl nicht wirklich sein das sich jemand als Experte aufspielt und alle anderen Kommentare und Verbesserungsvorschläge schlicht als "nicht belegt" oder "zu kompliziert" abwimmelt. Ab einem gewissen Punkt ist ja wohl die Mehrheit im Recht, auch wenn man sich das selbst nicht eingestehen will. Aber besonders dann wenn die Mehrheit aus Leuten besteht die tatsächlich mit der Materie zu tun hat, sollte man seinen eigenen Stolz in Frage stellen und nachgeben. Schliesslich ist Wikipedia ja nicht zur Beweihräucherung des eigenen Egos da, sondern um Fakten zu vermitteln. Gewisse (vorallem technische) Themen die ihren Ursprung in einer Sub-Kultur haben, lassen sich u.U. nicht ausreichend mit Quellen belegen, oder in einfachen Worten erklären. -- Mrsid 12:05, 4. Nov. 2009 (CET)

Ich spiele mich nicht als Experte auf, und dass Du das nicht verstanden hast, ist das Problem. Ich versuche hier sachlich vorzugehen, ernte aber statt inhaltlicher Beiträge nur Gekrittel wie von Dir hier und die wiederholte Behauptung, ich habe keine Ahnung. Das ist aber kein Inhalt, den man in den Artikel einfügen kann.

Und (technische) Inhalte lassen sich auch in "Subkulturen" mehr oder weniger belegen. Wo das nicht geht (und das Problem kenne ich durchaus), muss man zumindest konsistent und schlüssig erklären. Dabei geht es nicht darum, ob das in der jetzigen Version des Artikels der Fall ist, sondern wie man da hinkommt. Deswegen die Faktensammlung.

Deine Erläuterungen zur "Mehrheitsmeinung" sind leider falsch. Erstens ist die Demoszene keine Mehrheit, zweitens ist unbelegt, dass diese sich hier überhaupt äußert, und nicht nur (wildes Beispiel, kein PA beabsichtigt:) ein Scriptkiddie mit drei Sockenpuppen, drittens kann auch die Mehrheit falsch liegen. Ich frage mich nur: In welchem Punkt denn? Da Du Dich inhaltlich nicht beteiligst, also keinerlei Punkte nennst, sondern nur Angriffe gegen mich fährst, macht Dein ganzes Gekrittel wenig Sinn.

Also erstens "ergibt" es wenn dann Sinn. Wie war das noch mit dem "sprachlich niedrigen Niveau"? Zweitens lässt die Suggestion, dass alle Kritik an geinem Artikel eigentlich nur der Feldzug eines Einzigen sei, der dich aus einem völlig unerfindlichen Grund fertig machen will äußerst tief blicken. Weil der Artikelinhalt selbst kann ja scheinbar per Definition nicht der Grund für die zahlreiche Kritik sein. Drittens finde ich deinen Ansatz "Änderungen und Kritik bitte hier auf die Diskussionsseite, ich beurteile die dann und pflege sie gegebenenfalls ein" sehr befremdlich und überhaupt gar nicht Wikipedia-konform. Und viertens kannst du zum Beweis meiner Authentizität einfach mal hier gucken! ;-) Und bei "die Demoszene ist keine Mehrheit" fällt mir einfach überhaupt nix mehr ein. Wer ist denn bitte im Jahre 2009 (und hier) deiner Meinung nach "die Mehrheit" in Sachen RasterIRQ? -- DeeKay64 15:22, 4. Nov. 2009 (CET)

Dass die WP nicht zur Beweihräucherung des Egos da ist, sehe ich auch so. Deswegen wehre ich mich gegen die Über-Geeks, die mit Codebesipielen werfen. Schwanzvergleich geht anders. Das hier ist eine Enzyklopädie. Rasterzeileninterrupt 12:24, 4. Nov. 2009 (CET)

Doch, du spielst dich hier als Experte auf, weil Du der ursprüngliche Autor des Artikels bist. Somit stehst Du als Erster in der Beweispflicht. Wo sind die Belege für die Behauptungen in deinem Artikel? Allein die Tatsache das Dein Artikel kritisiert wird, sollten Dir zu denken geben. Wer hätte denn Interesse daran den Artikel zu verschlechtern? Ich persönlich bin nicht jemand der bei Wikipedia Informationen beiträgt, sondern lediglich Konsument. Wenn ich aber Artikel vorfinde, von denen ich selbst weiss das sie falsche Informationen enthalten, muss ich mich dazu äussern. Ich erspare mir selbst Fakten hier hinzuzufügen, weil das andere vor mir schon zur Genüge getan haben. Etliche Versuche den Artikel zu korrigieren, inklusive Quellenangaben und Erläuterungen wurden hier ohne bessere Erklärungen zurückgewiesen. Das erschreckt mich. Es ist also scheinbar schon so das Wikipedia die Spielwiese einige Besserwisser ist, und das wirft ein sehr schlechtes Licht auf die Sache, und zwingt mich in Zukunft bei jedem Artikel zuerst mal die Diskussionsseite zu lesen, bevor ich auf den Inhalt vertrauen kann. Jeder der diese Seite hier liest, kann sich selbst ein Bild davon machen. -- Mrsid 13:37, 4. Nov. 2009 (CET)

Erstens: Willkommen in der Wikipedia. So ist das hier, man sollte übrigens jede Information kritisch betrachten.

Zweitens: Außer Behauptungen und Angriffen steht hier nix.

Drittens: Da Du ach eigener Aussage nichts beitragen möchtest, können wir Dich ignorieren. Bitte lass die Diskussionsseite jetzt in Ruhe. Rasterzeileninterrupt 16:40, 4. Nov. 2009 (CET)

Wenn jemand nicht durch Datenblätter und Erklärungen zu überzeugen ist, helfen nur noch Code-Beispiele. Wie soll man den jemanden überzeugen, der hartnäckig behauptet, die Erde sein eine Scheibe. - Und der sich dagegen wehrt, in's All zu fliegen und einen Blick zu werfen? Und was sollen die Fachkundigen hier tun? Die eine Ausweiskopie schicken? Warum müssen ca. 5 Diskutierende Dir beweisen, dass sie Ahnung haben und nicht umgekehrt? Muss ein Arzt Dir auch beweisen, das er sich besser damit auskennt als Du? Alle hier haben Deine Fragen beantwortet, aber Du beantwortest keine einzige Frage direkt (z.B. nach Farbmischung oder Branchprediction). (nicht signierter Beitrag von Skoe (Diskussion | Beiträge) 13:15, 4. Nov. 2009 (CET))

Hört dieses Nein-Doch jetzt mal auf? Zwischen Erklärung und Behauptung gibt es einen Unterschied. "Wir wissen es besser" ist keine Antwort auf die Frage: "Was passiert da genau?". Das steht weder jetzt im Artikel noch stand es in der Version von DeeKay64, und es tröpfelt nur langsam in der Faktensammlung. Und jetzt hört auf, hier Angriffe zu fahren. Liefert bitte inhaltliche Beiträge, anstatt über Personen zu reden. Rasterzeileninterrupt 16:40, 4. Nov. 2009 (CET)

---

Alternativentwurf

Der Rasterzeileninterrupt ist ein Interrupt, der ausgelöst wird, wenn der Videochip eines Computers die Darstellung einer bestimmten Rasterzeile auf dem Bildschirm oder Fernsehschirm beginnt.

(Gilt das auch für Bildschirme? IIRC funktionierte das nur mit 50Hz-TV-Geräten. Rasterzeileninterrupt 17:12, 4. Nov. 2009 (CET))

Ja, Bildschirm ist der passendere Begriff hier. Rasterzeileninterrupts funktionieren sogar mit Bildschirmen die keinen eigentlichen Rasterstrahl besitzen, wie z.B. das LCD eines Gameboy Advance (ich hoffe das ist oben bereits ausreichend belegt worden, falls nicht steurere ich gerne spezifischere GBA Dokumentation bei, da ich 3 Jahre professionell auf der Plattform entwickelt habe). Und schliesslich kann man ja auch an den C64 Bildschirme (auch LCDs z.b. mit FBAS- oder S-Video-Eingang) anschliessen. -- Mrsid 17:20, 4. Nov. 2009 (CET) (erledigt)

Die Rasterzeileninterruptprogrammierung wurde intensiv auf den Heimcomputern der 1980er Jahre angewendet. Sie wurde bald zu einem festen Bestandteil nahezu aller für 8-Bit-Heimcomputer geschriebener Computerspiele.

Der Bildaufbau auf üblichen Datensichtgeräten wie Fernsehern und Monitoren findet zeilenweise statt. Der Videochip, der die Farbdaten ausgibt, enthält dazu unter anderem einen Zähler für die momentan auszugebende Bildzeile, die sogenannte Rasterzeile. Unterstützt der Videochip einen Rasterzeileninterrupt, kann von der Software eine Zeile festgelegt werden, bei der dieser Interrupt ausgelöst werden soll. Erreicht der Rasterzeilenzähler diesen Wert, signalisiert der Videochip eine Interruptanforderung an den Prozessor. Dieser unterbricht das laufende Programm und führt eine Unterbrechungsroutine (Interrupt Handler) aus. Am Ende der Unterbrechungsroutine fährt der Prozessor mit dem unterbrochenen Programmteil fort.

Ein bekannter klassischer Grafikchip, bei dem der Hersteller die Mechanismen für einen Rasterzeileninterrupt eingebaut hat, ist der VIC-II (MOS Technology 6569 und ähnliche Varianten) (Datenblatt verlinken). Dieser wurde unter anderem im Commodore 64 verbaut. Aber auch jüngere Hardware unterstützt Rasterzeileninterrupts, wie z.B. der Nintendo Gamecube (Quelle? Noch aktuellere bekannt?).

Anwendungen

Eine der einfachsten Anwendungen des Rasterzeileninterrupts ist der geteilte Bildschirm (Split Screen). Dieser kann z.B. in einem Computerspiel den oberen Teil des Bildes im Grafikmodus darstellen und den unteren Teil im Textmodus, z.B. für eine Punkteanzeige. Einige Computer, wie z.B. der C16, C116, Plus4 sowie C128 unterstützen sogar in ihrem eingebauten BASIC einen Splitscreen-Modus, der intern via Rasterzeilen-Interrupt realisiert wird. Auf dem C64 war diese Funktionalität nicht in dessen BASIC implementiert, das überhaupt keine Unterstützung für den Grafikmodus bot. (Verlinken: BASIC-Referenz?)

(Hmm? Mag ja sein, dass man in BASIC direkt keine Unterstützung hatte, aber welche Rolle spielt das? Ein Poke, und der Bildschirm zeigte Grafik. Wie war das denn beim C128, hatte der explizite BASIC-Grafik-Befehle? Rasterzeileninterrupt 17:17, 4. Nov. 2009 (CET))

Ja. Hab auch was dazu gefunden: http://www.commodore.ca/manuals/128_system_guide/sect-06a.htm (Und könntest Du bitte die Diskussion unterhalb dieses Entwurfs verschieben, dann bleibt er zusammenhängend lesbar. Oder Du packst ihn gleich auf die Hauptartikelseite, putzt ihn (Links etc.), machst diese Seite hier leer und wir fangen auf einem weißen Blatt an, weitere Details zu klären.) --Skoe 17:36, 4. Nov. 2009 (CET)

Inline-Diskussionen sind eigentlich ganz gut, man muss sie nur irgendwann zwischendurch rauskürzen. Ich schau mir den Link mal an... Rasterzeileninterrupt 17:54, 4. Nov. 2009 (CET) (erledigt)

Dazu wird vom Hauptprogramm ein Rasterzeileninterrupt für die Zeile vorbereitet, in der auf den Textmodus umgeschaltet werden soll. Das Erreichen dieser Zeile löst einen Interrupt aus. In der Unterbrechungsroutine wird der Videochip so umkonfiguriert, dass er Text darstellt. Dieser Vorgang wird pro Bildaufbau ein zweites mal durchgeführt, um für den oberen Bildteil wieder zurück auf den Grafikmodus zu schalten.

Rasterzeileninterruptprogrammierung ermöglicht auch, den Grafikchip auf Arten zu verwenden, die der Hersteller vermutlich so nicht vorgesehen oder zumindest nicht dokumentiert hatte. So kann zum Beispiel die Begrenzung des Videochips VIC-II auf acht Sprites umgangen werden, indem die in Hardware implementierten Sprites mehrfach untereinander angezeigt werden. Dieses sogenannte Sprite-Multiplexen wurde in vielen C64-Spielen verwendet.

(Was ist nun mit den Blockverschiebungen? IMHO nur möglich, wenn man den IRQ nutzt, um Offsets zu verändern, oder irgendwie anders die Anzeige zu verzögern, so dass ein Block auf der Mattscheibe zu wandern beginnt, obwohl er im Speicher an fester Stelle steht. Rasterzeileninterrupt 17:17, 4. Nov. 2009 (CET))

Das können wir ja genauer untersuchen/erklären, wenn der Hauptartikel steht. Einverstanden? --Skoe 17:36, 4. Nov. 2009 (CET)

Dann vergesse ich das. Ich lege einfach einen Abschnitt Diskussion:Rasterzeileninterrupt#Blockverschiebungen an. Rasterzeileninterrupt 17:54, 4. Nov. 2009 (CET)

Probleme und Grenzen

(evtl.: Variable Interruptlatenzen => unbekannte horizontale Position)

Ähm... Ich habe so 1990 oder so rasend schnelles horizontales Scrolling gesehen. Das muss ja irgendwie funktioniert haben. Wurde da vielleicht nur ein Offset inkrementiert, und der IRQ gewissermaßen als Zeitgeber verwendet? Das würde erklären, warum ich mich nicht erinnere, ein senkrecht geteiltes Bild gesehen zu haben. Andererseits: Sicher, dass es unmöglich ist, die Zahl der zwischen IRQ bis zum Service Routine vergangenen Zyklen zu ermitteln? Rasterzeileninterrupt 17:27, 4. Nov. 2009 (CET)

Das hat mit dem von mir gemeinten Problem nichts zu tun. Aber Details zu dem Thema wie gesagt lieber auf einem weißen Blatt. --Skoe 17:38, 4. Nov. 2009 (CET)

Bei Scrolling wurde immer nur der Offset inkrementiert, plus ggf. Neuberechnung der einscrollenden Zeile/Spalte. Zumindest auf dem Atari XL/XE war das so. Hat aber nichts mit Raster-IRQ (bzw. DLI auf dem Atari) zu tun, es sei denn, das Splitscreen verwendet wurde, um Bildschirmteile unterschiedlich zu scrollen. (Hopper/SquoQuo ohne Anmeldung, keine Sockenpuppe) (nicht signierter Beitrag von 89.244.191.212 (Diskussion | Beiträge) 17:43, 4. Nov. 2009 (CET))

Ok, das war es was ich in Erinnerung hatte: Verschieden schnelles (vor allem horizontales) Scrollen. Rasterzeileninterrupt 17:54, 4. Nov. 2009 (CET)

(Ende Alternativentwurf)

---

Diskussion Alternativentwurf

Kann man sicher noch ausbauen, ist erstmal als Basis gedacht, mit der ein LAE begründet werden könnte. Meinungen? --Skoe 16:35, 4. Nov. 2009 (CET)

Ich finde den Artikel so auf jeden Fall besser. Ein paar kleine Sachen:

1) Interrupt verlinken

Die Verlinkungen sind bei weitem noch nicht vollständig, aus Zeitgründen. Auch die Dokumente aus dieser Diskussion hier müssten noch zusammengesammelt werden.

*hust* Wenn die Diskutanten sich mal bemühen könnten, mit den Quellen rüberzukommen, wird das vielleicht mal was. Ich habe oft genug genau darum gebeten. Rasterzeileninterrupt 17:27, 4. Nov. 2009 (CET)

2) Der Satz: "Sie wurde bald zu einem festen Bestandteil nahezu aller für 8-Bit-Heimcomputer geschriebener Computerspiele." - ist der so richtig? Bin kein Experte in den Punkt, aber wie sah es z.B. auf dem ZX Spectrum oder Amstrad CPC aus?

Gute Frage --Skoe 17:17, 4. Nov. 2009 (CET)

Also Fakt ist wohl, dass es auf dem C64 üblich war, und der Gameboy Advance wurde auch mehrfach erwähnt. Außerdem Atari und... GameCube? Atari glaube ich ungeprüft, aber bisher scheinen wir nur Quellen für den C64 zu haben. Allgemeiner formuliert könnte man sagen: "Sie wurde bald zu einem festen Bestandteil nahezu aller für den C64 geschriebener Spiele und auch auf anderen Plattformen der 8-Bit-Ära angewendet." Besser? Rasterzeileninterrupt 17:27, 4. Nov. 2009 (CET)

Auf Ataris wurde der sogenannten DLI (Display List Interrupt) verwendet, um bspw. Farben oder Zeichensatz zu wechseln (intensiv z.B. bei Alternate Reality genutzt). Ehrlich gesagt war mir die erste Version des Satzes lieber, da weniger C64-spezifisch. (Hopper/SquoQuo ohne Anmeldung, keine Sockenpuppe) (nicht signierter Beitrag von 89.244.191.212 (Diskussion | Beiträge) 17:43, 4. Nov. 2009 (CET))

der ursprüngliche satz ist definitv besser. praktisch alle videochips konnten ab spätestens mitte der 80er rasterinterrupts auslösen, und natürlich wurden diese dann auch benutzt. --62.143.153.84 18:06, 4. Nov. 2009 (CET)

Ich finde die Formulierung "fast aller" immer noch zu stark ohne Belege.. da unabhängig von den anderen Systemen beispielsweise auch Textadventures, viele Strategiespiele etc. auf dem C64 wohl weniger den Raster-IRQ benutzt haben dürften (wenn man VBlank mal aussen vor lässt). Wie wäre etwas abgeschwächt mit "eines Großteils" oder "vieler" anstatt "fast aller"? --Petuschki 14:26, 5. Nov. 2009 (CET)

3) der Teil mit dem Umschalten zwischen Grafik- und Textmodus ist ein wenig zu detailliert, finde ich zumindest. --Petuschki 17:01, 4. Nov. 2009 (CET)

Ich habe mir nur gedacht, wie man einen unbedarften Leser grob erklären kann, was man mit einem R. anfangen kann. Dann sollte der Abschnitt "Probleme und Grenzen" lieber vollkommen raus.

Evtl. kann man den genauen Ablauf etwas zusammenkürzen und einfach sagen, dass bei Erreichen einer bestimmten Horizontalposition umgeschaltet wird. Rasterzeileninterrupt

wenn man das unbedingt erklären will kann man das ganz gut in drei gruppen unterteilen:

- 8bit platformen wie diverse arcade geräte, heimcomputer und konsolen. klassische anwendungen für den rasterinterrupt: split-screen (scrolling), farbbalken (rasterbars), sprite multiplexing. beispiele für geräte: atari 800, c-64, gameboy color, NES

- 16bit platformen wie zb SNES, GBA, Amiga500. klassische anwendung (zusätzlich zu den oben genannten) zb der bekannte "mode 7" pseudo 3d effekt

- "moderne" platformen. hier spielt der raster interrupt nur noch eine relativ untergeordnete rolle und wird typischerweise zum umschalten der aktuellen grafikseite oder zum starten einer display liste verwendet. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 18:21, 4. Nov. 2009 (CET))

Joa, das klingt vieeel besser, als der ursprüngliche Entwurf von DeeKay64. :) Ich verbessere mal ein bisschen, bitte Diffs beachten. Rasterzeileninterrupt 17:08, 4. Nov. 2009 (CET)

Das klingt gut. Wird's doch noch produktiv? :) Die Einschränkung auf Fernseher finde ich nicht ideal, weil Monitore damals auch üblich waren, wenn auch nicht im Heimbereich. Wie wäre es mit Bildschirm oder so? Hab's jetzt oben nicht geändert, damit nicht wieder Dissonanzen entstehen. --Skoe 17:18, 4. Nov. 2009 (CET)

Da meine letzten gefühlten 200 Beiträge Hinweise auf die Faktensammlung waren, nehme ich das mal als Scherz. Monitore waren IIRC problematisch und haben bei RZ-IRQ-Programmierung zu Problemen geführt. Warum weiß ich nicht mehr. Können wir das irgendwie prüfen? Das steht sicher irgendwo drin. Wie gesagt, ich muss meine 64'er erst raussuchen... Rasterzeileninterrupt 17:27, 4. Nov. 2009 (CET)

Nein, das ist vom Monitor unabhängig, und macht keine Probleme. Die Rasterzeileninterrupts werden ja auch ausgelöst wenn gar kein Fernseher oder Monitor am Rechner angeschlossen sind. Das passiert alles nur im Computer, der Fernseher liefert kein Signal zurück, es ist nur ein Ausgabegerät. Er ist daher komplett passiv und richtet sich ganz nach dem Signal das ausgegeben wird. -- Mrsid 17:37, 4. Nov. 2009 (CET)

Ja, dass ein TV ein Ausgabegerät ist, ist klar, vielen Dank auch. ^^ Ok, also waren die Monitore genauso 50Hz-Geräte wie Fernseher? Nur eben mit Composite-Eingang? (Ich hatte keinen Monitor, und der Artikel C64 gibt nichts her.) Und in den USA waren es entsprechend 60Hz-Geräte? ich schreibe mal oben Monitore mit rein... Rasterzeileninterrupt 17:50, 4. Nov. 2009 (CET)

Das stimmt alles. --Skoe 17:57, 4. Nov. 2009 (CET)

Wollte nur sicherstellen das es kein Missverständnis gibt, sorry. Ja, C64 Monitore sind ganz normale PAL/NTSC Videomonitore. Man kann an die auch Videorecorder oder andere Konsolen (z.b. NES/SNES oder irgendwas anderes das ein Standard FBAS Videosignal ausgibt) anschliessen. Und klar, je nach Standard (PAL oder NTSC) sind es entweder 50Hz oder 60Hz. Das ist auch der Grund warum C64 Spiele und Demos die für PAL entwickelt wurden auf NTSC unter Umständen nicht richtig funktionieren (und umgekehrt), da das Rastertiming deutlich unterschiedlich ist. -- Mrsid 17:59, 4. Nov. 2009 (CET)

Ich finde, das sollte im Artikel erwähnt werden, in einem Satz. Rasterzeileninterrupt 18:13, 4. Nov. 2009 (CET)

Rasterzeileninterrupt ist doch ganz einfach:

    (Code gelöscht Rasterzeileninterrupt 22:57, 4. Nov. 2009 (CET))

Da gibt es keinen Hack, sondern einfach nur schlichtes Befummeln von paar VIC Registern die seit Anfang an dokumentiert sind, selbst im C64 Standard Handbuch. Dementsprechend bekommt man nun immer an Y-Pos $52 des Bildes einen Interrupt geworfen und kann dort lustige Effekte machen, wie etwa die Rahmenfarbe ändern. Wer einen Beleg braucht hackt das im Emu in den Turboassembler oder einen Monitor und startet das ganze mal. Genauso gut kann man diesen Effekt aber auch per Polling des Registers $d012/$d011 erreichen. Auch Interrupthandler eines solchen Interrupts ausgeführte Effekte sind nicht zwingend auf diesen Interrupt angewiesen. Jedoch kann durch den Interrupt ein Polling vermieden werden, und somit ausserhalb des Interrupthandlers die CPU für andere Dinge verwendet werden. 92.227.85.187 (Bitbreaker) (20:19, 4. Nov. 2009 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Sorry, aber das hilft uns nicht weiter und passt auch nicht zum Diskussionstrang hier. Der Code ist sicher auf speziellen C64-Seiten besser aufgehoben als in der WP. Rasterzeileninterrupt 22:57, 4. Nov. 2009 (CET)

Hab mal einen Bearbeitungsbaustein gesetzt, damit sich keiner mehr unnötig Mühe am alten Artikel macht. Rasterzeileninterrupt 22:57, 4. Nov. 2009 (CET)

Hack

Nochmal zu dem Begriff "Hack":

Oben wurde leider nur gebetsmühlenartig wiederholt, dass der RZ-IRQ kein Hack sei, was klar ist. (Ist halt ein Signal.) Aber es geht dabei um etwas anderes, um das "Aufbohren" des Geräts. Im Entwurf steht ja jetzt, dass die Funktionalität so vermutlich nicht vorgesehen (oder vielleicht auch "nur" nicht vorhergesehen) war. IMHO rechtfertigt das den Verweis auf das Lemma Hack. Hack bedeutet ja (wie im ursprünglichen Text beschrieben) den kreativen und respektlosen Umgang mit Technik. (Technik "verdient" im Gegensatz zu Menschen nicht immer Respekt.)

Die Frage ist jetzt: Haben sich schon vor dem C64 Programmierer den RZ-IRQ zu nutze gemacht? Wenn der schon herstellerseitig unterstützt wurde, ist das ja eher ein Argument dagegen, denn es war eine "interne" Funktion. Die Manipulation von Offsets im RZ-IRQ-Handler ist außerdem etwas anders als ein simpler Split Screen. Meinungen? Rasterzeileninterrupt 17:44, 4. Nov. 2009 (CET)

Das einzige was im Entwurf in der Richtung steht, daß es weiterführende Techniken gibt (wie z.B. Spritemultiplex), die so evtl. vom Hersteller nicht vorhergesehen wurden. Das ändert aber nichts daran, daß der IRQ natürlich vom Hersteller vorgesehen wurde (btw: ich würde Spritemultiplex auch nicht als Hack bezeichnen). Hack in dem Sinne wäre für mich z.B. der "HIP Mode" auf Ataris, der einen "Fehler" im Grafikchip ausnutzt, um in hochauflösenden Grafiken die Anzahl der Farben zu erhöhen. (Hopper/SquoQuo) (nicht signierter Beitrag von 89.244.191.212 (Diskussion | Beiträge) 17:54, 4. Nov. 2009 (CET))

Nachtrag: Um Splitscreen zu machen, wird üblicherweise der RZ-IRQ benötigt, um eben die verschiedenen Register und Offsets vor Beginn des nächsten Abschnitts zu wechseln. Insofern ist das Manipulieren des Offsets im RZ-IRQ ein Teil, um Splitscreen zu erzeugen. (Hopper/SquoQuo) (nicht signierter Beitrag von 89.244.191.212 (Diskussion | Beiträge) 18:00, 4. Nov. 2009 (CET))

Es ist scheinbar subjektiv, ob etwas ein Hack ist oder "bestimmungsgemäßer Gebrauch". Wenn in der Spec, steht, dass ich mit dem Register XYZ1 einen RZ-IRQ programmieren kann, und das in Register XYZ2 die Y-Koordinate steht, an der ein Sprite dargestellt wird, brauche ich nur 1 + 1 zusammenzählen: Sprite oben hinprogrammieren, RZ-IRQ in die Mitte legen, Sprite unten hinprogrammieren. Das Grafikchip macht genau das, was in der Spec steht, er malt das Sprite an der programmierten Position. Also IMHO kein Hack, höchstens ein Trick. Sowas wie: Wenn Du untertourig fährst, sparst Du Benzin.

Das Beispiel mit dem offenen Border: Es gibt ein Register, mit dem man im VIC-II zw. 25- und 24-Zeilendarstellung umschalten kann. Die Bedeutung ist in Zusammenhang mit Scrolling zu sehen. Wenn ich nun einen RZ-IRQ in die 25. Zeile lege und dann dort auf 24 Zeilen umschalte, "vergisst" der VIC, dass er am unteren Rand angekommen ist und eigentlich die Rahmenfarbe darstellen müsste. Und dann stellt er manche mehr (Sprites) und manche weniger sinnvollen Sachen (Ghostbyte) dar. Das ist auf alle Fälle nicht so geplant gewesen, also könnte es als Hack bezeichnet werden (was nicht abwertend ist).

Meine Meinung: Im Kapitel "Anwendungen" könnte das Wort Hack etwa so auftauchen: "RZ-IRQs wurden außerdem in Hacks benutzt, die die Möglicheiten des Videochips....." Einvestanden? --Skoe 19:24, 4. Nov. 2009 (CET)

Bitte Gnade. Kein "Hack"! Wieviele Leute müssen diese Wortwahl noch bemängeln? Fakt ist, dass man die meisten VIC-Tricks, die man als "Hack" bezeichnen könnte überhaupt gar nicht mittels eines RasterIRQs realisieren könnte! Das einzige, was mir jetzt einfällt wo der immanente Jitter des RasterIRQ kein Problem darstellt wäre das Öffnen des Upperlower Borders bzw. ein FLD - und Sprite-Multiplexer, was *keine* vom Hersteller nicht vorgesehene Nutzung darstellt (Siehe Butterfield, 1984)! Alle anderen VIC-Tricks (FLI, FPP, Linecrunching, AGSP etc) erfordern zyklusexaktes Timing - was wiederum manuell programmiert werden muss, ohne IRQ (will sagen: Bis der Raster erstmal stabil ist ist der IRQ längst Geschichte!). Wie oben schon gesagt: Wenn's um einzelne Zyklen geht kann man sich keine 3 Rasterzeilen leisten um einen jitternden IRQ zu stabilisieren! -- DeeKay64 21:02, 4. Nov. 2009 (CET)

Vielleicht ist es wirklich so, dass man nicht mit aller Gewalt hier einen Hack reininterpretieren sollte, wenn es so umstritten ist. Es würde den Artikel nicht tatsächlich verbessern. In meinem Entwurf habe ich ihn nicht ohne Grund nicht erwähnt. --Skoe 22:41, 4. Nov. 2009 (CET)

Ich fand die Formulierung von Skoe schon ganz gut, man könnte vielleicht sowas schreiben wie "Effekte/Funktionalitäten, die vom Hersteller offenbar nicht vorgesehen/bewusst eingeplant waren...", (natürlich ohne Schrägstriche). Die Kritik von DeeKay64 kann ich nicht nachvollziehen. Es ist ja nicht so, dass kein Zusammenhang zwischen den Programmiertricks (und solche kann man durchaus als Hacks bezeichnen, das ist ja eine der ursprünglichen Bedeutungen) und dem RZ-IRQ besteht, oder dass dieser Zusammenhang weg wäre, nur weil schon X Taktzyklen vergangen sind.

Das ist genau das, was du schlicht nicht kapieren willst, egal ob wir es noch hundertmal wiederholen: Der RasterIRQ hat *nichts* mit fortgeschrittenem VIC-Coding und -Tricks zu tun! Nichts! Nada! Es ist eine Technik, die nur einem einzigen Zweck dient: Dass der Coder nicht umständlich auf eine Rasterzeile warten muss durch ständiges Pollen des $d012 Registers - was *während* der VIC-Tricksercode läuft nicht nötig ist! -- DeeKay64 23:27, 4. Nov. 2009 (CET)

Genau, beides wird bzw. wurde gemeinsam angewendet, und das ist der Zusammenhang.

Nein. Bitte google den Unterschied zwischen einer hinreichenden und einer notwendigen Bedingung. -- DeeKay64 02:03, 5. Nov. 2009 (CET)

So wie Straßen und Autos zusammengehören, obwohl das eine das andere nicht braucht. Rasterzeileninterrupt 23:54, 4. Nov. 2009 (CET)

Nein, eher wie ein elektrischer und ein manueller Korkenzieher und eine Flasche Wein. Mit beidem kriegt man den Wein auf, aber beim einen muss man halt ein bisschen drehen und beim anderen nur auf nen Knopf drücken. Da es aber beim Weintrinken eher selten um das Flaschenöffnen sondern vielmehr um den Wein selbst (die VIC-Tricksereien) geht würde auch niemand behaupten, dass ohne elektrischen Flaschenöffner kein Weintrinken möglich wäre! -- DeeKay64 02:03, 5. Nov. 2009 (CET)

Nur ist es eben so, dass elektrische Korkenzieher eher selten sind, der RZ-IRQ aber häufig. Das ist ein faktischer Zusammenhang, ich spreche schon lange nicht mehr von Vorraussetzng. Und in dem Artikel geht es um den RZ-IRQ, also in Deiner Analogie um das Öffnen der Flasche, nicht das, was danach kommt. Was ist daran schwer zu verstehen? Ein Korkenzieher erleichtert das Trinken von Wein. Der RZ-IRQ erleichtert Effekte A, B und C. Rasterzeileninterrupt 13:26, 5. Nov. 2009 (CET)

Nachtrag: Man könnte also formulieren, dass der RZ-IRQ VIC-Tricksereien (die mit dem Determinismus) massiv vereinfacht. Ich vermute sogar aus dem Bauch raus, dass das Polling so viel Zeit kosten würde, dass andere Sachen (Hintergrundmusik, Spiellogik) darunter leiden würden. Hab ich jetzt nicht nachgerechnet, aber es geht ja ohnehin um den Zusammenhang zwischen den beiden. Rasterzeileninterrupt 00:05, 5. Nov. 2009 (CET)

Nein, könnte man nicht. Nochmal: Für die meisten VIC-Tricks KANNST du gar keinen RasterIRQ nehmen! Weil a) jitter, ergo nicht genau genug und b) keine Rasterzeit dafür da ist. Und das mit dem "spielelogik etc leidet massiv" zeigt nur wieder mal, dass du es immer noch nicht kapiert hast. Ein Frame am c64 hat auf PAL-Systemen etwa 18500 Taktzyklen. Wenn man jetzt mal ein Spiel als Beispiel nimmt dann braucht die Grafik X Zyklen, die Musik Y und die Spielelogik Z. Wenn jetzt X+Y+Z größer als 18500 ist hast du ein Problem, völlig egal, ob du $d012 pollst oder nen RasterIRQ programmierst, um auf eine bestimmte Zeile zu warten. Wenn es kleiner ist ist es Jacke wie Hose, was du mit den übrigen freien Zyklen anstellst, wobei in vielen Fällen ein RasterIRQ halt einfacher programmiert ist und ne sauberere Lösung darstellt. -- DeeKay64 02:03, 5. Nov. 2009 (CET)

Es geht ja auch nicht um "die meisten" Tricks, sondern um einige. Nebenbei: Gegen den Jitter gibt es doch Mittel, wurde hier auf der Seite und IIRC auch in dem Video beschrieben.

Zum Polling: Ich hatte schon gesagt, dass ich das nicht nachgerechnet habe. Dass Polling Rechenleistung kostet, brauchen wir aber doch nicht wirklichzu diskutieren, oder? Rasterzeileninterrupt 13:26, 5. Nov. 2009 (CET)

@DeeKay: Du hast hoffentlich den feinen Unterschied zw. meiner Forumlierung und der von R. bemerkt: Ich habe geschrieben, dass der RZ-IRQ auch für Hacks benutzt wurde (unter der Annahme, dass man das Öffnen des unteren Borders als Hack bezeichnen könnte, da das von den Entwicklern des VIC-IIs höchstwahrscheinlich nicht vorgesehen wurde). Ich habe explizit nicht den RZ-IRQ, Split Screen oder Sprite-Multiplexer oder gar Scrolling (?!) gemeint. Diese Klarstellung nur, damit niemand den Eindruck bekommt, ich hätte keine Ahnung von dem, was ich schreibe. --Skoe 09:40, 5. Nov. 2009 (CET)

Wie gesagt: Ich finde die Erklärung ok, und denke, wir nehmen sie jetzt in den Artikel so auf, auch wenn Deekay64 das nicht möchte. Mir scheint das doch eher Kleinkrämerei zu sein, was dagegen ins Feld geführt wird. Rasterzeileninterrupt 13:26, 5. Nov. 2009 (CET)

Ich tendiere eher dazu ihn nicht in den Artikel mit aufzunehmen, da es a) nicht direkt mit dem RZ-IRQ zu tun hat (siehe Beispiel mit der Zange), b) es hier nur eine Stimme gibt, die es (unbedingt) als Hack bezeichnen möchte c) Den Informationsgehalt des Artikels nicht verbessert --Skoe 13:37, 5. Nov. 2009 (CET)

Ich möchte an dieser Stelle darauf hinweisen, dass "TheK" sich ganz unten explizit gegen diesen "Hack"-Unsinn verwehrt. -- DeeKay64 13:40, 5. Nov. 2009 (CET)

Ohne inhaltlichen Beitrag. (Sowohl TheK, als auch Du.) Etwas als "Unsinn" zu bezeichnen, ist kein Beitrag zur Diskussion. Lern es jetzt bitte, Du störst die Diskussion, und das ist IMHO auch eine Form von Vandalismus. Rasterzeileninterrupt 13:47, 5. Nov. 2009 (CET)

Ok, Skoe hat mich überzeugt. DeeKay64, Du bist schon wieder unverschämt. Rasterzeileninterrupt 13:45, 5. Nov. 2009 (CET)

Fakt ist jedenfalls, dass aus dem C64 weitaus mehr rausgeholt wurde, als man ursprünglich für möglich hielt (zwischen 1984 und 1990 liegen auch Welten). Das geht IMHO nicht auf "normale" Entwicklungen der Informatik zurück, sondern eben auf immer ausgefeiltere Manipulation der Register usw. - aber so langsam drehen wir uns im Kreis. Rasterzeileninterrupt 23:03, 4. Nov. 2009 (CET)

Wir drehen uns deswegen im Kreis, weil du auch nach hundertmal immer noch nicht einsehen willst, dass rastersynchrone Programmierung *nichts* mit dem RasterIRQ zu tun hat! Wie oft müssen wir das noch schreiben? -- DeeKay64 23:27, 4. Nov. 2009 (CET)

Du hast doch gerade geschrieben, was die beiden miteinander zu tun haben.

Ja. "hinreichende" vs "notwendige" Bedingung. *seufz* -- DeeKay64 02:03, 5. Nov. 2009 (CET)

Auch wenn Du den Unterschied kennst, hast Du deswegen noch lange nicht recht. Ich kenne ihn übrigens auch, und er spielt an dieser Stelle einfach keine Rolle, weil wir uns bereits geeinigt haben, dass nicht "notwendig" sondern sowas wie "erleichtern" im Artikel stehen soll. Rasterzeileninterrupt 13:26, 5. Nov. 2009 (CET)

Und jetzt reg Dich mal ab, mach mal ne Wikipause von ein paar Tagen oder so. Danach gibt es einen schönen Artikel, der nicht in jeder Hinsicht Deiner Meinung entsprechen wird, aber sicher besser ist, als der alte. Rasterzeileninterrupt 23:54, 4. Nov. 2009 (CET)

Wie kommst du darauf, dass ich mich aufrege? Ich hab äußersten Spaß daran, dasselbe zehnmal zu schreiben! ;-) -- DeeKay64 02:03, 5. Nov. 2009 (CET)

Nachtrag: "Wir drehen uns im Kreis, weil Du unrecht hast", ist ein schlechter Argumentationsstil. ^^ Rasterzeileninterrupt 00:05, 5. Nov. 2009 (CET)

und wenn es aber doch leider die wahrheit ist ? (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 13:48, 5. Nov. 2009 (CET))

Interessante Deutung. Wo genau steht "weil du unrecht hast"? Ich les da "dass rastersynchrone Programmierung nichts mit dem RasterIRQ zu tun hat", das ist also eine äußerst kreative Interpretation des Gesagten deinerseits. Das geht schon über den PA hinaus in den Bereich der Unterstellungen hinein. Bitte bleib sachlich! -- DeeKay64 02:03, 5. Nov. 2009 (CET)

Da steht: "Wir drehen uns deswegen im Kreis, weil du auch nach hundertmal immer noch nicht einsehen willst,". Rasterzeileninterrupt 13:26, 5. Nov. 2009 (CET)

Rasterzeileninterrupt: Wenn man ein Ziel mit und ohne RZ-IRQ erreichen kann, was in der Realität nunmal so ist (kann Dir gern ein Beispielprogramm schicken, wo etwas einmal mit und einmal ohne gemacht wird), ist der RZ-IRQ nunmal keine Voraussetzung für dieses Ziel. Nur weil man mit einer Zange auch einen Nagel in die Wand schlagen kann, muss ja dieser Fakt nicht im WP-Artikel über Zangen vorkommen, stimmts? Übrigens kommt es wirklich auf das Programm und einige Randbedingungen an, ob RZ-IRQ oder Polling geeigneter ist. Aber genau da verlieren wir uns in Details, die die Komplexität eines WP-Artikels übersteigen, soll ja kein Programmierkurs werden. --Skoe 09:40, 5. Nov. 2009 (CET)

Nachtrag: Man darf natürlich nicht vom heutigen Wissen ausgehen. Rasterzeileninterrupt 23:11, 4. Nov. 2009 (CET)

Der C64 hatte doch nur einen 4-Farb-Modus mit voller und einen 16(?)-Farb-Modus mit halber Auflösung. Mit dem RZ-IRQ konnte man da deutlich mehr rausholen. Ich würde das schon als Hack bezeichnen, egal, ob es nun durch Page Flipping oder Farbmischungen (nein, hab ich immer noch keine Quelle für) oder sonstwas gelungen ist. und den Sprite-Multiplex auch. Ein Hack muss ja auch nicht "böse" sein, wie die Nutzung von "illegalen" OpCodes. Es genügt IMHO, etwas zu "verbiegen" und kreativ zu nutzen. Hmm. Rasterzeileninterrupt 18:03, 4. Nov. 2009 (CET)

Soso, der c64 hatte also einen 4-Farb-Modus. Und illegale Opcodes sind "böse". Was man hier nicht alles lernt! ;-) -- DeeKay64 02:13, 5. Nov. 2009 (CET)

der von dir gemeinte effekt heisst unter democodern "FLI", und ja, den könnte man durchaus als nicht so vorhergesehen oder "hack" bezeichnen. --62.143.153.84 18:11, 4. Nov. 2009 (CET)

Und FLI steht für was? Rasterzeileninterrupt 18:14, 4. Nov. 2009 (CET)

"flexible line interpretation", was den effekt beschreibt das wenn man dem VIC zu gegebener zeit, nämlich jede rasterzeile einmal, durch manipulation des y-scroll counters vorgaukelt er wäre jetzt am anfang einer character-zeile und müsste somit daten aus dem ram lesen um diese darzustellen erreicht das nicht wie üblich alle 8 sondern jede zeile neue daten - in dem fall neue farben - gelesen werden. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 18:27, 4. Nov. 2009 (CET))

Man sollte an dieser Stelle dringend erwähnen, dass FLI mit einem RasterIRQ unmöglich zu realisieren ist. Man macht maximal am Anfang einen (muss aber nicht) und dann war es das in Sachen RasterIRQ, mindestens bis zum Ende der FLIgfx. -- DeeKay64 02:13, 5. Nov. 2009 (CET)

Irgendwo hier war doch ein Beispiel aus den 70ern. Finde ich gerade nicht... --Skoe 17:57, 4. Nov. 2009 (CET)

Oben steht: "2600 Programmer's Guide", Steve Wright (Atari), 1979. Hab ich jetzt gerade nicht zur Hand... Rasterzeileninterrupt 18:04, 4. Nov. 2009 (CET)

Blockverschiebungen

Hier möchte ich mal erklärt haben, wie das nun genau geht... ^^ Rasterzeileninterrupt 18:03, 4. Nov. 2009 (CET)

As said: Es gibt so etwas nicht, mein Vorschlag wäre, daß Du ein Demo/Spiel nennst, bei dem Du das gesehen hast. Dann können die C64-Experten vermutlich sehr schnell und sehr detailliert beschreiben, was technisch dahintersteckt, just my 0.02$. (Hopper/SquoQuo) (nicht signierter Beitrag von 89.244.191.212 (Diskussion | Beiträge) 18:08, 4. Nov. 2009 (CET))

Hä? Natürlich gibt es horizontale und vertikale Blockverschiebungen. Reden wir evtl. aneinander vorbei? Natürlich schiebt man nicht einen Block in den anderen, es müssen schon abgegrenzte Bereiche oder der gesamte Bildinhalt sein. Rasterzeileninterrupt 18:13, 4. Nov. 2009 (CET)

Als Blockverschiebung würde ich evtl. bezeichnen, was der Blitter im Amiga macht. Im Atari (wohl auch C64 und den meisten 8Bit Maschinen) z.B. gibt es zwei Dinge: Grobes Scrolling durch verschieben der Grafik-Adresse (dabei kann natürlich nur byteweise verschoben werden, also z.B. um ein ganzes Zeichen oder um 4 Pixel, je nach Grafikmodus) plus Feinscrolling per Register. Dabei wird dann dem Grafikchip mitgeteilt, er möge den Screen um eine definierte Anzahl Pixel nach oben/unten bzw. links/rechts verschieben (üblicherweise im Bereich der Breite/Höhe eines Zeichens, d.h. 8x8 Pixel im hochauflösenden Modus). Aus der Kombination von beidem entsteht dann Scrolling. Dabei muss wie gesagt der entsprechend erscheinende Bildbereich (Zeile/Spalte) neu berechnet werden. Wenn nun bspw. im Split Screen oder Mehrebenenscrolling verschiedene Bildbereich unterschiedlich scrollen, so werden die Register für Adresse und Feinscrolling eben in einer entsprechenden Zeile per IRQ oder mitten in der Zeile (nach einer berechneten Anzahl von Cycles) gewechselt. Speziell letzteres ist aber knifflig und würde hier definitiv zu weit führen (Hopper/SquoQuo) (nicht signierter Beitrag von 89.244.191.212 (Diskussion | Beiträge) 18:24, 4. Nov. 2009 (CET))

In dem Video von diesem Vortrag wird das erklärt: http://www.pagetable.com/?p=54 (konkreter Teil beginnt ab Minute 50:00, aber auch alles davor und danach ist sehr relevant zum Thema) -- Mrsid 18:14, 4. Nov. 2009 (CET)

Beschreibung von Rasterinterrupts beginnt zirka ab Zeitindex 41:30 -- Mrsid 18:20, 4. Nov. 2009 (CET)

Ja, das Video kannte ich schon. Gerade nochmal reingeguckt. Also ist es doch so, dass für horizontales Scrolling, zumindest wenn es in einem (vertikal) abgegrenzten Bildbereich passiert, der RZ-IRQ verwendet wird, und dass Cycles abgezählt werden, wenn man etwas "mitten" in der Zeile tun will. Somit werden sehr große Pixelblöcke mit minimalem Aufwand verschoben. Ist doch prima, das sollte im Artikel stehen, finde ich. Allerdings für Normalsterbliche verständlich. Rasterzeileninterrupt 22:55, 4. Nov. 2009 (CET)

Also es ist so (immer aus Atari-Sicht, aber ich gehe fest von aus, daß das auf anderen 8 Bit Rechnern identisch funktioniert): Wenn Du in verschiedenen Bereichen unterschiedlich horizontal scrollen willst (oder unterschiedliche Farben, Sprites, whatever), dann nimmt man für weniger kritische Operationen tatsächlich den IRQ, einfach weils eleganter ist und man kein Heckmeck mit Polling machen muss. Das geht aber nur bei Sachen, wo es nicht auf Pixelgenauigkeit ankommt. Am Ende der Rasterzeile hat man nur ein paar Zyklen (nagel mich nicht fest, ich habe für Atari etwas in der Gegend von 60 in Erinnerung) bis der Strahl mit der nächsten Rasterzeile beginnt. Viel mehr als ein paar Register switchen geht da nicht, für Verändern des Offsets und des Feinscrolling reichts aber, um z.B. Parallax Scrolling zu realisieren. Das Wechseln innerhalb einer Zeile ist ein anderes Thema, zum einen ist der Prozessor für die meisten Veränderungen schlicht nicht schnell genug, als das man signifikante Operationen innerhalb des Screens durchführen könnten. Zum anderen ist aber tritt, wie schon erwähnt, der IRQ nicht an der exakt selben Position innerhalb der Zeile auf, da u.a. der aktuelle Befehl noch abgearbeitet werden muss. Das ganze geht aber schon wieder viel zu sehr in die Technik rein, und hat mit RZ-IRQ eben auch nur am Rande zu tun. Mein Vorschlag wäre, zum RZ-IRQ einfach zu beschreiben, daß man ihn benutzt(hat), um für einen definierten Bereich auf dem Screen Farben, Sprites, Fonts, Modus zu setzen. Wie Deekay schon sagte, mit den fortgeschritteneren Techniken wie z.B. FLI hat das nichts zu tun. (Hopper/SquoQuo)

Das finde ich jetzt fast noch amüsanter als das ganze Entertainment hier. ;-) Weil das nämlich mein Deus Ex Machina Introbild ist aus unserem Demo, mit dem der Michael da VIC-Coding erklärt.. ;-) Er hat übrigens einen Fehler drin, den ich ihm schon gemailt hab: Mayhem in Monsterland ist Zeichensatzgrafik.. -- DeeKay64 23:32, 4. Nov. 2009 (CET)

Ist ja schön, dass Du so ein erfahrener Coder bist und "dem Michael" mal gesagt hast, was er falsch macht. Aber was hat Dein Absatz mit dem Thema hier zu tun? Und wieso fährst Du schon wieder Angriffe ("das ganze Entertainment hier")? Rasterzeileninterrupt 23:48, 4. Nov. 2009 (CET)

Persönlicher Angriff? Also wenn du immer noch nicht mitbekommen hast, für welche Belustigung diese Show hier in der aktiven Szene sorgt, dann kann ich dir auch nicht helfen. Ach ja: "erfahrener Coder" - bitte PAs unterlassen, danke. Und deine Frage geb ich direkt mal zurück: Was hat dein Artikel mit dem Thema zu tun? 8) -- DeeKay64 01:31, 5. Nov. 2009 (CET)

Löschen und Editieren von Diskussionsbeiträgen

Die Diskussions-Seite ist dafür gut, dass Leute ihre Meinung zum Artikel äußern. Sie ist nicht dafür gut, dass ein selbsternannter Admin ihm unliebsame Diskussionbeiträge oder Abstimmungen einfach löscht oder ihm genehm umformuliert, insbesondere wenn er ganz offensichtlich nicht in der Position ist, die Relevanz für das Thema zu beurteilen. Das hat mit demokratischem Prozess nichts mehr zu tun. Wenn das so weiter geht werde ich Schlichter berufen. -- DeeKay64 23:27, 4. Nov. 2009 (CET)

Ja, mach das doch mal. Und sag ihm auch gleich, dass Du bereits zweimal verwarnt wurdest. Diskussionsbeiträge umformuliert? Diff or it didn't happen. Rasterzeileninterrupt 23:47, 4. Nov. 2009 (CET)

Aber gerne doch: hier und hier Kannst du bitte deine Persönlichen Angriffe ("zweimal verwarnt") auf meine Person unterlassen? Sachlich bleiben! -- DeeKay64 01:24, 5. Nov. 2009 (CET)

oder hier. Ich schließe mich der Aufforderung von Deekay an: Bitte verändere nicht die Diskussionsbeiträge anderer Nutzer! Wenn Du nicht mit ihnen einverstanden bist, kommentiere das bitte, aber lösche sie nicht. Es wäre sicherlich überlegenswert, die Diskussionsseite etwas aufzuräumen, nachdem der Artikel eine stabile konsensfähige Form erreicht hat, aber im Moment ist das vollkommen kontraproduktiv und bringt nur böses Blut. --Petuschki 01:42, 5. Nov. 2009 (CET)

Nachtrag: Wenn du auf deiner eigenen Diskussionsseite die Kritik löschst ist das zwar nicht die feine englische Art, aber letztendlich deine Sache. Aber an den Beiträgen anderer hier hast du nix zu verändern - insbesondere, wenn es dich oder deinen Schrieb tangiert. -- DeeKay64 02:36, 5. Nov. 2009 (CET)

DeeKay64 und Petuschki, Ihr habt hier wahllos irgendwelche Diffs rausgesucht, die aber alle keine inhaltliche Veränderung zeigen. (Das Entfernen von Quellcode ist keine inhaltliche Veränderung, auch das Einfügen von Überschriften nicht, sondern schlichtweg Aufräumen. Wenn daran wirklich etwas stören sollte, dann kann man das entsprechend konkretisierend in Worte fassen, das ist Euch aber nicht gelungen.) Rasterzeileninterrupt 12:59, 5. Nov. 2009 (CET)

Entschuldige mal, aber wenn du Grundsatzdiskussion in Gänsefüßchen stellst und aus "Abstimmung" "sogenannte "Abstimmung", Ergebnis ist irrelevant, es wird gearbeitet wie sonst auch" machst ist das also keine inhaltliche Veränderung? Das ist wohl echt nur deine Meinung.. -- DeeKay64 13:03, 5. Nov. 2009 (CET)

Die Abstimmung war nunmal quatsch, und die Grundsatzdiskussion zu dem Zeitpunkt noch keine. Vielleicht nicht die geschicktesten Edits, aber deswegen so ein Fass aufzumachen, das solltest gerade DU lieber lassen. Rasterzeileninterrupt 13:37, 5. Nov. 2009 (CET)

Die Diffs waren nun gerade nicht wahllos. Das Einfügen von Quellcode mag Deiner Meinung nach der Übersichtlichkeit abträglich sein, für andere dagegen wichtige Informationen liefern. Im gegebenen Fall handelte es sich außerdem nicht um seitenlange Listings, sondern um ein relativ kurzes Codefragment. Es ist jedenfalls einfach schlechter Stil, Diskussionsbeiträge anderer Autoren (speziell während die Diskussion noch im Gange ist) zu editieren und zu löschen, solange sie nicht unter Vandalismus fallen oder rechtswidrige Äußerungen beinhalten. Bitte respektiere das einfach, du möchtest ja auch nicht, dass jemand Deine Beiträge löscht, weil sie ihm aus irgendwelchen Gründen nicht gefallen. Späteres(!) Aufräumen schließt das natürlich nicht aus. --Petuschki 15:00, 5. Nov. 2009 (CET)

DeeKay64: Meine Benutzerseite wird selbstverständlich aufgeräumt, wie jede andere auch. Ich werde Dir das nicht erklären, such Dir einen anderen Wikipedianer dafür. Haltlose Vorwürfe wie die, dass ich "Kritik an meiner Person" unterdrücken würde o.ä. hinterlassen keinen guten Eindruck. Rasterzeileninterrupt 13:01, 5. Nov. 2009 (CET)

Ok, falls hier noch einmal ein Beitrag von mir gelöscht wird, ohne Kommentar und anonym, dann sehen wir uns hier wieder http://de.wikipedia.org/wiki/Wikipedia:Vermittlungsausschuss -- Mrsid 09:08, 5. Nov. 2009 (CET)

Ich hoffe, das hängt nicht mit meiner Bearbeitung zusammen. Ich hatte vorher einen längeren Absatz eingefügt, bin mir aber keiner Löschung bewusst, taucht aber im selben Diff auf. Falls ich da tatsächlich aus Versehen das gelöscht haben sollte (wie auch immer) dann möchte ich mich dafür entschuldigen. (Hopper/SquoQuo) (nicht signierter Beitrag von 145.253.187.66 (Diskussion | Beiträge) 09:23, 5. Nov. 2009 (CET))

Ok, kein Problem. -- Mrsid 09:40, 5. Nov. 2009 (CET)

Zwischenabschluss

Ich glaube es ist Zeit, den diskutierten Entwurf zu veröffentlichen. Die Dinge, die drinstehen scheinen unumstritten zu sein. Damit ist das Lemma eigentlich ordentlich erklärt. Ob und welche Erweiterungen richtig sinnvoll sind, kann dann immernoch geklärt werden.

Rasterzeileninterrupt, Du scheinst Dich gut mit Mechanismen und Syntax der Wiki-Engine auszukennen, möchtest Du das machen oder soll ich? Meiner Meinung sollte der Artikel heute durch einen sachlich richtigeren ersetzt werden. --Skoe 09:28, 5. Nov. 2009 (CET)

Hab ihn online gestellt und die Hardwareliste (und die Links) um ein paar weitere Systeme ergänzt. -- DeeKay64 10:39, 5. Nov. 2009 (CET)

Sehr schön. Auf die Anmerkung (von außen), dass noch nicht klar ist, warum es den RZ-IRQ überhaupt gibt, habe ich noch einen Satz eingefügt. Außerdem wurde uns vorgeschlagen, nicht nur Weblinks zu nennen, sondern http://de.wikipedia.org/wiki/Wikipedia:EN zu beachten. Da bietet sich u.a. das C64 PRM an, Datenblätter, aber auch die Sachen, die unter Weblinks stehen. --Skoe 11:07, 5. Nov. 2009 (CET)

weitere Links

• http://hitmen.c02.at/files/yagcd/yagcd/chap5.html#sec5.3 - gamecube video register doku (0xCC00202C und folgende)
• http://hitmen.c02.at/files/releases/gbc/gbc_lcdc_interupts.txt - gameboy/gameboy color display interrupts (übersicht) (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 13:30, 5. Nov. 2009 (CET))
• http://magicdisk.untergrund.net/md/KURS-IRQ-KURS.txt.html - interrupt kurs von ivo herzeg (mr.cursor), erschienen in der magic disk 64, magna media verlag. (nicht signierter Beitrag von 62.143.153.84 (Diskussion | Beiträge) 14:28, 5. Nov. 2009 (CET))

Das war doch der CP Verlag, oder nicht? Magna Media war der Nachfolger von Markt & Technik.

ja stimmt, hab ich glatt verwechselt :)

Externe Anmerkung..

Nachdem sich gerade ZWEI Benutzer (mit unterschiedlichen IPs, um gleich mal den Socken-Müll zu den Akten zu legen) wegen dieses Artikels im Chat melden: Also die Einleitung mit "Ist ein Hack in der C64-Szene" ist ja schonmal zum Brechreize erzeugen und völliger Unsinn. Ein Interrupt ist kein Hack, sondern eine Funktion. Ein Hack kann höchstens sein, was man damit anstellt. Einen Interrupt als Zähler auszuwerten, ist alleine aber immer noch kein Hack; der Systemtimer arbeitet ja nach genau diesem Prinzip. --TheK? 11:30, 5. Nov. 2009 (CET)

Ich denke, dieser Kritikpunkt erledigt sich gerade von selbst. Ich gucke mal, wer das da reingeschrieben hat. DeeKay64 hat ja schon wieder wild am Artikel rumgebaut und die Diskussion ignoriert. Rasterzeileninterrupt 13:11, 5. Nov. 2009 (CET)

Äh.. Du "guckst, wer das reingechrieben hat"? Tip: Schau mal in den Spiegel.... -- DeeKay64 13:29, 5. Nov. 2009 (CET)

Nein er hat die Ergebnisse der Diskussion eingebaut, was inzwischen auch von Wikipedianern gesichtet wurde. --Skoe 13:17, 5. Nov. 2009 (CET)

Ja, stimmt, hatte ich erst falsch gesehen. Er hat, nachdem Du den Alternativentwurf geschrieben hast, an dem DeeKay64 nahezu nicht mitgewirkt hat, diesen selbst reingeschrieben. prinzipiell könnte man sagen: "It's a wiki", aber dass er jetzt als Artikelschreiber in der Historie steht, finde ich im Kontext der Diskussion hier und aufgrund seines Auftretens und schon arg unverschämt. Rasterzeileninterrupt 13:40, 5. Nov. 2009 (CET)

Er hat an dem Entwurf nicht mitgeschwirkt, weil er erstens gesperrt war und zweitens mit den Nebenwirkungen der Beruhigungstabletten zu kämpfen hatte :) --Skoe 13:46, 5. Nov. 2009 (CET)

Ich muss hier doch mal eine mittelgroße Lanze für Deekay brechen. Ich halte es durchaus für berechtigt, daß er als Artikel(mit)schreiber auftaucht, da er 1) einen wesentlichen Beitrag in der Diskussion geliefert hat (auch wenn dem ein oder anderen der Diskussionsstil etwas ruppig vorkam) und 2) ich definitiv weiß, daß er eine Ahnung hat, von dem, was er schreibt. Wo ich Dir allerdings Recht gebe, ist, Skoe großen Respekt für seine sehr gute Vorlage zu zollen. btw: Datensichtgeräte heißen die Dinger, ob sich das schön anhört oder nicht... (Hopper/SquoQuo) (nicht signierter Beitrag von 145.253.187.66 (Diskussion | Beiträge) 14:04, 5. Nov. 2009 (CET))

Obwohl ich wahrscheinlich die Hauptarbeit am Text der jetzigen Version hatte, ist mir ziemlich egal, wer da als Author drin steht. Hauptsache, der Artikel ist sachlich richtig und alle beruhigen sich wieder etwas :) --Skoe 14:11, 5. Nov. 2009 (CET)