WDC Tools STARTUP.ASM and C samples files for 6502/816

[Agumander]

Unfortunately it seems I need more than the -D USING_02 (with or without the space) option to build without modifying any files in the bin or include folder. The build succeeds without errors, but my program doesn't boot properly if I restore the zpage.inc and wdc02cc.cfg files to their "factory" state. Seems like something still ignores the conditional and uses the wrong values.

[enso]

You guys are way more patient than I can even imagine! I am curious to see how this resolves. It would be nice to have a 'reference' compiler straight from the horse.

[Druzyek]

Agumander, hmm, strange. What are you running to test with? Also, you may want to modify your STARTUP02.asm if the stack being set to 0xD7FF won't work on your system. See if my test code will compile and run for you:

Code: Select all

#include <stdio.h>

unsigned char * const DEBUG = (unsigned char * const)0xFFE7;

const char *msg="Hello, world!";

int main()
{
   const char *ptr=msg;
   while(*ptr) *DEBUG=*ptr++;
   
   while(1);
   
   return 0;
}

[Agumander]

I'm testing with my Tetris project, which compiles and builds fine if I stub out the whole ELSEIF USING_134 section of wdc02cc.cfg

It does look like it still builds fine with zpage.inc restored to normal. It also seems to work if I indent the insides of the IF...ELSEIF...ENDIF construction in wdc02cc.cfg

[Druzyek]

Strange. You might want to reduce your Tetris game down smaller and smaller until you get the smallest example you can that won't compile right without the modified cfg file.

[Proxy]

I know it's a slightly old Thread, but thanks for posting the STARTUP files.
after i (mostly) got CC65 to work i wanted to try out the WDC C Compiler for the 65816, so this was perfect!

maybe it's because i now have experience from setting up CC65 but i found it somewhat straight forward to getting the compiler to work.
with some exceptions of course...

for example WDC's included STDINT.H is... kinda broken, and it took me a lot of cryptic compiler errors before i figured out why.
it doesn't define uint8_t or int8_t (only the 16 and 32 bit types) and even then uint32_t and int32_t don't actually work because SIZEOF_LONG is aparently never declared so the 32 bit types are never defined either.
i had to heavily modify the file to allow for anything besides uint16_t and int16_t to be usable. (though it does mean the file now assumes that char = 1 byte, int = 2 bytes, and long = 4 bytes)

other than that all i did to get it up and running was:
modify the STARTUP file to fit the hardware i want. (renamed from STARTUP.ASM to crt0.s to be more consistent with CC65 and Interrupt routines are kept in a seprate file)
the only directly C related symbol in crt0.s is MAIN, which has a different name depending on the Memory Model, i just choose large (main is therefore ~~MAIN) because it has the fewest memory restrictions.
after that i was able to start writing C and just had to fiddle around with the Linker for a while. here the complete commands i used to compile, and link everything:

Code: Select all

WDC816AS -O Config\crt0.o Config\crt0.s
WDC816AS -O Config\interrupt.o Config\interrupt.s
WDC816CC -SOP -ML -O Temp\test.o test.c
WDCLN -T -HB -C10000,0 -D20000, -O test.bin Config\crt0.o Config\interrupt.o Temp\test.o

(CODE gets loaded and runs in Bank 1, Data gets loaded with CODE but then gets copied to Bank 2)
one thing i did to make sure the crt0.s code will be put at the very start of the output file (because it contains the header i need) is removing the "STARTUP SECTION OFFSET $xxxx" line, which then automatically placed it into the CODE Segment, then when linking i just made it be the first input file in the command (it seems to link from left to right like CC65)

though i got it to output some code i don't know if it will actually work as i currently have no 65816 Computer.
another thing, how exactly does the compiler use the Direct page? does it move it around whenever it needs more than 256 DP Locations, so do i need to keep track of that when handling interrupts? and how do i tell the linker to reserve some specific bank 0 addresses for myself so it doesn't overwrite them with other vairables?

and one last thing, sorry for kinda hijacking the thread but i have not been able to figure this out in either CC65 or WDC816CC...
what do you have to do in C to get the compiler to declare a symbol with a specific value and then export it?
like this:

Code: Select all

; WDC:
TEST_SYM EQU $69
XDEF TEST_SYM
; CC65:
TEST_SYM = $69
.export TEST_SYM

i tried using extern like this:

Code: Select all

extern uint8_t TEST_SYM = 0x69;

but all that does is generate a Label named "TEST_SYM" that points to the value, instead of being set to it:

Code: Select all

TEST_SYM:
    DB $69
XDEF TEST_SYM

which is completely different from what i try to achieve.

any tips?

[Druzyek]

Quote:

i tried using extern like this:

Code: Select all

extern uint8_t TEST_SYM = 0x69;

Extern doesn't declare a variable that is visible externally. Instead, it tells the linker that the variable is declared externally elsewhere (without extern). For example, you can declare a global variable in one file then access it in another:

Code: Select all

//globals.c
uint8_t TEST_SYM;

Code: Select all

//main.c
extern unit8_t TEST_SYM;
int foo()
{
print_unit8(TEST_SYM);
}

On the other hand, if you just want a constant value and don't necessarily need to store it in a variable, you can use #define in a header file included in both c files.

[Proxy]

Druzyek wrote:

Extern doesn't declare a variable that is visible externally. Instead, it tells the linker that the variable is declared externally elsewhere (without extern). For example, you can declare a global variable in one file then access it in another:

Code: Select all

//globals.c
uint8_t TEST_SYM;

Code: Select all

//main.c
extern unit8_t TEST_SYM;
int foo()
{
print_unit8(TEST_SYM);
}

On the other hand, if you just want a constant value and don't necessarily need to store it in a variable, you can use #define in a header file included in both c files.

hmm i see, then i misunderstood the use of extern.
sadly #define only works for other c or header files, not already assembled object files...

I still feel like they should be a way to do this as it seems really useful to be able to define externally accessable symbols to be used by hardware specific libraries in a c source file without needing access to the source code of the libraries and having to manually re-assembling/compiling them for each target system.
though maybe this is outside the C standard, but even then i could still suggest this as a new feature to the CC65 devs (and maybe even WDC if they even update their tools anymore?)