The cc65 toolset provides a set of pre-defined libraries that allow the user to target the executable image to a variety of hardware platforms. In addition, the user can create a customized environment so that the executable can be targeted to a custom platform. The following instructions provide step-by-step instructions on how to customize the toolset for a target that is not supported by the standard cc65 installation.
The platform used in this example is a Xilinx Field Programmable Gate Array (FPGA) with an embedded 65C02 core. The processor core supports the additional opcodes/addressing modes of the 65SC02, along with the STP and WAI instructions. These instructions will create a set of files to create a custom target, named SBC, for Single Board Computer.
The targeted system uses block RAM contained on the XILINX FPGA for the system memory (both RAM and ROM). The block RAMs are available in various aspect ratios, and they will be used in this system as 2K*8 devices. There will be two RAMs used for data storage, starting at location $0000 and growing upwards. There will be one ROM (realized as initialized RAM) used code storage, starting at location $FFFF and growing downwards.
The cc65 toolset requires a memory configuration file to define the memory that is available to the cc65 run-time environment, which is defined as follows:
MEMORY {
ZP: start = $0, size = $100, type = rw, define = yes;
RAM: start = $200, size = $0E00, define = yes;
ROM: start = $F800, size = $0800, file = %O;
}
ZP defines the available zero page locations, which in this case starts at $0 and has a length of $100. Keep in mind that certain systems may require access to some zero page locations, so the starting address may need to be adjusted accordingly to prevent cc65 from attempting to reuse those locations. Also, at a minimum, the cc65 run-time environment uses 26 zero page locations, so the smallest zero page size that can be specified is $1A. The usable RAM memory area begins after the 6502 stack storage in page 1, so it is defined as starting at location $200 and filling the remaining 4K of space (4096 - 2 * 256 = 3584 = $0E00). The 2K of ROM space begins at address $F800 and goes to $FFFF (size = $0800).
Next, the memory segments within the memory devices need to be defined. A standard segment definition is used, with one notable exception. The interrupt and reset vector locations need to be defined at locations $FFFA through $FFFF. A special segment named VECTORS is defined that resides at these locations. Later, the interrupt vector map will be created and placed in the VECTORS segment, and the linker will put these vectors at the proper memory locations. The segment definition is:
SEGMENTS {
ZEROPAGE: load = ZP, type = zp, define = yes;
DATA: load = ROM, type = rw, define = yes, run = RAM;
BSS: load = RAM, type = bss, define = yes;
HEAP: load = RAM, type = bss, optional = yes;
STARTUP: load = ROM, type = ro;
ONCE: load = ROM, type = ro, optional = yes;
CODE: load = ROM, type = ro;
RODATA: load = ROM, type = ro;
VECTORS: load = ROM, type = ro, start = $FFFA;
}
The meaning of each of these segments is as follows.
ZEROPAGE: Data in page 0, defined by ZP as starting at $0 with length $100
DATA: Initialized data that can be modified by the program, stored in RAM
BSS: Uninitialized data stored in RAM (used for variable storage)
HEAP: Uninitialized C-level heap storage in RAM, optional
STARTUP: The program initialization code, stored in ROM
ONCE: The code run once to initialize the system, stored in ROM
CODE: The program code, stored in ROM
RODATA: Initialized data that cannot be modified by the program, stored in ROM
VECTORS: The interrupt vector table, stored in ROM at location $FFFA
A note about initialized data: any variables that require an initial
value, such as external (global) variables, require that the initial
values be stored in the ROM code image. However, variables stored in
ROM cannot change; therefore the data must be moved into variables that
are located in RAM. Specifying run = RAM as part of
the DATA segment definition will indicate that those variables will
require their initialization value to be copied via a call to the
copydata routine in the startup assembly code. In addition,
there are system level variables that will need to be initialized as
well, especially if the heap segment is used via a C-level call to
malloc ().
The final section of the definition file contains the data constructors
and destructors used for system startup. In addition, if the heap is
used, the maximum C-level stack size needs to be defined in order for
the system to be able to reliably allocate blocks of memory. The stack
size selection must be greater than the maximum amount of storage
required to run the program, keeping in mind that the C-level subroutine
call stack and all local variables are stored in this stack. The
FEATURES section defines the required constructor/destructor
attributes and the SYMBOLS section defines the stack size. The
constructors will be run via a call to initlib in the startup
assembly code and the destructors will be run via an assembly language
call to donelib during program termination.
FEATURES {
CONDES: segment = STARTUP,
type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__;
CONDES: segment = STARTUP,
type = destructor,
label = __DESTRUCTOR_TABLE__,
count = __DESTRUCTOR_COUNT__;
}
SYMBOLS {
# Define the stack size for the application
__STACKSIZE__: value = $0200, weak = yes;
}
These definitions are placed in a file named "sbc.cfg" and are referred to during the ld65 linker stage.
In the cc65 toolset, a startup routine must be defined that is executed
when the CPU is reset. This startup code is marked with the STARTUP
segment name, which was defined in the system configuration file as
being in read only memory. The standard convention used in the
predefined libraries is that this code is resident in the crt0 module.
For this custom system, all that needs to be done is to perform a little
bit of 6502 housekeeping, set up the C-level stack pointer, initialize
the memory storage, and call the C-level routine main ().
The following code was used for the crt0 module, defined in the file
"crt0.s":
; ---------------------------------------------------------------------------
; crt0.s
; ---------------------------------------------------------------------------
;
; Startup code for cc65 (Single Board Computer version)
.export _init, _exit
.import _main
.export __STARTUP__ : absolute = 1 ; Mark as startup
.import __RAM_START__, __RAM_SIZE__ ; Linker generated
.import copydata, zerobss, initlib, donelib
.include "zeropage.inc"
; ---------------------------------------------------------------------------
; Place the startup code in a special segment
.segment "STARTUP"
; ---------------------------------------------------------------------------
; A little light 6502 housekeeping
_init: LDX #$FF ; Initialize stack pointer to $01FF
TXS
CLD ; Clear decimal mode
; ---------------------------------------------------------------------------
; Set cc65 argument stack pointer
LDA #<(__RAM_START__ + __RAM_SIZE__)
STA sp
LDA #>(__RAM_START__ + __RAM_SIZE__)
STA sp+1
; ---------------------------------------------------------------------------
; Initialize memory storage
JSR zerobss ; Clear BSS segment
JSR copydata ; Initialize DATA segment
JSR initlib ; Run constructors
; ---------------------------------------------------------------------------
; Call main()
JSR _main
; ---------------------------------------------------------------------------
; Back from main (this is also the _exit entry): force a software break
_exit: JSR donelib ; Run destructors
BRK
The following discussion explains the purpose of several important assembler level directives in this file.
.export _init, _exit
This line instructs the assembler that the symbols _init and
_exit are to be accessible from other modules. In this
example, _init is the location that the CPU should jump to when
reset, and _exit is the location that will be called when the
program is finished.
.import _main
This line instructs the assembler to import the symbol _main
from another module. cc65 names all C-level routines as
{underscore}{name} in assembler, thus the main () routine
in C is named _main in the assembler. This is how the startup
code will link to the C-level code.
.export __STARTUP__ : absolute = 1 ; Mark as startup
This line marks this code as startup code (code that is executed when the processor is reset), which will then be automatically linked into the executable code.
.import __RAM_START__, __RAM_SIZE__ ; Linker generated
This line imports the RAM starting address and RAM size constants, which are used to initialize the cc65 C-level argument stack pointer.
.segment "STARTUP"
This line instructs the assembler that the code is to be placed in the STARTUP segment of memory.
JSR zerobss ; Clear BSS segment
JSR copydata ; Initialize DATA segment
JSR initlib ; Run constructors
These three lines initialize the external (global) and system variables. The first line sets the BSS segment -- the memory locations used for external variables -- to 0. The second line copies the initialization value stored in ROM to the RAM locations used for initialized external variables. The last line runs the constructors that are used to initialize the system run-time variables.
JSR _main
This is the actual call to the C-level main () routine,
which is called after the startup code completes.
_exit: JSR donelib ; Run destructors
BRK
This is the code that will be executed when main ()
terminates. The first thing that must be done is run the destructors
via a call to donelib. Then the program can terminate. In
this example, the program is expected to run forever. Therefore, there
needs to be a way of indicating when something has gone wrong and the
system needs to be shut down, requiring a restart only by a hard reset.
The BRK instruction will be used to indicate a software fault. This is
advantageous because cc65 uses the BRK instruction as the fill byte in
the final binary code. In addition, the hardware has been designed to
force the data lines to $00 for all illegal memory accesses, thereby
also forcing a BRK instruction into the CPU.
The next step in customizing the cc65 toolset is creating a run-time library for the targeted hardware. The easiest way to do this is to modify a standard library from the cc65 distribution. In this example, there is no console I/O, mouse, joystick, etc. in the system, so it is most appropriate to use the simplest library as the base, which is for the Watara Supervision and is named "supervision.lib" in the lib directory of the distribution.
The only modification required is to replace the crt0 module in
the supervision.lib library with custom startup code. This is simply
done by first copying the library and giving it a new name, compiling
the startup code with ca65, and finally using the ar65 archiver to
replace the module in the new library. The steps are shown below:
$ copy "C:\Program Files\cc65\lib\supervision.lib" sbc.lib
$ ca65 crt0.s
$ ar65 a sbc.lib crt0.o
For this system, the CPU is put into a wait condition prior to allowing interrupt processing. Therefore, the interrupt service routine is very simple: return from all valid interrupts. However, as mentioned before, the BRK instruction is used to indicate a software fault, which will call the same interrupt service routine as the maskable interrupt signal IRQ. The interrupt service routine must be able to tell the difference between the two, and act appropriately.
The interrupt service routine shown below includes code to detect when a BRK instruction has occurred and stops the CPU from further processing. The interrupt service routine is in a file named "interrupt.s".
; ---------------------------------------------------------------------------
; interrupt.s
; ---------------------------------------------------------------------------
;
; Interrupt handler.
;
; Checks for a BRK instruction and returns from all valid interrupts.
.import _stop
.export _irq_int, _nmi_int
.segment "CODE"
.PC02 ; Force 65C02 assembly mode
; ---------------------------------------------------------------------------
; Non-maskable interrupt (NMI) service routine
_nmi_int: RTI ; Return from all NMI interrupts
; ---------------------------------------------------------------------------
; Maskable interrupt (IRQ) service routine
_irq_int: PHX ; Save X register contents to stack
TSX ; Transfer stack pointer to X
PHA ; Save accumulator contents to stack
INX ; Increment X so it points to the status
INX ; register value saved on the stack
LDA $100,X ; Load status register contents
AND #$10 ; Isolate B status bit
BNE break ; If B = 1, BRK detected
; ---------------------------------------------------------------------------
; IRQ detected, return
irq: PLA ; Restore accumulator contents
PLX ; Restore X register contents
RTI ; Return from all IRQ interrupts
; ---------------------------------------------------------------------------
; BRK detected, stop
break: JMP _stop ; If BRK is detected, something very bad
; has happened, so stop running
The following discussion explains the purpose of several important assembler level directives in this file.
.import _stop
This line instructs the assembler to import the symbol _stop
from another module. This routine will be called if a BRK instruction
is encountered, signaling a software fault.
.export _irq_int, _nmi_int
This line instructs the assembler that the symbols _irq_int and
_nmi_int are to be accessible from other modules. In this
example, the address of these symbols will be placed in the interrupt
vector table.
.segment "CODE"
This line instructs the assembler that the code is to be placed in the
CODE segment of memory. Note that because there are 65C02 mnemonics in
the assembly code, the assembler is forced to use the 65C02 instruction
set with the .PC02 directive.
The final step is to define the interrupt vector memory locations. Recall that a segment named VECTORS was defined in the memory configuration file, which started at location $FFFA. The addresses of the interrupt service routines from "interrupt.s" along with the address for the initialization code in crt0 are defined in a file named "vectors.s". Note that these vectors will be placed in memory in their proper little-endian format as:
$FFFA - $FFFB: NMI interrupt vector (low byte, high byte)
$FFFC - $FFFD: Reset vector (low byte, high byte)
$FFFE - $FFFF: IRQ/BRK interrupt vector (low byte, high byte)
using the .addr assembler directive. The contents of the file are:
; ---------------------------------------------------------------------------
; vectors.s
; ---------------------------------------------------------------------------
;
; Defines the interrupt vector table.
.import _init
.import _nmi_int, _irq_int
.segment "VECTORS"
.addr _nmi_int ; NMI vector
.addr _init ; Reset vector
.addr _irq_int ; IRQ/BRK vector
The cc65 toolset will replace the address symbols defined here with the actual addresses of the routines during the link process.
The cc65 instruction set only supports the WAI (Wait for Interrupt) and STP (Stop) instructions when used with the 65816 CPU (accessed via the --cpu command line option of the ca65 macro assembler). The 65C02 core used in this example supports these two instructions, and in fact the system benefits from the use of both the WAI and STP instructions.
In order to use the WAI instruction in this case, a C routine named "wait" was created that consists of the WAI opcode followed by a subroutine return. It was convenient in this example to put the IRQ interrupt enable in this subroutine as well, since interrupts should only be enabled when the code is in this wait condition.
For both the WAI and STP instructions, the assembler is "fooled" into placing those opcodes into memory by inserting a single byte of data that just happens to be the opcode for those instructions. The assembly code routines are placed in a file, named "wait.s", which is shown below:
; ---------------------------------------------------------------------------
; wait.s
; ---------------------------------------------------------------------------
;
; Wait for interrupt and return
.export _wait, _stop
; ---------------------------------------------------------------------------
; Wait for interrupt: Forces the assembler to emit a WAI opcode ($CB)
; ---------------------------------------------------------------------------
.segment "CODE"
.proc _wait: near
CLI ; Enable interrupts
.byte $CB ; Inserts a WAI opcode
RTS ; Return to caller
.endproc
; ---------------------------------------------------------------------------
; Stop: Forces the assembler to emit a STP opcode ($DB)
; ---------------------------------------------------------------------------
.proc _stop: near
.byte $DB ; Inserts a STP opcode
.endproc
The label _wait, when exported, can be called by using the
wait () subroutine call in C. The section is marked as
code so that it will be stored in read-only memory, and the procedure is
tagged for 16-bit absolute addressing via the "near"
modifier. Similarly, the _stop routine can be called from
within the C-level code via a call to stop (). In
addition, the routine can be called from assembly code by calling
_stop (as was done in the interrupt service routine).
Oftentimes, it can be advantageous to create small application helpers in assembly language to decrease codespace and increase execution speed of the overall program. An example of this would be the transfer of characters to a FIFO (First-In, First-Out) storage buffer for transmission over a serial port. This simple action could be performed by an assembly language driver which would execute much quicker than coding it in C. The following discussion outlines a method of interfacing a C program with an assembly language subroutine.
The first step in creating the assembly language code for the driver is
to determine how to pass the C arguments to the assembly language
routine. The cc65 toolset allows the user to specify whether the data
is passed to a subroutine via the stack or by the processor registers by
using the __fastcall__ and __cdecl__ function qualifiers (note that
there are two underscore characters in front of and two behind each
qualifier). __fastcall__ is the default. When __cdecl__ isn't
specified, and the function isn't variadic (i.e., its prototype doesn't have
an ellipsis), the rightmost argument in the function call is passed to the
subroutine using the 6502 registers instead of the stack. Note that if
there is only one argument in the function call, the execution overhead
required by the stack interface routines is completely avoided.
With __cdecl__, the last argument is loaded into the A and X
registers and then pushed onto the stack via a call to pushax.
The first thing the subroutine does is retrieve the argument from the
stack via a call to ldax0sp, which copies the values into the A
and X. When the subroutine is finished, the values on the stack must be
popped off and discarded via a jump to incsp2, which includes
the RTS subroutine return command. This is shown in the following code
sample.
Calling sequence:
lda #<(L0001) ; Load A with the high order byte
ldx #>(L0001) ; Load X with the low order byte
jsr pushax ; Push A and X onto the stack
jsr _foo ; Call foo, i.e., foo (arg)
Subroutine code:
_foo: jsr ldax0sp ; Retrieve A and X from the stack
sta ptr ; Store A in ptr
stx ptr+1 ; Store X in ptr+1
... ; (more subroutine code goes here)
jmp incsp2 ; Pop A and X from the stack (includes return)
If __cdecl__ isn't specified, then the argument is loaded into the A
and X registers as before, but the subroutine is then called
immediately. The subroutine does not need to retrieve the argument
since the value is already available in the A and X registers.
Furthermore, the subroutine can be terminated with an RTS statement
since there is no stack cleanup which needs to be performed. This is
shown in the following code sample.
Calling sequence:
lda #<(L0001) ; Load A with the high order byte
ldx #>(L0001) ; Load X with the low order byte
jsr _foo ; Call foo, i.e., foo (arg)
Subroutine code:
_foo: sta ptr ; Store A in ptr
stx ptr+1 ; Store X in ptr+1
... ; (more subroutine code goes here)
rts ; Return from subroutine
The hardware driver in this example writes a string of character data to a hardware FIFO located at memory location $1000. Each character is read and is compared to the C string termination value ($00), which will terminate the loop. All other character data is written to the FIFO. For convenience, a carriage return/line feed sequence is automatically appended to the serial stream. The driver defines a local pointer variable which is stored in the zero page memory space in order to allow for retrieval of each character in the string via the indirect indexed addressing mode.
The assembly language routine is stored in a file names "rs232_tx.s" and is shown below:
; ---------------------------------------------------------------------------
; rs232_tx.s
; ---------------------------------------------------------------------------
;
; Write a string to the transmit UART FIFO
.export _rs232_tx
.exportzp _rs232_data: near
.define TX_FIFO $1000 ; Transmit FIFO memory location
.zeropage
_rs232_data: .res 2, $00 ; Reserve a local zero page pointer
.segment "CODE"
.proc _rs232_tx: near
; ---------------------------------------------------------------------------
; Store pointer to zero page memory and load first character
sta _rs232_data ; Set zero page pointer to string address
stx _rs232_data+1 ; (pointer passed in via the A/X registers)
ldy #00 ; Initialize Y to 0
lda (_rs232_data) ; Load first character
; ---------------------------------------------------------------------------
; Main loop: read data and store to FIFO until \0 is encountered
loop: sta TX_FIFO ; Loop: Store character in FIFO
iny ; Increment Y index
lda (_rs232_data),y ; Get next character
bne loop ; If character == 0, exit loop
; ---------------------------------------------------------------------------
; Append CR/LF to output stream and return
lda #$0D ; Store CR
sta TX_FIFO
lda #$0A ; Store LF
sta TX_FIFO
rts ; Return
.endproc
The following short example demonstrates programming in C using the cc65
toolset with a custom run-time environment. In this example, a Xilinx
FPGA contains a UART which is connected to a 65c02 processor with FIFO
(First-In, First-Out) storage to
buffer the data. The C program will wait for an interrupt generated by
the receive UART and then respond by transmitting the string "Hello
World! " every time a question mark character is received via a
call to the hardware driver rs232_tx (). The driver
prototype uses the __fastcall__ extension to indicate that the
driver does not use the stack. The FIFO data interface is at address
$1000 and is defined as the symbolic constant FIFO_DATA.
Writing to FIFO_DATA transfers a byte of data into the transmit
FIFO for subsequent transmission over the serial interface. Reading
from FIFO_DATA transfers a byte of previously received data out
of the receive FIFO. The FIFO status data is at address $1001 and is
defined as the symbolic constant FIFO_STATUS. For convenience,
the symbolic constants TX_FIFO_FULL (which isolates bit 0 of
the register) and RX_FIFO_EMPTY (which isolates bit 1 of the
register) have been defined to read the FIFO status.
The following C code is saved in the file "main.c". As this example demonstrates, the run-time environment has been set up such that all of the behind-the-scene work is transparent to the user.
#define FIFO_DATA (*(unsigned char *) 0x1000)
#define FIFO_STATUS (*(unsigned char *) 0x1001)
#define TX_FIFO_FULL (FIFO_STATUS & 0x01)
#define RX_FIFO_EMPTY (FIFO_STATUS & 0x02)
extern void wait ();
extern void __fastcall__ rs232_tx (char *str);
int main () {
while (1) { // Run forever
wait (); // Wait for an RX FIFO interrupt
while (RX_FIFO_EMPTY == 0) { // While the RX FIFO is not empty
if (FIFO_DATA == '?') { // Does the RX character = '?'
rs232_tx ("Hello World!"); // Transmit "Hello World!"
} // Discard any other RX characters
}
}
return (0); // We should never get here!
}
The following commands will create a ROM image named "a.out" that can be used as the initialization data for the Xilinx Block RAM used for code storage:
$ cc65 -t none -O --cpu 65sc02 main.c
$ ca65 --cpu 65sc02 main.s
$ ca65 --cpu 65sc02 rs232_tx.s
$ ca65 --cpu 65sc02 interrupt.s
$ ca65 --cpu 65sc02 vectors.s
$ ca65 --cpu 65sc02 wait.s
$ ld65 -C sbc.cfg -m main.map interrupt.o vectors.o wait.o rs232_tx.o
main.o sbc.lib
During the C-level code compilation phase (cc65), assumptions
about the target system are disabled via the -t none command
line option. During the object module linker phase (ld65), the
target customization is enabled via inclusion of the sbc.lib
file and the selection of the configuration file via the -C
sbc.cfg command line option.
The 65C02 core used most closely matches the cc65 toolset processor
named 65SC02 (the 65C02 extensions without the bit manipulation
instructions), so all the commands specify the use of that processor via
the --cpu 65sc02 option.