Beiträge von Rapid Eraser

    Ich habe kein Windows und kann es daher nicht testen, doch ixquick zeigte mir diese Möglichkeit:
    (entnommen aus Bitte melde dich an, um diesen Link zu sehen.)

    Vielleicht funktioniert das ja (immer noch)?

    Doch die gibt es und diese Standards haben den C64 in seiner grossen verkauften Stückzahl so erfolgreich gemacht - bis heute ;) :
    1. der originale CBM-Kernal - der kleinste gemeinsame Nenner wo jede Software mit laufen sollte
    2. die Schnittstellen, die bei allen PCB-Revisionen nach aussen hin gleich sind.

    Nun werden wir leider nie erfahren ob der C64 nicht noch erfolgreicher gewesen wäre wenn man HW und Standards ab und an mal entstaubt hätte... ;)
    Sei's drum. Jetzt tut's der verbleibenden Szene glaube ich auch keinen großen Abbruch mehr. Die Alternative zu "das neue Spiel läuft mit Zusatzhardware" lautet ja leider nicht immer "das neue Spiel läuft ohne Zusatzhardware" sondern bisweilen auch "es gibt kein neues Spiel" (siehe z.B.Unknown Realm).

    Um Deine Idee umzusetzen, müsstest Du entweder den Kernal ändern oder eine Zusatz-Software verwenden (siehe z.B. xlink, TheServant).
    Das ist für einen bestimmten Einsatzzweck zwar toll und auch sinnvoll, aber da Du diesen geänderten Kernal nicht in JEDEN C64 dieser Welt finden wirst, wird sich Deine UCB-Schnittstelle wohl auch nicht als ein QuasiStandard etablieren. Das sage ich Dir schonmal voraus, bevor Du mit der Arbeit anfängst. ;)

    Ich hatte daran gedacht Zusatzsoftware (UCB-Treiber für die verschiedenen Interfaces) auf C64-Seite zu verwenden. Neue Software müsste das explizit integrieren und bestehende Software müsste dafür entsprechend gepatched werden. Also eigentlich genauso wie es jetzt auch schon ist. Nur das beides im Idealfall deutlich einfacher wird. Der 9-Pin Guru geht ja schon in diese Richtung; soweit ich das verstanden habe soll er eine ganze Palette von Eingabegeräten auf ein einheitliches Interface abbilden. Das ist eigentlich schon genau das, was mir auch vorschwebt. Nur eben in einer "allumfassenden" Variante und nicht nur speziell für Joysticks/Joypads/Mäuse. Sonst geht das womöglich wieder nur so lange gut bis irgendjemand einen alternativen Mausadapter aus dem Hut zaubert, weil er Features haben möchte die im 9PG nicht vorgesehen sind, oder bis eine andere Hardware den gleichen Port verwendet, oder bis einer einfach Spaß an HW-Entwicklungen hat und allein deshalb was neues bastelt.


    Damit das gehandlet werden kann muss ja wahrscheinlich ein externer Controller (sowohl am C64 als auch an den Erweiterungen/Geräten angeschlossen) die Steuerung davon (u.a das multiplexen von Leitungen) übernehmen... Ob das machbar ist?

    Genau so müsste es gehen:

    Sicher, das Konzept "alles an einen Bus" hat durchaus seine Schwächen, aber schlimmer als der Status Quo ("alles vollkommen verschieden, selbstgefrickelt und gerne auch inkompatibel") sollte es kaum werden.

    Wenn man den Gedanken mal weiterspinnt könnte der UCB-Controller ja sogar die jeweiligen Treiber für die verschiedenen Interfaces zum "download" anbieten. Ein Programm müsste dann zunächsteinmal nur grundlegende Transferroutinen zum UCB-Controller beinhalten. Damit könnte man dann weitere Routinen "nachladen". Solange diese Routinen die definierten Interfaces erfüllen könnten SW-Entwickler damit arbeiten ohne sich großartig weitere Gedanken machen zu müssen. Und genau da würde ich gerne hinkommen, den Programmieren jetzt mal die Arbeit bei der Unterstützung von Hardware zu erleichtern.


    PS: Als 'wesentlich erweiterte ExPort-Weiche' habe ich es noch nicht betrachtet. Vielleicht wenn man die Möglichkeiten des Exp-Ports ignoriert und sich auf ein einfaches Kommunikationsprotokoll beschränkt... :D

    PPS: Natürlich wird das wohl nicht gleich der neue Quasi-Standard werden, schon gar nicht wenn ich das im Alleingang angehe. Aber ich sehe in der Idee durchaus einige bestechende Vorteile.

    Klar bietet es sich an sich an Konzepten von USB zu orientieren. Aber gleich den ganzen USB-Standard zu übernehmen? Abgesehen vom Overhead könnte ich mir da gut vorstellen das man damit Entwickler von Homebrew-Hardware verschreckt... und wenn die dann doch wieder ausscheren und was eigenes, einfacheres basteln ist nix gewonnen.
    Eigentlich geht's mir aber hauptsächlich darum einheitliche (Software-)Schnittstellen zu schaffen, damit irgendwelche HW nicht immer nur von ein oder zwei Programmen weltweit unterstützt wird. Ob das nun über UCB, USB, PCIe, IrDA oder indianische Pfeiftanz-Kommunikation abläuft wäre dafür auch egal.

    <offtopic>
    Ich möchte an dieser Stelle mal eben bewusst offtopic werden um ein Thema anzureissen das zwar nur indirekt zu diesem Thread gehört aber für die Leserschaft hier möglicherweise interessant ist. Falls es Reaktionen darauf gibt mag ein Admin das freilich sehr gerne in einen eigenen Thread auslagern.

    Hintergrund: Ich patche hin und wieder mal Spiele/Tools, u.a. auch damit sie von externer Hardware (Speichererweiterung, Maus, Massenspeicher etc.) profitieren können. Und dabei ärgere ich mich jedesmal darüber das es auf den C64 keinerlei Standarts gibt. Die Tage habe ich mir z.B. ein RPG vorgenommen und ihm eine RAMdisk verliehen*. Nun, an Speichererweiterung gibt es ja jede Menge: REU, GeoRam, SuperRam, Pagefox, VDC etc. pp., und sie alle werden grundlegend unterschiedlich angesteuert. Bei Massenspeichern, Turbokarten, Maus-Adaptern usw. ist es genauso. Es gibt auch wenigstens ein halbes Dutzend verschiedene 4-Spieler-Adapter, und sie alle sind inkompatibel zueinander (obgleich sie sich teilweise lediglich in der Pinbelegung unterscheiden). Es gibt auf dem C64 ja leider nichteinmal vernünftige Methoden um evtl. vorhandene Zusatzhardware zu erkennen... Und das finde ich persönlich sehr ärgerlich. Zumal man bisweilen sehr lange googeln muss um mal Informationsbruchstücke zur Ansteuerung der jeweiligen Hardware aufzufinden. Ganz abgesehen davon das man viele Hardwareerweiterungen nicht gleichzeitig nutzen kann weil sie den gleichen Port beanspruchen.

    Idee: Mir kam daher die Idee (und bisher ist es nur eine vage Idee, ohne jegliche Ausarbeitung) einen einheitlichen Bus für den C64 zu gestalten. Nennen wir ihn mal den Universal Commodore Bus (UCB). Mir schwebt dafür ein Gerät für irgendeinen Port des C64 vor (z.B. den Tape-Port, der ist glaube ich noch nicht so strapaziert). Also ein Gerät, das man in den Tape-Port einstöpseln kann, und das dann eine Anzahl x von UCB-Schnittstellen zur Verfügung stellt**. An die einzelnen UCB-Schnittstellen liessen sich dann - ggf. mit jeweils einem individuellen Adapter - alle möglichen Geräte anschließen, z.B. Mäuse, Joysticks, Joypads, Tastaturen, Massenspeicher, Speichererweiterungen und was weiss ich nicht alles.
    Das UCB-Protokoll (seriell?), über welches man mit dem Gerät (und weiter mit den jeweiligen angeschlossenen Devices) kommuniziert, müsste zunächst mal einen Transport-Layer definieren, also eine einheitliche Kommunikationsmöglichkeit schaffen. Das Application-Layer müsste dann ermöglichen die angeschlossenen Devices abzufragen und anzusteuern. Die Devices werden in Klassen mit jeweils einem definiertem Interface eingeteilt, z.B. InputDevice/Digitaljoystick, InputDevice/Analogjoypad, InputDevice/Maus, InputDevice/Tastatur, IO/Massenspeicher, IO/Ramdisk, usw.
    Die jeweiligen (intelligenten) UCB-Devices/UCB-Adapter für eine konkrete Hardware müssten dann halt dafür sorgen das sie das UCB-Protokoll verstehen, also sich bei einem Bus-Query dementsprechend melden können und das jeweiliges Interface inplementieren. Da Microcontroller - etwa für die Adaption Maus->UCB - heutzutage nur ca. 2 Euro kosten und sich leicht auf Lochraster löten lassen wäre das - in dieser Hinsicht - durchaus eine realisierbare Sache.

    Für die Nutzung müsste ein Programm dann freilich einen (einzigen) UCB-Treiber beinhalten. Mir schwebt da für die Ansteuerung sowas vor wie (Pseudocode):

    wobei digitale Joysticks/-pads ein Maus-Interface freilich auch erfüllen können (das müsste der jeweilige Adapter dann halt implementieren). Wäre dann halt ggf. umständlicher in der Nutzung, aber immerhin geht's. Ist zumindest besser als all die schöne Zusatzhardware überhaupt nicht zu unterstützen (was ja z.Z. leider der Normalfall ist). :(

    Zusammengefasst: Für einen Programmierer kann es in einen enormen Kraftakt ausarten möglichst viele Hardwareerweiterungen zu unterstützen, nicht zuletzt weil deren Dokumentation bisweilen sehr spärlich ist. Mit einem einheitlichen Bus/Treiber (welchen es noch zu entwerfen gilt) könnte das anders aussehen. Zumindest ich selbst würde so etwas jedenfalls begrüßen.

    Was meint ihr - macht es irgendeinen Sinn diese Idee weiter zu verfolgen und zu realisieren? Der Status Quo ist ja das nur ca. jedes tausendste Programm irgendeine Zusatzhardware unterstützt, wobei jedoch grob geschätzt 5% aller Programme von Zusatzhardware profitieren könnten (was aber niemand implementiert, u.a. möglicherweise weil es sehr aufwendig werden kann die verschiedensten Hardwarealternativen anzusteuern bzw. weil die Zielgruppe für die Verwendung einer konkreten Hardware zu klein ist als das sich jemand darum bemüht). Ein UCB könnte zumindest dieses Problem beheben.


    * mag jemand beta-testen?
    ** als physikalische Schnittstelle des UCB könnte man DIN-Stecker nutzen oder (virtuelle) Userports oder was auch immer
    </offtopic>

    Jetzt kommen sicher gleich die Linux-Anbeter und preisen ihren selbst gelesenen und verifizierten Quellcode und machen dir das ganze Thema karpott.


    Och, irgendwie habe ich das Gefühl das niemand, der sich auf diesem Level mit Linux auseinandersetzt, dieses System preisen wollen wird. Im Gegenteil, meiner Erfahrung nach gruselt es einen um so mehr, je tiefer man in die Internas vordringt - bis hin zum völligen Unglauben, das so ein atemberaubender Bockmist jemals irgendwie funktionieren können wird... (wer je in ein altes Gerät von Siemens hineingeschaut hat kennt das Gefühl - das Innenleben schaut aus als würde es im Leben nicht funktionieren; tatsächlich aber sind die ollen Siemens-Sachen auch in 100 Jahren nicht tot zu kriegen :) )

    Aktuelles Beispiel: Derzeit schlage ich mich bei Linux mit dem "Startmenu" herum. Unter Windows lässt sich das super simpel nach Belieben umstrukturieren; unter Linux muss man schon bald ein Mannjahr veranschlagen wenn man das tatsächlich in den Griff bekommen möchte. Zwar gibt Freedesktop.org einen Standard vor (der schon besch...eiden genug ist), allerdings scheinen sich alle an der tatsächlichen Darstellung des Startmenus beteiligten Parteien (Distribution, X-Server, Fenstermanager, Desktopumgebung und Applikationen) die Freiheit zu nehmen diesen Standard nach Herzenslust abzuändern. Und trotzdem halten sie sich dann nicht mal an ihre eigenen Abänderungen, geschweige denn an sonst irgendeine Regel... (das Ganze erinnert mich an handgeschriebene Webseiten aus den 90er-Jahren; auch da hatte man nur eine Chance wenn der HTML-Parser atemberaubend fehlertolerant war). Alleine das Auffinden eines zu einer Applikation gehörenden Icons wird unter Unix zum Staatsakt. Der Bitte melde dich an, um diesen Link zu sehen. gibt dazu zwar einen Algorithmus vor (der "nur" drei verschachtelte Schleifen vorsieht in denen über irgendwelche Verzeichnisse iteriert wird um das Icon zu fnden), allerdings sind in der Realität auf meinem frisch installierten Debian-System mindestens 5 verschachtelte Schleifen notwendig. Und das auch nur unter den Voraussetzungen, das man die aktuelle Desktopumgebung irgendwie dazu bewegen kann einem das eingestellte Iconset zu verraten und das man in der Lage ist die von der Desktopumgebung verwendeten *.desktop-files zu identifizieren und zu interpretieren (und natürlich das deren Inhalt wenigstens irgendwie auf die Realität abbildbar ist). Und das man für Icons Formate wie SVG und XPM verarbeiten kann. GTK und libmenu-cache bieten da zwar schon einige Funktionen für an, aber out-of-the-box nutzbar sind die auch nicht, da ist noch einiges an Nachbearbeitung für nötig. Wenn man etwas wirklich einigermaßen funktionierendes haben möchte dann muss man sich das wohl aus den Sourcen von PCmanFM o.ä. selber extrahieren, denn jegliche Quellcodes und Dokumentationen dazu scheinen wie Staatsgeheimnisse gehütet zu werden.
    Von Applikations-Kategorien und *.menu-files will ich jetzt gar nicht erst anfangen...

    Sorry, aber das musste jetzt raus.

    Also Jedenfalls - bei derart besch... Standards und deren nicht-Einhaltung wundert mich der Resourcenbedarf heutiger Betriebssysteme gar nicht mehr so sehr. Schätze mal bei Windows wird das - angesichts einer Registry > 100mb - auch nicht schöner aussehen. Bei den einigermaßen populären Betriebssysteme (Windows/Linux/MacOs) kann man wohl nicht viel dagegen machen sondern muss es einfach hinnehmen. Wobei man freilich nicht vergessen darf das ein Betriebssystem eine schon ziemlich komplexe Angelegenheit ist; bis beim Endanwender mal irgendeine Anwendung reibungslos läuft hatten auf dem Weg dahin wahrscheinlich schon 100e oder 1000e von Programmieren von Hard- und Software ihre Finger im Spiel. Von daher würde ich mir bei einer Größenordnung von 10 GB für ein Betriebssystem noch nicht viele Gedanken machen (da sind ja vermutlich auch Treiber für hunderte verschiedene Hardwarekomponenten mit eingerechnet). Sicher, Commodore hätte damals halt einen Standard vorgegeben und diesen ins ROM gebrannt, so das sich jeder daran hätte halten müssen. Aber so funktioniert das heute halt nicht mehr, heute sollen auch Standards automatisch aktualisiert werden können. Und da Standards bisweilen sehr komplex sein können wird halt auch "das Betriebssystem", wie auch immer man das genau abgrenzt, sehr komplex und damit auch sehr voluminös ausfallen. Bei Windows 10, soweit ich es bisher begutachten konnte, würde ich jetzt aber nicht unbedingt von einem überproportionalen (unangemessenen) Resourcenbedarf reden wollen. Jedenfalls nicht im Vergleich zu anderen aktuellen Betriebssystemen.

    Ich habe meinen gesamten Kram so um die Jahrtausendwende verschenkt. Seitdem habe ich genau gar nichts mehr von Commodore. Aber davon los komme ich dennoch nicht... (möchte ich aber auch gar nicht)

    Mal für den Fall das ich irgendwann wieder einen "Schreibtisch mit Platz drauf" habe - wäre jemand von euch bereit einen funktionstüchtigen c64 + floppy zu verkaufen? Er käme bei mir auch in gute, fachkundige Hände. :)

    Ich hatte mich grob hier dran orientiert: Bitte melde dich an, um diesen Link zu sehen. , aber das ist dann wohl nicht so das Wahre.


    Och, nach dem überfliegen der Seite möchte ich sagen: Es ist ja nicht falsch, was der Mann da schreibt. Im Gegenteil, er pflegt sogar einen exquisiten Programmierstil. Jonathan Quayle Higgins würde vermutlich ähnlichen Code abliefern*. Nur für Demos u.ä. taugt das leider nicht eben viel; dort hat sich ein "grobschlächtigerer" Stil bewährt.
    Was ich immer lesenswert fand waren die Kurse in der Bitte melde dich an, um diesen Link zu sehen.. Schau in einer ruhigen Minute mal da rein, da wird dir sicherlich einiges wieder in Erinnerung gerufen. :)

    * Tatsächlich bin ich selber vor der Lektüre dieser Webseite nie auch nur auf die Idee gekommen beim C64 Raster- und Timerinterruptquellen gleichzeitig zu verwenden und per $d019 zwischen ihnen zu unterscheiden. Da habe ich jetzt auch wieder etwas dazugelernt. :)

    Das Flackern könnte daran liegen das der Kernal einen Timerinterrupt verwendet (um die Tastatur abzufragen usw.). Du schaltest hier lediglich einen Rasterinterrupt hinzu, ohne jedoch den Timerinterrupt zu deaktivieren. Folglich treten beide Arten von Interrupt auf und können sich u.U. in die Quere kommen. Versuch mal die Timer mittels

    Code
    lda #$7f
    sta $dc0d
    sta $dd0d


    zu deaktivieren, das sollte schon reichen.

    Hast du mal bei "den großen Alten" nachgesehen (Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen.)? Sammelbestellungen bei denen gibt's immer mal wieder im Bitte melde dich an, um diesen Link zu sehen., da kannst du dich für ein paar solcher Taster sicherlich mit anhängen.

    Also codebase64.org ist wirklich mit Abstand der sinnvollste Ort fuer dergleichen.


    Ach, das hatte ich früher auch gedacht. Aber immerhin heisst der Laden ja Codebase und nicht Erklärbase, daher bin ich mir gar net so sicher ob dort "einsteigerfreundliche Erklärungen" erwünscht sind... So findet sich beispielsweise zu dem in diesem Thread erwähnten Effekt der Bitte melde dich an, um diesen Link zu sehen. auch einfach nur'n Codeschnipsel - ohne irgendwelche Erläuterungen, die einen geneigten Leser in die Lage versetzen würden den Effekt zu verstehen und selbstständig anzuwenden. Dabei hätte das den Autor auch nur ein paar Minuten gekostet.

    Naja, ich schätze mal ich habe da einfach eine andere Zielgruppe vor Augen. Abgesehen davon werde ich mit Sicherheit auch nicht nur "pures Gold" schreiben, daher finde es gar keine schlechte Idee wenn man ersteinmal noch Nachfragen, Anmerkungen und Korrekturen in so einen Text einarbeiten kann, bevor er dann in irgendeinem Wiki veröffentlicht wird.

    Ich finde den Vorschlag super.
    Das schöne an einem Forum ist die Interaktion, die Diskussion.


    Okay, ein Padawan reicht mir schon :) . Nachdem die Texte formvollendet ausdiskutiert wurden kann man sie ja immer noch ins Wiki/in die Codebase* übernehmen.

    * Bei der Codebase habe ich leider die Erfahrung gemacht das Beiträge jederzeit von populäreren Namen gnadenlos mit - meiner Ansicht nach - schlechteren Texten überschrieben werden. Ich selber werde den Teufel tun da nochmal einen Beitrag für zu verfassen, aber jemand anderes mag das latürnich jederzeit versuchen.

    Seit wann ist da eigentlich die Bezeichnung "Countingsort" gängig? Als ich damals™ das erste mal von dem Verfahren gehört hab', lief das noch unter Bucketsort.

    Hmm, ich denke ein wesentlicher Unterschied zwischen Bucket- und Countingsort ist das beim Bucketsort die Originalelemente herumgeschoben werden, während beim Countingsort die Elemente jeweils neu erzeugt werden. Solange die Elemente nur aus einer Zahl bestehen mag dieser Unterschied marginal sein, aber wenn an den Elementen noch andere Daten dranhängen - wie in diesem Fall eine Speicheradresse - dann lässt sich der "reine" Coutingsort halt nicht mehr so ohne weiteres anwenden.
    Schätze mal die meisten Leute hier (oder zumindest meine Wenigkeit) haben für die Compo einen Hybriden aus Counting- und Bucketsort implementiert. Da darf man wohl getrost beide Bezeichnungen für verwenden.


    Sehr schön, Code Vortanzen sollte bei der nächsten Compo unbedingt Pflicht sein, finde ich ^^

    :lol27:

    PS:

    Um Mafiosino zu motivieren (und damit ich nicht den nächsten Wettbewerb austragen muss ;) )

    Alter Schwede, was für Peiselullisches Opcode Massaker veranstaltest du denn da?? 8| Auf 13.9xx Zyklen komme ich ja auch noch, aber weniger geht hier wirklich nicht...

    Bei der Codebase wird jedoch vieles leider nicht erklärt sondern lediglich Codeschnipsel gepostet (welche ich selbst bisweilen nur sehr mäßig hilfreich finde). Aber wenn das reicht - ich reisse mich jetzt auch nicht unbedingt um Arbeit. ^^

    Das Wiki werde ich dann mal durchstöbern (aber ehrlich gesagt würde ich da nun auch nicht gerade nach solchen Themen suchen...)

    ...sollte ich das jetzt doch falsch interpretiert haben, mögen mich die Democoder verbessern... :whistling:


    Ich kann dich net verbessern, denn das hast du imho völlig richtig beschrieben (und das mit viel weniger Worten als ich...). :)


    Offtopic: Was mir im Verlauf des Threads auffiel war das scheinbar doch recht viele User Interesse an dem Thema haben. Da stellt sich mir gerade die Frage ob sich dieses Interesse nur auf diesen einen Thread ersteckt oder ob's allgemein ein Interesse an Beschreibungen von Demo- bzw. VIC-Effekten gibt? Mir schwebt da gerade sowas vor wie die Profi-Corner, damals in der 64'er*, halt eine lose Reihe von Threads in denen irgendsowas mal erklärt wird. Da es hier im Forum ja einige (ehemalige) Democoder gibt werden sich hoffentlich genug Autoren dafür finden, die ihr Wissen an die nächste Generation weitergeben möchten. :)

    * nur halt ohne nervige Redakteure, welche die Artikel verkorksen. Lol, ich habe so manchen der Autoren schimpfen hören wie ein Rohrspatz, weil Pit & Co die Originalbeiträge dergestalt umgeschrieben haben, das am Ende ein "atemberaubend bescheuerter Unsinn" gedruckt wurde... (O-Ton AD/FC) :drunk:

    Ich glaube den Schnipsel rahm ich mir auch ein. Ich erinnere mich daran, dass ich da irgendwann mal verzweifelt bin in welcher Reihenfolge mit welchem Timing die Register zu resetten sind, damit man keine Flacker-Zeile hat.


    Lol, das brauchst du glaube ich nicht, der Schnipsel ist mehr oder weniger auch nur frei nach Schnauze geschrieben. Sicher, ein ordentlicher Mensch würde dafür sorgen, das die VIC-Register zum exakt richtigen Zeitpunkt beschrieben werden um ein Flackern zu vermeiden. Leider hat man häufig gar nicht die Möglichkeit dazu alle Register zum jeweils notwenigen Zeitpunkt zu beschreiben, was halt zur Folge hat, das auf dem Bildschirm vorübergehend der Inhalt "irgendwelcher undefinierten" Speicherstellen erscheint.
    Der einzige Trick bei der Sache besteht nun eigentlich darin zu wissen was der VIC wann anzeigt und dementsprechend darauf zu reagieren. Um ein Flackern beim Umschalten zu verhindern muss man eigentlich nur selber dafür sorgen, das in besagten "irgendwelchen undefinierten Speicherstellen" zum Zeitpunkt des Umschaltens der gewünschte Inhalt drinsteht. Die jeweiligen Speicheradressen mögen unbeabsichtigt sein, ihren Inhalt können wir jedoch kontrollieren. Und dann flackert da - in Idealfall - auch nix mehr. ^^

    Das dürfte wohl durch Bitte melde dich an, um diesen Link zu sehen. zustande kommen.

    Ganz genau so ist das. Der VIC hat intern einen drei Bit breiten Row-Counter, der in jeder der 200 Zeilen des sichtbaren Bildschirminhalts um eins hochgezählt wird. Bei einem Überlauf werden die jeweils nächsten 40 Zeichen aus dem Videoram in interne Speicherzellen des VICs eingelesen, wozu der VIC vorübergehend die CPU lahmlegen muss → die sog. Badline.

    Zwischen dem Inkrementieren des Row-Counters und dem Triggern des nächsten Auslesens des Videorams (der Badline) besteht ein schmales Zeitfenster. Das können wir nutzen um $D011 in diesem Zeitfenster entsprechend zu manipulieren, wodurch zwar alle internen Zähler des VIC (die „interne Verwaltung“ des Bildschirms) kohärent bleiben, der Trigger für das Auslesen der jeweils nächsten 40 Zeichen aus dem Videoram jedoch ausbleibt. Folglich benötigt der VIC in der nächsten Rasterzeile keine zusätzlichen 40 Zyklen, und somit legt er auch nicht die CPU lahm, und somit können wir auch in der Mitte der Rasterzeile $D016 beschreiben.
    Der Nachteil ist natürlich, das wir dadurch auch keine neuen Zeichen auf den Bildschirm bekommen. Der VIC stellt halt ganz normal diejenigen Zeichen dar, die sich in den 40 internen Speicherzellen befinden. Da diese jedoch nicht aktualisiert wurden wiederholen sich die vorherigen Textzeilen (vgl. Bild 1a und 1b).
    Um diesen Nachteil zu kompensieren können wir in jeder achten Rasterzeile auf einen neuen Charset/eine neue VIC-Bank umschalten. Der VIC liest - abgesehen halt vom Videoram - alles in Echtzeit aus dem Speicher aus, also genau dann wenn er es benötigt. Durch den neuen Charset werden zwar immer noch die gleichen 40 Zeichen auf dem Bildschirm angezeigt, allerdings sind diese nun – über den veränderten Charset – an andere GFX-Daten gebunden. Folglich zeigt der VIC auch in jeder Zeile andere Grafik an.
    Zur Verdeutlichung ist in Bild 1c dargestellt wann der VIC 40 neue Zeichen aus dem Videoram liest (Badline, in rot hervorgehoben) und wann - ungefähr - $D011 beschrieben wird (in grün) um die Badlines zu verhindern. Nach dem Beschreiben von D011 wird auch $D018 neu gesetzt um neue GFX-Daten auf dem Bildschirm zu sehen.

    In meinem oben geposteten Quellcode werden $D011 und $D018 zwar in jeder Rasterzeile beschrieben, allerdings ist das nicht nötig. Es reicht die Register in jeder achten Rasterzeile zu beschreiben. Der (fast*) einzige Grund für das Beschreiben in jeder Zeile war, das sich dadurch die Schleife vereinfacht hat. :)


    * Da $D018 nun ohnehin schon in jeder Rasterzeile beschrieben wird bietet sich für das Sprite in der Mitte des Bildschirms ein arme-Leute-Multiplexer an**: In dem obigen Code wird lediglich ein einziges Sprite angezeigt, in Y-Richtung gestretched. Normalerweise wird dadurch jede Zeile zweimal angezeigt, wodurch das Sprite grobauflösend wirkt. Um das zu verhindern schalten wir in jeder Rasterzeile das Videoram per $D018 um. Auch wenn keine neuen Zeichen mehr aus dem Videoram gelesen werden, so liest der VIC dennoch in jeder Zeile die Spritepointer am Ende des Videorams neu ein. Durch das Umschalten des Videorams können wir demnach auch die Spritepointer umschalten. Das ständige Umschalten von $D018 hat nun zur Folge, das in jeder Rasterteile neue Spritepointer verwendet werden (bzw. in unserem Fall zwei Spritepointer in zwei Videorams abwechselnd; die Pointer liegen bei $43ff und $47ff)). Dadurch liest der VIC auch in jeder Rasterzeile GFX-Daten aus zwei (alternierenden) Spriteblöcken für das Sprite ein, wodurch die verminderte Y-Auflösung kompensiert wird.

    ** in Verbindung mit dem $D017-Mega-Stretch-Trick oder wie der heißt kann man daraus freilich auch einen reiche-Leute-Multiplexer machen..


    Edit: In Bild 1c habe ich 'nen Fehler gemacht: Die unterste grüne Markierung muss natürlich weg, und dafür muss in die oberste Rasterzeile des "READY" noch eine rote Markierung hin. Sonst bekämen wir ja wieder nur "ABC" zu sehen und nicht das "READY"...

    Ich hab's jetzt mal mit der Originalmethode ($d016-split) versucht. Badlines werden verschluckt und stattdessen neue Grafikdaten über $d018 eingeblendet. Ging problemlos. :) Wenn da sonst nicht mehr viel passieren soll dann würde ich das den Rotationen vorziehen...

    Die Hauptschleife schaut entsprechend einfach aus: