Cygwin and code::blocks. A dream becomes reality.

pnpbios · Post by **pnpbios** » Mon Dec 19, 2005 1:44 am

Yes, after long last, I have finaly integrated code::blocks with everybody's favorite dreamcast environment. I will post final instructions on it later today, but let's just say, it wasn't easy.

LyingWake · Post by **LyingWake** » Mon Dec 19, 2005 1:58 am

Good work. I'll try it out once you get the instructions up.

pnpbios · Post by **pnpbios** » Mon Dec 19, 2005 10:41 am

OK, here are the step by step instructions to building your own code::blocks setup. This tutorial assumes no responsibility for broken or dammaged development environments. This tutorial also assumes you are using the Dreamcast Development CD, revision R1 or R2.

Also, this has only been attempted with C projects using sh-elf-gcc. I will try to come up with a way to get C++ working in the future. This may be solveable by creating a copy of this compiler and adding the appropriate flags.

If you are using R2, Code::Blocks comes on the CD, otherwise you are going to have to download that seperately.

Once installed, we must now setup the compiler. Go to the menu bar and go settings->compiler. This will bring you to the menu we will be working with. Next, under compilers listed at the top, go down until you find GNU GCC compiler. Hit the copy button, then rename it to something that matches your tastes. I set mine as the default, but you don't have to.

Under the first tab (comipler), select the second sub tab (other options), and add the folowing lines.

Code: Select all

-O2 -DFRAME_POINTERS -ml -m4-single-only
-fno-optimize-sibling-calls

Under the third sub tab (#defines), add these lines. I'm not totaly sure why this works, and I don't remember adding them this way, but they were there when I opened code::blocks this morning, so oh well. It just works this way, trust me.

Code: Select all

_arch_dreamcast -D_arch_sub_pristine -Wall
_arch_dreamcast -D_arch_sub_pristine -Wall -g -fno-builtin -fno-strict-aliasing

Go to the second primary tab labled Linker. Add the folowing lines to the Other Options box.

Code: Select all

-g -fno-builtin -fno-strict-aliasing  -ml -m4-single-only -Wl,-Ttext=0x8c010000
-nostartfiles -nostdlib
C:\cygwin\usr\local\dc\kos\kos\kernel\arch\dreamcast\kernel\startup.o
-Wl,--start-group -lkallisti -lc -lgcc -Wl,--end-group

Again, it is realy important that your directories match mine. Your program will not link properly without startup.o. Unlike with DCFreeDev, you don't have to copy startup.o to your project folder.

Next comes the directories main tab. Under the first sub tab, compiler, add the following directories.

Code: Select all

C:\cygwin\usr\local\dc\kos\kos-ports\include
C:\cygwin\usr\local\dc\kos\kos\include
C:\cygwin\usr\local\dc\kos\kos\kernel\arch\dreamcast\include
C:\cygwin\usr\local\dc\kos\kos\addons\include

under the second tab, linker, add these.

Code: Select all

C:\cygwin\usr\local\dc\kos\kos\lib\dreamcast
C:\cygwin\usr\local\dc\kos\kos\addons\lib\dreamcast

Alrighty, next, the programs tab!
Set your base directory to this.

Code: Select all

C:\cygwin\usr\local\dc\sh-elf

Now, we setup the programs.

Code: Select all

C compiler:     sh-elf-gcc.exe
C++ compiler:     sh-elf-g++.exe
Dynamic Linker:     sh-elf-g++.exe
Static Linker:     sh-elf-ar.exe

leave debugger, resource compiler, and make alone. We don't need them.
Under aditional paths, add this.

Code: Select all

C:\cygwin\bin

That's it. Now you are done setting up the compiler! To make sure it works, try creating a project.

Go File->New Poroject. Make a new Console program, but make sure to set it as a C project. (haven't figured out C++ yet). Also, set it so it doesn't add any files to the project.

Go Projects->properties. Click Project build options and make sure that you have your new compiler selected. Next, click on the targets tab, and change your output file name extension to .elf, instead of .exe.

Now, at this point, you have a prety good template setup for future projects, at this time, you could save it as a template under Projects->Save as User Template. I'll leave that up to you.

Add a new C source file to the project, and for a sample, this works prety well.

Code: Select all

#include <kos.h>

int main(int argc, char **argv) {
	int x, y;

	/* Bother us with output only if something died */
	dbglog_set_level(DBG_DEAD);

	/* Set the video mode */
	vid_set_mode(DM_640x480, PM_RGB565);

	for (y=0; y<480; y++)
		for (x=0; x<640; x++) {
			int c = (x ^ y) & 255;
			vram_s[y*640+x] = ((c >> 3) << 12)
				| ((c >> 2) << 5)
				| ((c >> 3) << 0);
		}

	/* Pause to see the results */
	while(1);
	usleep(5*1000*1000);

	return 0;
}

The way the compiler is setup right now, it links to the default libraries, lkallisti and lgcc, and so on. To link to other ones, go Project->Build options, and add them from there. You won't see all the changes we made, because code::blocks hides them from the user unless explicitly changed. As long as the compiler is set to the one you made, no problems.

One last thing, don't try executing, When I want to compile, I usualy just hit the rebuild button.

Happy coding, and let me know if you run into any issues!

Strapping Scherzo · Post by **Strapping Scherzo** » Mon Dec 19, 2005 12:56 pm

What I would like to see is code::blocks setup so it also supports the new debugging support with dc-load 1.0.4 and the BBA. code::blocks has nice debugging features.

pnpbios · Post by **pnpbios** » Mon Dec 19, 2005 1:17 pm

Strapping Scherzo wrote:What I would like to see is code::blocks setup so it also supports the new debugging support with dc-load 1.0.4 and the BBA. code::blocks has nice debugging features.

Send me a broadband addaptor, and I'll see what I can do.

LyingWake · Post by **LyingWake** » Mon Dec 19, 2005 4:56 pm

I'd like to see this to be an alternative to the ISO - not attached to it.

You should group everything together that is needed and put all of it in a simple installer (something like Nullsoft). Have it labeled something like "Code::Blocks DC Dev Environ" and that way, the user can install Code::Blocks, and if they want to, they can download your installer, install it over Code::Blocks, then make the necessary changes inside Code::Blocks.

That way, they dont need to install my Dev ISO if they don't want to.

If you'd like, I'll be glad to help you if it's needed.

EDIT: Also, R1 of the ISOs directory for kos is a little different. Instead of /usr/local/dc/kos like how R2 is, R1's structure is /usr/local/dc/kos1.3.

EDIT2: Another concern - the Code::Blocks that comes on the R2 ISO does not have the compiler with it. It is just the bare text editor - does this matter?

pnpbios · Post by **pnpbios** » Mon Dec 19, 2005 6:53 pm

No, the compiler does not matter. It's being setup to use the dreamcast cygwin one.
I was thinking a self contained package would be nice too. Now that I have my proof of concept completed, i'm a few steps closer.

My big beef with code::blocks is that the export/import settings function is broke, and i'm not sure what I would be able to hack my own thing of it together. I'll play around with it later tonight and see if i'm missing anything.

Thanks for the responses, has anybody tried this yet?

pnpbios · Post by **pnpbios** » Tue Dec 20, 2005 11:39 am

Alright, I figured out a hack to import and export compiler settings for code::blocks. The thing is, it's just a hack for now, because in the next version they are switching to an xml based settings configuration. As soon as I can get the exported regfile uploaded, I'll post it here.

edit: a link to the regfile
http://mavdisk.mnsu.edu/longaj/dcdev/cbreg.zip

somebody try this and tell me if it works.

pnpbios · Post by **pnpbios** » Wed Dec 21, 2005 1:02 pm

Ok, I tried the registry hack on another machine, and it works perfectly. Ladies and Gentlemen, we have a working setup. The only problem right now is that it will overwrite your old compiler settings if you have another custom compiler installed. I'll see what I can do to fix this.

Humanoid · Post by **Humanoid** » Thu Dec 22, 2005 4:46 pm

Thanks PNP! After learning that the DC had an SDL port, I always wanted to start dev work for it, but I never got motivated enough to actually set up a dev environment. Luckily, I saw your instructions, and they work perfectly! I only have one problem after compiling your example, and its probably unrelated to the actual dev setup. When I try to convert the ELF file to a BIN using Elf2bin, it creates a bin with a size of 0kb. Can someone haelp me with this?

(Sorry for the mild derail!)

EDIT: Forgot to mention that the ELF actually HAS size, 893kb to be exact.

LyingWake · Post by **LyingWake** » Thu Dec 22, 2005 4:56 pm

I recommend using 1st_read.bin file checker to convert the ELF to a BIN, or simply use the .R -stack switch with sh-obj-elf.exe

Humanoid · Post by **Humanoid** » Thu Dec 22, 2005 4:59 pm

Thanks LyingWake, it worked! I look forward to porting my tilemap engine now

pnpbios · Post by **pnpbios** » Thu Dec 22, 2005 7:21 pm

Well, I'm glad it worked. I figured out a solution that seems to work with C++ anyways, I'll post that when I get a good chance.

Post by **Quzar** » Thu Dec 22, 2005 7:34 pm

Have you tested reading from /pc/ yet?

pnpbios · Post by **pnpbios** » Thu Dec 22, 2005 7:55 pm

No, I haven't. Should it be any different? I do something a little differently. I run mkisofs on whatever directory I want to be my disc image, and mount that over DC-TOOL. This saves me a huge ammount of pain when I will go to convert my code from test to produciton.

ATani · Post by **ATani** » Sun Jan 01, 2006 2:14 am

On linux you can create a copy of the GCC compiler settings and then set the compiler programs to use the kos gnu_wrapper scripts. No fussing with the compiler/link settings at all!

Basically copy GCC, rename to something useful (KOS), go to programs tab, set root dir to kos/utils/gnu_wrappers, set programs to: kos-cc, kos-c++, kos-c++, kos-ar

go into the gnu_wrappers directory, create a symlink called "bin" pointing to the gnu_wrappers dir:
"ln -s . bin"

The only requirement is that you have your environ.sh script executed before starting the wrapper scripts.

If you want to get romdisk support you can add the commands to the pre-build step in your project build options and then add romdisk.o to the linker extra args section.

pnpbios · Post by **pnpbios** » Sun Jan 01, 2006 8:52 am

ATani wrote:On linux you can create a copy of the GCC compiler settings and then set the compiler programs to use the kos gnu_wrapper scripts. No fussing with the compiler/link settings at all!
.....

The only requirement is that you have your environ.sh script executed before starting the wrapper scripts.

This has what to do with setting it up under an IDE? I'm sorry, but I'm not sure why you came here to post that...

Here is the C++ version I promised. It will overwrite your previous settings, so you will loose your pure C compiler. Change your project files and file extensions as required

http://mavdisk.mnsu.edu/longaj/dcdev/dccpp.zip

ATani · Post by **ATani** » Sun Jan 01, 2006 2:12 pm

pnpbios wrote: This has what to do with setting it up under an IDE? I'm sorry, but I'm not sure why you came here to post that...

I will take that with a very large grain of salt... The reason why I posted that in this thread is because this thread started out with configuring code::blocks to work for DC development.

My post was to provide an alternative to your instructions, which IMHO are much simpler and are more maintainable since you do not have to disable non DC compilation.

BlackAura · Post by **BlackAura** » Sun Jan 01, 2006 8:20 pm

pnpbios wrote:This has what to do with setting it up under an IDE? I'm sorry, but I'm not sure why you came here to post that...

Because it gives people a nice little hint about how to get it working with the Linux version of Code::Blocks (which I just did). Instead of mucking around with various command-line flags, you can just point Code::Blocks to the wrapper scripts provided in kos/utils/gnu_wrappers, which take care of calling the real compilers with the appropriate parameters. The rest of the setup (adding the include directories and so on) is pretty much the same, although not required for the compiler to function. It is required for the IDE to find the include and library files, of course. It (should) also work correctly with C++, and C/C++ mixed projects.

I don't know if this is present in the Windows version of Code::Blocks, but in the Linux version under Settings->Compiler, in the Other tab, there's an option labelled "Shell to run console programs". That can be set up to run your app through DCLoad by specifying DCLoad instead of a terminal app.

ATani · Post by **ATani** » Sun Jan 01, 2006 8:29 pm

BlackAura wrote:I don't know if this is present in the Windows version of Code::Blocks, but in the Linux version under Settings->Compiler, in the Other tab, there's an option labelled "Shell to run console programs". That can be set up to run your app through DCLoad by specifying DCLoad instead of a terminal app.

That is an option I somehow overlooked... Cool tip

One more tip, you should be able to setup gdb to work with dcload by using the gdb plugin configuration dialog to add "target remote :2159". I have not tried this yet but it should work.

Mike