Katana Dev. Box: Unable to use CodeSpace Debugger with SDK R11b

Hi there!

As you know, I finally fixed my Dev. Box unit so now it's time to play with it!

So I followed the Startup Guide from the SDK R11b, and I have a problem with the CodeScape Debugger. I don't know why, but the behavior is not the one described in the guide. When I recompile the QuikTst2 sample then I load it from the CodeScape Debugger, everything seems to be OK: The CodeScape Debugger shows me the linked source code, and the execution cursor is put on the main() function. But when I execute step-by-step the sample program, the program exits when initializing the VGA cable... The Dev. Box exits to the Dreamcast BIOS.

What am I doing wrong?

Thank you for the help!

 

unfortunately i do not have my devbox with me right now so i could test your executable.

From the sound of it, since you can single step your executable in codescape then i think the whole setup is ok. May i ask which compiler and makefile configuration are you using?

Let's start simple and see how i can help from memory only. Have you tried to switch the devbox from OS mode to CPU mode? I recommend CPU mode, you can set it through a menu in Codescape. Also try to 'close' the gdrom emulator door from gdWorkshop before loading the executable.

 

Hi dmtnklb and thank you very much for your interest about my question!
Yeah I think my whole setup is fine, since I've tested the Windows CE SDK and everything is working good with it.

I've simply used the provided QuikTst2 sample, as specified in the Startup Guide. So you'll find it in the standard installation of Katana SDK under Samples/Kamui2/QuikTst2. I haven't modified anything, I've just recompiled with gmake the sample because CodeScape was lost, I mean the debugger was showing an incorrect instruction line instead of main() (maybe the symbol file was not recompiled in SDK R11b but no big deal, just recompiling it fixed the problem).

I think you are 100% right, this is related to CPU/OS mode. I remember CodeScape was showing something on the first startup about this. But I don't remember what was the content of that Dialog Box. Plus, I don't remember how to check if I in CPU/OS mode and how to switch them, I didn't found the option in the CodeScape window. I'm in GD-ROM mode (not Emulation mode) as requested by the Startup Guide (you know, this option is set from GDWorkshop).

Thank you very much for your time!

 

Check codescape a bit better... the setting is under Tools->Processor or Tools->Simulate Processor or something like that. Can't remember exactly right now.

Another option would be to change it from the DACheck utility. It gives you the option when you exit.

It is easy to check if you are in OS or CPU mode. When you power on the unit, if you see just a black screen you are in CPU mode. If you see the dreamcast bios menus, then you are in OS mode.

 

You right, it's under Tools > Configure Target / Communication. I was in CPU mode.

Definitely, I think there is a problem somewhere.
My Dev. Box is exiting to the Dreamcast BIOS when executing the following instruction:

Code:

case SYE_CBL_VGA:   /* Standard VGA. */
    sbInitSystem (KM_DSPMODE_VGA, KM_DSPBPP_RGB565, 1);

This happens in both CPU and OS mode.
So the provided QuikTst2 sample never continues beyond that point.

 

which compiler are you using? shc, gcc or metrowerks?

There is a chance shinobi is not initialized correctly if you are not using shc. Take a look at the readme file of the sdk. There is a section describing how you have to call a workaround function before initializing shinobi if you are using gcc. It might be that this is the case.

 

I would also assume the dip switches are set correctly for vga mode

 

Here is the provided makefile, I presume it uses gcc since shc is in comment:
I compile it with gmake (as described in the guide).

Code:

#------------------------------------------------------------------------------
#QuikTst2.mak
#------------------------------------------------------------------------------

PROJECT =   QuikTst2

PROJECT_SRC   = \
       QuikTst2.c\
       sbinit.c\

OPTIMIZE =   1

#COMPILER =   SHC
GFXLIB =   KAMUI2
OUTPUT =   ELF

DEBUG  =   TRUE
LIST   =   FALSE

include $(KATANA_ROOT)\Sample\dc.inc

Plus, the first instruction in the QuikTst2.c file is:

Code:

#ifdef __GNUC__
   shinobi_workaround();
#endif

So I presume that workaround you was talking about is that one?

The Rotate SW is on 9th position (PAL) and the DIP switches are in right position I think, since when I set the Dev.Box in OS mode, I can see the Dreamcast BIOS interface on my VGA screen.

Really I don't have any idea of what's going wrong plus it's the first time I'm using this Set 5 (so long time to fix it... almost 1 year) so I'm a true beginner on Dev.Box related stuff.

 

If you're in GD-ROM mode, try again with a real GD-ROM inserted in the tray.
sbInitSystem does a check I think on the gd filesystem if I remember correctly, and stops if it's not happy with what it finds.

 

Try to use SHC instead of gnu and remove the shinobi workaround workaround to make sure nothing funky is happening (it's not necessary for shc anyway).

And maybe T_chan is right about the gd-rom thing, but i always worked in emulator mode so i have no recollection about it.

 

T_chan, you are right, when I put a random GD-ROM in the Dev.Box (Dreamkey 3) the sample works! Well done!

dmtnklb, I tried to recompile with SHC (by setting COMPILER = SHC in the makefile) and when I remove the GD-ROM from the drive, the problem is still here. The only solution is to put a GD-ROM in the drive. I switched the Dev.Box into Emulation mode with GDWorkshop but the issue remains.

Do you know a way to work on the Dev.Box without GD-ROM in the drive?

Thank to both of you

 

In emulation mode, I would guess that you would need to create an image with GD Workshop.
(create a GD Workshop project with the different tracks, ...)

 

i am not sure if you can ommit a gdrom or a virtual one, as far the sbinit cheks are concerned... i mean, in my projects i always have at least one texture for the font, so i always had something loaded in the virtual drive.

 

Hello!
Ok I've created a project in GDWorkshop and guess what? I can run a binary executable without inserting a GD-ROM in the drive! Woot!
So I think my problem is definitely fixed, it was just a lack of knowledge about the Set 5 (and the Startup Guide not so much detailed...).
Thanks to both of you!

 

Who needs Sega Tech Support when you have Assemblergames ?

Have fun with your devkit !