Code::Blocks.

[Stef]

So it's the md.ld file which is probably not compatible with your GCC version. I modified it compared to the original one, i did some minors tweaks and corrections but maybe they are not correct.
What version of GCC are you using ? I guess you need to replace all the binary and the libc file with your linux version ?

As I mentioned above, it gave that error with every version of gcc from 3.4.0 to 4.1.1. I've decided to stick with 4.1.1 for the moment. Someone at Novell maintains the m68k cross compiler, updating to the current stable gcc and compiling rpms for 586 and x86_64 (the one I'm using).

I recompiled all the lib files, and have it using the libgcc.a that comes with the cross compiler. A quick look at the code generated doesn't reveal anything out of the ordinary. I'm still using the md.ld from the version 4 devkit with BLOCK (0x4) removed. Should I try an older version?

Every version of mini dev kit uses the same md.ld file. I was speaking about the ld file you can file on some XGCC for 68k cpu. Anyway i checked them and they are even more buggy...

Try to replace the
".data BLOCK (0x4) :"
by
".data 0xff0000 :"

In fact the .data section isn't usable with genesis as the compiler doesn't have code to init data in memory. We have to *always* use unitialised variable then initialize them in code otherwise the compiler generate an error message. Hopefully we can survive without it constantes are of course possible, only initialised variables is not allowed.

By the way, did you know a way to force the compiler to use register instead of stack to pass parameters ? i compiled severals version of GCC here and the optimisations are not good. I've the best result with -O1 and GCC 2.8 gives exactly the same result as 4.1... it's a bit disapointing :-/

[Chilly Willy]

Every version of mini dev kit uses the same md.ld file. I was speaking about the ld file you can file on some XGCC for 68k cpu. Anyway i checked them and they are even more buggy...

Try to replace the
".data BLOCK (0x4) :"
by
".data 0xff0000 :"

Well, that doesn't fail, but the programs still don't work.

In fact the .data section isn't usable with genesis as the compiler doesn't have code to init data in memory. We have to *always* use unitialised variable then initialize them in code otherwise the compiler generate an error message. Hopefully we can survive without it constantes are of course possible, only initialised variables is not allowed.

I kind of thought that would be the case as you can't exactly stick data for the data area into the rom without also having code to copy that data into the data area later - something the current code doesn't do. It's easy enough to simply remember to set variables at the start of the program.

By the way, did you know a way to force the compiler to use register instead of stack to pass parameters ? i compiled severals version of GCC here and the optimisations are not good. I've the best result with -O1 and GCC 2.8 gives exactly the same result as 4.1... it's a bit disapointing :-/

According to the gcc internal docs, the m68k arch ALWAYS passes function args on the stack.

The convention is still (as far as I can determine, even for modern ColdFire CPUs) d0-d1/a0-a1 are scratch, all other regs must be preserved, args are pushed on the stack from right to left, and args are promoted to 32 bits before pushing. AmigaOS made use of this by making varargs functions that called the real function by simply passing a pointer to the stack. That's one of the toughest things to mimic with AROS (the Amiga Research OS).

[Fonzie]

Hopefully we can survive without it Wink constantes are of course possible, only initialised variables is not allowed.

You mean, gcc for megadrive don't handle initialized local variables? (for global, I know it works, but for local...)

Wow, that would be terrible ^^ I often initialize variable to 0 when defining them, this don't work?

[Stef]

Every version of mini dev kit uses the same md.ld file. I was speaking about the ld file you can file on some XGCC for 68k cpu. Anyway i checked them and they are even more buggy...

Try to replace the
".data BLOCK (0x4) :"
by
".data 0xff0000 :"

Well, that doesn't fail, but the programs still don't work.

It does work for me on win32 system, i guess something is wrong with your "linux genesis GCC setup" :-/
can you try to debug the rom in an emulator (Gens KMod) to see what is wrong with the generated code ?

I kind of thought that would be the case as you can't exactly stick data for the data area into the rom without also having code to copy that data into the data area later - something the current code doesn't do. It's easy enough to simply remember to set variables at the start of the program.

yep, it's exactly that. I thing i can do something for it, just need to do research on LD definition stuff

By the way, did you know a way to force the compiler to use register instead of stack to pass parameters ? i compiled severals version of GCC here and the optimisations are not good. I've the best result with -O1 and GCC 2.8 gives exactly the same result as 4.1... it's a bit disapointing :-/

According to the gcc internal docs, the m68k arch ALWAYS passes function args on the stack.

The convention is still (as far as I can determine, even for modern ColdFire CPUs) d0-d1/a0-a1 are scratch, all other regs must be preserved, args are pushed on the stack from right to left, and args are promoted to 32 bits before pushing. AmigaOS made use of this by making varargs functions that called the real function by simply passing a pointer to the stack. That's one of the toughest things to mimic with AROS (the Amiga Research OS).

I really wonder why they never used a "register type" calling convention... 68k cpu has many registers and using stack is a big waste of time on function you use a lot. Well, asm is the only way to do it here :-/

Hopefully we can survive without it Wink constantes are of course possible, only initialised variables is not allowed.

You mean, gcc for megadrive don't handle initialized local variables? (for global, I know it works, but for local...)

Wow, that would be terrible ^^ I often initialize variable to 0 when defining them, this don't work?

It just doesn't work, in fact your variables are *always* initialised to 0 (default memory content) whatever the value you give to it.
I'll try to add "the initialised variable feature" in the next version of the dev kit.

[Chilly Willy]

It does work for me on win32 system, i guess something is wrong with your "linux genesis GCC setup" :-/
can you try to debug the rom in an emulator (Gens KMod) to see what is wrong with the generated code ?

That's the plan at this point. I'm probably just missing something stupid. Problems like this often tend to be the result of something trivial and stupid.

By the way, did you know a way to force the compiler to use register instead of stack to pass parameters ? i compiled severals version of GCC here and the optimisations are not good. I've the best result with -O1 and GCC 2.8 gives exactly the same result as 4.1... it's a bit disapointing :-/

According to the gcc internal docs, the m68k arch ALWAYS passes function args on the stack.

The convention is still (as far as I can determine, even for modern ColdFire CPUs) d0-d1/a0-a1 are scratch, all other regs must be preserved, args are pushed on the stack from right to left, and args are promoted to 32 bits before pushing. AmigaOS made use of this by making varargs functions that called the real function by simply passing a pointer to the stack. That's one of the toughest things to mimic with AROS (the Amiga Research OS).

I really wonder why they never used a "register type" calling convention... 68k cpu has many registers and using stack is a big waste of time on function you use a lot. Well, asm is the only way to do it here :-/

yeah, I was thinking about it, and it seems the best you could do would be something like

Code: Select all

  asm("move.l %1, d0"
      "move.l %2, d1"
      "move.l %3, a0"
      "jsr    label"
      "move.l d0, %0"
      : (result)    /* output  */
      : (arg1), (arg2), (arg3)    /*  inputs  */
      : "d0", "d1", "a0"    /*  clobber list  */
      );

Something like that. Haven't tried it myself, but it seems to be the only way you'd be able to call assembly langauge routines with arguments passed via register without making a stub. Most of the examples for this are x86, so the code above probably needs to be played with to get it right. You could probably make a #define for this.

[Chilly Willy]

Okay, done figgered it out. I ran the sample in gens-kmod and noticed it was constantly taking a bus error at some address in the code. Looked at the code in their disassembly window and it said illegal opcode. I loaded the code into ReSource in UAE and checked - there were long branches in that segment of the code, and nowhere else. Well, there was only one thing that could be - libgcc.a. So I went back to my uClinux gcc archive and checked - they have several directories for it, one for a different 68K variant. I grabbed the libgcc.a from the 68000 directory, recompiled the samples, and they work fine. The moral of the story is - double check you're using the right libgcc.a file or BOOM!!

Anyhow, both gencube3D and partic compile and run fine now. Thanks for the help! And the guide. So, this can all be set up in linux virtually the same way as in Windows. You'll find a gcc 4.1.1 m68k cross compiling toolchain made for uClinux here, just make sure to use the proper libgcc.a file, and make the change to the md.ld file discussed in previous posts.

[Stef]

Code: Select all

  asm("move.l %1, d0"
      "move.l %2, d1"
      "move.l %3, a0"
      "jsr    label"
      "move.l d0, %0"
      : (result)    /* output  */
      : (arg1), (arg2), (arg3)    /*  inputs  */
      : "d0", "d1", "a0"    /*  clobber list  */
      );

Something like that. Haven't tried it myself, but it seems to be the only way you'd be able to call assembly langauge routines with arguments passed via register without making a stub. Most of the examples for this are x86, so the code above probably needs to be played with to get it right. You could probably make a #define for this.

Unfortunatly that type of tip isn't optimal for code compilation, anyway it's better that using the stack
It's cool you finally figured out the problem with GCC !

[Chilly Willy]

Code: Select all

  asm("move.l %1, d0"
      "move.l %2, d1"
      "move.l %3, a0"
      "jsr    label"
      "move.l d0, %0"
      : (result)    /* output  */
      : (arg1), (arg2), (arg3)    /*  inputs  */
      : "d0", "d1", "a0"    /*  clobber list  */
      );

Something like that. Haven't tried it myself, but it seems to be the only way you'd be able to call assembly langauge routines with arguments passed via register without making a stub. Most of the examples for this are x86, so the code above probably needs to be played with to get it right. You could probably make a #define for this.

Unfortunatly that type of tip isn't optimal for code compilation, anyway it's better that using the stack
It's cool you finally figured out the problem with GCC !

Yeah, I'm just trying to decide what to do as a demo now.

I'm doing some PSP work right now, but after that, I'll try to put a little time on the SEGA. Do a little program, maybe work on that code above.

[Fonzie]

In fact the .data section isn't usable with genesis as the compiler doesn't have code to init data in memory.

I thought about that... but my GCC does add a little piece of code, before "main()" that check for a flag in RAM (set to 1 or 0) and if its set to 0, it just initialize a bunch of stuff and set it to 1.

I noticed that hidden thing because I wanted, some months ago, to have my code to boot at max speed, and there were always a sort of "lag" between the jmp"main" from sega.s and main() function.... It's when i disassembled my rom that I found this "gcc code addition" which can be pretty heavy (in size) depending of what you do in your code later...

[ch0d3]

Excellent guide, thank you very much. Had everything up and running in about 10 min. Nice devkit too

I am new to Genesis dev so this is a great help.

-ch0d3

[Stef]

Excellent guide, thank you very much. Had everything up and running in about 10 min. Nice devkit too

I am new to Genesis dev so this is a great help.

-ch0d3

You're welcome !
Always nice to see new genesis dever here =)