Beiträge von ClausS

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

    Ü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:gruebel

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

    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:

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

    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 {:search:} 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.

    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

    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:

    • //
    • TRACE
    • DIM
    • NULL
    • PEEK
    • POKE
    • SYS

    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

    • BASIC
    • SYS 50000

    Un danch schliesslich:

    KOMMANDDS UND ANWEISUNGEN, DIE DIE SOFTWAREPAKETE IN

    MASCHINENSPRACHE (im folgenden 'packages' genannt) BETREFFEN

    • USE
    • LINK
    • DISCARD
    • STOP
    • END

    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:

    • GRAPHICS
    • TURTLE
    • SPRITES
    • FONT
    • SOUND
    • PADDLES
    • JOYSTICKS
    • LIGHTPEN

    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

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

    Ich habe zu ASCII, und PETSCII mal ChatGPT befragt:

    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)

    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

    Wird in dem Buch ausschliesslich COMAL 0.14 beschrieben, oder wird da auch COMAL 2.01 behandelt?

    Mir ist da leider auch keine direkte Moeglichkeit bekannt.

    Dafuer muesste jemand eine Funktion schreiben.:whistling:

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

    Sagen wir aber zumindest mal: Es funktioniert.

    Und der Treppenwitz dabei ist: Diese Scripte werden auf Microsofts eigenem Github-Dienst gehostet :D

    Naja, war eigentlich mehr eine retorische Frage.:D
    Passt schon.:thumbup:

    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