| |
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! :)
|
|
... 27 posts hidden. Click here to view all posts....
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
To track down bugs with modern fancy tools you all would first of all need to produce code/demos :-P Also, i wonder how we survived in the past? :-)
A simple bcs *, bcc * or alike was enough to check if flags are for sure at the state we expect them or else our program will lock up. $02 is also a good opcode to use with vice, so you can trigger the monitor as soon as your wanted piece of code is reached. I mean, we have already a whole programming language on board to do complex debugging tasks and giving feedback: 6502
So far i have not crossed borders that would make me need more. There's other things that are way more interesting in my opinion, like having a proper profiler and thus be able to detect dead code (micro64 is giving some more information here in the monitor), or have cycles of certain code segments counted easily.
Just wondering. |
| |
Brush
Registered: Apr 2002
Posts: 22 |
I think i agree with Bitbreaker.. Breakpoints are not a must in case of c64 as you can actually change the code quickly enough and recompile/restart. I think the point is that with modern tools we could save few minutes here and there.
But profiling is a different story.. The closest thing to profiling i've been using was to slam tons of watchpoints around the code part i was optimising, running it in vice, capturing the vice output into a text file and then calculating the "weight" of each instruction with some text based utilities. That was slow but sort of worked. But i would resort to it only in the worst case (that case was my worst case as it was not a simple inner loop optimization but something bigger with a complex flow and branching and i had to figure out the right mix depending on the input data)..
Anyway, you mentioned micro64 and profiling. I remember trying it out a year ago or so and although it mentioned the profiling in the changelog i was not able to turn it on and get anything sensible out.
Could you post some short instruction on how to make it work? Thanks in advance! |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
The micro64 has a monitor that can be accessed via a terminal/telnet, a typical output would look like:
$0030: b0 de bcs $0110 ; 0.55% executed, 72.81% taken
$0032: 46 11 lsr $11 ; 0.15% executed
$0034: 90 ee bcc $0124 ; 0.15% executed, 87.77% taken
$0036: a9 80 lda #$80 ; 0.07% executed
$0038: 85 11 sta $11 ; 0.07% executed
$003a: 45 13 eor $13 ; 0.07% executed
$003c: 85 13 sta $13 ; 0.07% executed
$003e: 85 16 sta $16 ; 0.07% executed
$0040: 30 e2 bmi $0124 ; 0.07% executed, 51.24% taken
$0042: e6 14 inc $14 ; 0.04% executed
$0044: e6 17 inc $17 ; 0.04% executed
$0046: d0 dc bne $0124 ; 0.04% executed, 100.00% taken
$0048: a9 01 lda #$01 ; 1.13% executed
$004a: 19 d3 28 ora $28d3,y ; 1.13% executed
$004d: 99 d3 28 sta $28d3,y ; 1.13% executed
The mnemonic decoding yet showed some bugs (sta ($xxxx),y how cool would that be) BeRo is informed and has fixed those issues already. The output is not yet perfect, but gives a few interesting numbers, most of all, on how often a branch is taken. |
| |
Brush
Registered: Apr 2002
Posts: 22 |
You ought to be kidding me :)
I've fired up micro64, even were in the monitor, even saw the command to reset the profiler stats but never actually disassembled a running piece of code.
Thanks for the tip, you've made my day! |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
DGGR: Exactly. Good to see you found the solution. Im not checking csdb that often anymore, but I just started this little facebook group , so feel free to join https://www.facebook.com/groups/RetroAssembler/ and discuss any retro assembler. There you will get a quick answer. Once I get time to make new releases it will be announced there as well.
Edit : Btw Everybody is welcome |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
oldsk00l -> newsk00l -> facebook shadow scene ... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"Also, i wonder how we survived in the past? :-)"
it sucked.
I remember having turn disk bug in Void while linking on a stock machine.
We spent a whole afternoon with Edhellon with this:
- load turbo ass
- load source
- change something
- save object
- load binary
- load object
- save them in one file to demo linking disk
- watch fuckin whole first side
- discover turn disk is still buggy
- goto 10
yeah, and in the end it turned out that I have deleted the turn disk routines from the binarily ripped loader, because I had no idea they are there for that :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:watch fuckin whole first side
thats your own fault though, loaders for side 2 could be done in 1997 too (just like part selectors) :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
that wouldnt make auto disk side change detection work tho. anyway after like the 8th time we tried the loader alone, instead of watching the whole side 1, to speed things up :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
no, but you could have tested only the last part of side 1 and the disk changing :) (you cant imagine how often i did that for artphosis.... argl) |
| Previous - 1 | 2 | 3 | 4 - Next |
