Hallo EgonOlsen71 danke für deine Erklärung.
Damit habe ich es verstanden.
Es gibt 33 Antworten in diesem Thema, welches 5.636 mal aufgerufen wurde. Der letzte Beitrag (
Hallo EgonOlsen71 danke für deine Erklärung.
Damit habe ich es verstanden.
Als HAL würde ich es z.b. bezeichnen, wenn ich auf nen beliebigen unterstützten System, z.b. C=, BBC, Apple-II ...., z.b. eine Funktion habe
CRT_Set_BGColor(int8 red,int8 green,int8 blue),
die die Hintergrundfarbe passed zu den im Standard-RGB-Farbraum übergebenen Farbkoordinaten einstellen (und auf Systemen mit wenigen Farben eben die Passendste auswählen,bei den nur 16 Farben eines C64 ein ziemlicher Kompromiss, ganz klar, aber dafür universell)
So eine Funktion wäre ohne Gammakorrektur, Alphakanal und CMYK-Kompatibilität aber unbrauchbar.
Als HAL würde ich es z.b. bezeichnen, wenn ich auf nen beliebigen unterstützten System, z.b. C=, BBC, Apple-II ...., z.b. eine Funktion habe
CRT_Set_BGColor(int8 red,int8 green,int8 blue)
...
So eine Funktion wäre ohne Gammakorrektur, Alphakanal und CMYK-Kompatibilität aber unbrauchbar.
So, so, wäre sie das?
Kleine Gegenfrage: Was kannst Du besser: Buzzword-Bashing oder Bullshit-Bingo?
Sorry: CMYK ist Druckfarbmischung, hat jetzt mit Bildschirm so gut wie gar nix zu tun, jedenfalls haben all meine FarbMONITORE RGB als Grundfarben, dafür all meine FarbDRUCKER CMYK...
Gammakorrektur macht -wenn dann- der Bildschirm im Rahmen eines Farbprofils, aber sorry, bei max. 121 Farben eines C= 8bitters wird man das nicht brauchen, das bekommt jeder mit Farb- Helligkeits- und Kontrastregler noch selbst hin...
Die in meinem Beispiel angedeutete 24bit lineare RGB-Farbcodierung findet übrigens seit Mitte der 90er in VGA-Karten genauso Verwendung wie in hochwertigen Spezialgrafikkarten z.b. von SGI.
Und mit Alphakanal hat das auch überhaupt nix zu tun, da wir nur EINEN Layer hier haben, da gibt und braucht es keine Transparenz!
Und zudem stehen im zitierten Post oben zwei Dinge:
1) es ist ein REINES Beispiel, der Sinn liegt darin, unterschiedlichste Hardware zu unterstützen, ohne deren Feinheiten oder gar Register etc. kennen zu müssen. Dazu braucht man natürlich ein Superset an Features, die entweder (siehe Baudrate COM) dann abfragbar sind, oder -wie hier- einfach auf die Möglichkeiten der echten HW runtergebrochen werden.
2) es gibt -seitens des Compilers, also NICHT zur Laufzeit eine "Übersetzungstabelle", die würde möglicherweise eine Gammakorrektur dann schlicht enthalten, die restlichen Begriffe haben mit der Aufgabenstellung nicht mal im Ansatz zu tun!
Meiner 2 Jährigen sage ich auch immer, sie solle keine Dinge in den Mund nehmen, die sie nicht kennt! ![]()
Meiner 2 Jährigen sage ich auch immer, sie solle keine Dinge in den Mund nehmen, die sie nicht kennt!
Töchterchen: "Papi, fass mal an deine eigene Nase!"
Ich würde dem Threadersteller - der gewisse Ähnlichkeit mit Spacer hat - wirklich empfehlen, nicht nur irgendwelche Code-Fragmente zu sammeln und dann zu versuchen, daraus irgendwas zu machen - nein, der TE sollte sich wirklich von Anfang an ("es war einmal ein Register...") mit der Hardware und deren Programmierung beschäftigen. Das macht nicht nur viel Spaß - es bringt auch viel mehr, weil man dann auch weiß, warum man etwas genauso tun muss, wie man es eben tut.
Ich würde dem Threadersteller - der gewisse Ähnlichkeit mit Spacer hat -
![]()
Meiner 2 Jährigen sage ich auch immer, sie solle keine Dinge in den Mund nehmen, die sie nicht kennt!
Töchterchen: "Papi, fass mal an deine eigene Nase!"
Gehts auch ein wenig konstruktiver, oder nur Lust am Stänkern?
Etwas Abstraktionsvermögen habe ich bei meinen Beispielen vorausgesetzt und dass ein BILDSCHIRMHINTERGRUND (sic!) weder CMYK-Farbmodell, da selbstleuchtend und somit RGB als auch erst recht keinen Alpha-Channel braucht (da konstante und eben NICHT transparente Hintergrundfarbe), dürfte kaum zu leugnen sein, oder?
Und von einer Basisbibliothek für uralte 8-Bit Rechner auf heutige Echtfarben-Bildverarbeitung und deren Finessen zu springen ist weder sinnvoll, noch relevant hier! Und da die 24bit schon vom Compiler dann mittels Tabelle oder Berechnung auf die deutlich kleineren Ziel-Werte (eben für die Register des TED, VIC etc) umgesetzt werden, ist es auch keine Ressourcenverschwendung.
Ich wollte hier mal einstreuen, das mir brauchbare Programmierumgebungen für den C64 fehlen, wie es sie heute wie Sand am Meer für die div. uCs gibt, z.b. die Compiler von MikroE, welche quer über mehrere uC Familien verschiedener Hersteller sogar einen annähernd gleichen Satz an brauchbaren und erprobten HAL-Routinen für die OnBoard-Peripherie sowie beliebte externe Peripherie (wie z.b. LCDs via SPI etc) bieten.
Möglicherweise habe ich eine vergleichbare Implementierung aber schlicht noch nicht gefunden, daher hier die Fragestellung und Erklärung dazu. Welche absichtlich hier mit eingefügt wurde, um möglichst Viele Leute zu erreichen, die möglicherweise damit Erfahrung haben.
Wenn dann aber Antworten, die nicht nur falsch, sonden absolut unpassend zum Thema sind, zurückkommen, erlaube ich es mir durchaus auch mal etwas direkter zu werden...
Ich würde dem Threadersteller - der gewisse Ähnlichkeit mit Spacer hat - wirklich empfehlen, nicht nur irgendwelche Code-Fragmente zu sammeln und dann zu versuchen, daraus irgendwas zu machen - nein, der TE sollte sich wirklich von Anfang an ("es war einmal ein Register...") mit der Hardware und deren Programmierung beschäftigen. Das macht nicht nur viel Spaß - es bringt auch viel mehr, weil man dann auch weiß, warum man etwas genauso tun muss, wie man es eben tut.
Wenn alle so denken würden, lebten wir heute noch in Steinzeit-Höhlen!
Arbeitsteilig vorgehen und kapseln, abstrahieren, das ist doch das Geheimnis jeglichen Fortschritts.
Heute weiß doch kaum noch Jemand, wie sein Auto im Detail funktioniert,noch hätte er die Möglichkeit es wirklich SELBST zu reparieren. Auf Modulebene vielleicht, aber das Steuergerät bekommst Du weder im Detail diagnostiziert, noch gar erfolgreich repariert (wenn Du das nicht zufällig professionell machst...) Oder die Smart-Phones: wer hat denn da noch den Überblick, was die wann und wohin mit welchem Protokoll verschicken, wie man deren Betriebssystem gegen Angriffe härten könnte etc etc etc.
Die werden einfach nur bedient und genutzt!
Und ich kann Leute wie den Thread-Ersteller gut verstehen, wenn die -vielleicht vom Raspi oder Arduino kommend- hier eine ebenso strukturierte und abstrahierte Entwicklungsumgebung eben erwarten.
Seinerzeit, als in Ermangelung einer privaten 100k DM Workstation die Meisten wohl AUF dem C64 eben diesen programmierten, wäre weder eine moderne IDE noch gar ein komplexer Precompiler-Lauf möglich gewesen, aber heute geht das, wie man an Systemen wie o.g. ja sieht.
Mit den Registern MUSS sich dann keiner mehr auseinandersetzen, reine Zeitverschwendung. Und wer heute erst einsteigt, der hat eben keine 30 Jahre Zeit gehabt wie wir "Alten", um sich das alles anzueignen (und wieder zu vergessen....)
Man KANN die Beschäftigung mit den Basics auf Registerebene interessant finden, aber man MUSS nicht! Ebenso wie wohl die Wenigsten wissen, wie die CPU intern funktioniert,deren ALU, Decodierlogik, prefetching etc etc. oder gar Multi-Emitter-Transistoren auf DIE-Ebene. (@AstroSID mal definitiv aussen vor, vielleicht auch noch ein zwei Andere...)
Und ich denke, es wäre gut, hier auch kein "Muss" aufzubauen, denn das schreckt ab und ohne Nachwuchs macht es doch auch keinen Spass, oder?
Also erklären, ok. aber nicht zur Religion erklären!
ich muss auch nicht wissen, welchen Zündwinkel mein Auto braucht und welche Winkel die Nocken auf der Welle haben, um damit zu fahren und trotzdem viel Spass dabei haben ![]()
Just my 2 Cents!
Gehts auch ein wenig konstruktiver
Ok, hast gewonnen. Deshalb folgender Vorschlag:
Ich wollte hier mal einstreuen, das mir brauchbare Programmierumgebungen für den C64 fehlen
Das schöne an KickC. cc65 und Konsorten ist ja, dass die Open Source sind und Contributions gerne gesehen werden, soweit ich weiss. Kannst du da vieleicht mitwiken oder zumindest hier eine Liste mit kommentierten Funktionsköpfen bzw. -prototypen zusammenstellen, die so eine HAL haben sollte. Am Bestein in einem neuen Thread.
Ich wollte hier mal einstreuen, das mir brauchbare Programmierumgebungen für den C64 fehlen
Das schöne an KickC. cc65 und Konsorten ist ja, dass die Open Source sind und Contributions gerne gesehen werden, soweit ich weiss. Kannst du da vieleicht mitwiken oder zumindest hier eine Liste mit kommentierten Funktionsköpfen bzw. -prototypen zusammenstellen, die so eine HAL haben sollte. Am Bestein in einem neuen Thread.
Das ist jetzt das klassische Henne-Ei-Problem:
Wenn ich die Zeit und Muse dazu hätte, würde ich das liebend gerne tun. Hab ich aber nicht, daher würde ich -ganz User oder meinetwegen auch "Konsument"- das zu"kaufen", sprich etwas nutzen, was schon existiert, um darauf dann in schnellerer Zeit komplexere Lösungen erstellen zu können, die dann vielleicht wieder Jemand Anderem nützen, sei es als User oder als Basis oder als Tool für weitere Entwicklungen.
Dieses Etwas muss aber natürlich irgendwie passend sein, sowohl für mich und meine persönlichen Voraussetzungen, als auch für den Zweck tauglich.
Ich befinde mich sozusagen gerade in der Auswahlphase diesbezüglich.
Und fand erstaunlicherweise: NICHTS! (ansonsten musste ich eher feststellen, dass meine Ideen alle schon irgendwer realisiert hat, sowohl die "alten" aus der damaligen Zeit, als auch Dinge, die mir erst in den letzten Jahren eingefallen waren... Indien und China haben zusammen mehr HOCHbegabte Kinder, als wir überhaupt Einwohner...)
Daher suchte ich den Fehler bei mir und den möglicherweise falschen Stichworten bei der Suche auf Google & Co. und zog sozusagen hier den Publikums-Joker, in der Hoffnung, dass meine Beispiele und Erläuterungen helfen zu verstehen, was ich -und womöglich auch der Threadersteller- eigentlich suchen...
Wenn ich jetzt anfange, MISRA Standard liegt- offziell auf mich lizenziert- hier mit auf dem Tisch, hier eine HAL-Struktur vorzugeben, ohne aber diese selbst dann auch umsetzen zu können, dann wird daraus nur eines: eine endlose Diskussion um vermutlich unwichtige Details.
Zudem geht mir diese Zeit davon ab, das zu programmieren, was ich als ANWENDUNG vor Augen habe...
Also insofern: hier bin ich ganz KONSUMENT, an dem, was dann dabei rauskommt, lasse ich gerne andere wiederum partizipieren!
(siehe meine eher HW-lastigen Threads und die immer wieder mal erwähnten Möglichkeiten, auch eher seltenere oder hochpreisige Literatur etc. via PN zu teilen.)
Mein Vorschlag an diese Community wäre, sich entsprechende µC-IDEs und Libraries wie die schon erwähnten Arduino und MikroE-Compiler (samt Zubehör z.b. f. TFT Displays) oder meinetwegen (steckt ja auch C dahinter) auch Matrixmedia s FlowCode mal anzusehen.
Mir persönlich gefallen die Umsetzungen von MikroE am Besten, die von FlowCode sind gut gemeint, aber leider im Detail dann schlecht gemacht (z.b. Zählschleifen in derart automatisch erstellten Unterprogrammen anstelle Interrupt-Steuerung), sowie in den letzten 2-3 Versionen zu sehr auf die Simulationsebene abgedriftet. Arduino ist wieder seine eigene Welt, begrenzt schon durch die geringe Auswahl an Targets im Gegensatz zu den anderen beiden Umgebungen.
Von Infineon (früher Siemens) gibt es seit den 90er Jahren schon eine automatische und Dialog-Gesteuerte Erstellung von templates für die Einbindung aller verfügbaren peripheren Einheiten für die C16x Prozessoren (und deren zahlreiche Nachfolger...) namens " DAvE ".
Microchip bietet eine ähnliche Funktionalität in den neueren MPLAB-Versionen ebenso an, aber natürlich jeweils begrenzt auf die OnBoard-Peripherie im Gegensatz zum System-Ansatz der Produkte von Matrixmedia und MikroE. Es gibt sicherlich noch zig weitere solche Systeme.
Mich erstaunte eben nur, dass ZWISCHEN hoch spezialisierten Insellösungen wie der TGI-Lib und sehr rudimentären Ansätzen (sprich der reinen Vordefinition von Namen für Register-Adressen und teils noch die 1:1 Abbildung deren Inhaltsstruktur) eben NICHTS zu finden war...
Danke und beste Grüße!
*Ruudi*
Ich 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.
Wenn ich jetzt anfange, MISRA Standard liegt- offziell auf mich lizenziert- hier mit auf dem Tisch, hier eine HAL-Struktur vorzugeben, ohne aber diese selbst dann auch umsetzen zu können, dann wird daraus nur eines: eine endlose Diskussion um vermutlich unwichtige Details.
Zudem geht mir diese Zeit davon ab, das zu programmieren, was ich als ANWENDUNG vor Augen habe...
Ein Entwurf für ein Headerfile, mit Kommentaren versehen und vieleicht mit Dokumentationstags ergänzt, nimmt doch nicht so viel Zeit in Anspruch. Also nur zu.
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.
Das ist echt zu geil hier...
Aber ja, es gibt sogar einen Ansatz, nennt sich "8bit Unity", ob das jetzt exakt so ist wie Ruudi es sich von der Community wünscht (oder sollte ich eher sagen "fordert") kann ich nicht beurteilen, aber kann man sich ja mal anschauen wenn man Bedarf an sowas hat...
Bitte melde dich an, um diesen Link zu sehen.
EDIT: Mein Fall waers jedenfalls nicht (nicht dass das so verstanden wrid als wuerde ich das "empfehlen")