Debunking the two myths about WDC C Compiler.

Programming the 6502 microprocessor and its relatives in assembly and other languages.
Post Reply
tokafondo
Posts: 344
Joined: 11 Apr 2020

Debunking the two myths about WDC C Compiler.

Post by tokafondo »

- Myth #1: "It's not a full version. You need to pay for the full version".

From the WDC Website: "Version 2.1 Release Update: The latest WDCTools release will feature TIDE Removed, FULL VERSIONS of our C-Compilers and Optimizers, 9 simulator/hardware projects with command line batch scripts to get you working fast."


- Myth #2: "It only works in Windows".

You can use Wine 32 bits to run at least the command line utilities. Not even Virtualbox or whatever. I've tested this by myself. And as the command line utilities doesn't load the GUI, I think that they can be used in native scripts (bash and others).
User avatar
Druzyek
Posts: 367
Joined: 12 May 2014
Contact:

Re: Debunking the two myths about WDC C Compiler.

Post by Druzyek »

Wouldn't "It works on Windows" need to be true before "It only works on Windows" could be true? I'm still waiting on an answer for over a year from customer support of where I can find the non-existent files referenced in the documentation you need to compile at the command line in Windows.
tokafondo
Posts: 344
Joined: 11 Apr 2020

Re: Debunking the two myths about WDC C Compiler.

Post by tokafondo »

What files are those? I'm curious.
User avatar
Druzyek
Posts: 367
Joined: 12 May 2014
Contact:

Re: Debunking the two myths about WDC C Compiler.

Post by Druzyek »

tokafondo wrote:
What files are those? I'm curious.
Startup.ASM for one.

See "Copying data" on page 15 of the linker documentation showing an example file for the 65C816. This should be included in the installation and isn't. I can compile and link the program below, but msg is never initialized, so reading just yields uninitialized garbage:

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;
}
EDIT: updated C code
tokafondo
Posts: 344
Joined: 11 Apr 2020

Re: Debunking the two myths about WDC C Compiler.

Post by tokafondo »

But isn't the code of startup.asm commented in the next pages?

Code: Select all

STACK		EQU			$F000			;CHANGE THIS FOR YOUR SYSTEM
STARTUP	 SECTION	  OFFSET $FF80
START:
			  CLC							;clear carry
 			 XCE							;clear emulation
			  REP			#$30			;16 bit registers
			  LONGI		 ON
			  LONGA		 ON
			  LDA			#STACK			;get the stack address
			  TCS							;and set the stack to it
[and so...]
User avatar
Druzyek
Posts: 367
Joined: 12 May 2014
Contact:

Re: Debunking the two myths about WDC C Compiler.

Post by Druzyek »

tokafondo wrote:
But isn't the code of startup.asm commented in the next pages?

Code: Select all

STACK		EQU			$F000			;CHANGE THIS FOR YOUR SYSTEM
STARTUP	 SECTION	  OFFSET $FF80
START:
			  CLC							;clear carry
 			 XCE							;clear emulation
			  REP			#$30			;16 bit registers
			  LONGI		 ON
			  LONGA		 ON
			  LDA			#STACK			;get the stack address
			  TCS							;and set the stack to it
[and so...]
That's 65C816 assembly and won't work for a 65(C)02. Besides, hunting down a file that doesn't come with the compiler to copy and paste something out of a pdf into a source file just to get it to compile is beyond amateur hour. Not that it matters on a 6502 since you can't compile even if you have the pdf.
tokafondo
Posts: 344
Joined: 11 Apr 2020

Re: Debunking the two myths about WDC C Compiler.

Post by tokafondo »

Ok. Have you a list of the files you miss? There has to be a place where they could be found.

I've seen something about a folder called WDC_SDS in documents from 2005.
User avatar
Druzyek
Posts: 367
Joined: 12 May 2014
Contact:

Re: Debunking the two myths about WDC C Compiler.

Post by Druzyek »

tokafondo wrote:
Ok. Have you a list of the files you miss?
No. Like I mentioned above, the compiler is happy to produce a binary that doesn't do anything useful since it's missing at least that file and maybe others. I have no way of knowing what's left out that would be needed to have it produce working programs.

You may be able to get it to produce the file you need from the IDE, but that crashes for me.

What do you think about changing the name of the topic and your first post since it's not true (at least for the time being) that you can compile at the command line with what WDC provides?
User avatar
Agumander
Posts: 129
Joined: 17 Jul 2018
Location: Long Island, NY
Contact:

Re: Debunking the two myths about WDC C Compiler.

Post by Agumander »

Druzyek wrote:
Like I mentioned above, the compiler is happy to produce a binary that doesn't do anything useful since it's missing at least that file and maybe others. I have no way of knowing what's left out that would be needed to have it produce working programs.
Wouldn't it be relatively straightforward to run a simple program through it, then disassemble that output to see what's missing between that program and a working binary for your system? If you can figure out where your code starts and what offsets are assumed then you shouldn't need to do much besides jump to the pointer.
User avatar
Agumander
Posts: 129
Joined: 17 Jul 2018
Location: Long Island, NY
Contact:

Re: Debunking the two myths about WDC C Compiler.

Post by Agumander »

Well that's some egg on my face. I can't even get it to compile from the command line, WDC02CC just crashes. I might be missing even more than you are! :oops:

Though the useless binary file you describe sounds like the relocatable object file the manual references. If I could get even that far, I'd be interested to try filling in the blanks left by startup.asm, maybe even write a generator tool since the manual hints its meant to be customized for different systems.

EDIT:
Ok, so I've got it compiling and building a binary. It just doesn't get very far. The biggest undocumented hole I've found is how the startup.asm is expected to initialize the pseudo registers. My (simulated) system gets stuck somewhere in the "csav" routine that contains all the tasty overhead of calling a C function, which I think is due to the virtual stack pointer not being set. Will continue to plug at it.

EDIT2:
After a lot of mucking about I figured out that half my problem was my emulator missing some 65C02 opcodes. My current implementation of startup.asm merely zeroes out RAM before setting the stack pointer pseudo register to something manageable. However it still messes up if I add any local variables to a function so there's quite a bit left to understand.

My startup.asm so far:
https://github.com/clydeshaffer/gametan ... tartup.asm
tokafondo
Posts: 344
Joined: 11 Apr 2020

Re: Debunking the two myths about WDC C Compiler.

Post by tokafondo »

I'm trying to help here. Or at least know what is being talked about to try to get help.

The Assembler/Linker/Librarian document referenced in from 2005. The startup.asm file is assembler. But the missing file seems to me being from C.

What is/are the missing file/s? I can find stdio.h in /wdc/Tools/include

Thanks.
User avatar
Agumander
Posts: 129
Joined: 17 Jul 2018
Location: Long Island, NY
Contact:

Re: Debunking the two myths about WDC C Compiler.

Post by Agumander »

The missing file is almost certainly the example assembly file referenced in the documentation.
I've also been looking at this manual from 2013, specifically about the WDC02CC compiler included with WDCTools. It describes the job that the startup.asm is supposed to accomplish, and how to turn your object files generated by WDC02CC and WDC02AS into an actual binary with WDCLN.

The compiler uses a virtual stack to manage function calls, separate from the hardware stack at $0100.
The required tasks of the startup file are:
- Set uninitialized memory segments to 0
- Copy the values of variables with initializers from ROM into their mapped RAM locations
- Set the zero page stack pointer "register" used by the virtual stack to the top of the memory range you want to use for the virtual stack.
- Declare the interrupt vectors
- Jump into your main C function

4/5 of these are pretty easy, though setting up the virtual stack registers has been a head scratcher. Unfortunately the 65816 code doesn't illuminate much because the 65816's hardware stack is apparently sufficient for running C programs.

EDIT: Okay, so some of the difficulty again turned out to be my own buffoonery. My loop to clear ZP wasn't actually clearing ZP, resulting in unexpected behavior. I've got local/stack variables working except for argument passing, which seems to freeze the program.
tokafondo
Posts: 344
Joined: 11 Apr 2020

Re: Debunking the two myths about WDC C Compiler.

Post by tokafondo »

I've searching for some form of help regarding this. It seem this has been discussed before, so let's move the conversation there.
brich057
Posts: 1
Joined: 16 Jun 2025

Re: Debunking the two myths about WDC C Compiler.

Post by brich057 »

In a WDCTools video he says and shows that to create new project it takes copying and pasting a current example and renaming it. So if your not doing that, then I bet that is why your having such problems. Here is a link to that video
https://youtu.be/bbfEleNRH1o?si=vuNULaouKzXL7Xe8
Post Reply