How do I get CC65 to include NO startup code?

[Mike]

A digital clock program. Read the jiffy clock and display it [...]

In that case, the thread 'Display of TI$ in border (unex. or +3K)' might be worth a look.

[groepaz]

technically, you dont need to recompile anything, just use -t none for no startup code and instead of main() use start():

Code: Select all

$ cat test.c
void start(void)
{
    asm("inc $d020");
}
$ cl65 -o test.bin -t none test.c
$ hex test.bin
0000  ee 20 d0 60

(mind you, a lot of the C language relies on the startup code, so you better know what you are doing... at least properly set up the pointers to the software stack and heap. perhaps you also want a basic stub so you dont need to run the binary by SYS. and add a proper CBM load address to the output. etc etc )

[JavaJack59]

just use -t none for no startup code and instead of main() use start():

That looked promising, but I just ended up with a bunch of "Unresolved external" errors.
I also briefly tried Quetzalcoatl for comparison, and it wouldn't build either ("Could not find runtime library uplrtime.obj")
Guess it's back to BASIC or klutzing my way through assembly.

[Misfit]

Hi,

I use CC65 for VIC games and here is my simple cc65 project skeleton (unexpanded vic):

crt0.s:

Code: Select all

.import   _main
.import   __RAM_START__, __RAM_SIZE__	; Linker generated
.export   __STARTUP__ : absolute = 1    ; Mark as startup
.include  "zeropage.inc"

.segment "STARTUP"
.word $1001; Load address
.byte $0B, $10, $00, $00, $9E, '4','1','0','9',$00, $00, $00

lda #<(__RAM_START__ + __RAM_SIZE__)
sta sp
lda #>(__RAM_START__ + __RAM_SIZE__)
sta sp+1
jsr _main

..and main.c:

Code: Select all

typedef unsigned char byte;

#define SCREEN_ADDR   (0x1E00)
#define COL_ADDR      (0x9600)

byte* ptr_screen;
byte* ptr_color;

void main()
{
    ptr_screen = SCREEN_ADDR;
    ptr_color = COL_ADDR;
    
    ptr_screen[1] = 0x01;
    ptr_color[1] = 0x02;
    
    ptr_screen[2] = 0x02;
    ptr_color[2] = 0x03;

    loop:
    goto loop;
}

[Mike]

Misfit, your example is missing the necessary *.cfg file for the unexpanded VIC-20. It would also have been nice to provide a make file.

Nonetheless, I ran main.c through cc65 with '-t none', with this result (sorry for this slightly longer listing ...):

Code: Select all

;
; File generated by cc65 v 2.13.2
;
	.fopt		compiler,"cc65 v 2.13.2"
	.setcpu		"6502"
	.smart		on
	.autoimport	on
	.case		on
	.debuginfo	off
	.importzp	sp, sreg, regsave, regbank, tmp1, ptr1, ptr2
	.macpack	longbranch
	.forceimport	__STARTUP__
	.export		_ptr_screen
	.export		_ptr_color
	.export		_main

.segment	"BSS"

_ptr_screen:
	.res	2,$00
_ptr_color:
	.res	2,$00

; ---------------------------------------------------------------
; void __near__ main (void)
; ---------------------------------------------------------------

.segment	"CODE"

.proc	_main: near

.segment	"CODE"

	ldx     #$1E
	lda     #$00
	sta     _ptr_screen
	stx     _ptr_screen+1
	ldx     #$96
	lda     #$00
	sta     _ptr_color
	stx     _ptr_color+1
	lda     _ptr_screen
	ldx     _ptr_screen+1
	jsr     pushax
	ldx     #$00
	lda     #$01
	ldy     #$01
	jsr     staspidx
	lda     _ptr_color
	ldx     _ptr_color+1
	jsr     pushax
	ldx     #$00
	lda     #$02
	ldy     #$01
	jsr     staspidx
	lda     _ptr_screen
	ldx     _ptr_screen+1
	jsr     pushax
	ldx     #$00
	lda     #$02
	ldy     #$02
	jsr     staspidx
	lda     _ptr_color
	ldx     _ptr_color+1
	jsr     pushax
	ldx     #$00
	lda     #$03
	ldy     #$02
	jsr     staspidx
L0015:	jmp     L0015
	rts

.endproc

Dumbing down cc65 for this kind of use is really like using a hammer to turn a screw.

The equivalent assembly code (excluding the BASIC stub) would only use 4 LDAs and 4 STAs.

Well, you got 'Bertie the Ball' built and working with that method, but that verbose code above makes me wonder if it had been possible to pack the game into just +8K RAM instead (or providing more screens) - with pure assembly.

The lesson for me: it is actually possible to use cc65 in the way asked for in the OP. Not that I would want to use it like that, though.

<fx=goes off the stage></fx>

[JavaJack59]

missing the necessary *.cfg file

Yeah. I ended up with this:

Code: Select all

E:\coding\cc65\min>ld65 main.o vic20_minimal.o
ld65: Error: Memory configuration missing

[Misfit]

project files

of course pure assembly code makes a smaller program, but I'm too lazy to create whole game without C-language.
Sometimes it's better to use more memory if it is the only way to create a finished product.

[JavaJack59]

project files

PERFECT.
For the uninitiated (read: me) what's the purpose of the "fill=yes" for "RAM" in the .cfg? I tried "fill=no" just to see what would happen and it seemed to work anyway.

Sometimes it's better to use more memory if it is the only way to create a finished product.

Agreed.

[JavaJack59]

Off to a decent start. Even pulling in memset and memcpy, I'm still under .5KB.

[groepaz]

Dumbing down cc65 for this kind of use is really like using a hammer to turn a screw.

not really. he made a small crt0 which basically removes the heap, and doesnt use the interrupt chain stuff. both of which you dont want to use in a memory constrained environment anyway - i have done the same for all c64 programs i made with cc65.

The equivalent assembly code (excluding the BASIC stub) would only use 4 LDAs and 4 STAs.

try with -Osir the generated code is large in some cases, but its not *that* bad really

[Mike]

try with -Osir the generated code is large in some cases, but its not *that* bad really

Now that's really funny. With a slightly trimmed version of 'main.c' ...

Code: Select all

typedef unsigned char byte;

#define SCREEN_ADDR   (0x1E00)
#define COL_ADDR      (0x9600)

void main()
{
    *((byte *)(SCREEN_ADDR+1)) = 0x01;
    *((byte *)(COL_ADDR+1)) = 0x02;
    
    *((byte *)(SCREEN_ADDR+2)) = 0x02;
    *((byte *)(COL_ADDR+2)) = 0x03;

    loop: goto loop;
}

... and using 'cc65 -t none -Osir' it's actually possible to coerce cc65 into producing the desired output:

Code: Select all

;
; File generated by cc65 v 2.13.2
;
	.fopt		compiler,"cc65 v 2.13.2"
	.setcpu		"6502"
	.smart		on
	.autoimport	on
	.case		on
	.debuginfo	off
	.importzp	sp, sreg, regsave, regbank, tmp1, ptr1, ptr2
	.macpack	longbranch
	.forceimport	__STARTUP__
	.export		_main

; ---------------------------------------------------------------
; void __near__ main (void)
; ---------------------------------------------------------------

.segment	"CODE"

.proc	_main: near

.segment	"CODE"

	lda     #$01
	sta     $1E01
	lda     #$02
	sta     $9601
	sta     $1E02
	lda     #$03
	sta     $9602
L0017:	jmp     L0017

.endproc

Not bad.

Maybe I'm just used to a C programming style that doesn't want to miss out on the standard library functions. On non-65xx platforms, that is. Of course C always offers you to create an own library, when the supplied implementation doesn't suit you.

[groepaz]

oh, actually even with cc65 it is a very good idea to use the standard library as often as possible (usually the generated code will be smaller and faster than doing the same stuff inline) - however, its also a good idea to think twice about what you are using. as said malloc is often not a good idea and static buffers work better (as in: smaller footprint). also avoiding things like printf (because printf is actually file i/o, it pulls in tons of stuff - better use conio). those things are common things to do on other embedded platforms as well

[JavaJack59]

I could do with some tips on converting the jiffy clock to integers 0-9. I'm assuming there's something in ROM that can do this for me ("print ti$") but I don't know how to make use of it.

[Mike]

I could do with some tips on converting the jiffy clock to integers 0-9. I'm assuming there's something in ROM that can do this for me ("print ti$") but I don't know how to make use of it.

I suppose you overlooked that reply:

A digital clock program. Read the jiffy clock and display it [...]

In that case, the thread 'Display of TI$ in border (unex. or +3K)' might be worth a look.

And yes, there's a routine in ROM to do the same. However, that routine relies on float and string operations and requires one to set up a lot of zeropage locations, and memory areas in a certain way to operate correctly.

Anyway, it should not be too difficult to infer from the disassembly how my own implementation of the conversion works. The jiffy clock is a 24-bit number, and it is incremented by one every 1/60 second (and reset to 0 as it reaches 24:00:00). There's a table with tens of hours, then hours, tens of minutes, minutes, tens of seconds and seconds in jiffies, which are (in that order) subtracted off a copy of the jiffy clock until the respective digit underflows to obtain a string equivalent to TI$ - which however is directly written to a part of the extended screen unreachable by the editor.

OTOH, there's always 'time.h' in the standard library, where time(), localtime() and asctime() also should be able to do the job.

[JavaJack59]

subtracted off a copy of the jiffy clock until the respective digit underflows

Yeah, I did read it, but it wasn't immediately obvious to me how to translate it into vanilla C, since it relied on lower level things like the CPU overflow flag.