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: You don't need to set any environment variables for this toolchain as long as you use the default path for the toolchain (/opt/toolchains/sega). The examples and games come with a binary image for people who wish to try them without needing to build anything.
WINDOWS USERS: NOW YOU TOO CAN JOIN IN THE FUN OR SUFFER!ORHOW TO DO ALL OF THAT ABOVE STUFF EVEN THOUGH I RUN WINDOWS The short version: Do it using MinGW. If you know what that is and how to use it, chances are you've already got the build environment set up anyways and don't need this. The long version for people who don't know what's what: Go here and click on "Download mingw-get-inst-20111118.exe (591.9 kB)" Run the installer once it finishes downloading, and select to install, at the minimum, the C compiler, the C++ compiler, the MSYS Basic system, and the MSYS Developer toolkit. Or, you can be lazy like me and just install everything. By default, it will install to C:\MinGW - it is highly advised that you leave it there. Keeps the path short. Once it is installed, open up C:\Mingw\msys\1.0 - this is your pretend /, so don't lose this location. I suggest dropping a shortcut on the desktop or in your windows 7 Favorites1. Minimize this window, we'll come back to it later. Now, on your desktop, create a folder called MD_BUILD. This is just a temporary location where we'll keep the things we downloaded. Once that's sorted, follow the instructions all the way up until the last step, but putting all the extracted files inside MD_BUILD. Then, just move the entire folder inside that minimzed window I mentioned earlier. I'd just put it right on the filesystem root, keeps the path as short as possible2. Now, Click on the "Start" menu/orb/flag and head to All Programs > MinGW > MinGW Shell, or just run "C:\MinGW\msys\1.0\msys.bat" directly. Same effect - a command window opens up inside your virtual home folder. Simply use cd to change to where you put your build files (In my case, cd /MD_BUILD) and continue with the final step. NOTE: Any time you want to actually compile with this toolchain, you will have to launch the MinGW Shell. I suppose that technically, all of the built components can be run OUTSIDE the shell, but then you'd have to also set up the path and environment variables and do all sorts of jig-pokery to get it working correctly. Since MSYS is so tiny and hard drives are so big, I don't see any harm in leaving it installed anyway. 1 Windows Vista / 7 users: With the power of an elevated command prompt , you can use mklink to allow access to your regular desktop/documents folder from inside the shell. Simply run a command prompt as administrator, cd to wherever you want to drop the link, then use mklink /D Name_of_Link "Folder Being Linked To" Example: mklink /D Documents "C:\Users\Phil\Documents" Using quotation marks to enclose the name of the target are not required unless there are spaces in the path (Ex: "Program Files"), but I always enclose the target in quotes, just as a good practice. Also, you need to enclose the Link Name in quotes if there is a space in that name as well (Ex: "My Documents"), but it's generally a bad idea to put spaces in a name when it can easily be avoided. 2 On an actual Linux/Unix filesystem, it is generally not a good idea to clutter up your root (/) with folders, simply because having write access to the filesystem root is a Bad ThingTM - But since this is windows and you already have write access to / and because it doesn't hold anything actually critical to your computer's ability to boot/run, there really isn't any reason not to keep the path short. My build environment actually has MD_BUILD on the root, along with a folder which is symlinked to a folder inside my windows User folder. I do all my editing with Programmer's Notepad, save to a folder in my favorites, and then build inside msys. Now I just have to learn how to program, lol!
ADDENDUM FOR WINDOWS USERS: I have tried compiling the toolchain, and subsequently compiling the C version of the tic-tac-toe example. If both compile correctly, "It works!" - if I cannot compile the toolchain, it just "does not compile" I have not had a situation where the toolchain compiles but the example doesn't. Anyway, results are below: Code (Text): +------------------------------------------+-----------------------------+ | OPERATING SYSTEM CONFIGURATION | RESULT | +------------------------------------------+-----------------------------+ | Windows 7 64-bit | It works! | | Windows 7 32-bit | It works! | | Windows 7 32-bit (VM) | It works! | | Windows XP (Real Machine) | Does not compile. | | Windows XP (VM) | It Works! | | Windows 98 (VM) | BSOD on compile! | +------------------------------------------+-----------------------------+ As a note, I'm not sure why it doesn't compile on my actual XP box. I blame quantum entanglement or something. I'll figure it out later. The Windows 98 VM really pisses me off because I spent the greater part of a day getting mingw and msys to run on the 98 box and just ended up seeing it BSOD when I compiled. PS: The forum really needs some sort of table tag. I was trying to make my results all neat and tidy and there's no table button.
Wow, that is a bit odd about XP on a real system not working when it does in a VM. I wonder if it's memory related... gcc takes a LOT of memory to compile itself. How much memory did each setup have?
Ah, right. Let me see. The 32-bit Windows 7 VM had 1GB of memory. The Windows XP VM had 1GB of memory. The actual Windows XP box only had 768MB The Windows 98 VM had 1GB of memory, I increased it to 2GB after the BSOD and it still BSOD-s on compile. And I no longer have access to the 32-bit Windows 7 install. I was fixing it up for a friend. Still, I want to say it had like 2GB on it. I'm not sure. For the record, the exact error I'm getting on that failed Windows XP build is: Code (Text): configure: error: in `/md_build/build-binutils-sh-elf-2.22/ld': configure: error: C++ preprocessor "/lib/cpp" fails sanity check See 'config.log' for more details. EDIT: And here's the "config.log" mentioned above.
Can't tell from the error message... if/when I get errors like that, I google on the error (in this case, something like "/lib/cpp fails sanity check" ) and it usually turns something up that leads me to the issue. I assume you set up mingw the same on both the vm and the real system?
Configure is trying to use g++.exe but it doesn't seem to exist? That's the main error that seems to appear in config.log. (g++ is the C++ compiler, by the way) EDIT: also Guess I better shut up before saying anything, there're a shitload of errors there, gotta find out which one is causing it all...
Win98 is not supposed to work with nore than 512MB of RAM without patches. There is a patch by Xeno86 that fixes problems up to 1GB, and a patch that costs money that will fix up to 4GB (and with another non free patch you can utilize memory beyond 4GB).
