Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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: 11116
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?
 
... 32 posts hidden. Click here to view all posts....
 
2014-06-19 18:19
chatGPZ

Registered: Dec 2001
Posts: 11116
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: 2844
- 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: 1627
I approve of this discussion. :D
2014-06-20 08:33
chatGPZ

Registered: Dec 2001
Posts: 11116
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: 2844
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: 11116
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: 2844
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: 11116
for that we have breakpoints =)
2014-06-20 09:37
Krill

Registered: Apr 2002
Posts: 2844
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?
Previous - 1 | 2 | 3 | 4 | 5 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
St0rmfr0nt/Quantum
Grue/Extend
MCM/ONSLAUGHT
Guests online: 120
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Wafer Demo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Logo Graphicians
1 Sander  (10)
2 Facet  (9.7)
3 Mermaid  (9.4)
4 Pal  (9.4)
5 Shine  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.062 sec.