SpritesMind.Net

Chilly Willy, Jaklub clearly defined that he uses Stef's devkit, and I said that too. If you'll look at the devkit, you'll see that we don't use assembly, the code is in sega.s from the devkit, it has all initializations and some math.

I don't know who introduced the problem, Stef or someone else (the code contains parts from Sozobon). Anyway - I was absolutely sure that the code has no problems, because it used by many people in every project based on the devkit, and I'm really glad that the problem is finally located and solved, and I don't have to change the compiler.

I guess I thought he was just using the compiler, not the support code.

Gigasoft gave the answer, i used bsr for VBlank and HBlank callback which only permit +/-32KB addressing, when your code becomes larger than 32KB this error can occurs. Replacing BSR by JSR definitly fixe the problem...

About optimisation level to use with GCC, i tried many comabinaisons with both GCC 3 and GCC 4 and -O1 generally gives the best results for 68K target... unfortunatly gCC doesn't perform well with 68K, if you need performance, you have to use ASM :-/

Stef wrote:unfortunatly gCC doesn't perform well with 68K, if you need performance, you have to use ASM :-/

Yeah, the same is true for almost anything except x86[_64].

Chilly Willy wrote:Too bad the MiNT guy doesn't keep binaries on his page for Windows. Oldly enough, he does for linux and OSX.

Hello, I'm the MiNT guy.
First, I'm very glad someone tried my Atari ST cross-compiler for building Sega Genesis binaries.

What is the problem with the binaries on my page ?
I provide binaries for Windows/Cygwin, as well as for other operating systems.
http://vincent.riviere.free.fr/soft/m68k-atari-mint/

Vincent Riviere wrote: Hello, I'm the MiNT guy.
First, I'm very glad someone tried my Atari ST cross-compiler for building Sega Genesis binaries.

It's always nice to have devs for things like this on the forum.

What is the problem with the binaries on my page ?
I provide binaries for Windows/Cygwin, as well as for other operating systems.
http://vincent.riviere.free.fr/soft/m68k-atari-mint/

Whoops! My fault... for some odd reason, I read the "Cygwin package" label as being just the patched source ready for cygwin compiling.

It turns out it's the binary for the component. Sorry if I confused anyone. Okay, that makes it easy for Windows people who wish the latest m68k gcc. So we should really put together a new devkit using this.

Don't know for others, but for me Cygwin+Windows is not easy. Stef's devkit is easy, Cygwin is not. When I've seen Cygwin in requirements, I've thought 'not an option then'. I'm pretty sure that Linux users could enjoy the MiNT, however, for me as Windows user it is not better than simply to switch to Linux (I'd prefer that instead, if I had to).

Just my personal opinion, not to offend anybody.

You don't need all of CygWin, just enough to run the toolchain, plus make. It should be fairly easy to package a minimal set of CygWin files with the binutils and gcc from MiNT along with the devkit. Just decompress and use.

Chilly Willy wrote:It's always nice to have devs for things like this on the forum.

Thanks
Originally, I was interested by GameBoy Advance toolchains, but I started to familiarize with GCC by using the Atari ST MiNT target, because I already knew the hardware and the OS.

Shiru wrote:Don't know for others, but for me Cygwin+Windows is not easy.

Cygwin is not easy. It is a complete UNIX-like environment for Windows. I use it daily, and I'm very happy with it. That's why I have built my MiNT cross-compiler for it.

However, if the goal is to integrate GCC with some other Windows tools, a port using MinGW (instead of Cygwin) would be better. Someone told me he had recompiled my cross-compiler that way. The resulting compiler does not require Cygwin for being run. But currently I prefer a full-featured Cygwin compiler.

Shiru wrote:Don't know for others, but for me Cygwin+Windows is not easy. Stef's devkit is easy, Cygwin is not. When I've seen Cygwin in requirements, I've thought 'not an option then'...

It's exactly why i built that mini devkit, i wanted to have the strict minimum requirement to get my C files to compile in M68K obj file, that's it

This probably means that someone used a BRA.W in the sega cartridge header support code and your own interrupt handler code is getting linked more than 32K away. If you can change the order in which the files are linked, this probably would go away.

But the real problem is sega.o using a branch instead of a jump.