Page 31 of 57
Posted: Tue Aug 07, 2012 9:15 pm
by Chilly Willy
bioloid wrote:Ok, as I just got, the compiler is doing weird stuff sometimes. No problem with the sgdk! thanks.
Some times it's not "weird" so much as not a beginner topic. For example, you do know when to use volatile and when it's not needed, right? How about memory barriers on code? These often lead to "weird" behavior if you don't understand what is going on. When in doubt, disassemble to .o file with objdump, or have the compiler generate assembly with -c -S options.
Posted: Tue Aug 07, 2012 9:25 pm
by bioloid
I guess you explained exactly what I mean. The sgdk is here to save people times, without it I didnt get here... I wont go other road since I already know where it goes, really. Thanks to this nice community!
Posted: Tue Aug 07, 2012 9:34 pm
by bioloid
Stef wrote:maybe there is something incorrect with the reset handler...
Globals variables aren't "reseted", for sure I've only one currently and going to move it...
Posted: Tue Aug 07, 2012 11:11 pm
by Chilly Willy
bioloid wrote:Stef wrote:maybe there is something incorrect with the reset handler...
Globals variables aren't "reseted", for sure I've only one currently and going to move it...
There's the problem... look at sega.s
Code: Select all
SkipSetup:
move.w #0,%a7
move.w #0x2300,%sr
jmp _reset_entry
Continue:
* clear Genesis RAM
lea 0xff0000,%a0
moveq #0,%d0
move.w #0x3FFF,%d1
ClearRam:
move.l %d0,(%a0)+
dbra %d1,ClearRam
* copy initialized variables from ROM to Work RAM
lea _stext,%a0
lea 0xFF0000,%a1
move.l #_sdata,%d0
lsr.l #1,%d0
beq NoCopy
subq.w #1,%d0
CopyVar:
move.w (%a0)+,(%a1)+
dbra %d0,CopyVar
NoCopy:
move.w #0,%a7
move.w #0x2300,%sr
* Jump to initialisation process...
jmp _start_entry
Notice how it skips clearing ram and copying the vars reset? That's the SkipSetup path. For a program to work, it needs to reset the vars and bss on reset as well. If you wish info to survive a reset, it should be handled separate from regular variables. We might want special reset-proof memory functions added to the sdk.
Posted: Fri Aug 10, 2012 3:54 pm
by oofwill
I've got a problem since today.
Windows 7 ask me to update him.
I let him do those update and reboot pc.
Since this moment i've got a problem when i want to show tiles on screen.
When tiles are supposed to appear at center of the screen, they appear alternativly at the left or the right of the screen.
I'm sure there is a problem with SGDK since when i run old programs they run correctly, but when i compile them and ruen them again, they show the same problem
Yesterday i made this : (works correctly)
http://youtu.be/HwRNwcGx0j4
and today, just after i compile : (no changes in my program)
http://youtu.be/MAuUvOd1C4A
Sprites are correclty shown, text too if font_base is used, but not with modified font_tiles.
Don't understand. I reboot windows, check envirnment var and recompile bin, without success...
I tried to create a new project. It works until i show tiles on screen, they are not at the good place... once to the left, once tio the right... very strange...
EDIT : It seems windows is not faulty.
I've just installed SGDK on a laptop with XP SP3, imported my project and compiled it. Same problem...
:'(
Posted: Fri Aug 10, 2012 6:07 pm
by Stef
I guess you use the last version of SGDK right ?
You can have differences in a new SGDK version but that does not necessary mean there is a bug, maybe you use a method which has changed as
Code: Select all
void VDP_setTileMapRect(u16 plan, const u16 *data, u16 x, u16 y, u16 w, u16 h);
In this case you have to change your code. Usually i try to avoid that changes but sometime i just can't...
Can you show us the code you use to load your plan tilemap ?
Posted: Fri Aug 10, 2012 6:18 pm
by Stef
Chilly Willy wrote:
Notice how it skips clearing ram and copying the vars reset? That's the SkipSetup path. For a program to work, it needs to reset the vars and bss on reset as well. If you wish info to survive a reset, it should be handled separate from regular variables. We might want special reset-proof memory functions added to the sdk.
Actually you can detect reset in the main() method by testing the first argument. Here's the declaration of main method in SGDK :
hard != 0
--> hard reset (mean you just turned on the system)
hard == 0
--> soft reset (mean you pressed the reset button or used the SYS_reset() method)
As Chilly mentioned, memory is only reseted on hard reset (except dynamic memory which is always reseted). If you want to reset your globals variables, you have to initialize them in your main method.
Posted: Fri Aug 10, 2012 7:30 pm
by oofwill
Stef wrote:I guess you use the last version of SGDK right ?
You can have differences in a new SGDK version but that does not necessary mean there is a bug, maybe you use a method which has changed as
Code: Select all
void VDP_setTileMapRect(u16 plan, const u16 *data, u16 x, u16 y, u16 w, u16 h);
In this case you have to change your code. Usually i try to avoid that changes but sometime i just can't...
Can you show us the code you use to load your plan tilemap ?
Thats it!
Bastien help me and it seems VDP_doVRamDMA() uses word instead of bytes for the last argument.
I've made change and it works now
thanks anyway

Posted: Fri Aug 10, 2012 7:36 pm
by Stef
oofwill wrote:Stef wrote:I guess you use the last version of SGDK right ?
You can have differences in a new SGDK version but that does not necessary mean there is a bug, maybe you use a method which has changed as
Code: Select all
void VDP_setTileMapRect(u16 plan, const u16 *data, u16 x, u16 y, u16 w, u16 h);
In this case you have to change your code. Usually i try to avoid that changes but sometime i just can't...
Can you show us the code you use to load your plan tilemap ?
Thats it!
Bastien help me and it seems VDP_doVRamDMA() uses word instead of bytes for the last argument.
I've made change and it works now
thanks anyway

Ah yeah i forgot about this one, i modified DMA methods, sorry for that as it can indeed cause "invisible" changes :-/
But now these methods are consistent, i also removed useless ones to make things simpler...
Posted: Fri Aug 10, 2012 7:38 pm
by oofwill
No problem
Most important is that i can continue coding ^^
Posted: Sun Aug 12, 2012 1:36 pm
by bioloid
Ok, no more problems, malloc/free and things work like a charm.
Chilly Willy: you were right, I was writing in bad memory at one point, that was causing troubles at the end of my program.
Thanks goes to Stef for the awesome SGDK, and see you next time people !
Posted: Sun Aug 12, 2012 6:50 pm
by Chilly Willy
bioloid wrote:Chilly Willy: you were right, I was writing in bad memory at one point, that was causing troubles at the end of my program.
That's experience talking... I can't tell you how many times I've done that myself.

Posted: Wed Aug 22, 2012 4:01 pm
by djcouchycouch
It's just a little thing, but I think it could be helpful if there were an SGDK function that sets the scrolling mode. I use VDP_setReg(0x0b, value) to set the scroll mode, but it doesn't fit the general ease-of-use of the SGDK API. And it wasn't obvious to me when I started that it was the way to set it. So maybe something like
Code: Select all
#define HORZ_SCROLL_MODE_PLANE <whatever>
#define HORZ_SCROLL_MODE_TILE <whatever>
#define HORZ_SCROLL_MODE_LINE <whatever>
#define VERT_SCROLL_MODE_PLANE <whatever>
#define VERT_SCROLL_MODE_TWOTILE <whatever>
void VDP_setScrollingMode(u16 plan, u16 horzscrollmode, u16 vertscrollmode);
// example
VDP_setScrollingMode(APLAN, HORZ_SCROLL_MODE_PLANE, VERT_SCROLL_MODE_PLANE);
It would be a lot clearer and more obvious to someone new coming into the SGDK.
Anyway, just an idea!
Posted: Wed Aug 22, 2012 11:18 pm
by Stef
Nice idea

And unfortunately that is not the only missing function to set VDP stuff unfortunately (i think about tilemap, sprite table address also..).
I will add this function to start with

Posted: Thu Aug 23, 2012 6:55 pm
by djcouchycouch
Another little thing: the makefile calls mkdir for every file to ensure that the out, out/src and out/res directories are created. It's probably overkill. There should be a way to speed up compilation by just creating those directories once at the start.
I found this site which has about a half dozen different suggestions on how to do it.
http://www.cmcrossroads.com/ask-mr-make ... n-gnu-make
I attempted to use one of the suggestions in makefile.gen but couldn't wrap my head around the changes required to make it work. Maybe someone more familiar with makefiles can see what changes would be required to make it work.