SpritesMind.Net

Posted: **Mon May 12, 2008 7:42 am**

You haven't posted what compiler settings you're using. For all we know, you aren't compiling with the 68000 flag set.

Posted: **Mon May 12, 2008 8:09 am**

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:

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 $@

And how do you think I get almost-working code (with problems with modulo and division) without 68000 flag set?

Posted: **Mon May 12, 2008 11:16 am**

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.

Posted: **Mon May 12, 2008 12:31 pm**

I never pad any of my stuff, no problems on real HW.. I usually unpad homebrew to get faster programming times

Posted: **Mon May 12, 2008 2:48 pm**

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

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.

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

Posted: **Mon May 12, 2008 4:10 pm**

same thing here, I use UCON from the beggining

and it's multi os

Posted: **Mon May 12, 2008 5:01 pm**

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?

Posted: **Mon May 12, 2008 8:11 pm**

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?

Did you tried some optimisation flags as -Os (minimise code size), -Ot (minimize execution time) or -O2 (or greater level) ?
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).

Posted: **Mon May 12, 2008 8:29 pm**

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.

I have a file called pad.bat that I call on inside the bat routine to compile the game.

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

It is guaranteed powa! Works always!

Tulio

Posted: **Mon May 12, 2008 8:49 pm**

Stef wrote:Did you tried some optimisation flags as -Os (minimise code size), -Ot (minimize execution time) or -O2 (or greater level) ?

-Os, -O2 - code does not work, -Ot shows 'invalid option argument' error.

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).

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.

Posted: **Mon May 12, 2008 10:06 pm**

Shiru wrote:
Stef wrote:Did you tried some optimisation flags as -Os (minimise code size), -Ot (minimize execution time) or -O2 (or greater level) ?
-Os, -O2 - code does not work, -Ot shows 'invalid option argument' error.

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).
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.

I forgot that -Ot isn't supported on 68000 target...
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.

Posted: **Mon May 12, 2008 10:18 pm**

Stef wrote:I'm starting to be out of ideas about your problem :? The -fomit-frame-pointer change something ?

I'm already out of ideas.

-fomit-frame-pointer seems don't change anything, project works regardless of this option.

Stef wrote:Something i don't understand is how it can compile division code when you remove both sega.s code and libgcc ?!?

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.

Posted: **Mon May 12, 2008 10:54 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.

Posted: **Mon May 12, 2008 11:06 pm**

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?

Posted: **Tue May 13, 2008 1:28 am**

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:

Code: Select all

				MOVE.W	D0,($FF0000)
lbC00056C	MOVE.L	($FF0082),D1
				MOVE.L	D1,D0
lbC000574	CMP.L	D1,D0
				BEQ.B	lbC000574

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.

SpritesMind.Net

Sega Genesis Dev Kit (SGDK)