| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
Code based breakpoints using ca65 and VICE
Recent discussions about debugging etc made me do this, much like Doynax's stuff:
Macro for ca65:
.macro breakpoint name
.ident (.concat("br_", .string(name))):
.export .ident(.concat("br_", .string(name)))
.endmacro
Link line in your Makefile:
ca65 -C link -m map -Ln symbols $(OBJS) && sed 's/al [0-9A-F]* \.br_\([a-z]*\)/\0\nbreak \.br_\1/' < symbols > symbols2
Basically it tells ca65 to emit all labels into a file called symbols. The sed-script then locates all symbols starting with br_ and adds a breakpoint command after it.
To run in VICE:
x64 -moncommands symbols2 whateva.d64
This enables you to add breakpoints directly into your sourcecode like:
breakpoint flashcolors
inc $d020
jmp *-3
Have fun with future debugging! :)
|
|
... 27 posts hidden. Click here to view all posts....
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: if it goes this way, we will start creating unit tests in our c64 demo projects soon. ;)
@Nightlord: dude hear me, we are still waiting for C=++ :)
You say that is if it would be a bad thing..
I'm perfectly serious. It shouldn't be very difficult include a Lua interpreter in VICE and add a few hook functions for it to peek and poke around in memory and CPU the registers, and then allow breakpoints/watchpoints to trigger Lua callbacks rather than normal breaks.
Just imagine that you've got an awesome new idea for an optimized line-drawer, but you don't want to bother with 6502-optimizing all of the 3D math just yet. Or, better yet, if I (or even a non-developer) could try out and tweak new enemy behaviours for my game without having to worry about an efficient implementation. |
| |
andym00
Registered: Jun 2009
Posts: 44 |
@doynax: Why not just (ab)use an unused opcode in Vices 6510core.c which precedes a variable length string, which you can then parse in the opcode execution and spew out through debug_text() which pops out through Win32s OutputDebugString which handily arrives in your output window in VisualStudio :)
Proper formatting of the output even means a click on the outputted string will take you to the source file and line number that generated it..
I haven't done this with Vice yet (though probably will today), but have with several other emulators and then you can add whatever expression evaluation and handling you want to it..
I also want to experiment with shared memory stuff under Vice an investigate exposing the emulators memory to other processes to enable reading/writing of the memory from other applications..
|
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Code based breakpoints seems really cool. I did a createFile function to support it in Kick Assembler. Here is a little program that show how it's used:
.var brkFile = createFile("breakpoints.txt")
.macro break() {
.eval brkFile.writeln("break " + toHexString(*))
}
.pc=$0801 "Basic"
:BasicUpstart(start)
.pc=$1000 "Code"
start:
inc $d020
:break()
jmp start
NB. Use the -afo switch when assembling, otherwise filecreation is blocked |
| |
Dragnet
Registered: Nov 2006
Posts: 16 |
Hola,
Hey, neat feature! :)
But it would be even nicer if KickAss allowed command line arguments to be passed into the code, allowing the functionality to be truly generic...
For example, I use a unique "compile.bat" file to compile a given part (in a separate dir), with content like this:
java -jar c:/c64/KickAssembler35/kickass.jar foo.asm -showmem -vicesymbols -libdir "c:/c64/includes" -log foo.log
Then, if I was allowed to add additional user-defined arguments, say something like "-break_filename foo.txt", then the scenario would then become something like:
.var brkFile = createFile(getCommandLineArgument("-break_filename"))
.macro break(file) {
.eval file.writeln("break " + toHexString(*))
}
..
ldx #$ff
:break(brkFile)
lda #$00
:)
Regards / Dragnet |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting DragnetBut it would be even nicer if KickAss allowed command line arguments to be passed into the code, allowing the functionality to be truly generic... Can't you just use an environment variable or something? |
| |
Dragnet
Registered: Nov 2006
Posts: 16 |
Quote: Quoting DragnetBut it would be even nicer if KickAss allowed command line arguments to be passed into the code, allowing the functionality to be truly generic... Can't you just use an environment variable or something?
Well, not if I want to "inject" values into the KickAss script/macro code from the environment/command line - the problem is merely how to reference such values from within KickAss, e.g. using a getCommandLineArgument function or something of the like...
/Dragnet |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: Well, not if I want to "inject" values into the KickAss script/macro code from the environment/command line - the problem is merely how to reference such values from within KickAss, e.g. using a getCommandLineArgument function or something of the like...
/Dragnet
As I understand it KickAss exposes a full Java VM, so you should be able to SET a variable in your batch script just call System.getenv().get("BREAKPOINTS").
Or something along those lines anyway, though to be honest I have as little experience with Java as with KickAss. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
No, Kick Assembler has a script language that is working much like java (but it isn't java). So Dragnet is right, a getCommandLineArgument function would be nice. I will put it on the todo list. However, a getEnvironmentVar() would also do the trick. |
| |
Dragnet
Registered: Nov 2006
Posts: 16 |
Quote: No, Kick Assembler has a script language that is working much like java (but it isn't java). So Dragnet is right, a getCommandLineArgument function would be nice. I will put it on the todo list. However, a getEnvironmentVar() would also do the trick.
I'm probably opening up a can of worms here and being *very* nit-picking, I know, but using environment variables like this is in my humble view something not to do in the general case; here, however, the effect is arguably the same since the environment var can be set from the .bat script as well, but you are in effect forcing use of the Singleton pattern (blah blah...) instead of letting the user decide which instance (= values) to use (blah blah)... 8^)
So, to make a long boring story short, Slammer: do the getCommandLineArgument method first, then and only then consider the environment thing... How many lines of code will it take to implement in KickAss/Java - 10, max? :)
Regards /Dragnet |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
You could just use k2asm:
ldx #$00
{
lda text,x
beq _break
sta $0400,x
inx
bne _cont
}
rts
text:
.encoding "screencodes.enc"
#pybegin
import os
print '.enc "ASSEMBLED BY USER ' + os.getenv('USER').upper() + '",0'
#pyend
It also allows access to the commandline options, but you need to run the preprocess manually for that, I guess.
The possibilities are endless, if you actually have a full language available. There's a python library for everything... |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
