Building a Genesis/32X toolchain 1 - Go here and download the following: gcc-4.5.2.tar.bz2 gcc-g++-4.5.2.tar.bz2 gcc-objc-4.5.2.tar.bz2 Decompress them all in the same folder; you should end up with one folder called gcc-4.5.2. 2.1 - Go here and download mpfr-2.4.2.tar.bz2. 2.2 - Go here and download mpc-0.8.2.tar.gz. 2.3 - Go here and download gmp-5.0.1.tar.bz2. Decompress them all in the same folder. You should have three folders called mpfr-2.4.2, mpc-0.8.2, and gmp-5.0.1. Rename them to get rid of the version numbers, leaving you with mpfr, mpc, and gmp. Copy them into the gcc-4.5.2 folder. 3 - Go here and download binutils-2.21.tar.bz2. Decompress it in the same folder as the gcc folder so that you have two folders - gcc-4.5.2 and binutils-2.21. 4 - Go here and download newlib-1.19.0.tar.gz. Decompress it in the same folder as gcc and binutils, leaving you with three folders - gcc-4.5.2, binutils-2.21, and newlib-1.19.0. 5 - Download this archive containing a makefile and several linker scripts. Decompress it to the same folder as the others above. 6 - If you wish to leave the makefile with the default path of /opt/toolchains/gen, 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-gen" - depending on the speed of your computer, you should now have two toolchains in /opt/toolchains/gen: m68k-elf and sh-elf. Make another folder in /opt/toolchains/gen called ldscripts and copy the linker scripts from the archive into that folder. You now have the latest gcc, binutils, and newlib for both the 68000 and the SH2. The 68000 only has the C compiler, while the SH2 has compilers for C, C++, Objective-C, and Objective-C++. I tried making C++ on the 68000, but libstdc++ fails to build for the 68000, so there's little need for the compiler if you don't have the standard libs. C++ on the Genesis is crazy, anyhow. EDIT: New makefile will build C++, Obj-C, and Obj-C++ for 68000 as well. 8 - Make a bin folder in /opt/toolchains/gen. Copy whatever misc tools you use into it, like sixpack or bin2c. 9 - You'll need the proper exports to use the toolchains, and assuming you left the path to /opt, they would be: For the 68000: export GENDEV=/opt/toolchains/gen export PATH=$GENDEV/m68k-elf/bin:$GENDEV/bin:$PATH For the 32X: export GENDEV=/opt/toolchains/gen export PATH=$GENDEV/sh-elf/bin:$GENDEV/m68k-elf/bin:$GENDEV/bin:$PATH Here is an archive with example code - it includes Tic-Tac-Toe in both C and C++ for both the MD and the 32X, as well as my 32X version of Yeti3D with Module playing and sound effects. Also included are the latest linker scripts to be copied to /opt/toolchains/gen/ldscripts/. MD_32X_Examples.7z EDIT: Here's updated linker scripts for the MD. These replace the current files in /opt/toolchains/gen/ldscripts/. http://www.mediafire.com/download.php?2pc35tb4bp2b1yv
If you mean why are all the gcc and related files compressed, it's because they are too big to not compress for releases. Those arcs are SOURCE TEXT... just imagine how big the finished binary would be. That's why I don't just post an arc of the finished result, but rather how to make it yourself. Uncompressed, the finished toolchain is 770MB. If you meant why are the few linker scripts and the makefile archived, it's because you need to be sure people get them in an unadulterated state. For example, I've seen people just post makefiles in code tags on forums... and they NEVER work because the forum converts the tabs to spaces (makefiles REQUIRE tabs instead of spaces for indents to work right). If you meant why is the example compressed, it's for both reasons above - to keep the size down and to make sure it comes through unchanged. If I were just posting a snippet of code, like the DMA main loop, I'd just post it in code tags. Any time I post multiple files in particular, they're going to be compressed. Besides, if you can't handle a compressed file, you certainly aren't going to be making your own toolchain from scratch, and on the flip-side, if you can make a toolchain from scratch, a compressed file or two shouldn't make you bat an eye.
If you run into trouble, just ask. Feedback helps improve the process for the next time an update is needed. The example has a binary you can try without needing to make anything. It works fine in Fusion 3.6.4, but some folks say it's a little noisy. Fusion 3.6.3 (what us linux folks have) doesn't play the sound right at all. If you use Gens/GS, you need the DMA PWM patched version (I posted about that at SonicRetro in the Gens/GS forum). That sounds the closest to real hardware. Of course, if you have an Everdrive/NeoMyth/Md-Pro/MegaCart, you can just run it on real hardware. I think the real hardware sounds the best. Probably because the real hardware has some filtering that reduces any noise that's missing in emulators. In an emulator, the sound is often too raw.
Hey, I've been looking for a new project (to fill the void of the ten that are on the back burner <_<) If I wrote a libc++ specifically for Mega Drive (which compiled to optimized assembly, etc...) would you be willing to include it?
Well, I'm not sure it's really necessary. As one other person elsewhere commented, the issue might just be the configure options... or it could be I'm using gcc-core instead of gcc (that's a problem for the ARM cross-compiler, for example). If you really want C++ on the MD, I can play around with the makefile a bit and see if I can't figure it out. I just thought it wouldn't really be desired given the lack of memory in the MD. C++ goes through ram like nobodies' business, and the MD only has 64KB, some of which must be left for the stack... which C++ also uses like water. However, if you want to make a special libc++ specifically for the MD, I'd be happy to include it. Perhaps that would make using C++ on the MD more likely than the default library. Be sure to tailor it to use rom instead of ram whenever possible. You've got a lot more rom space than ram space after all.
Yeah, that's exactly what I was thinking, not using libc++ as it is, but writing an analogous library tailored specifically for the Mega Drive. A lot of libraries could even just be interpreted to C analogues and then into code, it's really to me just making coding familiar to people who extensively use C++ elements for code Edit: Because, if you remember, the first implementation of C++ was just a preprocessor, so I suppose you could do the same here
Okay! It was just gcc-core that was the problem in building c++ for the 68000. To build c, c++, objc, and objc++ for the 68000 as well as the SH2, use the directions in the opening post, but use the gcc-4.5.2 archive instead of the gcc-core-4.5.2. You'll also need a new makefile that adds the second pass to the 68000 target. That makefile and newer linker scripts can be downloaded here. Please note that there is no c++ example yet. I need to make a crt0.s file for c++ for the MD and 32X still. Hey loco, can you suggest a decent SMALL c++ example?
Yes. Text would be fine. That would allow me to make tests for the MD and 32X... I'm just looking for something a little more than "Hello World" that actually tests the C++. C++ hello world really doesn't test the C++ - it's just regular C using the C++ print mechanism instead of the C print mechanism.
Alrighty, use this: http://pastebin.com/hTP0GG3M It has C++ printing, a sample class, string stuff, if you need more than that, ask me (also, implement that commented out line in the destructor if you want to make sure that permission violation is caught and reported instead of just happening, as that tries to delete a pointer the code didn't allocate.) Edit: That is, assuming you've implemented dynamic memory, I've heard from people before that it'd be quite pointless on the Mega Drive
Thanks! Well, the regular allocator in libc should work, even if there's virtually no memory on the MD. The linker exports the end symbol that the sbrk function uses for setting up the heap... you just won't have hardly anything to work with, depending on how much data and bss is used. What would probably be a nice example would be something like tic-tac-toe in c++... or one of those games with a few pawns on a small board. Simple graphics anything can handle with real "game play" while still remaining simple enough to serve as an example most folks can follow.
Do you have special headers for the TMS9918, or are you strictly implementing the standard libraries, because if you want graphics, then I need an interface, unless you mean like faux-graphics in text
Actually, I just did an example: Tic-Tac-Toe in C++. Look at put_str in hw_md.s for an example of string output. The archive has a binary and all the source (including an updated linker script). It doesn't work on real hardware - need to debug it more - but it works under emulation. Probably missing an align somewhere. I'll update this when I get it working on real hardware, and then work on a 32X version so folks will have a skeleton to work from on both platforms. Anyway, this gives you an example of what I mean by C++ being "big" - the game itself and all the data (font tiles mostly) is maybe 12KB... the binary is 427KB. Controls: DPAD = select square, A = choose square, C = exit The game toggles between players, both using controller 0. It's just a simple example. EDIT: Example now works on real hardware... it just needed padding. I made a couple minor improvements to the linker script as well. I use dd to pad my files - it should be part of any *nix distro, and CygWin or MinGW as well. To adjust the padding, look at the size of temp.bin after compiling, then set the block size (bs=) in the makefile to the next closest power of two. You might also wish to change the rom end field in the header in crt0.s to reflect the same size. Note that padding isn't needed for emulators; also, the rom fields in the header and the checksum don't need to be set correctly either - the program doesn't use these at all. If you were making a real cart and wished to verify it's integrity, you might add a routine to crt0.s to do a checksum over the cart using the rom fields and the checksum in the header. TicTacToe-MD-Example.7z
Ah, yeah, I see what you mean on size. I guess programmers, if they really need OOP-like layout, they can just use structs and other C facilities to pull it off.
Well, remember that a LOT of that size is going into the rom. I'm sure folks could do quite a bit with C++ on the MD... it's just going to fill more of your flash cart. That's also the standard library - a cut down library would help minimize this. But yes, C would be better for a major project as it's easier to control the resource usage. That's why my initial guide to making the toolchain didn't worry about making c++, objc, or objc++ for the 68000. But, it's nice to have the option. Other than converting the cout/cin calls to something that's useful on the MD, the game really didn't need much. It's pieced together from two or three PD tutorials off the net, plus a little of my own contributions.
Ah, alrighty, cool. Heh, I don't know many people who use Obj-C anyway, I guess you could just leave it to people to implement C++ for now if they realllly need it, I mean, they're hopefully tech savvy enough
Yeah, exactly. If you're building your own toolchain and looking at skeleton code, you should be able to handle the rest. EDIT: Added latest examples and linker scripts to the OP.
If you have not gotten the MD C++ example to work, you aren't crazy. I goofed up something in the example archive. I changed a flag for compiling the crtstuff.c file, but then "lost" the changes to the linker script to go with it. So the problem was my fault. Sorry. Here's the updated linker scripts for the MD (this wasn't an issue for the 32X). These replace the current files in /opt/toolchains/gen/ldscripts/. http://www.mediafire.com/download.php?2pc35tb4bp2b1yv
