Code::Blocks.
Moderator: BigEvilCorporation
Code::Blocks.
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...
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...
Ah ? ben si ? pourquoi pas...
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Code::Blocks.
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.MG wrote: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...
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
-
- Very interested
- Posts: 160
- Joined: Sun Apr 29, 2007 10:04 pm
- Location: Belo Horizonte, MG, Brazil
I use it too.
It took me a while to get everything to work as it should:
It's really unfortunate that the configuration importing option isn't implemented yet.
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
- -T C:/utils/GenDev/bin/md.ld
-nostdlib
- C:\utils\GenDev\lib\sega.o
- Compiler: C:\Utils\Gendev\Include
Linker: C:\Utils\Gendev\Lib
- 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
- 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
- $linker $libs $link_objects $libdirs -o $exe_output.out $link_resobjects $link_options
- Link libraries (sega.o MUST be the first object to be linked!):
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"
- On the "Target's build options" button, select GenDev as the compiler;
- Select GNU GCC Compiler;
It's really unfortunate that the configuration importing option isn't implemented yet.
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
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
Ah ? ben si ? pourquoi pas...
-
- Very interested
- Posts: 160
- Joined: Sun Apr 29, 2007 10:04 pm
- Location: Belo Horizonte, MG, Brazil
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.
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.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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
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
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Daaaayyyyamn!! That was one complete guide!Stef wrote: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
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).
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.
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.
Ah ? ben si ? pourquoi pas...
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
So close! I get to the very end and get this from the build logs:
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.m68k-elf-ld: address 0x4bc90 of bin/Release/gencube3d section .data is not within region ram
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Generally this message comes from a bad md.ld definition file.Chilly Willy wrote:So close! I get to the very end and get this from the build logs:
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.m68k-elf-ld: address 0x4bc90 of bin/Release/gencube3d section .data is not within region ram
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
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.Stef wrote:Generally this message comes from a bad md.ld definition file.Chilly Willy wrote:So close! I get to the very end and get this from the build logs:
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.m68k-elf-ld: address 0x4bc90 of bin/Release/gencube3d section .data is not within region ram
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
Using the partic sample that comes in the dev kit yields the same error:
The only change I made to that sample was you had "#include "vangelisS.h"" when the name was capitalized (linux is case sensitive).m68k-elf-ld: address 0x28cbcc of bin/Debug/particle section .data is not within region ram
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).
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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 ?
What version of GCC are you using ? I guess you need to replace all the binary and the libc file with your linux version ?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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).Stef wrote: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 ?
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?