Sega Genesis Dev Kit (SGDK)
Moderator: Stef
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
I said that many times too - I use makefile.gen from kit, none of flags were changed. If you don't have it, there is file:
And how do you think I get almost-working code (with problems with modulo and division) without 68000 flag set?
Code: Select all
CC= e:/gendev/bin/gcc
OBJC= e:/gendev/bin/objcopy
ASMZ80= e:/gendev/bin/asmz80
BINTOC= e:/gendev/bin/bintoc
#OPTION= -Dnologo_
SRC_C= $(wildcard *.c)
SRC_S= $(wildcard *.s)
SRC_SZ80= $(wildcard *.s80)
OBJ= $(SRC_SZ80:.s80=.o)
OBJ+= $(SRC_C:.c=.o)
OBJ+= $(SRC_S:.s=.o)
LINKOBJ= sega.o \
$(OBJ)
INCS=
FLAGS= $(OPTION) -m68000 -Wall -O1 -fomit-frame-pointer $(INCS)
FLAGSZ80= -c -i -x1 -x2 -x3 -z -lnul
all: rom.bin
rom.bin: rom.out
$(OBJC) --pad-to 131072 -O binary rom.out rom.bin
rom.out: $(OBJ)
$(CC) -T e:/gendev/bin/md.ld -nostdlib $(LINKOBJ) e:/gendev/bin/libgcc.a -o rom.out
%.o80: %.s80
$(ASMZ80) $(FLAGSZ80) -o$@ $<
%.c: %.o80
$(BINTOC) $<
%.o: %.c
$(CC) $(FLAGS) -c $< -o $@
%.o: %.s
$(CC) $(FLAGS) -c $< -o $@
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Something important to know : if you test your code on real hardware the
"--pad-to" option have to be 128 KB boundary and greater than your rom size.
If your rom size is ~900 KB then you must replace "--pad-to 131072" by "--pad-to 1048576" and it won't work on real hardware.
If someone know how force the rom size to be 128 KB boundarie i'm interested ! It's a pain to always modify that --pad-to option when needed.
"--pad-to" option have to be 128 KB boundary and greater than your rom size.
If your rom size is ~900 KB then you must replace "--pad-to 131072" by "--pad-to 1048576" and it won't work on real hardware.
If someone know how force the rom size to be 128 KB boundarie i'm interested ! It's a pain to always modify that --pad-to option when needed.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
I never pad any of my stuff, no problems on real HW.. I usually unpad homebrew to get faster programming times
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 81
- Joined: Tue Jul 10, 2007 7:45 pm
- Location: Brazil / USA
- Contact:
Not true for all flash systems. Tototek flasher software will trim your game data if the rom is not aligned to a 2^x multiple, and that obviously will generate unexpected results at some point.TmEE co.(TM) wrote:I never pad any of my stuff, no problems on real HW.. I usually unpad homebrew to get faster programming times
Anyway everytime when I compile Pier Solar for test I have UCON pad the rom and recalculate the checksum. With BasiEgaXorz I also have to add the header standard info (-1991 parameter), otherwise the game will not run on any of my MDs.
Seeya.
Tulio
I found source of my problems finally. It's -O1 option. If I remove it, all works, with modulo and division. I compiled platform game project successfully, all works without problems which version compiled with SGCC had. Only problem, it much slower than SGCC code (and one of reasons for moving to GCC was more optimized code..).
Can anybody explain how can it work with -O1 for Stef, but don't work for me?
Can anybody explain how can it work with -O1 for Stef, but don't work for me?
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Did you tried some optimisation flags as -Os (minimise code size), -Ot (minimize execution time) or -O2 (or greater level) ?Shiru wrote:I found source of my problems finally. It's -O1 option. If I remove it, all works, with modulo and division. I compiled platform game project successfully, all works without problems which version compiled with SGCC had. Only problem, it much slower than SGCC code (and one of reasons for moving to GCC was more optimized code..).
Can anybody explain how can it work with -O1 for Stef, but don't work for me?
Very strange though, do you mix some asm code with the C code ? I guess you take care about the stack convention for function calls (store all registers except D0-D1/A0-A1).
-
- Very interested
- Posts: 81
- Joined: Tue Jul 10, 2007 7:45 pm
- Location: Brazil / USA
- Contact:
I have a file called pad.bat that I call on inside the bat routine to compile the game.Stef wrote:Something important to know : if you test your code on real hardware the
"--pad-to" option have to be 128 KB boundary and greater than your rom size.
If your rom size is ~900 KB then you must replace "--pad-to 131072" by "--pad-to 1048576" and it won't work on real hardware.
If someone know how force the rom size to be 128 KB boundarie i'm interested ! It's a pain to always modify that --pad-to option when needed.
So to generate rom01.bin I call buildcart.bat rom01
The last command on that bat is a call to pad rom01
Inside the pad.bat file I call:
Code: Select all
ucon64 -q --pad %1.bin
ucon64 -q --chk %1.bin
Tulio
-Os, -O2 - code does not work, -Ot shows 'invalid option argument' error.Stef wrote:Did you tried some optimisation flags as -Os (minimise code size), -Ot (minimize execution time) or -O2 (or greater level) ?
Not, I don't mix asm and C. Well, almost - I have few asm("nop"); lines in gamepad polling function. But I already tried to remove this code, nothing changes. All other code is pure C.Stef wrote:Very strange though, do you mix some asm code with the C code ? I guess you take care about the stack convention for function calls (store all registers except D0-D1/A0-A1).
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
I forgot that -Ot isn't supported on 68000 target...Shiru wrote:-Os, -O2 - code does not work, -Ot shows 'invalid option argument' error.Stef wrote:Did you tried some optimisation flags as -Os (minimise code size), -Ot (minimize execution time) or -O2 (or greater level) ?
Not, I don't mix asm and C. Well, almost - I have few asm("nop"); lines in gamepad polling function. But I already tried to remove this code, nothing changes. All other code is pure C.Stef wrote:Very strange though, do you mix some asm code with the C code ? I guess you take care about the stack convention for function calls (store all registers except D0-D1/A0-A1).
I'm starting to be out of ideas about your problem The -fomit-frame-pointer change something ? Something i don't understand is how it can compile division code when you remove both sega.s code and libgcc ?!? O1 or not, that shouldn't compile at all.
I'm already out of ideas.Stef wrote:I'm starting to be out of ideas about your problem :? The -fomit-frame-pointer change something ?
-fomit-frame-pointer seems don't change anything, project works regardless of this option.
I use libgcc. I removed it just for test purposes, to see if compiler actually uses it or not, and added it back when managed to get 'undefined reference to __divsi3' error.Stef wrote:Something i don't understand is how it can compile division code when you remove both sega.s code and libgcc ?!?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Okay, all my ideas have been stupid up to now ( ), so let's keep that going... maybe you have a structure that is optimized into a packed form that places a word or long on an odd address. The 68000 can't read words or longs from odd addresses. I know that the default alignment on gcc is to the natural size, but maybe O1 on the 68000 changes that.
I have some structures in game project, but it's hard to find any structures in test code which just changes palette randomly - and it have same problems with compilation.
Here is test compiled without optimization and with -O1. I'm not good in 68K debug and also tired for today, but from fast look into debugger, isn't optimized code uses illegal opcodes?
Here is test compiled without optimization and with -O1. I'm not good in 68K debug and also tired for today, but from fast look into debugger, isn't optimized code uses illegal opcodes?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Here's the problem - you apparently don't have the vblank counter set as volatile. In the noopt code, the wait is done as a subroutine, while in the O1 code, it does this:
It tries to inline the routine, and cache the variable as part of the optimizing. The var must be volatile to make sure it's loaded from memory every single reference.
Code: Select all
MOVE.W D0,($FF0000)
lbC00056C MOVE.L ($FF0082),D1
MOVE.L D1,D0
lbC000574 CMP.L D1,D0
BEQ.B lbC000574