Time to update to gcc 4.6.2

Chilly Willy · Post by **Chilly Willy** » Mon Feb 13, 2012 4:14 am

Building a Genesis/32X toolchain

1 - Go here and download the following:

gcc-4.6.2.tar.bz2

Decompress it to wherever you keep your projects; you should end up with a folder called gcc-4.6.2.

2.1 - Go here and download mpfr-2.4.2.tar.bz2.
2.2 - Go here and download mpc-0.9.tar.gz.
2.3 - Go here and download gmp-5.0.4.tar.bz2.

Decompress them all in the same folder. You should have three folders called mpfr-2.4.2, mpc-0.9, and gmp-5.0.4. Rename them to get rid of the version numbers, leaving you with mpfr, mpc, and gmp. Copy them into the gcc-4.6.2 folder.

3 - Go here and download binutils-2.22.tar.bz2.

Decompress it in the same folder as the gcc folder so that you have two folders - gcc-4.6.2 and binutils-2.22.

4 - Go here and download newlib-1.20.0.tar.gz.

Decompress it in the same folder as gcc and binutils, leaving you with the folders - gcc-4.6.2, binutils-2.22, and newlib-1.20.0.

5 - Get this archive and decompress it to the same place as the previous directories. You should have two more directories, bin and ldscripts, in addition to the file, makefile-sega.

6 - If you wish to leave the makefile with the default path of /opt/toolchains/sega, make sure you have permission to write to /opt or the toolchain will fail to install to the path. Since there's nothing critical in /opt, it's easiest just to do "sudo chmod 777 -R /opt" which allows anyone to do anything they want in /opt.

7 - Run "make -f makefile-sega" - depending on the speed of your computer, in an hour or two you should have two toolchains in /opt/toolchains/sega: m68k-elf and sh-elf. Copy the ldscripts and bin directories to /opt/toolchains/sega.

You now have the latest gcc, binutils, and newlib for both the 68000 and the SH2. Both have compilers for C, C++, Objective-C, and Objective-C++. The bin directory has a few common tools one might use for compiling Z80 code for the MD. Copy whatever other tools you use into it, like sixpack or bin2c.

Note: The size of the built toolchain can be reduced by stripping the debug symbols from the executables in the bin directories, and by deleting the libraries meant for CPUs other than the 68000 and SH2. For example, you don't need the libraries for the 68020 or 68040 or SH3 or SH4, etc.

Here is an archive with example code - it includes Tic-Tac-Toe in both C and C++ for both the MD and the 32X. You should be able to compile them with the toolchain you just built. They should run on an emulator like Kega Fusion or Gens/GS, or on a real MD/32X with a flash cart.

Here are a few archives of things I've built for the 32X using the toolchain. They should all build and run fine using this toolchain.
32xrick-20120212.7z
Wolf32X-20120212.7z
TremorTest-20120212.7z
yeti3d-20120212.7z

Here is an archive with three libraries. You will need them for the Tremor example. Build them BEFORE trying to build the Tremor test. Be sure to run "make install" to install the libraries into the toolchain so it can find them.

Note: Not only is this version of the toolchain newer, but the examples and games have been updated so you no longer need to set any environment variables or paths as long as you use the default toolchain path (/opt/toolchains/sega). So it's easier than ever to compile using my projects as a template. Note that the projects themselves are not updated beyond changes to the makefiles and crt0 files for the new build layout. All the examples and games include a binary rom image for quick testing for folks who wish to try them without needing to build anything.

EDIT: New link for three libraries archive.

etoD · Post by **etoD** » Sun Feb 26, 2012 2:54 pm

Thanks for this, it was really helpful.
For an archive which has everything up to step 5 completed:
http://projects.earthshine.it/sega/sega-builddir.tar.gz (135MB)
Then all you will need to do is extract this somewhere, and proceed from step 6.

CW, if you want somewhere to host those demos and other stuff, I can give you a few hundred MB on my server if you like, just to avoid the demon mediafire...

Chilly Willy · Post by **Chilly Willy** » Sun Feb 26, 2012 6:38 pm

Well, I'll hang on to the mediafire and fileden in any case, but I don't mind having some other places for big things like this.

Did you strip out the libraries for CPUs other than the 68000 and SH2? That helps bring the size down considerably. You might also try a few other compressors to see which does the best job for what's left. No reason to make people download more than needed.

sega16 · Post by **sega16** » Sun Feb 26, 2012 11:09 pm

Try 7-zip that does way better than alot of other programs and to makes things even better it is open source http://www.7-zip.org/

Chilly Willy · Post by **Chilly Willy** » Sun Feb 26, 2012 11:34 pm

sega16 wrote:Try 7-zip that does way better than alot of other programs and to makes things even better it is open source http://www.7-zip.org/

Yeah, 7-zip is definitely a leader for best general compressor around. You may have noticed that my archives in the OP are 7-zipped. There's a nice Windows version, and every linux distro has 7-zip in their repository for easy installation. I'm certain there's a nice OSX version as well. You see quite a bit more 7-zip in the last five years than before. Even many comic scanslators use 7-zip now, and at least a couple comic readers allow for 7-zip arcs as well as rar and zip. Most emulators for the PC (linux/Windows/OSX) accept 7-zipped rom images.

etoD · Post by **etoD** » Mon Feb 27, 2012 12:24 pm

Yeah, good idea I guess! I haven't stripped any files from the source code because I don't know anything about the various programs' codebase/where to begin with it. I'll see what size it comes out with 7zip and repost a link in this post.
Also if you chose a username I'll set up some space for you - doing my bit to help :p
BTW whilst we're here, haha.. what's the most up to date emu for both Linux and Windows in terms of accuracy, latest undocumented features implemented etc...?

Chilly Willy · Post by **Chilly Willy** » Mon Feb 27, 2012 6:20 pm

For a user name, you can just use something like "chillywilly".

I use Fusion 3.63x, and Gens/GS r7 with my DMA PWM modification. In Windows, you would use Fusion 3.64.

I'm not aware of any emulator yet supporting the CD mode 1 in 32X mode. I had to get that working completely on real hardware via flash cart. Fusion supports mode 1 in MD mode.

djcouchycouch · Post by **djcouchycouch** » Tue Feb 28, 2012 2:43 pm

I'm sorry for the basic question, but does this have to do with updating the GCC used in the SGDK? Or is this a totally different thing?

Thanks!
DJCC.

Chilly Willy · Post by **Chilly Willy** » Tue Feb 28, 2012 6:15 pm

djcouchycouch wrote:I'm sorry for the basic question, but does this have to do with updating the GCC used in the SGDK? Or is this a totally different thing?

Thanks!
DJCC.

Sort of different - this gcc could be used in place of the one in sgdk, but it's not specifically aimed at that. It's just my toolchain, and I don't normally use the sgdk.

M-374 LX · Post by **M-374 LX** » Sun Apr 01, 2012 2:44 am

I have GCC 4.7.0.

When attempting to compile a program, I got the following warning:

Code: Select all

cannot find entry symbol _start; defaulting to 80000080

Additionally, the program (which I have compiled with SGCC before) did not work.

How can I correct it?

Chilly Willy · Post by **Chilly Willy** » Sun Apr 01, 2012 8:05 pm

MD and 32X roms start based on a specific set of headers at the start of the rom, not from the start of the file or any __start vector. It's meaningless on the MD/32X and can be safely ignored. You can stick a __start label anywhere to suppress the warning if you feel like it... maybe at the start of the code in crt0.s.

As to the program not working, I can't say as I have neither your source nor any idea how you changed it to work with my toolchain. I imagine you forgot something, or maybe messed up the link order. Remember that wherever the rom header is, that MUST BE FIRST in the link order. When in doubt, use a hexeditor on the binary to check that everything got placed at the correct location in the file.

M-374 LX · Post by **M-374 LX** » Sun Apr 01, 2012 10:25 pm

After adding the label "_start" to the beginning of the startup code and making it global, the program worked partially.

The program should show a tile map and generate a PSG frequency, but it did not show the tile map.

The VDP debug tool available in the emulator showed that the color were properly set, but no tiles were loaded.

Here is the code of the functions related to the VDP:

Code: Select all

void load_tiles()
{
    register ulong *pl;
    register uint x;

    pl = (ulong *) GFXCNTL;
    *pl = GFX_WRITE_ADDR(0);

    pl = (ulong *) GFXDATA;
	
    for (x=0; x<8*2; x++) /* 8 (height of the tiles) * 2 (number of tiles) */
        *pl = tiledata[x];
}

void set_colors()
{
    register ulong *pl;
    register uint *pw;

    pl = (ulong *) GFXCNTL;
    *pl = GFX_COLOR_WRITE_ADDR(0);

    pw = (uint *) GFXDATA;
    *pw = 0;		/* color 0 - background */
    *pw = 0x0888;	/* color 1 - dark grey */
    *pw = 0x0CCC;	/* color 2 - light grey */
}

void load_map()
{
    register ulong *pl;
    register uint *pw;
    register uint x;

    pl = (ulong *) GFXCNTL;
    *pl = GFX_WRITE_ADDR(PLANE_ADDR);

    pw = (uint *) GFXDATA;
    for (x = 0; x < 32*28; x++)
        *pw = map[x];
}

I used the startup code from Kaneda's home page.

What could be wrong here?

Chilly Willy · Post by **Chilly Willy** » Mon Apr 02, 2012 2:10 am

The pointers need to be volatile. For example

volatile ulong *p1;

Without the volatile, consecutive stores/loads through the pointer won't be actually stored. Another issue I have run into a LOT is any C code directly accessing hardware should be compiled at no more than -O1 or it fails in odd ways. I've just gotten into the habit of using -O1 for hardware related files. I've verified this issue on MIPS, SH2, and M68K gcc. x86 doesn't have that problem - volatile alone is enough. Not sure about ARM.

M-374 LX · Post by **M-374 LX** » Mon Apr 02, 2012 11:56 am

Making the pointers volatile did not work.

By writing:

Code: Select all

    volatile ulong *pl;

    pl = (ulong *) GFXCNTL;
    *pl = GFX_WRITE_ADDR(0);

    pl = (ulong *) GFXDATA;
	
    *pl = 0x00000000;
    *pl = 0x00000000;
    *pl = 0x00000000;
    *pl = 0x00000000;
    *pl = 0x00000000;
    *pl = 0x00000000;
    *pl = 0x00000000;
    *pl = 0x00000000;

    *pl = 0x22222222;
    *pl = 0x11121111;
    *pl = 0x11121111;
    *pl = 0x11121111;
    *pl = 0x22222222;
    *pl = 0x11111112;
    *pl = 0x11111112;
    *pl = 0x11111112;

I got (in the VRAM) the tile shown in the left side of the image, while expecting the other one:

Chilly Willy · Post by **Chilly Willy** » Mon Apr 02, 2012 5:26 pm

Is the advance reg set to 2 like it should be?