Alles anzeigenIch wollte hier mal einstreuen, das mir brauchbare Programmierumgebungen für den C64 fehlen
Leider paßt das von Dir genannte Beispiel nur gar nicht zu den 8 Bit-Rechnern und mag daher auch ein Grund sein, warum es die von Dir gewünschte Basisbibliothek nicht gibt. Erlaube mir, das Beispiel aufzugreifen, um anhand dessen stellvertretend die Gründe zu erläutern.
Die Bestimmung der Farbe erfolgt beim C64 doppelt indirekt: zunächst über das Bitmuster als Index in die Farben des Farbrams, dann über das Farbram in die eigentliche Palette des C64. Um eine Farbe zu setzen, müßte man also mindestens zusätzlich angeben, mit welchem Bitmuster diese Farbe gemalt werden soll. Das führt aber höchstwahrscheinlich schnell zu einem Chaos, denn dazu gehört, daß man als Programmierer genau mitverfolgen muß, in welcher Kachel jetzt welche Farbe mit welchem Bitmuster gemalt wurde, zumindest sofern man mehr als vier Farben anzeigen möchte.
Beim C64 hat man zusätzlich eine Hintergrundfarbe für die gesamte Bitmap, die man irgendwie gesondert setzen muß. Beim C16 sind es sogar zwei, und beim VC20 gar drei. Um die dadurch entstehende Begrenzung in der Farbauswahl zu umgehen, ist es eine übliche Praxis, mehr Farben über Rasterinterrupts zu erzeugen. Doch woher soll die Bibliothek wissen, an welcher Zeile der Farbwechsel stattfindet?
Was den AppleII als weitere 8 Bit-Plattform anbelangt, scheitert das RGB-Modell schon daran, daß der AppleII zwei Arten von Schwarz und Weiß kennt. Malt man mit dem falschen Schwarz eine Linie über einen grünen Untergrund, verfärbt sich dieser links und rechts der Linie orange usw. Hier muß man die Farben also anders auswählen, doch nicht über Bitmuster, denn die ändern sich je nach gerader oder ungerader Spalte, sondern allein über abstrakte Farbnummern. Hinzukommt, daß beim AppleII Farben gerne gedithert werden, z. B. eine Mischung aus Blau und Weiß ergibt Hellblau. Aber wie diese Mischung genau aussehen soll, ist eine Kunst für sich, da es hierfür zig Möglichkeiten gibt. Eine einfache Umrechnung von RGB auf Mischung kann da nicht gelingen.
Lange Rede, kurzer Sinn: Die Hardwareeigenschaften der verschiedenen 8 Bit-Rechner sind viel zu verschieden, als daß man sie alle über einen Kamm scheren könnte. Selbst auf einer Plattform gibt es schon Probleme, wenn diese mehrere verschiedene Anzeigemodi vorsieht wie z. B. HiRes und Multicolour. In der Praxis benötigen Programme jeweils maßgeschneiderte individuelle Lösungen. So habe ich z. B. im Laufe der Zeit viele verschiedene Linienroutinen geschrieben in Abhängigkeit von HiRes/Multicolour, Größe der Malfläche, Bitmap/Zeichensatz, Geschwindigkeit vs. Kompaktheit usw. 8 Bit-Rechner sind nun einmal keine PCs, und sie lassen sich daher auch nicht wie PCs programmieren.
Es ging im Beispiel -was auch rein als solches zu verstehen war, allein um die Hintergrundfarbe und zwar im Hires- oder Text-Mode, MultiColor war aussen vor.
Natürlich steigt der Aufwand einer universellen Umsetzung, das ist kein reines 8Bit Problem, das kennt man bei moderneren Oberflächen z.b. QT wie auch im "echten" HAL Bereich im Embedded (z.b. Autosar) jeweils genauso.
Aber man hat heute auf dem Rechner der IDE um derart viel mehr Speicher und Rechenleistung als auf dem Target, dass man diese Komplexität durchaus beherrschen kann.
Und für EINE Hintergrundfarbe als "Kompromiss" zw. der einen auf dem C64 und den möglicherweise mehreren auf anderen Systemen braucht man weder Raster-IRQ noch großartig Alpha-Blending oder Farbkreistheorien... (wenn man genau ist, sind die von Dir beschriebenen modes auch schon wieder multi-color modes jeweils, ob die Farben dafür dann global (wie beim VC20) oder lokal je 8x8 "Zeichen" wie beim TED zu hinterlegen sind, sind dann die Details der Realisierung.)
Das zweite Beispiel war eher das, was mir persönlich am Herzen liegt, nämlich alles rund um PIA, VIA, CIA, ACIA.
Dazu gehören die Timer, die PWM-Ausgabe mittels der Timer/Counter, die Frequenz- und Periodenmessung, die IRQ-Verwaltung, die GPIOs, Templates für komplexere GPIO Nutzung wie z.B. Tastaturmatrix, LED-Charlieplexing, die SPI resp. UART, die sich mit dem Schieberegister "basteln" lassen, sowie die im Kernal schon vorhandenen Routinen für IEC, RS232 und auch Cursor-Handling, die über die jumptables sogar recht systemunabhängig von Commodore schon implementiert wurden seinerzeit (oder von Bill M$ Gates, ganz ohne verstecktem ID-Chip noch 8-) ...).
Das Ganze ohne OS-overhead und ohne den Anspruch, damit prämierungswürdige "Szene-DEMOS" zu programmieren, sondern eher wirkliche Anwendungen, die der verfügbaren Rechenleistung und Speicherkapazität angepasst sind. Eben quasi wie Arduino oder PIC, aber mit Tastatur und CRT-Controller.