Hallo Leute,
Welches C benutzt ihr um am bzw. für den CPC etwas zu programmieren.
Bin selber kein C Code, aber habe mich mal etwas mit dem Small-C unter CP/M beschäftigt.
Welchen Compiler kann man empfehlen?
Ich denke, dass die meisten Leute, heutzutage C-Code am CPC schreiben, den SDCC-Compiler benutzen. Dieser ist imho am weitesten entwickelt und der wird auch aktiv weiter entwickelt. Die Leute z.B. die CPCtelera benutzen, müssen den auch alle nehmen.
Ich persönlich programmiere halt beruflich (heutzutage zwar viel weniger) in C/C++ und mir liegt das dann eher, mir die groben Abläufe in C auszudenken und umzusetzen. Du kannst dann z.B. dir eine Spriteroutine in Assembler schreiben, musst dich halt an eine bestimmte Konvention der Parameterübergabe halten, macht dann einen C-Rahmen drum und benutzt die Assembler-Spriteroutine aus C-heraus. Oft bin ich halt schneller bei eitwas, wenn ich es erst einmal in C-Code und anschliessend den ein oder anderen Teil durch Assembler ersetze.
Ein Nachteil, wenn man auf SDCC setzt und, wie ich, auch viel in assembler macht, ist dass der assemblercode teilweise etwas anders geschrieben werden muss. z.b. ld a,#0x23. Ausserdem kennt er die "illegalen" opcodes nicht. Hier kann man sich aber durch makros behelfen.
Zum Thema debugger: SDCC kann mit bereits existierenden debuggern umgehen(z.b.: http://fivedots.coe.psu.ac.th/~cj/masd/resources/sdcc-doc/SDCCUdoc-28.html für die kommandozeile). Aber es würde z.B. schon folgendes eine grosseHhilfe sein: Der compiler spuckt immer eine Datei aus, in der alle funktionen und globalen variablen mit adressen hinterlegt sind. Wenn man jetzt im CPC-Debugger auf diese funktionen breakpoints setzen könnte, die dann auch noch abgespeichert wären und sich die inhalte der gewünschten variablen in einem fenster anzeigen lassen könnte, wäre schon viel vereinfacht.....
Ah, vielen Dank für die ausführliche Antwort. :smiley027: Wie kommuniziert das SDCC denn mit dem CPC? Ist das alles in einer Library? Gibt's da den Source Code? Kann man die ändern? :o
Habe daran gedacht so eine Library umzubauen, dass das SDCC auch für FutureOS zu gebrauchen ist. Den Assembler-Teil hätte ich wohl ganz schnell zusammen, nur den C-Teil... :)
Also, ich habe nie ernsthaft versucht in C zu programmieren, mich reizt das Thema dennoch, da die Programmiersprache sehr viel mehr Möglichkeiten bietet als andere, um ,,maschinennah" zu arbeiten. Ich hatte mal Kontakt (direkt am CPC) mit dem Hi-Soft C Compiler oder dem von Arnor. Beide versprechen nah am KR Standard zu sein, obwohl das heute wahrscheinlich gar nicht mehr so viel bedeutet.
Ich habe zuviel in Basic gemacht, daher fällt es mir relativ schwer in C mich zurechtzufinden. Muss halt mehr üben. Das Einbinden von Assemblercode finde ich einfach auch gut zur Erweiterung der Möglichkeiten.
SDCC scheint neben Z88DK am aktuellsten zu sein. Sind nicht beide ineinander aufgegangen oder vertausche ich hier was?
Ne Library wäre z.b. das cpctelera. Ich nutze aber quasi meine eigene library.
Es gibt zuerst eine startup-datei in assembler für den c-code. Wenn man in C keine globale initialisierte variablen benutzt, braucht man in dieser startup-datei nix anderes tun als .org #4712 und dann jp _main. Der Assembler kennt alle c-variablen und funktionen indem man ein _ davor schreibt. Was passiert: ich lande automatisch in meiner void main(void). Hier kann ich dann meine eigenen lib-funktionen aufrufen.
Ich nutze kein cpctelera, da ich schon ganz gerne mein eigener herr bin und das cpctelera ja eher generisch ist und viele dinge (noch) nicht kann. Ich schaue mir natürlich gerne an, wie die manche sachen lösen.
So sieht dann z.B. eine Lib-Funktion von mir aus:
void ClsC000(void) __naked
{
__asm
ld hl, #0xc000
ld ( hl ), #0
ld de, #0xc001
ld bc, #0x3FFF
ldir
ret
__endasm;
}
Das naked heisst übrigens das die funktion nix automatisch rettet und ich dafür verantwortlich bin, dass die register dannach korrupt sind.
Anderes Beispiel, wo der compiler die register rettet (den code sieht man natürlich nicht hier):
void SetColorDirect(unsigned char nColorIndex, unsigned char nPalette)
{
nColorIndex;
nPalette;
__asm
ld ix, #2 ;; [3] IX Points to SP+2 (first 2 bytes are return address)
add ix, sp ;; [3] , to use it for getting parameters from stack
ld e, 0( ix )
ld l, 1( ix )
ld b, #0x7f
ld c, e
di
out (c), c
ld c, l
out (c), c
ei
__endasm;
}
...reicht es in Deiner "naked" variante nicht einfach aus mit push & pop die Register vorher zu stapeln und wieder zurückzuholen?
Wenn Du sie retten willst, dann geht das so, aber wenn du sie, wie ich in dem Beispiel nicht retten musst, dann wäre das retten verschwendung von rechenzeit und speicherplatz.
Quote from: Shining on 16. January 2018, 20:43:42
... Wenn man in C keine globale initialisierte variablen benutzt, braucht man in dieser startup-datei nix anderes tun als .org #4712 und dann jp _main.
Den Speicher unter &4712 kann man also nicht nutzen?
Weiss jetzt nicht, ob das ernst gemeint war oder eine echte Frage. Aber bezüglich Speicheraufteilung ist der C-Kram ja nicht anders als Assembler.
Pentomino z.B. benutzt das komplette RAM von 0x40-0xFFFF. Bei Defence ist das ähnlich, da nutze ich aber den Bereich wo AMSDOS initialisert nur für temp-kram, da ich das amsdos ja zwischendurch zum laden/speichern brauche...
Bei dem demo, an dem ich gerade arbeite , liegt der overscan bei 0x200-0x7FFF. (für ein 64kB-Programm).
Ok, man kann also den ganzen Speicher nutzen. Die Frage war schon ernst gemeint, denn bei Small C für CP/M kann man nix unter org &0100 nutzen. Leider hab ich von C wirklich zu wenig Ahnung um für den SDCC eine Library zu schreiben, um FutureOS zu unterstützen.
Wenn jemand Lust hätte da mitzuhelfen, dann würde ich den ASM Teil machen. Das FIOLIB (meine Library für Small-C für FutureOS) gibt's ja schon, aber es ist hald nur Small-C. ::)
Also ich nutze - zum Ausprobieren !- gerne cpctelera und damit SDCC.
Was aber auch geht ist SDCC mit "eigenen Librarys" - ich finde eine gute Anleitung dazu gibt es hier: http://www.cpcmania.com/Docs/Programming/Programming_in_c_and_assembly_language_Compilers_and_alternatives_for_PC.htm (http://www.cpcmania.com/Docs/Programming/Programming_in_c_and_assembly_language_Compilers_and_alternatives_for_PC.htm)
Und als Batch zum "Bauen" nutze ich etwas, was ich mir aus dem hier https://cpcrulez.fr/coding-crossdev_sdcc-00-developper_en_C_pour_CPC_par_stephbb75.htm (https://cpcrulez.fr/coding-crossdev_sdcc-00-developper_en_C_pour_CPC_par_stephbb75.htm) gebastelt habe
SDCC und CPCDiskXP in den "PATH", die angehängten Dateien in ein Verzeichnis und dann in der CMD "einfach" "COMP pixeltest" ... und wenn alles gut läuft kommt eine *.dsk heraus ;)
WoW! Du kennst Dich aus! Da muss man erst mal durchsteigen! Danke für die ganzen Links, guck ich mir gleich mal an.
Assembler fällt mir da viel leichter, denn dass SDCC und was man da so braucht ist schon ziemlich umfangreicher.
Hoffentlich krieg ich es mal hin meine Fiolib dafür einzusetzen, denn dann könnte man das SDCC auch für FutureOS verwenden. Aber da brauch ich wohl Hilfe.
Auch wenn ich - wie alle hier ? - nicht viel Zeit für dieses Hobby und schon gar nicht wirklich Ahnung habe ;) - mal was ausprobieren / schauen ob ich zum Laufen/compilen bringe - da unterstütze ich gerne im Rahmen des Möglichen.
Wenn Du also mal was in der Richtung hast, kannst Du mich hier / oder jemand der im EU-Wiki unterwegs ist dort, da bin ich häufiger - gerne mal anpingen.
Das gilt natürlich auch für alle Anderen hier ! Mehr als "da habe ich keine Ahnung von" oder "tut mir leid das schaffe ich zeitlich nicht" kann nicht passieren :)
Ich baue meine Prototypen. (Ausser die Teile, wo ich eh schon eigene Routinen für habe) immer teilweise in C. Und optimiere die dann immer mit und mit und ersetze die dann teilweise später durch asm. Als CPC-Asm-Programmierer muss man sich ein bisschen an die andere asm-syntax gewöhnen.
Z88DK kannste vergessen.
Ist für den CPC nicht viel los.
Ich spielte nur mit dem SDCC und dem JavaCPC.
Hatte mal vor 8 Jahren mehrere CPC6128 . Hatte auch mal einen umgebaut mit einem Amiga 3,5 Laufwerk.
Da mir das programmieren lieber ist für den CPC habe ich den JavaCPC zum lernen und spielen bevorzugt. Ich
wusste dann auch das es auf den CPC bei mir lief. Den Reiz brauchte ich nicht mehr und habe dann
die ganzen Kisten verkauft und trotzdem meine Freude an JavaCPC mit den Experimenten und deren besonderen Speicherweiterungen für besondere Programme. Gerade die Speichererweiterungen für meine originalen CPC6128 konnte ich nicht mehr kaufen , weil die sau teuer geworden sind und rar.
Beim SDCC muss du viele Routinen selber schreiben für den CPC. Ist aber nicht so schwer.
Zumal die Beschreibung im Profibuch für den CPC leicht zu lesen ist.
Das C/PM gefällt mir gut, weil ich als Erwachsener in den Jahren damit schon etwas zu tun hatte.
Und das C/PM auf den CPC6128 ist beonders zuverlässig und gut mit noch vielen erhältlichen freien Programmen.
Vielleicht beschäftige ich mich mit 69 Jahren mal wieder mit dem JavaCPC und grabe mal meine alten selbst erstellten Routinen aus.
Habe die Grafikroutinen (CPC6128) für den SDCC erstellt als Lib.
Gruss
Tja, wäre schön, wenn es so eine Art Handbuch zum SDCC geben würde, eines das auch zum Erlernen von C geeignet ist.
Hallo, guten Tag.
Wie werden die selbsterstellten LIB dem Programm bekannt gemacht.
Ich kann ja jetzt nicht nur ASM schreiben, die muss ja irgendwo erkannt werden ? Haederdatei oder so ?
Gruss
Wenn man größere Projekte hat nutzt man für gewöhnlich Makefiles für den Compiler.
Im Makefile werden die Librarys verlinkt und im Programmcode includet man dann die Headerdatei der Library.
Mit SDCC habe ich mich aber noch nicht beschäftigt und weiß nicht, wie ein dort übliches Makefile aussieht.
Das cpctelera kann ich auch empfehlen.
Habe es sogar mit 71 Jahren geschafft es zu installieren auf meinem Notebook und es läuft wunderbar.
Das compilieren der Programme ist sehr einfach von Cygwin64.
Hätte ich nicht gedacht. Ich lese viel oberflächlich, daher kommen meine Fehler.
Es lohnt sich dieses cpctelera mal zu installieren.
Einige Tipps kann ich schon geben.
Gruss
Glückwunsch!
Ruhe in frieden CPC codierung ? ???
Und was genau meinst Du damit?
naked geht wunderbar für sdcc.
----------------------------
void BasicMove(u16 x, u16 y) __naked __z88dk_callee {
x;y;
__asm
pop hl
pop de
ex (sp), hl
jp 0xBBC0
__endasm;
}
---------------------------
Quote
Ruhe in frieden CPC codierung ?
Na hat dein CPC Corona-aussetzer :)
Quote
...und das cpctelera ja eher generisch ist und viele dinge (noch) nicht kann.
Ist auch nicht der Sinn von Cpctelera. Du hast dich mit Cpctelera noch nicht auseinander gesetzt?
Du musst dich auch schon selber um bestimmte Dinge kümmern.
cpctelera ist auch nicht für Einsteiger geeignet und zum lernen von C gedacht.
Wenn ich bewegte Grafiken brauche (Sprite und Hintergrund) oder Musik mit Interrupt habe ich es nicht geschafft dieses alleine in Sdcc zu machen.
Ich scheiterte daran.
Dieses ccpctelera hilft mir dabei um mein Sdcc program zu erweitern.
Gruss
Quote from: Im Wald on 23. July 2020, 11:33:01Ruhe in frieden CPC codierung ? ???
Na hoffentlich nicht. Es gibt ja einiges auf und für den CPC. Eventuell könnten sich ja ein paar C Enthusiasten zusammen setzen und ein Projekt ins Leben rufen, bei dem alles auf dem CPC läuft ohne, dass man PCs benötigt. Würde mich freuen. :)
Für Assembler gibt es ja genau das bereits, und zwar den Orgams Assembler. :winke0002:
Quote from: TFM on 28. January 2024, 17:45:26Quote from: Im Wald on 23. July 2020, 11:33:01Ruhe in frieden CPC codierung ? ???
Na hoffentlich nicht. Es gibt ja einiges auf und für den CPC. Eventuell könnten sich ja ein paar C Enthusiasten zusammen setzen und ein Projekt ins Leben rufen, bei dem alles auf dem CPC läuft ohne, dass man PCs benötigt. Würde mich freuen. :)
Für Assembler gibt es ja genau das bereits, und zwar den Orgams Assembler. :winke0002:
Ich werde eine Sprache schreiben, um vernünftigen Z80 Kode ohne große Bibliotheken zu produzieren.
Es kann 20 Jahre dauern
Quote from: Im Wald on 12. March 2024, 09:33:51Quote from: TFM on 28. January 2024, 17:45:26Quote from: Im Wald on 23. July 2020, 11:33:01Ruhe in frieden CPC codierung ? ???
Na hoffentlich nicht. Es gibt ja einiges auf und für den CPC. Eventuell könnten sich ja ein paar C Enthusiasten zusammen setzen und ein Projekt ins Leben rufen, bei dem alles auf dem CPC läuft ohne, dass man PCs benötigt. Würde mich freuen. :)
Für Assembler gibt es ja genau das bereits, und zwar den Orgams Assembler. :winke0002:
Ich werde eine Sprache schreiben, um vernünftigen Z80 Kode ohne große Bibliotheken zu produzieren.
Es kann 20 Jahre dauern
Wenn Du Lust hast, dann können wir die Sprache ja auch für FutureOS machen (zusätzlich zum nativen OS). In dem Fall würde ich mich um die Implementierung der Sprache ins OS kümmern, und Du Dich um die Sprache selbst. :)
Um Sachen wie Speicherverwaltung, relative Dateien, Bildschirmausgabe, Eingabe (Joysticks, Keyboard, Mäuse) etc. müsstest Du Dich dann nicht mehr kümmern.
Quote from: TFM on 12. March 2024, 15:17:38Wenn Du Lust hast, dann können wir die Sprache ja auch für FutureOS machen (zusätzlich zum nativen OS). In dem Fall würde ich mich um die Implementierung der Sprache ins OS kümmern, und Du Dich um die Sprache selbst. :)
Um Sachen wie Speicherverwaltung, relative Dateien, Bildschirmausgabe, Eingabe (Joysticks, Keyboard, Mäuse) etc. müsstest Du Dich dann nicht mehr kümmern.
Siehe:
Monitor and Cassette Utilities von Brian Cadge (https://www.cpc-power.com/index.php?page=detail&onglet=notices&num=10722)
Ich habe das Programm geändert, um zusätzliche Parameter zuzulassen. Im Moment sind das einfache Variablentypen und 8-Bit-Dezimalbytes. Ich kann zeigen, wie das geht.
Es müsste von Firmware auf FutureOS Specifics geändert werden.
Dieser Kode kann BASIC-Programme in Assembler umwandeln und kann Assembler verfeinern, wenn bestimmte Anweisungen gefunden werden.
Er würde vom ROM mit der Sprache auf der einen Seite mit RST 2 Side Call funktionieren, um auf das zweite Library ROM zuzugreifen.
Also, ich dachte jetzt an eine Programmiersprache und nicht an ein Tool. :)
Hallo IM WALD.
Ich habe hier in Future OS etwas angefangen.
Du musst alles selber in ASM schreiben und dann TFM den Auftrag gegeben alles in das Future OS rein ballern.
So einfach wie du es dir vorstellst ist es mit Future Os nicht.
Installiere das Future Os und schreibe erstmal für das Future OS ganz winzige ASM-Programme die Laufen. Es macht keinen Sinn das einer auf den Dachboden Programme findet und dann ...machmal..
Es müssen sich hier intererssenten finden die auch Lust mit Future Os haben , sonst hat es keinen Sinn da Manpower reinzustecken.
Ich freue mich auf dein erstes ASM-Programm (Winzig) für das Future OS.
Schau mal , wieviel interessierte in der Abteilung "Future Os" hier drin waren. Ich war längere Zeit der einzige.
Töne Blasen über Future Os können einige hier, installiert hat das von denen keiner. Schade für die schöne Arbeit vom Entwickler. Die meisten wollen immer nur das kindische Basic....dazu lernen ( Future OS) tut weh....
Gruss
Hallo,
Der ASM-Code dieses Tools hat eine Befehlseingabe und springt zu seiner Routine.
Er akzeptiert nur Befehlswörter ohne zusätzliche Parameter. Das kann im Abschnitt "saso" eingestellt werden, so dass das Ende des Befehls gefunden wird, wenn ein Leerzeichen, ein Symbol oder eine Null gefunden wird.
saso
or a
jr z,gotit
inc de
inc hl
ld a,(hl)
cp 32
jr z,gotit
jr cklp
Der Code selbst ist ideal für den Aufbau der frühen BASIC-Syntax [Befehl] <Parameter>, obwohl ich ihn verwende, um MC-Äquivalente zu konstruieren, wenn BASIC-ähnlicher Code eingegeben und mit 'RUN' ausgeführt wird.
Sie aktivieren meine Sprache mit RSX und fangen einfach an, Ihr Programm zu tippen. 'new' kann verwendet werden, um den RAM zu löschen, obwohl ich noch viele Dinge zu tun habe, um eine Firmware-Version zu entwickeln.
Ich suche auch nach Dingen, die ich in meiner Sprache tun kann, die in MC optimiert werden könnten, und füge nur dann eine Routine ein, wenn sie benötigt wird, anstatt eine ganze Bibliothek von Dingen hinzuzufügen.
Ich habe Small-C + FutureOS Library verwendet, um zwei grafische Demos zu erstellen. Vielleicht könnte das der Anfang sein, eine neue Sprache zu schreiben, wobei die in FutureOS geladene Datei ein Punkt ist, an dem man programmieren kann, was benötigt wird, anstatt nur da zu sein und Speicher zu verschwenden?
Ich habe ein kurzes Video im RAM gemacht, in dem ich Befehle zum Ändern der Bildschirmfarben, des Rahmens und zum Platzieren von kleinen Kästchen auf dem Bildschirm eingebe, die ASM-Code aus Brian Cadges Monitor Utilities verwenden.
Gruss
Ah, ja, so ein Video macht die Sache schon viel klarer :) :) :)
Bin gespannt wie es damit weitergeht. Zum FutureOS stehe ich natürlich immer gerne zur Verfügung. Aber bitte bedenken: Es ist ein OS keine Programmiersprache. Mit dem Small-C für FutureOS ist es leider länger her. Aber die FIOLIB kann für jeden C-Dialekt angepasst werden. Bitte bei mir melden wenn ernsthaftes Interesse besteht. :smiley027: