Code::Blocks.

[MG]

Yop !

Someone use Code::Blocks with the mini-dev kit from Stef ?

Because, today, I had tried to configure it but... grrrr, I'm really lost.
Since today I'm using Dev-C++, and I had succeded to configure it, but here...

If someone can help me, I'll be very happy

A+

PS : Same configuration as described in the mini-dev kit.
All the files in D:\Apps\GenDev\Bin etc etc...

[Stef]

Yop !

Someone use Code::Blocks with the mini-dev kit from Stef ?

Because, today, I had tried to configure it but... grrrr, I'm really lost.
Since today I'm using Dev-C++, and I had succeded to configure it, but here...

If someone can help me, I'll be very happy

A+

PS : Same configuration as described in the mini-dev kit.
All the files in D:\Apps\GenDev\Bin etc etc...

I do use it but i just can't use it "natively" for now. I remember something prevented me to get it...I guess it's possible but you probably have a lot of custom configuration to do.
Instead i'm using some "batch" in custom tools to compile and test my rom. I agree it's not very nice but good enough for me

[haroldoop]

I use it too.
It took me a while to get everything to work as it should:

• First, go to Build->Compiler Options;
  • Select GNU GCC Compiler;
    Click on "Copy";
    Name it "GenDev";
    In the Compiler->Other options tab, put: -m68000 -O1 -fomit-frame-pointer
    In the Linker tab:
    • Link libraries (sega.o MUST be the first object to be linked!):
      • C:\utils\GenDev\lib\sega.o
        C:\utils\GenDev\lib\z80_mvst.o
        C:\utils\GenDev\lib\audio.o
        C:\utils\GenDev\lib\base.o
        C:\utils\GenDev\lib\bitmap.o
        C:\utils\GenDev\lib\bitmapx.o
        C:\utils\GenDev\lib\font.o
        C:\utils\GenDev\lib\joy.o
        C:\utils\GenDev\lib\logo_lib.o
        C:\utils\GenDev\lib\maths3D.o
        C:\utils\GenDev\lib\maths.o
        C:\utils\GenDev\lib\psg.o
        C:\utils\GenDev\lib\tab_log2.o
        C:\utils\GenDev\lib\tab_pow2.o
        C:\utils\GenDev\lib\tab_sin.o
        C:\utils\GenDev\lib\timer.o
        C:\utils\GenDev\lib\tools.o
        C:\utils\GenDev\lib\vdp.o
        C:\utils\GenDev\lib\vdp_bg.o
        C:\utils\GenDev\lib\vdp_dma.o
        C:\utils\GenDev\lib\vdp_pal.o
        C:\utils\GenDev\lib\vdp_spr.o
        C:\utils\GenDev\lib\vdp_tile.o
        C:\utils\GenDev\lib\ym2612.o
        C:\utils\GenDev\lib\z80_ctrl.o
        C:\utils\GenDev\lib\z80_drv1.o
        C:\utils\GenDev\lib\z80_drv2.o
        C:\utils\GenDev\bin\libgcc.a
      Other linker options:
      • -T C:/utils/GenDev/bin/md.ld
        -nostdlib
    In the Directories tab:
    • Compiler: C:\Utils\Gendev\Include
      Linker: C:\Utils\Gendev\Lib
    In the Programs tab:
    • Compiler's installation directory: C:\utils\GenDev
      C compiler: gcc.exe
      C++ compiler: gcc.exe
      Linker for dynamic libs: ld.exe
      Linker for static libs: ld.exe
      Make program: make.exe
      Additional paths: C:\Utils\GenDev\bin
    In the "Other" tab, click in "Advanced Options":
    • Link object files to console executable (VERY IMPORTANT):
      • $linker $libs $link_objects $libdirs -o $exe_output.out $link_resobjects $link_options
        C:/utils/GenDev/bin/objcopy --pad-to 131072 -O binary $exe_output.out $exe_output
      (note that $libs comes before $link objects (so that sega.o will be the first to be linked), and that it calls the binary generation utility after linking everything)
  Create a new console application;
  Go to Project->Properties;
  • On the "Targets" tab:
    • On the "Target's build options" button, select GenDev as the compiler;
      On "output filename" put "something.md"
  Associate your favorite emulator with the ".md" extension, so that it will be executed everytime you run the project.

Phew! Well, that's it.
It's really unfortunate that the configuration importing option isn't implemented yet.

[MG]

Waow !

Thancks for theses infos.
Today I'll test them.
I will never have found all, alone

[MG]

Yop !

It's OK !
Thancks a lot.
(Lot of files in my lib must deleted, due to the Stef's update).

For the asm files, i'm using a command line under a DOS box (like usual to compile all the files).
After, I included them in the Project>Build Options>Linker>Link Libraries> and I put all the ".o" in this.

And, all is ok !
Thancks again !

Edit : I can have a compiled file, but, when I use Gens... gloups :/
Nothing on the screen :/
Bah, i can compile

[haroldoop]

I also had lots of "black" screens before figuring out how to do everything correctly.

You see, as cited above, sega.o MUST be the first object to be linked, because it contains the ROM header. If any other object is linked before it, the header gets moved to an invalid location, resulting in an invalid ROM.

That's why sega.o must be the first object in the list of objects to be linked, and that's also why it's necessary to change "Link object files to console executable" advanced option, so that the libs are linked before the project's objects, and not the reverse.

BTW, you can also tell Code::Blocks to compile and link your assembly files: Just add them to the project, right-click them, click on "Properties" and mark "Compile File" and "Link File". Worked for me.

[bastien]

i post because i need help for confugure code blocks with mini dev kit.
i will make all of instructions in the top but when i compile my code source i have this message error:
Can't find compile executable in your search patch for Megadrive C Compiler

[Stef]

I put a complete tutorial with screens shots on this topic :
http://www.spritesmind.net/_GenDev/foru ... php?p=2718

In fact i just forgot haroldoop already did it :-/
Anyway, maybe it'll be usefull for bastien

[Chilly Willy]

I put a complete tutorial with screens shots on this topic :
http://www.spritesmind.net/_GenDev/foru ... php?p=2718

In fact i just forgot haroldoop already did it :-/
Anyway, maybe it'll be usefull for bastien

Daaaayyyyamn!! That was one complete guide!

I use linux, but Fedora has Code::Blocks in the repo. I've installed it, so I think I'll try to set up the Genesis stuff like in the guide (but with linux paths and stuff).

[MG]

Thanks for the tutorial, Stef.
Good job

Edit :
Hue ?!
At office i can't install another version of code::blocks different than V1.0-RC2. grrrrrrr... because i'm working under Windows ME. :/
Therefore at office, the development for genesis is under Dev-Cpp and, at home, if i can, the development will be under code::blocks the latest version under Windows XP.

A big bouze* all these differents between all the Windows systems.

* En français dans le texte.

[Chilly Willy]

So close! I get to the very end and get this from the build logs:

m68k-elf-ld: address 0x4bc90 of bin/Release/gencube3d section .data is not within region ram

I can't find anything on it that seems to match. I spent the last DAY figuring out it wasn't compiler specific. I tried 3.4.0, 3.4.5, 4.1.0, and 4.1.1. I also tried the uClinux toolchains with the same results.

[Stef]

So close! I get to the very end and get this from the build logs:

m68k-elf-ld: address 0x4bc90 of bin/Release/gencube3d section .data is not within region ram

I can't find anything on it that seems to match. I spent the last DAY figuring out it wasn't compiler specific. I tried 3.4.0, 3.4.5, 4.1.0, and 4.1.1. I also tried the uClinux toolchains with the same results.

Generally this message comes from a bad md.ld definition file.
Are you using the last version (4 i believe) of the mini dev kit ? If yes, unfortunatly the gencube3D example is no more compatible (it can be modified though). Try with the included sample (partic or something like that) and keep me informed about your result, thanks

[Chilly Willy]

So close! I get to the very end and get this from the build logs:

m68k-elf-ld: address 0x4bc90 of bin/Release/gencube3d section .data is not within region ram

I can't find anything on it that seems to match. I spent the last DAY figuring out it wasn't compiler specific. I tried 3.4.0, 3.4.5, 4.1.0, and 4.1.1. I also tried the uClinux toolchains with the same results.

Generally this message comes from a bad md.ld definition file.
Are you using the last version (4 i believe) of the mini dev kit ? If yes, unfortunatly the gencube3D example is no more compatible (it can be modified though). Try with the included sample (partic or something like that) and keep me informed about your result, thanks

Yes, I'm using version 4. I also recompiled the .o files in case that was an issue (the ABI changes sometimes between compiler versions). I fixed the differences in gencube3D between what was there and what it is now. The reported error is the only one.

Using the partic sample that comes in the dev kit yields the same error:

m68k-elf-ld: address 0x28cbcc of bin/Debug/particle section .data is not within region ram

The only change I made to that sample was you had "#include "vangelisS.h"" when the name was capitalized (linux is case sensitive).

Given your dev kit was done for Windows based stuff, I wonder if there's a difference that needs to be accounted for in the ld file. I need to read up more on those. I found this page on the uClinux site about absolute linking. I noticed that they use --remove-section during the objcopy phase. I don't know if any of that applies here.

http://uldp.home.at/uclinux_doc_4.html

EDIT: Well, it's something about the ld file. I modified the one from the linked page and it goes through, but the rom doesn't work. Here's what I've done so far. I think I'm missing a section out of the rom part that the dev kit relies on to make the rom work. I'll keep hacking at the sections part until it breaks again, or it gets fixed.

EDIT 2: Well, the problem was the BLOCK (0x4) in the data line. Remove that and it doesn't give the error. However, the resulting bin file doesn't work. Now I have to find out why that is. A quick look shows the header to be fine (same as the bin that comes with the sample). Just a note, I'm using the original md.ld file again, with just the change made to the data section line to remove the BLOCK (0x4).

[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 ?

[Chilly Willy]

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?