[CSDb] - User Forums - VICE debug interface

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > VICE debug interface

2014-06-19 15:03

chatGPZ

Registered: Dec 2001
Posts: 11386

VICE debug interface

i want to add some simple mechanisms to VICE that will help with automatic regression testing (there are over 800 test programs now, running them all manually takes several hours) - this stuff might be interesting for coders writing c64 software as well, so before i start i am looking for some more ideas on what might be useful.... the whole thing would be implemented as either a cartridge or some special i/o device, so basically everything should be triggered by writing to certain registers. the minimal functionality i came up with looks like:
- exit vice with exit code (to signal the test suite success or error)
- print a string to console (with some kind of "printf" like functionality, so you can print contents of registers/memory easily)

what else may be useful?

2014-06-19 17:13

doynax
Account closed

Registered: Oct 2004
Posts: 212

Well, the proposed debugging console certainly would be helpful..

Beyond that I'd not mind some means of informing VICE that a particular overlay has been (un-)loaded. Manually installing the appropriate labels and breakpoints can get a bit hairy with multiple dynamically loaded slots.

The holy grail would be to let tracepoints trigger a (Lua?) script capable of inspecting/modifying the state of the system. E.g. to be able to litter the code with "free" assertions (with access to information hard to inspect unobtrusively like timing and CPU/drive-synchronization), pretty-print data-structures or to prototype algorithms in a high-level language.

2014-06-19 18:13

Peiselulli

Registered: Oct 2006
Posts: 81

Backward stepping, breakpoints triggers on processor register values, breakpoints to screen positions, a "next line" instruction to step forward one line of the raster beam and a window for listing the current code for all platform (like the windows port) or even better. Maybe the debug interface of "stella" for the atari 2600 may be an example.

But that are things that wouldn't help for your regression testing problem ...

2014-06-19 18:19

chatGPZ

Registered: Dec 2001
Posts: 11386

sometimes i really wonder if people actually read before they write an answer.... this is all stuff that has very little to do with "basically everything should be triggered by writing to certain registers". i am NOT touching the monitor or adding any related features, thats something completely different =)

(you can already trigger breakpoints depending on register values, btw)

2014-06-19 18:33

doynax
Account closed

Registered: Oct 2004
Posts: 212

Quoting Groepaz

sometimes i really wonder if people actually read before they write an answer.... this is all stuff that has very little to do with "basically everything should be triggered by writing to certain registers".

Yeah, sorry about going off-topic there and drooling over unrelated debugging features.

The overlay proposal was meant as a serious suggestion for a virtual debugging cartridge though as it requires cooperation from the code being emulated. I envisage an array of virtual bank-switching register which when poked would bring in the labels/breakpoints tagged with the written value (and unload whatever overlay was there previously.)

2014-06-19 21:42

Krill

Registered: Apr 2002
Posts: 2980

- passing arguments to the guest program
- an IO register which prints emulation state info to stdout/stderr upon access
- equivalent features for drive code (except argument passing)

2014-06-19 22:01

Frantic

Registered: Mar 2003
Posts: 1648

I approve of this discussion. :D

2014-06-20 08:33

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

- passing arguments to the guest program

like a commandline switch that will let you pass a value, which then can be seen in some i/o register?
Quote:

- an IO register which prints emulation state info to stdout/stderr upon access

ie like the output you get in the monitor when tracing code?

those should be fairly easy to do indeed :)

2014-06-20 09:01

Krill

Registered: Apr 2002
Posts: 2980

Quoting Groepaz

like a commandline switch that will let you pass a value, which then can be seen in some i/o register?

I was thinking of passing a complete string. Writing to the register would reset the character index to 0, and reading would return the current character and increase the index. The terminating character may be a 0, and after that, the string would either wrap or return 0 until writing to the register again. To keep parsing complexity low, you could simply pass a single-character string, but the possibility for more complex parameters is there.

Quote:

ie like the output you get in the monitor when tracing code?

Basically yes, but maybe with more information than just raster position and CPU state. There could be a register for every chip, such as VIC, SID, CIA1, CIA2 etc., and the value written to it could be a bitfield or enum value to determine how detailed the output should be. The idea is that you could check for more than just test passed/failed from the regression test script, diffing VICE's terminal output with a reference.

2014-06-20 09:09

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

The idea is that you could check for more than just test passed/failed from the regression test script

well, thats not really useful. for most of those tests even a full register dump wouldnt help - you'll have to examine wth happened in all detail anyway. for the regression-testing alone what i listed in the first post is more than sufficient already :)

2014-06-20 09:19

Krill

Registered: Apr 2002
Posts: 2980

True. But maybe it would help further debugging after a failed regression test, such that you can insert these writes at strategic points to find out where it breaks.

2014-06-20 09:24

chatGPZ

Registered: Dec 2001
Posts: 11386

for that we have breakpoints =)

2014-06-20 09:37

Krill

Registered: Apr 2002
Posts: 2980

Can you currently comfortably trigger host-level breakpoints from guest code, such that you can trap into a host debugger to debug VICE code by doing something in the emulated machine?

2014-06-20 10:03

Oswald

Registered: Apr 2002
Posts: 5094

its been a long time since I didnt understand an english sentence, so thank you for that :)

2014-06-20 10:16

Krill

Registered: Apr 2002
Posts: 2980

It's been a long time since my contributions to VICE, so my info may be a bit outdated. I just meant that when debugging a virtual machine, you're dealing with two code levels, the code running inside the VM and the actual VM code. Breakpoints can be set in either of them, but i'm not sure if you can currently run some code inside the VM to comfortably break into a debugger for the VM code itself.

With "comfortably" i mean not simply setting a breakpoint on some VM code which would trap into the debugger whenever passing it, but trigger that breakpoint from guest code running inside the VM depending on guest program state. Effectively, that would just require a special op-code or accessing a special IO register.

But i guess with the focus on regression testing, this is really not required.

2014-06-20 10:26

chatGPZ

Registered: Dec 2001
Posts: 11386

WAT

please forget "VM" and try again =)

2014-06-20 10:26

Krill

Registered: Apr 2002
Posts: 2980

Hmm, still off-topic, but generally a "hypervisor call" capability would be nice. Pass a string to VICE which would then be parsed and executed by VICE itself or some external means, with the result being passed back to the program running inside VICE.

2014-06-20 10:28

Krill

Registered: Apr 2002
Posts: 2980

Quote: WAT

please forget "VM" and try again =)

Note sure what you mean. VM in this case is VICE, as an emulator implements a virtual machine.

2014-06-20 10:40

chatGPZ

Registered: Dec 2001
Posts: 11386

i know that. however what you wrote requires interaction with not only the vice code, but also with whatever debugger is attached to it - thats completely beyond the scope of the original question, and probably not even possible in any practical way. remember this is a portable real world program that runs on dozens completely different environments, with completely different capabilities and architectures =P

2014-06-20 11:37

Oswald

Registered: Apr 2002
Posts: 5094

thanks I got it :)

2014-06-20 14:42

Flavioweb

Registered: Nov 2011
Posts: 463

What about a "redirect to console" to redirect monitor output that can be saved directly to a file?
Can be useful to save to file the output of trace command or similar things...

2014-06-20 14:54

Martin Piper

Registered: Nov 2007
Posts: 722

Headless mode with simple scripting.
So Vice would run without window at maximum warp in command line only mode.
It would run a simple script saying something like:
Load xxx.prg
Run for xxxx cycles
Or run until watch or break
Report memory at xxxx to yyyy to stout
Write C64 screen to file xxxx.bmp

This would let you run automated tests and capture test evidence for analysis.

2014-06-20 15:45

chatGPZ

Registered: Dec 2001
Posts: 11386

*sigh* i give up. (try -console and -moncommands)

2014-06-20 17:24

Endurion

Registered: Mar 2007
Posts: 73

Media handling (attach disk/tape)
Warp mode toggling

It might help if you tell what does test programs do

2014-06-20 17:28

chatGPZ

Registered: Dec 2001
Posts: 11386

what the test programs do doesnt matter at all, as said, what i listed in the first post is sufficient for the testing stuff. all i wanted to know is other things that perhaps could be useful and fit the "everything should be triggered by writing to certain registers" idea. oh well o_O

2014-06-20 20:57

Martin Piper

Registered: Nov 2007
Posts: 722

Quote: *sigh* i give up. (try -console and -moncommands)

Except on the Windows version the console and monitor commands don't quite offer the combination of functionality that was described.

Last version I tried it with VICE 2.4:

x64.exe -console
Result: VICE Error! Cannot set cooperative level: Parameter not valid

If I use: x64.exe -moncommands monitorExec.txt
Where monitorExec.txt contains:
l "C:\work\C64\BlankProjectComp\BlankProjectComp.prg" 0
w c000
g 80d

Then VICE (the whole Windows process, not the C64) crashes. :)

2014-06-21 05:50

Testicle
Account closed

Registered: Sep 2002
Posts: 131

Quote: *sigh* i give up. (try -console and -moncommands)

You seem to have a very low frustration tolerance limit. ;-)

2014-06-21 10:23

chatGPZ

Registered: Dec 2001
Posts: 11386

not at all, i just dont plan to continue this discussion when noone bothers to even read the question.

and i dont care about people not being able to use a proper shell (nor filing a proper bug report) either :)

2014-06-21 16:08

Stone

Registered: Oct 2006
Posts: 172

@Martin: I have used VICE scripting to automate song compiling with my native tracker. I modified the compiler to jump to a certain address ($cfff) after completion. This works even with VICE 2.4 on windows.

The command line I use is something like this:

x64.exe -drive8type 1541 -drive9type 1541 -autostart autocomp.d64 -9 temp.d64 -moncommand commands.txt -warp -logfile vice.log +sound -console

commands.txt is

break cfff
command 1 "quit"

(Sorry for staying off topic..)

2014-06-21 16:59

chatGPZ

Registered: Dec 2001
Posts: 11386

btw, that stuff isnt suited for the testsuite, because having a very simple "test cartridge" as described in the first post makes it possible to use the testsuite with another emulator with very little effort for the emulator author (i expect at least bero to jump on it as well once implemented)

2014-06-22 05:48

Martin Piper

Registered: Nov 2007
Posts: 722

Quote: @Martin: I have used VICE scripting to automate song compiling with my native tracker. I modified the compiler to jump to a certain address ($cfff) after completion. This works even with VICE 2.4 on windows.

The command line I use is something like this:

x64.exe -drive8type 1541 -drive9type 1541 -autostart autocomp.d64 -9 temp.d64 -moncommand commands.txt -warp -logfile vice.log +sound -console

commands.txt is

break cfff command 1 "quit"

(Sorry for staying off topic..)

Interesting. The +sound parameter allows -console to work without an error.

However there still doesn't seem to be a way to automatically save a BMP screenshot from the emulator and then quit once the breakpoint is hit.

The monitor "command" wants to use quotes and the scrsh command expects quotes so they're not compatible with each other.

2014-06-22 08:12

chatGPZ

Registered: Dec 2001
Posts: 11386

what about the "screenshot" command? *sigh*

2014-06-22 11:34

Martin Piper

Registered: Nov 2007
Posts: 722

Quote: what about the "screenshot" command? *sigh*

As I said above:
The monitor "command" wants to use quotes and the scrsh (screenshot) command expects quotes *so they're not compatible with each other.*

Unless you escape the command's quotes. Which isn't documented.

2014-06-22 11:43

chatGPZ

Registered: Dec 2001
Posts: 11386

i dont use windows, so well...

however, my solution for this stuff is the "pb" command

2014-06-22 12:00

Martin Piper

Registered: Nov 2007
Posts: 722

Quote: i dont use windows, so well...

however, my solution for this stuff is the "pb" command

Which when pointed to a file that contains the screenshot command followed by quit command it doesn't save a screenshot, it ignores that command and keeps the monitor window open.

When in console mode typing the screenshot command in the still open monitor window doesn't save a screenshot in console mode, instead it crashes.

Putting an escape quoted screenshot in a console mode monitor command file also gets ignores, probably because in the Windows version there isn't a valid screen to save.

2014-06-22 14:32

Krill

Registered: Apr 2002
Posts: 2980

Quoting Groepaz

i know that. however what you wrote requires interaction with not only the vice code, but also with whatever debugger is attached to it - thats completely beyond the scope of the original question, and probably not even possible in any practical way. remember this is a portable real world program that runs on dozens completely different environments, with completely different capabilities and architectures =P

No, you misunderstood me. I meant having a code path in VICE that would be taken in debug mode when triggered by the program in emulation after writing to a special IO register. You'd set a breakpoint there and debug normally. Any of the discussed debug registers would provide that, of course, but i just thought having a register print some internal emulation state (specified by the program in emulation) before breaking into the debugger might help debugging. But thinking further about it, implementing that possibly means more effort than gain.

2014-06-24 07:06

Perplex

Registered: Feb 2009
Posts: 255

Being able to dump all vic register writes (or optionally all memory writes) to file with at least the following info on each line:

- The location of the instruction doing the write
- The actual instruction (opcode + operands)
- The address being written to
- The new value being written
- The cycle offset into the frame (or vertical and horisontal position of the raster beam) when the write took place.

And of course being able to toggle this on/off by writing to a special i/o register.

In other words, something along the lines of "-soundrecdev dump", but for more than just sid register writes.

2014-06-25 20:50

Digger

Registered: Mar 2005
Posts: 437

Maybe just take a 256x256px 8bit snapshot and do a pixel diff comparison for regression testing...

Like shown here (Flash Player required) http://play.blog2t.net/files/fc64-player/?url=http://csdb.dk/re..

Or perhaps I haven't understood the question? ;-)

2014-06-26 14:51

Martin Piper

Registered: Nov 2007
Posts: 722

Quote: Being able to dump all vic register writes (or optionally all memory writes) to file with at least the following info on each line:

- The location of the instruction doing the write
- The actual instruction (opcode + operands)
- The address being written to
- The new value being written
- The cycle offset into the frame (or vertical and horisontal position of the raster beam) when the write took place.

And of course being able to toggle this on/off by writing to a special i/o register.

In other words, something along the lines of "-soundrecdev dump", but for more than just sid register writes.

This would be useful. If I have time I'll add it.
You might want VIC reads as well since some have effects.

2014-10-14 05:29

mankeli

Registered: Oct 2010
Posts: 146

So is this 'debug cartridge' implemented yet? :-)
I'd really like to have a register that prints stuff to the host console.

2014-10-14 14:28

doynax
Account closed

Registered: Oct 2004
Posts: 212

By the way, do any physical debugging cartridges exist for the C64?

That is not just the typical freezer/monitor but something more along the lines of an in-circuit emulator or a clever bit of programming allowing (relatively) unintrusive breakpoints and single-stepping from a remote host? What did the fancier development cross-development set-ups offer back in the day?

(Sorry to hijack the thread with a non-VICE related question.)

2014-10-14 15:10

chatGPZ

Registered: Dec 2001
Posts: 11386

something like that existed for PDS at least... i have heard of other inhouse solutions too (but never saw one myself)

2014-10-14 20:09

soci

Registered: Sep 2003
Posts: 480

I saw an in house "solution". It used a bunch of TTL IC and had to be combined with a freezer cartridge (maybe AR?). You could set up an address and it triggered freeze when it was hit.

Refresh

Subscribe to this thread: