Beiträge von Ruudi im Thema „Wie bekomme ich den Grafikmodus 320x200 in ASM für den Plus4?“

    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.

    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 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 :wink:

    Just my 2 Cents!

    Meiner 2 Jährigen sage ich auch immer, sie solle keine Dinge in den Mund nehmen, die sie nicht kennt! :wink:

    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...

    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! :wink:

    eine Art HAL scheint es auch in den modernen Entwicklungsumgebungen bislang nicht zu geben.

    Doch: Bitte melde dich an, um diesen Link zu sehen.

    Geht leider an dem vorbei, was ich meinte, lediglich die dort enthaltene TGI_ioctl geht ein wenig in diese Richtung.

    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)

    Oder z.b. für die serielle Schnittstelle

    COM_Get_Max_Port(void) erst mal rückmeldet, wie viele COMs es findet, 0 oder -1 heisst keine.

    COM_Get_Max_Baud(int port) würde dann dazu die maximale Baudrate abliefern

    COM_Open(int port, long baud, char parity, int stoppbit) könnte man einen Kanal mit einer Baudrate und Parity und Stoppbits konfigurieren und öffnen.

    Wie gesagt, Bezeichnungen oben sind Schall und Rauch, es sollten eben nur die gerätespezifischen Dinge so gut wie möglich versteckt werden, aber Limitierungen durchaus abfragbar sein (hier z.b. MaxBaud), um gegebenenfalls auch dem User dann eine passende Auswahl anbieten zu können (COM1 2400 Baud, Typ CIA, COM2 38400 Baud, Typ 6551) etc.

    Das TGI stellt hier sehr komplexe Zeichenfunktionen zur Verfügung, aber die Basis, sprich: welche Auflösung mit welcher Bittiefe ist überhaupt möglich, welche Farbtiefe wird unterstützt, wieviele Zeichen/Zeile und Zeilen hat der Modus, wieviele Modi und Bildschirmseiten gibt es, die sind nicht oder nur sehr versteckt vorhanden. Somit muss man die relativ große Bibliothek mit einbinden, wenn man z.b. nur komfortabel die Hintergrundfarbe verändern will...

    Also HW <-> HAL <-> System <-> Support <-> Application würde ich mir da aus Softwaresicht vorstellen, jeweils klein und modular gehalten, damit man den verdammt kleinen Speicher auch gut nutzen kann und dennoch nicht auf eine klare Struktur verzichten muss.


    Aber wie gesagt: sind nur fromme "Wünsche", ich selbst würde sowas bestenfalls benutzen, jetzt in 2021 so eine HAL für die alten Kisten selbst programmieren würde ich nicht, da spiel ich lieber mit den Spielen aus der Jugend und schwelge in Erinnerungen :wink: Oder restauriere so ne alte HW und freue mich an dem Charme der damaligen Systemumgebung, insbesondere CBM Basic 2.0 ...

    Das wäre jetzt ein gutes Beispiel für das, was ich in anderen Threads schon mehrfach angemerkt hatte:

    eine Art HAL scheint es auch in den modernen Entwicklungsumgebungen bislang nicht zu geben.

    Würde heutzutage tatsächlich erwarten, dass ich hier ein paar Funktionsheader aus Libraries habe wie (rein phantasiert jetzt):

    TED_init(void)

    TED_Mode(int)

    TED_GlobalColumbs(int)

    in denen solche Dinge definiert und soweit abstrahiert sind, dass ein Aufruf unter c Sinn macht. Natürlich muss man auch dann noch wissen, wie z.b. das Argument int im Mode auf die einzelnen Register des TED aufgeteilt wird, sprich welche Werte von int was auslösen. Vermutlich stellt das Basic oder gar der Kernal hier bereits geeignete Routinen zur Verfügung, auf die man aufsetzen kann.

    Kann man natürlich bis runter zu Ersetzungstabellen und Einzelbits durchziehen, aber so wie oben, durch Assembler Pragmas, die letztlich nix Anderes sind als die Pokes am C64 Basic 2.0, das erscheint gerade bei den 264ern mit dem guten Basic 3.5 eher als Rückschritt...

    Bevors wieder Klagen hagelt: NEIN, ich habe NICHT in die plus4.h reingeschaut, sondern nur auf den AssemblerCode und nur darauf bezieht sich mein Kommentar. Wenn also in plus4.h solche Prototypen definitiert sind, dann wäre allein der Code unsinnig (es sei denn, es wäre extrem zeitkritisch...) und der Hinweis auf die .h Dateien und entspr. Prototypes zielführend :wink:

    Definitionen wie Char * screen *8192 sind -angesichts von "nur" 64k RAM für "Alles" nicht nur "verschwenderisch", da 320x200/8 immer noch 8000 sind und nicht 8192, sondern stellen auch den Compiler vor große Herausforderungen, da wir hier einen 8Bit-Prozessor mit NUR 2 Stk. ACHT-Bit Index-Registern haben, d.h. wäre eine Aufteilung in x und y (Koordinaten) sinnvoller, die beiden index-register heissen zufällig auch schon so (kann aber sein, das der Compiler das dann ganz anders löst, da er fürs "housekeeping" auch ressourcen vorhält. Bitte bei allem C-Komfort immer daran denken, wie begrenzt die Ressourcen auf dem Zielsystem sind!

    Hinsichtlich der verschiedenen Funktionsmodule des CIA 6526 habe ich solch allgemeine Templates, um z.b. einen SPI-Kanal aufzumachen und mit SPI-Mode(1,1) dann zu senden oder auf Empfang zu lauschen, bislang vergeblich gesucht. Hinweise dazu jederzeit gerne willkommen.