#115385 - IanJ - Mon Jan 15, 2007 7:18 pm
Hi all,
I sent PayPal payment to Martin Korth for the No$Cash GBA debugger, and I've emailed him twice since, but got nothing.
EDIT: Turns out to be all my fault with a spam filter or something! Oops. Received a fine working debugger now!
Last edited by IanJ on Tue Jan 16, 2007 1:54 am; edited 1 time in total
#115389 - keldon - Mon Jan 15, 2007 7:46 pm
He is for real; but has serious issues with emails. Might be down to a bad spam filter claiming to filter spam, but filters everything else in sight.
Not sure how this belongs to the coding forum! What was your email title?
#115390 - IanJ - Mon Jan 15, 2007 7:51 pm
| keldon wrote: |
| He is for real; but has serious issues with emails. Might be down to a bad spam filter claiming to filter spam, but filters everything else in sight. |
Ugh. Ok. I don't see any other way of contacting him though.
| keldon wrote: |
| Not sure how this belongs to the coding forum! |
Apologies -- I was assuming other coders may have tried this debugger.
| keldon wrote: |
| What was your email title? |
Well, from PayPal it's "Receipt for Your Payment to <his address>"
Maybe I'll try posting something very simple from another address, but I'm suprised if he's filtering his own PayPal messages ;-)
Thanx.
#115396 - sgeos - Mon Jan 15, 2007 8:35 pm
Postcard? I don't image he gets much snail mail spam.
-Brendan
#115402 - kusma - Mon Jan 15, 2007 9:46 pm
If there were a reliable way of getting hold of him, I'd have bought a copy myself. It kinda sucks to have to gamble...
#115431 - IanJ - Tue Jan 16, 2007 1:52 am
| kusma wrote: |
| If there were a reliable way of getting hold of him, I'd have bought a copy myself. It kinda sucks to have to gamble... |
Well, it turns out there is -- Don't use an over-enthusiastic spam trap! Thanks to keldon raising this suggestion, I've now managed to contact Martin and received the Debugger and it's looking very handy!
#115432 - gmiller - Tue Jan 16, 2007 1:52 am
Any reason for not using Visual Boy Advanced with Insight?
#115433 - IanJ - Tue Jan 16, 2007 1:56 am
| gmiller wrote: |
| Any reason for not using Visual Boy Advanced with Insight? |
I've tried many many times. But I cannot get it to work. I would love to try that, but, I'm either stupid or it doesn't work. So far as I've got, GDB connects to VBA ok, but then just locks up.
Have you managed to use it successfully? Any tips?
#115436 - gmiller - Tue Jan 16, 2007 2:07 am
I know aabout the problems in the version that is out there but I do have a version that works for most things I debug. I had to fix the code in the emulator for debug and a few other things to make it work consistently. I you want to grab it the zip of the pre-compiled stuff is http://www.ivrtech.net/files/VBA_Install.zip and the source is http://www.ivrtech.net/files/VisualBoyAdvance.zip I have been able to debug ARM/Thumb mixtures and interrupts using this. If you find any problems just let me know or fix it yourself and send me the fix. I have been trying to find a home for this code but so far all I get is silence. For debugging all you need is the SDL version of the code. There are a couple of extra files along with this to install the Microsoft Visual C runtime environment so those need to be installed even for the SDL version.
| Code: |
vcredist_x64.exe
vcredist_x86.exe
|
#115582 - IanJ - Wed Jan 17, 2007 12:48 pm
Ok, cool stuff. This gets me a little further, but not debugging. I can fire up Insight and it downloads the image to VBA. Clicking "step", however, just runs the emulator rather than doing a step. Ie, I can't debug. The STOP button also fails. So it's communicating, but not really working for me still. I'm using the Insight build from the beta3 DevKitAdvance R5.
#115588 - gmiller - Wed Jan 17, 2007 2:37 pm
I know this might not mean much to you but here is what I do.
I have entries in my makefile to build and start the debugger or just run the debugger depending on what my goal is. Here is the relevent part of the makefile.
| Code: |
TARGET := $(shell basename $(CURDIR))
INCLUDES := $(DEVKITARM)
GDB_DIRS = $cdir:$cwd:
.
. (Lots of other stuff)
.
#---------------------------------------------------------------------------------
startsdl:
$(DEVKITPRO)/tools/win32/vbaSDL/vba.exe -3 -Gtcp:44444 &
#---------------------------------------------------------------------------------
makeini:
echo "File $(TARGET).elf" > insight.ini
echo "target remote 127.0.0.1:44444" >>insight.ini
echo "load $(TARGET).elf" >>insight.ini
echo "b main" >>insight.ini
echo "directory $(GDB_DIRS)">>insight.ini
echo "c" >>insight.ini
#---------------------------------------------------------------------------------
startinsight:
$(DEVKITPRO)/insight-6.4.50/bin/arm-elf-insight.exe --command=insight.ini $(TARGET).elf
#---------------------------------------------------------------------------------
gdb: clean
@make "DEBUG_SET=$(DEBUG_SET)" all
make startsdl makeini startinsight
#---------------------------------------------------------------------------------
rungdb: startsdl makeini startinsight
|
To just run the debugger i type:
make rungdb
This command starts the sdl version of the VBA code (listening on port 4444 for my machine) then builds an insight startup command file. After all this insight is started in a way that reads the built startup commands.
I can also to a rebuild of the code with debug generated in each object file (by using the "-g" compiler switch) and then link the code with debug (again the -g switch). To do this I type:
make gdb
This does a clean, make (with debug), and then starts the debugger. I hope this helps.
#119963 - werty - Tue Feb 27, 2007 11:04 pm
Baited into big IDE's and Host PC's ! Its too much trouble .
There is a fast way to program DS Lite ( i have 10 ) .
The DS BIOS is good enuf to allow you to create ur own
tiny debugger . But it will not use English , nor text ,
it will be symbolic ( true GUI ) .
Sorry i interrupted , go back to your 20 MB Host
buggy bloat system ....
| gmiller wrote: |
I know this might not mean much to you but here is what I do.
I have entries in my makefile to build and start the debugger or just run the debugger depending on what my goal is. Here is the relevent part of the makefile.
| Code: |
TARGET := $(shell basename $(CURDIR))
INCLUDES := $(DEVKITARM)
GDB_DIRS = $cdir:$cwd:
.
. (Lots of other stuff)
.
#---------------------------------------------------------------------------------
startsdl:
$(DEVKITPRO)/tools/win32/vbaSDL/vba.exe -3 -Gtcp:44444 &
#---------------------------------------------------------------------------------
makeini:
echo "File $(TARGET).elf" > insight.ini
echo "target remote 127.0.0.1:44444" >>insight.ini
echo "load $(TARGET).elf" >>insight.ini
echo "b main" >>insight.ini
echo "directory $(GDB_DIRS)">>insight.ini
echo "c" >>insight.ini
#---------------------------------------------------------------------------------
startinsight:
$(DEVKITPRO)/insight-6.4.50/bin/arm-elf-insight.exe --command=insight.ini $(TARGET).elf
#---------------------------------------------------------------------------------
gdb: clean
@make "DEBUG_SET=$(DEBUG_SET)" all
make startsdl makeini startinsight
#---------------------------------------------------------------------------------
rungdb: startsdl makeini startinsight
|
To just run the debugger i type:
make rungdb
This command starts the sdl version of the VBA code (listening on port 4444 for my machine) then builds an insight startup command file. After all this insight is started in a way that reads the built startup commands.
I can also to a rebuild of the code with debug generated in each object file (by using the "-g" compiler switch) and then link the code with debug (again the -g switch). To do this I type:
make gdb
This does a clean, make (with debug), and then starts the debugger. I hope this helps. |