C am CPC

[TFM]

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?

[Shining]

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

[TFM]

Ah, vielen Dank für die ausführliche Antwort.  Wie kommuniziert das SDCC denn mit dem CPC? Ist das alles in einer Library? Gibt's da den Source Code? Kann man die ändern? 

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

[HAL6128]

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?

[Shining]

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:

Code Select Expand

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

Code Select Expand

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;
} 

[HAL6128]

...reicht es in Deiner "naked" variante nicht einfach aus mit push & pop die Register vorher zu stapeln und wieder zurückzuholen?

[Shining]

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.

[TFM]

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

[Shining]

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

[TFM]

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. 

[SRS]

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

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

[TFM]

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.

[SRS]

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

[Shining]

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.

[cpcman]

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