Yes, you can write C code for the SD-8516. However there are certain… limitations of the self-hosted project. Staying positive however, you can do quite a bit.

What this is really is more of a baseline C you could write a better compiler in. That's where we are right now. Secondly, this is not packaged anywhere yet; I don't know if I want to release it because it is really not a very robust program; however, I very likely will, sometime in the fall.

v2 is v1 written in C. It compiles but there are issues I am working on.

The LLVM back-end is not self hosted however I may use it to recompile v2 because:

a) I demonstrated that V1 can compile V2 b) I demonstrated that V2 can compile V2 c) The issues surrounding a v3 from a v2 are memory management issues and: d) They could be solved by reworking the memory map but I don't want to do that yet because I want to do it for a v2 kernal rewrite.

v1, v2, and v3 are not intended to be frestanding in the sense that they use INT 0x10 for putchar and getchar. However, what this all amounts to is a chicken and egg rewrite TinyC v1 and the Kernal at the same time, and although I am superhuman I am not ultra-superhuman. Its a death by 1000 cuts. The 1000 cuts are all multiplicative and it got to the point where going through the living hell of writing an LLVM backend (6+ months of work) is visibly cheaper than doing it completely self hosted from scratch.

…Aaaaand, I can't make them totally freestanding without changing the memory mapped input anyways. So basically the whole thing is dead in the water and the entire project needs a total rewrite. Unless I forget about C.

Doing a full-freestanding LLVM backend for the SD-8516 kills all birds with one stone. A very heavy stone. Whether I redesign the memory mapped system and kernal or do it this way first, either way it is a living hell of epic proportions to get this all done. The LLVM way, is just easier to conceptualize. It makes the black box “one thing”– get the LLVM backend up. Then the top-down design plan can continue.

I guess what makes me sad is I wrote this whole thing in assembly and now that I want to bring up C, C itself is bucking the retro nature of what I am doing. C itself is telling me, “be more like UNIX and less like a C64 or Apple II”. As it turns out, C itself is a really different paradigm than the old ideas behind a hand-assembled BASIC interpreter. Systems build around that are just different and not well-suited for C. Bringing C up almost requires your entire system be written in C anyways. It starts to infect and change every little thing about your system. I don't know if I really even want that kind of change. I like my system. I didn't plan on all these concessions for a C. Most of what I have been doing, actually, is adding things to my assembler and CPU core to support C and the LLVM back-end. It was working fine before.

But before, we didn't have a C.

It seems, C is not just a language, but an expression of a computer architecture. And as such it is hard to bring it up on an architecture which is dis-similar to the one it was designed on. This may mean C is not the best language for the SD-8516. Like a square peg in a round hole.

And yet I soldier on. My mission will be to retain as much of the freespirit of the SD-8516 and conform to C as little as possible while getting a full self-hosted C. I do not even know if this is possible, but I am about to find out!

1. Get the LLVM backend up.
2. rewire the memory map to put the kernal in bank 0
3. …as we rewrite the kernal in C

This all needs to be done anyways because carts will need to be freestanding and not dependant on an upgradable OS. Like a console. The SNES doesn't have a command line or a MON or a programmer's interface. Moving the kernal to $0 and video to $1 means we can use everything else in one solid block which is just how I like to think.

Or maybe put the kernal and the video at the end of memory.

Basically I want to use LLVM to freestand the entire system in C. Then that becomes the rewrite. I think that's valid. Maybe what I should do is actualy change away from a memory mapped system to special CPU opcodes that access devices. Maybe INT needs to poll for IO instead. I don't know.

I just got this conclusion that the memory map is what is gumming up the whole system and I need time to think. Nothing can get done until I think this through. So getting a back-end up in LLVM will give me time to think.

The big issue now is how to package it for other people to use.

Currently if you want to write C for the SD-8516.. frankly, write your program and send it to me and I'll compile it for you. Trust me when I say that is easier.

Packaging it simply will take too much time away from developing it.

Given all this I recommend you program in assembly first. That's really what this project is about, the retro way. You should give it a shot, if you've never tried assembly before. This platform is designed with hand-assembly in mind. Like the old days. If you really want to program in C, well, it's coming, but C was never really common on the early home computers. They were more BASIC/assembly.

Anyways, i'm working on it, i'll post what information and updates I can..