| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
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! :)
|
|
| |
AlexC
Registered: Jan 2008
Posts: 299 |
This is great tip. Thanks. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
I still say we need an assembler pseudo-op to emit raw strings to a VICE monitor script, except perhaps with some way of embedding evaluated expressions. I mean, wouldn't it just be awesome to be able to have proper (non-intrusive) asserts in your code?
Unfortunately VICE's condition expressions aren't very powerful, but it shouldn't be very hard to extend them to handle flags, the cycle/scanline counters, and memory variables.
Just imagine setting up a check to see that the final element in a list really is zero, or that an addition didn't overflow, or even that some timed raster code always runs in the proper cycle.
Of course what we *really* need is to have a full-blown script interpreter (e.g. Lua or something) built into VICE, like some of those newfangled NES emulators have. That way you could prototype tricky functions in a high-level language, as well as verify the results of the final assembly function against the original HLL code. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I still say we need an assembler pseudo-op to emit raw strings to a VICE monitor script, except perhaps with some way of embedding evaluated expressions. I mean, wouldn't it just be awesome to be able to have proper (non-intrusive) asserts in your code?
Unfortunately VICE's condition expressions aren't very powerful, but it shouldn't be very hard to extend them to handle flags, the cycle/scanline counters, and memory variables.
Just imagine setting up a check to see that the final element in a list really is zero, or that an addition didn't overflow, or even that some timed raster code always runs in the proper cycle.
Of course what we *really* need is to have a full-blown script interpreter (e.g. Lua or something) built into VICE, like some of those newfangled NES emulators have. That way you could prototype tricky functions in a high-level language, as well as verify the results of the final assembly function against the original HLL code.
That would be awesome indeed ofcourse. |
| |
Skate
Registered: Jul 2003
Posts: 494 |
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=++ :) |
| |
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: 45 |
@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 |
... 27 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 - Next |
