My current devkit for MD/CD/32X

[Chilly Willy]

I'm posting an arc of the source needed to build my latest toolchain, along with a few examples. All the needed code is included together with a makefile to build everything at once. The toolchain is comprised of

gcc 12.1.0​

binutils 2.38​

newlib 4.2.0​

zasm 4.4​

Those are all the latest releases. To build, make sure your /opt folder can be written by your user. Download this archive and decompress into a folder; note that the file is over 100 MB, compressed with 7zip. In a terminal, cd to the directory you decompressed everything to, then enter 'make'. It will create the toolchain's directory (if need be) and then the sega directory inside that. It will then build c and c++ compilers for SH2 and 68000, using newlib for the standard c libraries. It will then create a bin directory in toolchains/sega, build zasm, and copy it into that bin directory. It will then copy the bootblocks and ldscripts directories into toolchains/sega. Once it's done, you can clean up the build folder by running 'make clean'. Note that the examples aren't copied into the toolchain.

Once the toolchain is done, you can build the examples to check that everything is working. I included my Yeti3D example, and the C/C++ TicTacToe examples for MD and 32X. All were tested on my system under Xubuntu 20.04 and work fine on real hardware and Fusion 3.64. I've also been building Doom 32X Resurrection and OpenLara with this for more than a month without issue, so it should be safe to update if you're using one of my older toolchains. Note that zasm 4.x introduced some changes - you need to change the makefile targeting the z80 like this

ASMZ80 = $(ROOTDIR)/bin/zasm
FLAGSZ80 = -bv2

and the first couple lines of the z80 source file like this

#target ram
#code SRAM, $0000, $2000

 

[vbt]

I'm posting an arc of the source needed to build my latest toolchain, along with a few examples. All the needed code is included together with a makefile to build everything at once. The toolchain is comprised of

gcc 12.1.0​

binutils 2.38​

newlib 4.2.0​

zasm 4.4​

Thanks @Chilly Willy, how good is GCC 12.1 for SH2 ? GCC team is so fast, so they already released 12.2:///

 

[Chilly Willy]

The gcc crew has been applying the whip on their teams for the last decade it seems like. I'll have to check if 12.2 fixes anything important, like a bad regression or the like.

As for how good it is... to tell the truth, I haven't seen a big change since lto was finalized. I have no idea why they keep bumping the major version number when most updates tend to be obscure and minor bug fixes. That seemed to be a trend that came up in the last decade - constantly bumping the major version number to make it SEEM like major progress is being made. Everyone does it, so you have to as well. Remember how slow the major version number of web browsers advanced? And now I'm using FireFox v103.0, Seriously, the version number is now the revision number, the revision number is now the build number, and the build number now follows individual commits.

 

[dibz]

The gcc crew has been applying the whip on their teams for the last decade it seems like. I'll have to check if 12.2 fixes anything important, like a bad regression or the like.

As for how good it is... to tell the truth, I haven't seen a big change since lto was finalized. I have no idea why they keep bumping the major version number when most updates tend to be obscure and minor bug fixes. That seemed to be a trend that came up in the last decade - constantly bumping the major version number to make it SEEM like major progress is being made. Everyone does it, so you have to as well. Remember how slow the major version number of web browsers advanced? And now I'm using FireFox v103.0, Seriously, the version number is now the revision number, the revision number is now the build number, and the build number now follows individual commits.

Maybe they're using Semver versioning? If that's the case, the major version bumps could imply they changed something that could break something.

 

[Chilly Willy]

The gcc folk are good about making sure that breaks in compatibility are widely known and discussed well ahead of time. Things like dropping a processor from the collection will take more than a year before they do it (if they decide to actually go through with it). When they removed COFF support from gcc, it was actually years from when it was first announced until it actually occurred. Ditto for the move from a.out to ELF. Most of the serious regressions aren't known until the release goes live as multitudes start using the new code, and they're good about making and maintaining a list of known regressions and other issues for each release. Given that, I don't think the version numbering is an indicator of potential breaks. Like many other large projects, the major version seems to be more an indication of WHEN a release occurs rather than what is in it. Ubuntu even went so far as to make the version/revision of their releases the actual date of the release. I admit that's actually pretty handy for the OS - you know just how old your OS is at any time, and how old another release is in comparison.

 

[LG30]

Hello and congratulations for your work and your tools.
I would like to know if you have at your disposal an encoder for SGA video files.
Thank you for your answer.

 

[Chilly Willy]

I just have the old disassemblies of the cinepak driver for the SCD. I also have Vic's code he did for playing RoQ video files on the 32X. You can get that at his repo. Anything else, you'd need to contact the authors.