6502.org

I'm having a problem building a C program for the W65C265SXB board. I'm trying to build this C file: First I compile it like this: Then I need to turn it into a hex file to send it to the board over serial, which is the part I can't figure out. I'm trying to link it like this: I've tried a bunch of different flags on the linker, and I always get "Undefined symbol: ~~puts" or something like that. The compiler manual says that puts is supported, and it's in the header file. I've also tried with the IDE and it seems to get the same error.

How do I invoke the linker?

I'm certainly no expert, but I remember having to provide a file to #include, e.g.

Sorry, I did, forum formatting ate it. That would make it not compile anyway, it compiles fine, it won't link.

Are you sure? I just tried it, and it worked fine. Everything between the [code] and [/code] gets displayed exactly as you write it. White space is preserved but formatting marks get ignored.

Oh, you're right, it must be the WDC contact form that ate it. Before I posted it here I asked the same thing in an email to WDC (since it's their compiler) and copied it out of the acknowledgement it sent me.

Anyway I just edited it to put the stdio.h bit in there. It compiles without a problem, and the resulting asm (if you pass -a) has an external reference to puts. But the linker can't find it no matter what I tell it to link against.

According to the documentation, you need -LC in the linker command line, and the location of the directory containing the standard libraries in the environment variable WDC_LIB. The example directory they give is C:\WDC\LIB, but it's going to depend on where the compiler got installed on your computer.

Compiler docs http://www.westerndesigncenter.com/wdc/ ... mpiler.pdf page 40
Linker docs http://www.westerndesigncenter.com/wdc/ ... Linker.pdf page 33

I've never tried using the WDC compiler, so I don't know whether that will actually work. But hopefully there's enough in the documentation to get you there.

The WDC library may not contain implementations for the stdio functions as they are very hardware dependent.

Adding -LC doesn't help (or -L anything else for that matter, none of the stuff in lib seems to contain the C standard library).

The manual says it does contain the stdio functions, but even if it doesn't, other functions (atoi is the one I tried) aren't there either, so it's not able to link in any libraries.

WDC_LIB is set, to the directory holding all the .obj files that it installed.

Is there any file in the installation with a name matching libc or LIBC or any combination?

Sure, tons:

c0.obj, c0c.obj, c0l.obj, c0m.obj, c0s.obj, c134.lib, c.lib, cc.lib, cl.lib, cm.lib, cs.lib, m134.lib, m.lib, mc.lib, ml.lib, mm.lib, ms.lib.

If I pass it -lcl and try to link against c0l.obj (which is what TIDE tries to do) it also says it can't find a bunch of other stuff, like close, write, IRQhandler, etc.

I'm sure the answer is that I'm not linking in the correct combination of these files but I can't find in the manual anywhere which ones I need. I would be willing to deal with it if the non-stdio stuff worked (having a puts that writes to the monitor would be a nice bonus but I wasn't really expecting it), but without the rest of the standard library, I mean, the compiler is kind of useless, even if it does technically compile things. I'd have to reimplement all that stuff on my own to use it.

Although to be fair it does compile and link things that don't use the standard library. As long as I'm willing to reimplement all that stuff myself (or find an open source one) I can use it.

I think I might have figured this out, no thanks to the manual: wdclib -s shows me that all the C library functions are in the whatever.lib files, and if I add those to the linker then it finds them and complains that some other things are missing: __unlink, __close, __isatty, __write, __lseek. But it only needs those symbols if I use anything in stdio. So maybe those are things I need to implement myself in order to use stdio functions? But non-stdio stuff will link now, at least, which is good enough, because I can make inline asm functions to write strings to the monitor.

So the final answer seems to be: (or with whatever memory model you want, L is the slowest but largest one)

ah, memory models, just to make life a little more complicated! Unavoidable, though, I think, for an '816.

The memory model thing is probably why you have to manually tell it what to link against. There are five copies of the std lib, one for each memory model and (I guess?) one for the 6502.

And it makes sense that fcntl.h would have no implementation, it would just be nice if the manual would TELL you that, or if they had an example C project, or if TIDE actually worked out of the box, or.... Yeah.

Yea, there shouldn't be any disk related code supplied.

I can name 2 '816 computers that had a disk drive: the Apple //GS, and the SuperCPU thing for the C64.

So, how CAN there be any disk support code with the compiler. For what machines? It would be nice if there was sample code that could be used and ported, however.

stdio can exist, simply because it can work with a serial console, but even then I'd be surprised if there was any real support.

At best, they should have libraries that leverage the monitors built in to the W65C134SXB and W65C265SXB boards.

Otherwise, yea, you get to write the rest yourself.