GBA debugging

[obcd]

I am new to this kind of devellopment. As I don't want to run before I can walk, I would like to experiment a little with the GBA before I start with DS programming. I have 2 issues for the moment.

1. When I run the arm-eabi-insight.exe, I can't click the "target settings". The window that is supposed to show up simply doesn't.
The GDB version is the 6.8.50. I am still using win 2000 as host os.

2. I would like to construct the XBOO cable. I am a bit scared of the original design as you connect a 5V device to a 3V3 device. During my search on the Internet, I ran into a couple of intellegent cables that have an embedded microcontroller. As legacy printerports start to dissapear, those look like a nice alternative. It might even be possible to use a USB device for that purpose, as those microcontrollers are becoming cheap nowadays. (Just loud dreaming for the moment.) I can't seem to find much description about how things work. The intellegent cables seem to download a small program into the gba ram, that handles the communication faster than the original gba multiboot loader. The Xboo communicator has buildin file transfer and a command interpreter?. Is there somewhere a detailed explanation available about how this all works? Supose I have the courage and time to design an intelligent cable, I would hate to have to reinvent everything again.

regards.

[obcd]

My first problem seems to be related to the fact that I have a pci adapter in my pc with a COM3 and COM4 port. When I disabled the driver for that adapter, I could acces the target settings menu. I also discovered that I could provide the settings in a command file that is loaded with the --command option. However, my vba (sdl)windows says that it is not receiving an acq, and I can't connect to it with the insight debugger. Anyone with a clue what I am doing wrong?

Thanks in advance.

[obcd]

It looks like the version of Insight that comes with the devkitpro is no longer compatible with the visual boy advance 1.7.1 version. Altough the tutorial on the site says that you shouldn't use a version of Visual Boy advance > 1.7.1, the screenshots clearly show that they are taken from a 1.8.x version? My current insight is the 6.4.50 and the one that came with devkitpro was the 6.8.50. The executable name changed from arm-elf-insight to arm-eabi-insight. I believe this has something to do with the latest ds libraries (I am a newbie remember..). I just don't see how I can debug ds code with insight, so I better start Googling again. Thanks everybody for all the replies so far. It has been helpfull.

[WinterMute]

Sorry, sometimes it takes a while to get around to replying to posts, we're usually busy on something toolchain related.

Unfortunately I don't have a current VBA which will work with the latest insight or gdb. Gmiller from this board has pm'd me to say he has one working but I hadn't got around to following up until you reminded me. Hopefully he should get back to me soon or reply to this thread.

The xboo cable works pretty well but, having said that, I have a couple of recent PCs where it doesn't work at all. I suspect some timing issues. It would be rather interesting to build an intelligent USB cable though, a lot of modern computers are leaving out the parallel & serial ports these days. I can probably give you some code & pointers if you're interested in pursuing that angle.

arm-elf vs arm-eabi is actually a change in the toolchain target - using eabi allowed us to better support the arm9 in the DS while retaining compatibility with the other arm devices we support. The libraries didn't change, they just needed recompiled with the new toolchain.

[obcd]

Thanks for your answer WinterMute, I will be more patient next time.
I discovered the way to print debug messages on the vba console, and for me, that is good enough right now. In my experience, most debuggers work fine until you start using interrupts, and are useless with them. I won't blame Insight / GDB being like that, but it is an experience I had with other debuggers.
Considering the Xboo cable, I found some interesting Atmel cpu's that have an embedded Usb port and an 8051 architecture. They only cost something like 6 euro, so it should be possible to create something fairly cheap. I know 256 KB isn't much if you plan on creating a game, but to learn GBA programming, it seems like a lot. Our first embedded boards only had 64Kb rom and 32KB ram memory.
I have the protocol description from the original No$gba documentation and an article about a xboo cable with an embedded 8051. It would be great if I could continue the work already done on the Xboo Communicator program. Again another Tool would make things even more complicated for beginners. I have a full time job and a wife who needs my attention from time to time. So I can't guarantee progress will go fast. I got a growing interest in GBA when I noticed that the support for it will dissapear when the new dsi arrives. Downloading GB roms from the nintendo shop doesn't seem a problem to me, but GBA rom's are rather big in size for that purpose. I also hate the idea that I have to pay again for all the games for which I own the cartridges already.

regards.

[gmiller1018]

I have updated the VBA source to correct the debug handshake and other issues so if you wanted to swap files I would be interested. The code for SDL works on many OS's but the non-SDL version only compiles on Windows because the original code uses a "broken" graphic library. I am looking for some way of getting the code to work in other environments but at this point I do not have the experience with the graphics libraries that the original code used.

[obcd]

Hi Garry,

I read your previous post about the vba sources and the fact that the GDB debugger wasn't working anymore. I haven't dug in the vba code much yet. Is it possible that you mean directx with a "broken graphic library" As I explained already, I am new to nintendo programming, and I have hardly any linux experience (which obviously you have.) Everything is pretty confusing in the beginning and spread over the internet on different places. If I compare with xbox1 programming, there you only have the openxdk and the official microsoft xdk. The first one is free but doesn't even natively support networking. So, the choice is easily made. If I can help you with anything, I will happily do so. I just can't make promises about the amount of free time I will have for it.

regards.