Sega Genesis Dev Kit (SGDK)

SGDK only sub forum

Moderator: Stef

Post Reply
8bitwizard
Very interested
Posts: 159
Joined: Sat Feb 24, 2007 11:35 pm
Location: San Antonio, TX

Post by 8bitwizard » Fri May 09, 2008 2:23 am

Sik wrote:It's an issue with all compilers. They expect the values to be initialized before calling main().
It's all in how you set up the linkage. For a binary that loads into an operating system, you want the initialized segment to load right into memory along with the code.

For ROM code, you need two things:

1) a section which takes the values of the initialized segment but goes into ROM. Note that it should be referenced in the code by the RAM address, which will be different from the ROM address. With GCC, this is done by properly setting up the linker file. (don't ask me how, I won't know until I figure out how to do it, and I'm not trying right now)

2) a routine called at startup (before main is called) to copy the initialized segment into RAM

Or you could just forget about initialized globals and write your code not to use them. Except that then you'll have a problem with pre-initialized arrays, which are very nice to have. I think you can declare them "const" and they'll go into a read-only segment (which means ROM), but of course you have to remember to use "const" every time.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Fri May 09, 2008 10:18 pm

Shiru wrote:
Stef wrote:I realised i never replied your last post.
I think the 32 bits modulo operation is buggy, i guess you're doing it on 32 bits sized variable ? I rarely use modulo but i never meet any problem with division. I'll check the 32 bits modulo code in sega.s file, maybe a stupid bug.
I did some tests today.

I downloaded and setup kit (only changed path where needed) once again to make sure that nothing broken after my previous try. I made only one change in sega.s - replaced line 132 from 'jmp start' to 'jmp main' (I don't use kit libs, like I said).

I made small program which changes palette randomly in loop (to see if program hangs). When I added some test lines in code.

First, I tried unsigned short variable. It have some value on start (i tried different initial values).

If I do operations:

i=(i+1)%10; //hangs

i++;
i%=10; //works

i=(i+1)/10; //hangs too

i++;
i/=10; //works

Then I tried unsigned long variable. Things even worse:

i%=10; //hangs
i/=10; //hangs

I also tried signed int and long, tried to declare variable inside 'main' or as global variable. Results are same.

So, if I did nothing wrong, it means that there is serious problems with kit.
I did all your tests and all of them work perfectly for me... yours problems are too serious and my library would never work if i had the sames bugs.
I did some code tracing on division and modulo part. I noticed the code executed isn't the one contained in the sega.s file as i always though ! It looks the same but it is *not exactly* the same.

How you're using the kit ? I mean, are you using you own makefile ? different compilation flags ?
Normally the kit should use libgcc. I believe the division / modulo code is taken from libgcc which is hopefully correct. In your case, and for some reason, i believe it directly uses the sega.s code which is wrong. You can use the -S flag to GCC and get the assembly listing, then you can confirm or not you're running on sega.s code.

Have you severals GCC setup on your computer ? sometime GCC configurations can conflict...

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Fri May 09, 2008 10:23 pm

8bitwizard wrote:
Sik wrote:It's an issue with all compilers. They expect the values to be initialized before calling main().
It's all in how you set up the linkage. For a binary that loads into an operating system, you want the initialized segment to load right into memory along with the code.

For ROM code, you need two things:

1) a section which takes the values of the initialized segment but goes into ROM. Note that it should be referenced in the code by the RAM address, which will be different from the ROM address. With GCC, this is done by properly setting up the linker file. (don't ask me how, I won't know until I figure out how to do it, and I'm not trying right now)

2) a routine called at startup (before main is called) to copy the initialized segment into RAM

Or you could just forget about initialized globals and write your code not to use them. Except that then you'll have a problem with pre-initialized arrays, which are very nice to have. I think you can declare them "const" and they'll go into a read-only segment (which means ROM), but of course you have to remember to use "const" every time.
I already tried to fix the devkit and get "initialised variables" to work (we already had a talk on that point i believe) but i failed :-/ I didn't spent many time as hopefully initialised variables are not "a must", you can always avoid them.

Shiru
Very interested
Posts: 786
Joined: Sat Apr 07, 2007 3:11 am
Location: Russia, Moscow
Contact:

Post by Shiru » Sat May 10, 2008 1:49 am

Stef wrote:I did all your tests and all of them work perfectly for me... yours problems are too serious and my library would never work if i had the sames bugs.
I suppose so after I noticed problem with division.
Stef wrote:I did some code tracing on division and modulo part. I noticed the code executed isn't the one contained in the sega.s file as i always though ! It looks the same but it is *not exactly* the same.
I just tried to completely delete division/module code from sega.s. No compilation errors and all works same, with same problems.
Stef wrote:How you're using the kit ? I mean, are you using you own makefile ? different compilation flags ?
I only removed all unneeded kit objs from makefile.gen:

LINKOBJ= sega.o \
$(OBJ)

(modified sega.s is in my folder)

All flags are same, but I also changed:

INCS= -I\

or

INCS= -I [full path to project folder]

Otherwise project compiles without any errors, but completely does not works (program not even starts).
Stef wrote:Have you severals GCC setup on your computer ? sometime GCC configurations can conflict...
Yes, I have many gcc setups. When I tried to install kit for very first time, I had conflicts with Symbian kit, but solved it. At least all other setups works without problems, and SMD projects compiles (and works somehow) too.

Anyway, at least I now know that it just my local problems, that's good.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat May 10, 2008 6:26 am

Your problem sounds like the one I had when I first set up gcc for 68000 on my linux box. It would crash when trying the examples in the devkit. My problem was that the gcc toolchain I was using defaulted to using libgcc for the ColdFire 52xx. Once I copied the 68000 libgcc into the libs directory, everything worked perfectly. So double-check that the libgcc you're using is indeed the 68000 libgcc.

Shiru
Very interested
Posts: 786
Joined: Sat Apr 07, 2007 3:11 am
Location: Russia, Moscow
Contact:

Post by Shiru » Sat May 10, 2008 7:03 am

I tried to specify full path to right libgcc.a, does not help.

Strange thing, if I remove both math code from sega.s and reference to libgcc.a from makefile.gen (and even delete libgcc.a file), nothing changes - project compiles successfully and works with same problems.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sat May 10, 2008 3:11 pm

Shiru wrote:I tried to specify full path to right libgcc.a, does not help.

Strange thing, if I remove both math code from sega.s and reference to libgcc.a from makefile.gen (and even delete libgcc.a file), nothing changes - project compiles successfully and works with same problems.
That's definitly not normal, the math code for division should exists as 68000 doesn't have native support of 32 bits divisions not multiplications.
Normally the code is taken from libgcc but the -nostdlib flag prevent it (theorically as here it doesn't seems to work), then it's taken from sega.s source. If your project compile without them (libgcc and sega.s code), it takes the math code from somewhere else, which explains your problems.
As Chilly Willy said, it's probably a wrong version of libgcc which is used in your case. Try to search about all your libgcc files on your computer, rename them until your MD program doesn't compile anymore ;)

The next version of the devkit won't include anymore the sega.s math code as it's not really needed. At the moment if i remove it compilation fails but i guess it's a problem with the -nostdlib flag, i should use -nostartfiles instead.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat May 10, 2008 9:21 pm

Don't try to use the path to the correct libgcc!! That didn't work for me either. That threw me off for the longest time. Instead, copy the proper libgcc file into the main gendev lib directory. That was the only way to get it to use the correct libgcc (in my case at least).

Shiru
Very interested
Posts: 786
Joined: Sat Apr 07, 2007 3:11 am
Location: Russia, Moscow
Contact:

Post by Shiru » Sun May 11, 2008 8:46 am

I don't think that problem in libgcc.a.

I tried to rename all other libgcc.a files on my computer, didn't help.
I tried to do all same on another computer, where no any gcc setups and any other dev software installed, and got same results.

In process, I noticed that INCS line into makefile.gen affects to project compilation in strange way.

If it contains any path (even one which does not exists) with \ slash on end of line, or just \ slash - project compiles without errors and works with problems with division and modulo (compiles without libgcc.a and math code in sega.s).

If it does not contains anything (inluding -I), libgcc.a not referenced in makefile.gen, and project uses 32bit division, compiler shows error 'undefined reference to __divsi3' (it also shows same error if I use i=(i+1)/10; where 'i' is 16bit variable). If I add reference to libgcc.a, it compiles without error, but does not work, and still does not work even if I remove division from code. Reference to libgcc.a can be with full path, and if I specify wrong path, it shows error 'no such file', so I think, there is no problem with right libgcc.a.

Same happens on both computers.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun May 11, 2008 10:03 am

Are you SURE you did everything in the setup? Double-check against the main post:
http://www.spritesmind.net/_GenDev//for ... =2718#2718

You'll notice at the end of step 10:

Code: Select all

and the libc at the end :
$(GENDEV_PATH)/bin/libgcc.a
You'd BETTER have libgcc.a! You won't get anything working without it! :D

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sun May 11, 2008 10:06 am

Chilly Willy wrote:Are you SURE you did everything in the setup? Double-check against the main post:
http://www.spritesmind.net/_GenDev//for ... =2718#2718

You'll notice at the end of step 10:

Code: Select all

and the libc at the end :
$(GENDEV_PATH)/bin/libgcc.a
You'd BETTER have libgcc.a! You won't get anything working without it! :D
Yep, it's important to have $(GENDEV_PATH)/lib/sega.o in first position and $(GENDEV_PATH)/bin/libgcc.a in last.

Shiru
Very interested
Posts: 786
Joined: Sat Apr 07, 2007 3:11 am
Location: Russia, Moscow
Contact:

Post by Shiru » Sun May 11, 2008 10:32 am

Chilly Willy wrote:Are you SURE you did everything in the setup? Double-check against the main post:
Main post in the middle of the thread? Never read that, because I don't use any IDE with kit and don't want to. I use makefile.gen which included into kit and instructions from first post of this thread.

Anyway, I have sega.o at begin and libgcc.a at end:

LINKOBJ= sega.o \
$(OBJ)

$(CC) -T e:/gendev/bin/md.ld -nostdlib $(LINKOBJ) e:/gendev/bin/libgcc.a -o rom.out
Chilly Willy wrote:You'd BETTER have libgcc.a! You won't get anything working without it! :D
It's clear, I tried to remove it just for test.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sun May 11, 2008 9:16 pm

Shiru wrote:
Chilly Willy wrote:Are you SURE you did everything in the setup? Double-check against the main post:
Main post in the middle of the thread? Never read that, because I don't use any IDE with kit and don't want to. I use makefile.gen which included into kit and instructions from first post of this thread.

Anyway, I have sega.o at begin and libgcc.a at end:

LINKOBJ= sega.o \
$(OBJ)

$(CC) -T e:/gendev/bin/md.ld -nostdlib $(LINKOBJ) e:/gendev/bin/libgcc.a -o rom.out
Chilly Willy wrote:You'd BETTER have libgcc.a! You won't get anything working without it! :D
It's clear, I tried to remove it just for test.
At least you found a way to get things working correctly !
GCC acts strangely sometimes as the libgcc.a which have to be placed in last position...

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon May 12, 2008 1:42 am

Did you recompile the rest of the devpak files with the same compiler as the libgcc came from? They have a tendency to switch certain things at a low level from time to time that breaks compatibility with stuff compiled under earlier versions.

Shiru
Very interested
Posts: 786
Joined: Sat Apr 07, 2007 3:11 am
Location: Russia, Moscow
Contact:

Post by Shiru » Mon May 12, 2008 7:26 am

Chilly Willy wrote:Did you recompile the rest of the devpak files with the same compiler as the libgcc came from? They have a tendency to switch certain things at a low level from time to time that breaks compatibility with stuff compiled under earlier versions.
I said for many times: I don't use rest of the devpak files. From all kit I need only compiler.

Post Reply