was du da schreibst ist richtig,![]()
aber irgendeinen Grund wird es wohl gegeben haben, dass die Pakete GRAPHICS, SPRITES, SOUND, und sogar JOYSTICKS und PADDLES mit aufgenommen wurden.![]()
Claus
was du da schreibst ist richtig,![]()
aber irgendeinen Grund wird es wohl gegeben haben, dass die Pakete GRAPHICS, SPRITES, SOUND, und sogar JOYSTICKS und PADDLES mit aufgenommen wurden.![]()
Claus
Also man kann von 96K oder etwas mehr mit SuperChipII auf stolze 512KB gehen.
Da lässt sich einiges unterbringen.
Das hat nicht mit SuperChipII zu tun, SuperChipII ist nur eine Erweiterung von Paketen, basieerend auf dem original Suoer-Chip, welches von Comal Today herausgegeben wurde.
Am Schluss werde ich mich doch dazu zwingen zu lernen wie man Pakete erstellt.
Schade ist es nicht so wie beim AMIGA COMAL wo man mit COMAL COMAL Pakete erstellen kann!
Das ist gar nicht so schwer.
Man muss wissen, was man möchte.
Man sollte 6510 Assembler können.
Und man sollte die Comal-Einsprungadressen, und deren Funktion kennen.
$8000 - $BFFF, 16KB werden vom COMAL verschlingt!
Wäre es in der Praxis möglich, diese 16KB auszulagern >>> COMAL >>> REU damit C64er zu mehr Arbeitsspeicher kommt?
Ich kann mich vorstellen, dass man einiges anpassen mĂĽsste.
Auch weil dann die neuen Pakete nicht mehr so ab $8009 möglich wären und das COMAL Modul selber hat ein paar Bytes ab $8000-$8009 abgespeichert.
Wenn der Aufwand nicht in die Kategorie UNMÖGLICH hinausläuft, wären das 16KB mehr Arbeitsspeicher für den C64, also ganze 50% mehr als jetzt oder 47KB Speicher für COMAL Programme!
Ich kenne mich mit den RAM-Erweiterungen für den C64 nicht aus, aber ich denke es wäre sehr schwer bis fast unmöglich.![]()
Übrigens, wäre PCBWay nicht in der Lage COMAL-Module zu produzieren?
Oder ist das jetzt neuerdings COMMODORE Eigentum?
Meine Module lasse ich immer von JLCPCB machen![]()
Der Modul-Code ist mMn kein Eigentum von Commodore.
Guten Morgen aus China
Claus
Meine Idee war eher dass man diese 16KB dann dem Commodore zur VerfĂĽgung stellt und anstelle von 16KB, 32KB ausserhalb des Commodores 64 KB {oder 4x16KB Banks} RAM einblendet. Also in diesem, laut Commodore, "...mehr RAM" Bereich!
Aber anscheinend ist mehr RAM eigentlich gar nicht mehr RAM als RAM, sondern mehr RAM als REU-RAM etc.
Irgendwie verwirrst du mich.
Meinst du jetzt mehr ROM, oder mehr RAM![]()
Egal, mit entsprechender Hardwareänderung am Modul, bzw. ein 'neues' Modul geht beides. Man kann sowohl mehr ROM, als auch mehr RAM zur Verfügung stellen.
Beides wird aber als 16kb Pages im Bereich $8000 - $BFFF verwaltet, und könnte auch mit SETPAGE entsprechend umgeschaltet werden, bzw. direkt in MS angesprochen werden.
Hardwaremässig muss man die Auswahl entsprechend erweitern. Bisher werden nur die Bits 0 bis 2 zur Dekodierung benutzt.
Nimmt man noch Bit 3 bis 5 hinzu, so kann man z.B. Bit 5 zum Umschalten von ROM auf RAM nehmen, und die Bits 3 und 4 zu Erweitern der Bänke.
Bisher Bit 0 - 2 = 8 Bänke,
Nachher Bit 0 - 4 = 32 Bänke
So habe ich es im Moment bei meiner Platine, und es funktioniert.
Möchte man die Änderung mit einem .crt machen, dann muss der Code zur Erkennung und Bereitstellung des Moduls für den entsprechenden Emulator angepasst werden.
Bzw. es muss der Code fĂĽr ein 'neues' COMAL-Modul geschrieben und integriert werden.
Zu den Registern:
Es hätte mich schon sehr gewundert, wenn COMAL da irgendwas hätte machen können.![]()
Aber nun scheint es ja zu funktionieren, das ist die Hauptsache.
Gute Nacht
Claus
Mit einem Patch im COAML-System, kann man diese Beschränkung umgehen, und sollte in der Lage sein bis zu 32 Pages a 32kb anzusprechen. (1MB)
Das stimmt so natĂĽrlich nicht ganz.
Richtig wäre: "und sollte in der Lage sein bis zu 32 Pages a 16kb anzusprechen. (512kb)
Ich habe das auch schon mit meinem Spezial-Modul ausprobiert.
Es hat natĂĽrlich geklappt.![]()
Ich habe dazu ein MX29F040 Eprom genommen.
Dort habe ich die ersten 4 x 16kb mit dem original COMAL80 geflasht.
Die nächsten 4 x 16kb mit dem SC-II.
Dann habe ich den Rest jeweils 16 kb mit den Werten $08 bist $1F beschrieben.
Das habe ich dann mit dem SMON fĂĽr COMAl kontrolliert, indem ich jede Bank einzeln eingeblendet habe, und mir den Inhalt ansehen konnte.
Damit COMAL auch diese Pages nach Paketen durchsuchen kann, und diese dort ausfĂĽhren kann, muss COMAL80 entsprechend gepatcht werden:
;$A3F7
!if PATCH = 0 {
; check for additional extensions on Pages
    ; here only the pages 83,84, and 85 are checked for extensions
LDA #$83 ; check PAGE4 (belongs to COMAL main part)
JSR .lA302
LDA #$84 ; check PAGE5 (1st 16kb)
JSR .lA302
LDA #$85 ; check PAGE6 (2nd 16kb)
JSR .lA302
}
    ; with the patch, it is possible to check as much we need. :)
!if PATCH = 1 {
; patch page limit
; a possible patch could be as following:
; replace the upper part with the following
LDA #$83 ; first page to check
- PHA ; save page
JSR .lA302 ; check page for extension
PLA ; get page back
CLC
ADC #$01 ; increase page counter
CMP #$87 ; cmp with max. page (in the original module there is a hardware limit)
                                ; the value can be changed to check more pages
BCC - ; next page
NOP ; fillbyte
; patch end
}
Alles anzeigen
Ja, lauft alles als Paket bei COMAL, egal ob ein Befehl, kein oder 50 drin sind.
Wenn wir schon bei 50 sind, gelesen habe ich, dass man anstelle von 16KB EPROMS, 32KB EPROMS verwenden kann.
Es gibt zwei Versionen des COMAL80-Moduls.
1. Das graue Modul, welches eigentlich nur in Nordamerika Verbreitung fand, und von den Machern der Comal Today 'vertrieben' wurde.
Diese hate 4 Steckplätze mit jeweils einem 16kb EPROM, und konnte auch nicht erweitert werden.
2. Das schwarze Modul, welches von Commodore unter anderem auch in Deutschland vertrieben wurde.
Dieses Modul hatte 3 Steckplätze, Auf den ersten 2 Steckplätzen befand sich das COMAL-System in jeweils 32kb ROM
Der 3. Steckplatz war frei, und konnte mit einem 32kb EPROM erweitert werden.
Näheres zu möglichen Erweiterungen ist in den nachfolgenden Links zu finden:
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.
COMAL80 2.01 kann von Haus aus die eigenen 4 Pages verwalten, und zusätzlich können noch zwei weitere Pages mit Paketen eingebunden werden.
Insgesamt sind das 96kb
Mit einem Patch im COAML-System, kann man diese Beschränkung umgehen, und sollte in der Lage sein bis zu 32 Pages a 32kb anzusprechen. (1MB)
Dazu müsste allerdings eine andere Hardware dafür entworfen werden. Als .crt-Version sollte es auch so möglich sein.
Ich denke, das sollte ausreichend sein. Die Software um dies zu fĂĽllen wird so schnell niemand schreiben.![]()
Der neue Commodore C64 kommt mit wesentlich mehr Speicher.
Es wäre doch ideal diese grössere EPROMS zu verwenden und diese dann beim C64 dort einbinden wo C64 Adressbereiche nicht gestört werden. Somit könnte man dann die COMAL Funktionalität und Möglichkeiten erheblich erweitern.
{Memory Map müsste natürlich entsprechend angepasst werden. Es ist schon mal gemacht worden und unmöglich ist es also nicht}
Die EPROMS, bzw. Pages werden ja schon so eingebunden, dass sie den C64 Adressbereich nicht stören.
Durch das Bank-Switching werden immer nur gerade die 16kb von $8000 bis $BFFF eingebunden, welche gerade gebraucht werden.
Als Beispiel nenne ich hier mal den Feinscrolling-Register! Der ist jetzt mit SPRITE-DATEN belegt.
Ich habe alle SETPAGES probiert, aber dieser Register gibt kein Lebenszeichen von sich. Das ist eigentlich nur ein Register.
Dort sind aber "tausende" Register für COMAL gestorben, ab $d000 {damit 32 Sprites untergebracht werden können}
In ComalToday fand ich soweit keine Angaben ob dieser Register an andere Stellen verschoben worden sind?
Die sind irgendwo weil Soundregister sind auch betroffen $d400.
Das mit den Registern kann ich nicht nachvollziehen.
Die Register im Bereich ab $D000 sind doch Hardware bedingt, da kann auch COMAL nichts dran ändern.
Eventuell kannst du das näher beschreiben, was du damit meinst.
Mit grösseren EPROMs, könnte dann ein sehr gescheites Köpfchen, COMAL Befehlsumfang erheblich erweitern.
Somit wäre es dann möglich eigenen Farbbereich für den Grafikbildschirm zu realisieren, alle Register ab $d000 wären verfügbar und damit hätte man ein USE Fun&Cool {
} Paket erstellen können {leider machen meine alten grauen Zellen nicht mit bei dem Plan}. TextBildschirm-Sprites, Mehrfarben-Zeichensatz, Feinscrolling in alle Richtungen und und...
Also COMAL-80 {C64} hat noch extrem viel Potenzial!
Siehe Aussagen oben, Register sind Hardware bedingt.
COMAL80 2.01 kann recht einfach erweitert werden.
Ob, und wie solche Erweiterungen aber von VICE , oder anderen Emulatoren unterstĂĽtzt werden, kann ich nicht sagen.
Da muss bestimmt auch noch der Code entsprechend angepasst werden.
Claus
Man hätte sicherlich den Grundwortschatz von COMAL um die Befehle ENGLISH und DANSK erweitern können, dann wären hier keine 'Pakete' notwendig gewesen.
Aber das macht mMn. doch auch keinen grossen Unterschied.
Möchte man z.B. ein anderes Sprachpaket nachladen, dann muss dass ja sehr wohl als Paket geschehen.
Ich denke nicht, dass man die Anzahl der Pakete bei COMAL80 hier in den Vordergrund gestellt hatte, sondern vorgebeugt hatte, dass, wenn man eine Sprache wählt, ein einheitlicher Weg gegangen werden sollte.
Aber das ist nur meine Meinung.
USE Dansk, USE English, USE Deutsch könnte man jetzt noch als Paket durchgehen lassen, weil die als PACKAGES bereits am Anfang aufgelistet sind und mit diesen Zusammen, komme ich sogar auf 13 Pakete bei COMAL-80-V2.02.
Korrekt, COMAL80 2.02 fuer den C128 hat insgesamt 13 Pakete.
Die zusaetzlichen 2 sind DEUTSCH, und RAMFILES
Na dann will ich mal das Raetsel um die fehlenden 'packages' aufloessen.
Es sind: English, Dansk, System
System wurde ja schon genannt.
In der Version 0.14 fuer den C64 mussste(konnte) man die Texte fuer die Fehlermeldungen nachladen, und waren kein fester Bestandteil des Systems.
Mit der Modulversion hat sich das dann geaendert, die Texte fuer die Fehlermeldungen wurden als 'package' mit in das Modul aufgenommen.
Und da dann immer noch genug Platz war, hat man auch gleich die Texte fuer Daenisch mit aufgenommen.
Umschalten kann man die Sprache mit z.B. USE dansk(english).
Zaehlt man die von mir erwaehnten 8 'packages', und diese 3 zusammen, dann kommt man auf die genannten 11 'packages'.
Auf der 'Cartridge Demo Disk 3" findet sich das Programm 'showlibs', mit dem man sich die enthaltenen 'packages' auflisten lassen kann.
Edit:
Ich habe das Programm mal angepasst, damit es auch auf dem C128 mit COMAL80 2.02 funktioniert. hier der Beitrag:Bitte melde dich an, um diesen Link zu sehen.
LG aus dem fernen China
Claus
Fuer COMAL80 2.01 gab es auf der 'Cartridge Demo Disk 3' das Programm 'showlibs'
Auf dem C128 liegt allerdings der Pointer 'libpt' nicht mehr an der Adresse $C7EF.
Damit das Programm auch auf dem C128 mit COMAL80 2.02 funktioniert, muss in der Zeile 460 der dort enthaltene Wert $C7EF auf $03B2 geaendert werden.
Im Anhang das schon abgeaenderte Programm.
LG
Claus
Weil ich mir immer alles so drehe, wie es mir passt.
Das habe ich mir ja schon gedacht.![]()
Dann sind wohl auch alle die USE {PACKAGE} im COMAL aktivieren und verwenden auch rettungslos verloren
So wie ich es sehe, gehören die USE-Packages zum Befehlsumfang der COMAL-Sprache. Die sind im COMAL-Modul fest integriert.
Wenn man hingegen Maschinenprogramme mit LINK benutzt, dann verlässt man die Sprache. Das ist dann, nach meiner Meinung, nicht mehr COMAL.
Im COMAL-Handbuch stehen die verbotenen Befehle ĂĽbrigens unter "Weitere Befehler", damit man sie nicht so leicht findet.
Dazu gehören:
- PEEK
- POKE
- SYS
- BASIC
- LINK
Ich denke, ich sollte das mal korrigiren.
Unter WEITERE BEFEHLE steht:
Wenn PEEK, POKE, und SYS 'verbotene' Befehle sind, warum dann nicht auch //, TRACE, DIM, und NULL?
Danach kommt der Abschnitt:KOMMANDOS 2UM START DER BETRIEBSSYSTEME
Un danch schliesslich:
KOMMANDDS UND ANWEISUNGEN, DIE DIE SOFTWAREPAKETE IN
MASCHINENSPRACHE (im folgenden 'packages' genannt) BETREFFEN
Die Befehle USE und DISCARD muessen auch fuer die Packages genutzt werden, welche im ROM des Moduls bereits vorhanden sind.
Dazu noch folgender Abschnitt aus dem Handbuch:
KOMMANDDS UND ANWEISUNGEN, DIE DIE SOFTWAREPAKETE IN
MASCHINENSPRACHE (im folgenden 'packages' genannt) BETREFFEN
USE
kann als Kommando oder Anweisung benutzt werden, um ein package benutzbar zu machen.
Der Befehl wird beispielsweise benutzt, um die im CONMAL-Modul bereits
vorhandenen packages zu aktivieren; die darin enthaltenen Befehle stehen dann zur
weiteren Programmierung zur Verfügung. Nähere Hinweise finden Sie bei den
package-Beschreibungen.
Beispiel:
USE graphics Das package 'graphics' wird aktiviert.
//Handbuch Zitat Ende
Die Modul-Version von COMAL80 2.01 ist ja im Endefeckt aus der vorherigen Version 0.14 entstanden.Da im Modul noch Platz war, hat man folgende Packages mit rein genommen:
Diese Packages sind zwar im Comal-Modul vorhanden, aber sie sind nicht in das Comal-Hauptprogramm integriert, sondern muessen mit USE erst eingebunden werden, und koennen auch mit DISCARD wieder aus dem Speicher 'geloescht' werden.
Zwischen diesen Packages, und den nachladbaren Packages gibt es keinen strukturellen Unterschied.
Auch wenn mancher hier im Forum anderer Meinung ist, behaupte ich trotzdem, das es nicht verwerflich ist, Packages zu benutzen.
LG aus dem fernen China
Claus
Alles anzeigenTja, der ASCII Code fĂĽr den Pfeil nach links entspricht nun mal dem Underscore. Damit ist da wohl alles richtig. (WofĂĽr man den Pfeil braucht, hat sich mir nie erschlossen. Nach rechts, OK...)
Wieso denn? Der ASCII-Code fĂĽr den Pfeil-nach-Links ist, laut dem C64-Handbuch, 95. Und wenn ich bei COMAL eingebe print chr$(95) oder nach Art des Hauses COMAL print ""95"", dann kommt der Pfeil-nach-Links.
Nur die Tastatur ist anders belegt als beim V2 Basic.
Wenn ich den Pfeil-nach-Links tippe, da kommt dann dieses komische PETSCII-Zeichen mit der dĂĽnnen Linie.
Wieso denn nur?
PS: Mir erschließt sich der Nutzen von Pfeil-nach-Links auch nicht. Aber trotzdem. Es geht ja ums Prinzip. Und als anständiger Commodore-Bürger kann ich das nicht so einfach hinnehmen.
Das Zeichen 95 ist in ASCII tatsaechlich der Unterstrich. Commodore hat ASCII fuer eigene Zwecke umdefiniert, und dies wurde spaeter umgenannt in PETSCII.
Allerding hat Commodore im Handbuch "ASCII" geschrieben, was eigentlich falsch war.![]()
Ich habe zu ASCII, und PETSCII mal ChatGPT befragt:
ZitatAlles anzeigenICH:
Was ist ASCII? und was ist PETSCII?
Warum ist z.B. das Zeichen 95 in beiden "Standards" unterschiedlich?
Ist PETSCII ein offizieller Standard?
KI:Sehr gute Fragen – das ist ein spannendes Thema aus der Computergeschichte!
ASCII
ASCII steht fĂĽr American Standard Code for Information Interchange.
Entwickelt Anfang der 1960er Jahre (ANSI-Standard 1963, erweitert 1967).
Definiert 128 Zeichen (0–127), davon sind:
0–31 Steuerzeichen (z. B. CR = Carriage Return, LF = Line Feed, BEL).
32–126 druckbare Zeichen (Buchstaben, Ziffern, Satzzeichen, Symbole).
127 ist DEL (Löschen).
Beispiel:
65 = A
97 = a
95 = _ (Unterstrich)
ASCII wurde zum Quasi-Standard, da er auf fast allen Computern der 1970er und 1980er genutzt wurde.
PETSCII
PETSCII steht fĂĽr PET Standard Code of Information Interchange.
Entwickelt 1977 von Commodore für den PET 2001 und später alle 8-Bit-Computer (VIC-20, C64, C128, Plus/4 etc.).
PETSCII basiert locker auf ASCII, aber:
Commodore hat eigene Steuerzeichen fĂĽr Bildschirmsteuerung eingefĂĽhrt (z. B. Cursor hoch/runter, Farbe setzen, Grafikzeichen).
Es gibt zwei Zeichensätze:
„Großbuchstaben + Grafikzeichen“ (Default beim C64).
„Groß- und Kleinbuchstaben“ (umschaltbar mit CHR$).
Viele Codes > 127 sind fĂĽr Blockgrafik, Rahmen, Kartenzeichen usw.
Beispiel:
65 = A (wie in ASCII).
97 = Grafikzeichen (kein a im Standardzeichensatz).
95 = PETSCII: horizontaler Block (—-ähnlich), nicht _.
Unterschied Zeichen 95
In ASCII: 95 = _ (Unterstrich).
In PETSCII: 95 = Grafikzeichen (meist horizontaler Balken).
Grund: Commodore wollte die „untere Hälfte“ für Blockgrafik und Steuerung nutzen, nicht für Kleinbuchstaben.
Darum wirken PETSCII-Texte in einem reinen ASCII-Terminal oft „verhackt“.
Ist PETSCII ein offizieller Standard?
Nein, nicht im Sinn von ANSI/ISO/ECMA.
PETSCII ist ein proprietärer Zeichensatz von Commodore.
Es wurde aber von Commodore offiziell dokumentiert (in HandbĂĽchern der PETs, C64, C128).
Heute wird PETSCII von Emulatoren (VICE, etc.) und Retro-Szenen als „Quasi-Standard“ weitergeführt.
👉 Zusammenfassung:
ASCII = internationaler Standard, Grundlage fĂĽr fast alle Textcodierungen.
PETSCII = Commodore-eigene Erweiterung, angepasst an Bildschirmsteuerung und Grafik, nicht kompatibel mit ASCII oberhalb von 0–64.
Ich:
In meinem CommodoreHandbuch fuer den C64 findet sich aber ASCII, und nicht PETSCII
KI:
Ah, genau – das sorgt oft für Verwirrung 🙂
Viele C64-Handbücher (vor allem die von Commodore selbst, aber auch Bücher von Drittanbietern) sprechen von „ASCII“ – obwohl sie in Wirklichkeit PETSCII meinen.
Warum steht im Handbuch „ASCII“?
Anfang der 1980er war ASCII schon ein geläufiger Begriff in der Computerwelt.
Commodore wollte den Eindruck erwecken, dass der C64 „standardkonform“ sei.
Tatsächlich hat man PETSCII benutzt, aber es wurde oft schlicht als „ASCII“ bezeichnet.
Technisch korrekt wäre: „ASCII-basiert, aber erweitert und geändert“.
Ergo, Commodore hatte seinerzeit ein bisschen geschwindelt.![]()
LG aus dem fernen China
Claus
Mein selbstgebautes COMAL-Modul hat bis zu 8 x 16kb RAM, welche unabhaengig voneinender von $8000 - $ BFFF eingeblendet werden koennen.
Das RAM (oder sagt man der RAM?) ist aber nicht beim normalen COMAL Modul vorhanden, das man damals offiziell kaufen konnte. Ich nehme mal an, dass da im Wesentlichen nur ROM-Chips drin waren und weiter nichts. Oder?
Random Access Memory = Wahlweise Zugriffs Speicher (kurz: Arbeitsspeicher)
Der Speicher = der RAM
Und ja, dieser RAM ist nicht bei einem normalem (originalem) Modul, welches man damals kaufen konnte, vorhanden.
Zudem kann man ein originales Modul auch nicht einfach so umbauen. (Leider)
Wenn die Log-Dateien, welche zu MS geschickt werde, auch so aussehen, dann ist es kein Wunder, dass Windows immer noch nicht so richtig funktioniert.![]()
Okay, danke für die Erläuterung. Und ich hab schon für einen Moment gedacht, im COMAL-Modul wäre RAM-Speicher enthalten, in dem der Grafikbildschirm angelegt wird. - ClausS hat mal ein Bild von seinem selbstgebauten COMAL-Modul gezeigt. Das sah vom Aufbau ziemlich kompliziert aus und deshalb hielt ich das für möglich.
Mein selbstgebautes COMAL-Modul hat bis zu 8 x 16kb RAM, welche unabhaengig voneinender von $8000 - $ BFFF eingeblendet werden koennen.
Zudem habe ich fuer den Denise-Emulator auch einen Patch geschrieben, und habe unter macOS dort auch diesen RAM im Emulator zur Verfuegung.
Allerdings habe ich noch nicht wirklich was damit gemacht.
Ich kann mir aber vorstellen, dass man das Paket RAMFILES aus COMAL 2.02 in COMAL 2.01 integrieren koennte.
Edit:
Fuer VICE habe ich disen Patch bisher noch nicht umsetzen koennen, da fehlen mir einfach die Programmierkenntnisse.![]()
Edit2:
Fuer das UC2 gibt es auch ein jedec File fuer die RAM-Unterstuetzung unter COMAL
Unter DRIVES gibt es den Menuepunkt "CHANGE ROM", dort kann man fuer jedes Laufwerk ein System einstellen.
Bitte melde dich an, um diesen Anhang zu sehen.
LG aus dem fernen China
Claus
Alles anzeigenHallo liebe COMAL-Community (bestehend aus ClausS).
Protest!!!
Ich bin hier auch immer mit dabei
Wenn ich nach meinem nächsten Projekt etwas mehr Zeit habe, werde ich mich auch mal tiefer in TSB und Comal einarbeiten.
Die Grundlage sind ja schon geschaffen.
Bitte melde dich an, um diesen Anhang zu sehen.
Bis dahin werde ich hier mitlesen!!!
Wird in dem Buch ausschliesslich COMAL 0.14 beschrieben, oder wird da auch COMAL 2.01 behandelt?
Alles anzeigenHallo liebe COMAL-Community (bestehend aus ClausS).
Ich habe mal eine Frage zum Graphics-Paket.
Der Hintergrund:
Wenn ich Text im Textmodus darstelle, dann habe ich beim C64 eine einzige Hintergrundfarbe und jeder 8x8 Pixel große Quadrant kann eine eigene unabhängige Vordergrundfarbe haben.
So weit ich weiĂź, ist das im Hires-Modus etwas flexibler. Da kann jeder 8x8 Pixel groĂźe Quadrant sowohl eine eigene Hintergrundfarbe als auch eine eigene Vordergrundfarbe haben.
Ich kann in COMAL jedoch keinen Befehl entdecken, der das unterstĂĽtzt.
Nehmen wir z.B. mal diesen Beispielcode:
Code10 use graphics 20 graphicscreen(0) 30 plottext(0,0,""28"R"30"G"31"B") 40 repeat until key$<>""Ich zeichne unten links in die Ecke die Buchstaben RGB. Das R ist rot, das G ist grĂĽn und das B ist blau.
Nun möchte ich, dass das R einen grünen Hintergrund hat, das G einen blauen Hintergrund und das B einen roten Hintergrund.
Sehe ich es richtig, dass das mit den gegebenen COMAL-Befehen nicht machbar ist?
Fragende GrĂĽĂźe,
Omega
Mir ist da leider auch keine direkte Moeglichkeit bekannt.
Dafuer muesste jemand eine Funktion schreiben.![]()
Mit Plottext einen Buchstaben schreiben, und dann mit Poke die Hintergrundfarbe anpassen.
Naechster Buchstabe, usw.
Finde ich aber gut, dass Du Dir, in China lebend, dort diese Frage stellst
Sagen wir aber zumindest mal: Es funktioniert.
Und der Treppenwitz dabei ist: Diese Scripte werden auf Microsofts eigenem Github-Dienst gehostet
Naja, war eigentlich mehr eine retorische Frage.![]()
Passt schon.![]()
Wenn du keine speziellen Windows Programme benötigst (und selbst da geht vieles mit Probieren), wäre nun der ideale Zeitpunkt mal Linux zu testen. (Das aus einem Mund, der bis vor 2 Jahren nur Windows am Start hatte
)
Kannst ja hier mal reinschnuppern Bitte melde dich an, um diesen Link zu sehen.
Nur mal eben zur Info:
Ich habe 3, jetzt 4 Rechner:
1 iMac 24 M1
1 Mac mini M4 pro; darauf laufen in Parallels Win11 for Arm, und Ubuntu
1 Thinkpad T420 mit macOS Sierra, Linux Mint, und Windows 10 im Parallelboot
und neu, 1 Redmi Book 14S mit Win11 (bisher ausschliesslich)
Ich brauche das Windows-System fuer meinen Eprombrenner XGecu T48. Dieser wird leider nicht von der Win11 ARM-Version unterstutzt
Ansonsten nutze ich Windows nur um etwas auszuprobieren, was es halt wirklich nur fuer Windows gibt, oder in anderen eventuell auftretenden Notlagen.
macOS nutze ich seit ca. 9 Jahren, davor war ich ca. 10 Jahre Linux-User
Meine persoenliche Meinung:
Es geht nichts ueber macOS