Have built a WDC65c816SXB-inspired SBC with a 65c816 CPU with an 6551 ACIA for console input/output. Have an assembler startup file that does the basic initing of CPU and ACIA after power-up and then transfers to control to the main() function in a .c file. At the moment, the main() function calls two functions I wrote myself called getchar() and putchar(). These are used to show a welcome message on the console and to read keystrokes from the keyboard. Both functions directly access the 4 ACIA registers, memory-mapped at RAM addresses 0x7F80...0x7F83. Nothing too hard or shocking. The ANSI-compliant C compiler from WDC (WDC816CC) includes the standard libraries that also have putchar() and getchar() functions. They typically read from stdin and write to stdout.

How do I configure the compiler's putchar() and getchar() to use those RAM addresses so they can replace my versions? This way I can also use other "stdio.h" functions such as printf() and scanf()?

personally i wouldn't be using WDC's tools, they definitely show their age... but if you get them to work and they work fine for your needs then go ahead.
but i would recommend something like Calypsi C, it's C99 instead of C89, has pretty good documentation, and is actively being maintained.
i also remember vbc (a forum member) talking about working on a VBCC port for the 65816, but that was a really long time ago and i wonder what happend to that project since (from my experience) making a crappy but functional backend shouldn't take that long, right?

anyways back to the WDC tools, i don't know how exactly they handle their standard libraries (but from the documentation i can see that they include them), but i'd assume that similar to newlib, the included libraries would only contain the hardware independent components which would make calls to system specific functions (open, close, read, write, sbrk, etc.)
to see if that's the case you could just try it out. make a simple hello world program with printf, include the given library while linking and then see which function the compiler will complain about being missing.

or if they include the source code for the used libraries (which they should) try to see if you can find any function stubs for read, write, etc. or grep (findstr on windows) through them to find any mentions of functions like that, which would also tell you what arguments they need.

then you just write them (either in assembly or C) assemble/compile them to object files and throw them into a library to link along side your program.

My main objections to Calypsi C are closed source, x86 only and restrictive license terms. But I suppose it's good it's out there.

_________________
Machine room: http://www.floodgap.com/etc/machines.html

the same is true for the WDC tools though, unless they just released the source code or made an ARM (or native 65816) version that i don't know of...

i'm still hoping for that VBCC port so we have a fully open source compiler that could in theory compile itself to allow for native C programming on a 65816. ah, the dream!

There's still SDCC (I still need to try out the latest version; the last had some issues. The most recent is still missing 6502 and 65c02 specific documentation).

I seem to remember that with SDCC it is necessary only to define putc() and getc() to make the stdio work.

Neil

edit: putchar() and getchar() - see here: viewtopic.php?f=2&t=7049#p98263

wait since when does SDCC have a 65816 target? i can't find anything to that online...

Oh I'm sorry; for some reason I thought we were looking for 65(c)02.

Mea culpa!

Neil

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Alan Cox has a C compiler under development that includes 6502 and 65816 support as part of his FUZIX Compiler Kit project. I don't think it is production ready yet, and I believe it has some limitations due to its intended use as part of the FUZIX project. No idea how good it is. Source is at https://github.com/EtchedPixels/Fuzix-Compiler-Kit.

I don't like to see the term "vaporware" applied to personal projects. It reads to me as perjorative. If a project seems to be making slow progress, there will be reasons. No-one has a right to demand that someone else's project should make progress.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

that's why i specifically said crappy backend. getting a backend into a "functional" state doesn't nearly take as long as making it generate good assembly.

my own SW32VM backend for VBCC took me a few months to get (mostly) working, 32-bit ints are broken for some reason, and VBCC doesn't include any kind of test suite, so knowing what features are still missing is difficult. but for having never worked with VBCC before i think i did pretty good so far. (i'll post an update on the SW32VM thread when i get time to just sit down and write it and push all updates to the github as well)

anyways this is why i would think that someone (or a team of people) much more knowledgeable than me likely already have a mostly functional backend and now just focus on bug fixing, optimizing the code generation, and adding customization options (like default pointer sizes).

Unfortunately some issues have prevented me from working on it as I had originally planned. It has not been canceled and the backend is mostly complete, but I still need to finish the C library, run my test suite, and do some optimizations.

And I am not aiming for "crappy but functional".

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!