Probably just me derping and echoing nothing into the file.

Whole set of commands with the fixes we've covered to this point:
Code:

I do have that at the top of the program. Here's the entire code:

Code:

I did however get it to assemble like this:
I don't think it worked though as i just got my first crash when running it oncalc

Using -shared at link-time is probably doing something entirely wrong. You should only have -static in there.

I have no idea what it does, to use "-fleading-underscore" it told me i needed it in there.

Just change 'main' to '_main' in your code (and remove -fleading-underscore and -shared from the arguments) and all will be well. Whatever you got -fleading-underscore from, it was some sort of strange shared-library workaround.

I already tried that and it still gives me the same error :/

Above just tested

Great, it assembled without errors this time and i got my .g3a file (and 2-byte .bin). Running it oncalc crashed, though. Can you not return directly from a program?

Thank you so much for all your help!

EDIT: An infinite loop also crashed.

You can return from a program, but when you do, the program can't run again until you run a different add-in first. Can you verify that the program starts before crashing, perhaps? Dump some bytes out the serial port or something?

iirc, you need to call a syscall and possibly other stuff before running your code. Look at the crt0.s file for the startup procedure.

I think it's not even running, but i don't know how to test for sure. I've tried adding in the crt0.S code (essentially just changing the "main: \ .long _main" to the address of the start of my program "main: \ .long start") but it still crashes on start. I'm not sure what the C program adds at the start. I'm not exactly sure what crt0.S is doing, it looks like it's copying the program into RAM? I don't know what the .data section is (where it's supposed to point to), it seems it's defined in prizm.x. Then runs a syscall (_GlibAddinAplExecutionCheck) and jumps to the program.

And what is the delay slot? After syscalls the compiler seems to put a nop after it.

Yes, that's important. In SH4 assembly, jumps and rets take place one instruction late, so the instruction after a jump and the instruction after a ret always occur before the jump or ret. It's important to put a nop (or an opcode that finishes your code) in that slot to avoid unexpected behavior.

Ah, that's interesting. Thanks for the information. I still can't seem to get the binary to run on calc, however :/

do you call that one syscall on startup?

Here's the code i'm trying to use:

Code:

The syscall i assume is " _GlibAddinAplExecutionCheck"? When i run it i get a system error: TLB ERROR, saying the PC is at 00300000 (that's where programs are run from, right?). That should be the header, is there something wrong with my header? It says TARGET = 00049426, i don't know what that means.

Sorry for the double post, i just wanted to say i got it assembling with the makefile, but it's still giving me the TLB error at 00300000. I can't for the life of me figure out what's wrong, as the C programs all run fine (and a C program of nothing but asm()'s also runs fine). Maybe i'll just write a converter to change every line of my asm code into an asm() command

Can you use something like XVI32 to compare the two binaries and see wherein the difference(s) lie?

Can you verify that the first op in your asm file is what the first op is in the g3a?

I've gone through the HEX and my program does start at +$7000 (the opcodes match). The files are exactly the same size, but diff says the two files are different.

EDIT: So i got the infinite loop to compile, however it required that i add an rts \ mov #00,r0 to the end, for some reason. Now my next program (getkey loop) is also crashing (or rather, failing to run) But it's late here so that'll be another mystery for another day.

I suspect these issues may be due to failing to tear down the stack frame that crt0 creates. Need to investigate by seeing what the generated code for a stub C addin does.

When in doubt, build something in C and examine the code it generates to see what's necessary.