6502 C-Compiler cc65

[Christoph M. (mchris)]

Im Moment versuche ich gerade, Assemblercode für den Junior-Computer mit 
dem C-Compiler zu erzeugen.

[
/*
 * Blinking an LED connected to PORTB0 of a Junior Computer
 *
 * compile blink.c

 *
 * 2025-05-28 mchris
 *
 */

// MOS6532 PIA addrese $1A80
#define PBD             (*(volatile unsigned char*)0x1A82)
#define PBDD            (*(volatile unsigned char*)0x1A83)
#define TIMER_READ      (*(volatile unsigned char*)0x1A84)
#define TIMER_DIV1024   (*(volatile unsigned char*)0x1A97)

void blink(void)
{
    // init PORTB0 as output
    PBDD=1;
    while(1)
    {
        TIMER_DIV1024=248;      // init timer for clkdiv=1024 and start=248
        while(TIMER_READ!=0);   // wait until timer is zero
        PBD^=1;                 ^// toggle PORTB0
    }
}

Mit der Befehlszeile
cc65 -O -t none blink.c
läst sich das folgende Assembler-File erzeugen:

;
; File generated by cc65 v 2.18 
;
  .fopt    compiler,"cc65 v 2.18 "
  .setcpu    "6502"
  .smart    on
  .autoimport  on
  .case    on
  .debuginfo  off
  .importzp  sp, sreg, regsave, regbank
  .importzp  tmp1, tmp2, tmp3, tmp4, ptr1, ptr2, ptr3, ptr4
  .macpack  longbranch
  .export    _blink

; ---------------------------------------------------------------
; void __near__ blink (void)
; ---------------------------------------------------------------

.segment  "CODE"

.proc  _blink: near

.segment  "CODE"

  lda     #$01
  sta     $1A83
L0014:  lda     #$F8
  sta     $1A97
L0015:  lda     $1A84
  bne     L0015
  lda     $1A82
  eor     #$01
  sta     $1A82
  jmp     L0014

.endproc

Was gar nicht so schlecht aussieht, wenn man es mit dem originale 
Assemblerfile, anhand dessen der C-Code erstellt wurde, vergleicht 
(siehe Anhang)

Das Problem: wie kann man aus diesem Assemblerfile den Binärcode 
erstellen, so dass er an der Adresse 0x300 beginnt?

Links:
cc65 : https://cc65.github.io/

Junior Computer: 
http://retro.hansotten.nl/6502-sbc/elektuur-junior/junior/base-elektor-junior/

[Andras H. (andras_h)]

Fehlt da nicht noch ein main und der C-Startup davor? Oder wie soll die 
C Umgebung aufgesetzt werden?

[Christoph M. (mchris)]

Andras H. (andras_h)
28.05.2025 16:45
>Fehlt da nicht noch ein main und der C-Startup davor? Oder wie soll die
>C Umgebung aufgesetzt werden?

Denke ich auch. Aber es werden ja die gleichen Befehle wie im oben 
angehängten 'Original' Assemblerprogramm (blink.asm) erzeugt und das 
braucht ja auch keinen Startup-Code.

[Andras H. (andras_h)]

Na ja, ich würde trozdem über den main laufen wollen. Vor allem, wenn 
der Compiler richtig den CPU supported, dann ist da schon alles fertig, 
und man hat später alle vorteile (?). Es wird auch einfacher zu testen.

Sonst Compiler Manual aufmachen und gucken, ob man irgendwie 
handgeschriebene asm befehle reintun kann. Meisst geht das mit asm("") 
oder _asm. Damit kann man beliebig hacken.

Aber ich würde erstmals den Hello Word empfehlen. Damit man guckt ob die 
Umgebung richtig funktioniert. Wenn das geht, dann würde ich versuchen 
irgendwie davon abweichen. Zum beispiel etwas ohne den startup code zu 
bauen.

[Bernhard K. (bkom)]

Beim cc65: nach dem Compile muss erst der Assembler
Und dann der Linker mit einem config-File aufgerufen werden:
In etwa so:

cc65 -O -t none blink.c
ca65 -l -cpu 65sc02 blink.s
ld65  -C deinesystemconfig.cfg blink.o -o blink.out

Das Config-File "deinesystemconfig.cfg" muss auf dein System passen,
Beispiele in "deinPfadzumcc65/lib/cc65/cfg" ...

Config-File Doku:
https://cc65.github.io/doc/ld65.html#s5

[Christoph M. (mchris)]

Bernhard K. (bkom)
28.05.2025 17:48
> cc65 -O -t none blink.c
> ca65 -l -cpu 65sc02 blink.s
> ld65  -C deinesystemconfig.cfg blink.o -o blink.out

Danke für den Hinweis.
Wie so oft, liegen die Probleme in den "filigranen" Details und mag an 
meiner cc65-Version
**ca65 V2.18 - Ubuntu 2.19-1
liegen, die standardmäßig im Ubuntu-Repo zu finden ist. Wenn ich in das 
Github-Repo des cc65 schaue, ist da ja eine ständige Weiterentwicklung 
zu sehen:
https://github.com/cc65/cc65

Mein Befehlssequenz sieht jetzt folgendermaßen aus (cfg und startup file 
im Anhang):

# C-Source nach Assembler konvertieren
cc65 -O -t none blink.c

# Assembler file compilieren
ca65 -l blink.lst blink.s
#( Listfile -l braucht filnamen )

#Startup script wird gebraucht und muss compiliert werden
cl65 -t none -c crt0.s -o crt0.o

# alles zusammenbauen: Link startup blink und startup-Code
ld65 -C junior.cfg crt0.o blink.o -o blink.bin

Aber es darf ja nichts zu einfach sein: Im Startup-Code muss ich das 
'jsr main' auskommentieren. Aus irgendwelchen Gründen wird das 'main' 
nicht gefunden ..

[Klaus (feelfree)]

Christoph M. schrieb:
> Aus irgendwelchen Gründen wird das 'main' nicht gefunden ..

Wenn sich die Aussage auf dein im Eröffnungsbeitrag vorgestelltes 
blink.c bezieht, dann ist der Grund ganz offensichtlich.

[Christoph M. (mchris)]

Klaus (feelfree)
29.05.2025 08:31

>Wenn sich die Aussage auf dein im Eröffnungsbeitrag vorgestelltes
>blink.c bezieht, dann ist der Grund ganz offensichtlich.

Nicht ganz. Ersetzte den Funktionsnamen 'blink' durch 'main' und es wird 
trotzdem nicht gehen.

[Harald K. (kirnbichler)]

Christoph M. schrieb:
> Wie so oft, liegen die Probleme in den "filigranen" Details und mag an
> meiner cc65-Version
> **ca65 V2.18 - Ubuntu 2.19-1
> liegen, die standardmäßig im Ubuntu-Repo zu finden ist.

... ein anderer auch aktiv gepflegter Compiler ist SDCC:
https://sdcc.sourceforge.net/

[Christoph M. (mchris)]

Harald K. (kirnbichler)
29.05.2025 11:13
> ... ein anderer auch aktiv gepflegter Compiler ist SDCC:
> https://sdcc.sourceforge.net/

Beim cc65
https://github.com/cc65/cc65
schreiben sie:
cc65 is originally based on the "Small C" compiler by Ron Cain and 
enhanced by James E. Hendrix.

[Klaus (feelfree)]

Christoph M. schrieb:
> Ersetzte den Funktionsnamen 'blink' durch 'main' und es wird
> trotzdem nicht gehen.

Aus dem main() im .c-source wird beim compilieren im .s ein _main 
exportiert, warum auch immer - ich kenne mich damit nicht aus.
Das auskommentieren von jsr main würde dazu führten, dass blink nie 
ausgeführt wird. Stattdessen könnte man im crt.s main zu _main ändern.

[Christoph M. (mchris)]

Klaus (feelfree)
29.05.2025 12:54

> Aus dem main() im .c-source wird beim compilieren im .s ein _main
> exportiert, warum auch immer

Das sind die 'filigranen' Details, von denen ich oben geschrieben hatte. 
Ein kleiner Unterstrich "_" macht den Unterschied, ob es geht oder nicht 
geht.
Mit dem Unterstrich kann man das erste Beispiel kompilieren .. ein 
erster Erfolg.

Aber die Welt darf ja nicht zu einfach sein. Will ich das 
Tonleiterprogramm kompilieren, welches Funktionsaufrufe aus der 'main' 
enthält

#include <stdint.h>

#define PBD             (*(volatile unsigned char*)0x1A82)
#define PBDD            (*(volatile unsigned char*)0x1A83)

void shortdelay(uint8_t x)
{
    do
    {
        x--;
    }while(x!=0);
}

void playnote(uint8_t n)
{
    uint8_t duration=50;

    do
    {
        shortdelay(n);
        shortdelay(0);

        PBD^=1;                 // toggle PORTB0

        duration--;
    }while(duration!=0);
}

void main(void)
{
    // init PORTB0 as output
    PBDD=1;
    while(1)
    {
        playnote(200);
        playnote(158);
    }
}

Werden die Stack Funktionen des C-Systems vermisst.

Linking temp.o and crt0.o, creating temp.bin
Unresolved external 'incsp1' referenced in:
  temp.s(36)
Unresolved external 'incsp2' referenced in:
  temp.s(68)
Unresolved external 'pusha' referenced in:
  temp.s(28)
  temp.s(50)
  temp.s(52)
Unresolved external 'sp' referenced in:
  temp.s(54)
  temp.s(62)
  temp.s(65)
  temp.s(66)
  temp.s(30)
  temp.s(33)
  temp.s(34)

Es fehlt als das nächste Puzzelstück im großen Kompiler-Abenteuerspiel.

[Klaus (feelfree)]

Christoph M. schrieb:
> Aber die Welt darf ja nicht zu einfach sein.

Nun ja, wer für einen 45 Jahre alten Einplatinenrechner ohne vernünftige 
Ein/Ausgabemöglichkeiten plötzlich eine Toolchain incl. C-Compiler haben 
will, kann halt nicht davon ausgehen, dass vor ihm schonmal jemand so 
verrrückt war, das auszuprobieren ...

[Thomas W. (datenreisender)]

Klaus schrieb:
> Christoph M. schrieb:
>> Aber die Welt darf ja nicht zu einfach sein.
>
> Nun ja, wer für einen 45 Jahre alten Einplatinenrechner ohne vernünftige
> Ein/Ausgabemöglichkeiten plötzlich eine Toolchain incl. C-Compiler haben
> will, kann halt nicht davon ausgehen, dass vor ihm schonmal jemand so
> verrrückt war, das auszuprobieren ...

Und dann nicht auf richtiger Hardware sondern mit einem Emulator 
entwickelt: That's the new Frontier!

P.S.: Genial finde ich es trotzdem.

[Bernhard K. (bkom)]

>
> # alles zusammenbauen: Link startup blink und startup-Code
> ld65 -C junior.cfg crt0.o blink.o -o blink.bin
>
> [/c]
>
Ich erinnere mich kaum noch - ist schon mehr als 15 Jahre her -
aber ich meine es fehlt noch "-t junior", die runtime-lib
für den Juniorcomputer gibts wahrscheinlich nicht, "-t kim" könnte
aber auch funktionieren ...

[Klaus (feelfree)]

Bernhard K. schrieb:
>>
>> # alles zusammenbauen: Link startup blink und startup-Code
>> ld65 -C junior.cfg crt0.o blink.o -o blink.bin
>>
>> [/c]
>>
> Ich erinnere mich kaum noch - ist schon mehr als 15 Jahre her -
> aber ich meine es fehlt noch "-t junior", die runtime-lib
> für den Juniorcomputer gibts wahrscheinlich nicht, "-t kim" könnte
> aber auch funktionieren ...

ld65 -t none crt0.o playnote.o none.lib -o playnote.bin

macht den Trick.

[Christoph M. (mchris)]

> Klaus (feelfree)
> 29.05.2025 16:30

ld65 -t none crt0.o playnote.o none.lib -o playnote.bin

>macht den Trick.

Jetzt scheint der Compiler das Linker-File zu ignorieren und statt das 
main an der gewünschten Adresse 0x300 anzuspringen, statt dessen nach 
0x1000 springt.

Mein Konfigurationsfile sieht so aus ( beim STACKSTART bin ich mir noch 
unsicher )

SYMBOLS {
    __STARTUP__:   type = import;
    __STACKSIZE__: type = weak, value = $0080;
    __STACKSTART__: type = weak, value = $0180;
}
MEMORY {
    ZP:       file = "", define = yes, start = $0000, size = $0100;
    CPUSTACK: file = "",               start = $0100, size = $0100;
    RAM:      file = %O, define = yes, start = $0300, size = $0800 - __STACKSIZE__;
}
SEGMENTS {
    ZEROPAGE: load = ZP,     type = zp;
    STARTUP:  load = RAM,    type = ro;
    LOWCODE:  load = RAM,    type = ro,  optional = yes;
    ONCE:     load = RAM,    type = ro,  optional = yes;
    CODE:     load = RAM,    type = ro;
    RODATA:   load = RAM,    type = ro;
    DATA:     load = RAM,    type = rw,  define   = yes;
    BSS:      load = RAM,    type = bss, define   = yes;
}
FEATURES {
    CONDES: type    = constructor,
            label   = __CONSTRUCTOR_TABLE__,
            count   = __CONSTRUCTOR_COUNT__,
            segment = ONCE;
    CONDES: type    = destructor,
            label   = __DESTRUCTOR_TABLE__,
            count   = __DESTRUCTOR_COUNT__,
            segment = RODATA;
    CONDES: type    = interruptor,
            label   = __INTERRUPTOR_TABLE__,
            count   = __INTERRUPTOR_COUNT__,
            segment = RODATA,
            import  = __CALLIRQ__;
}

[Klaus (feelfree)]

Christoph M. schrieb:
> Jetzt scheint der Compiler das Linker-File zu ignorieren

Hab's ja auch nicht angegeben.
Probier's mal mit deinem -C junior.cfg statt -t none.