Sega Genesis Dev Kit (SGDK)

[Chilly Willy]

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.

[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!

[bioloid]

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

[Chilly Willy]

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.

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

:'(

[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 ?

[Stef]

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 :

Code: Select all

extern int main(u16 hard);

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.

[oofwill]

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

[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 ?

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

[oofwill]

No problem

Most important is that i can continue coding ^^

[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 !

[Chilly Willy]

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.

[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!

[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

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