Re: Debugging - argh

2010-07-20 Thread Stefan Drissen
On Tue, Jul 20, 2010 at 5:12 PM, Andrew Collier wrote:

>
> (Has anyone ever looked into development of Eclipse plug-ins? It isn't
> something I've ever tried, but presumably it would be plausible for
> the assembler and SimCoupe to be plug-ins to the IDE, which would save
> anybody from having to write a UI for this stuff).


After getting frustrated with the JAM editor, and being an Eclipse user for
another language with a proprietary plug-in, I had a very quick look (5
seconds) at how hard can this be to implement (I do not speak Java). A Z80
Eclipse plug-in that was created for TI Calculator development does exist on
Sourceforge (http://sourceforge.net/projects/z80eclipse/), development was
abandoned in 2006. I do not know what state it is in. The standard Eclipse
documents for creating a plug-in are very extensive (
http://help.eclipse.org/helios/index.jsp?nav=/2), but daunting, which is
where the existing Z80 plug-in could help as a starting point.


Stefan


Re: Debugging - argh

2010-07-20 Thread david brant

On 20 Jul 2010, at 16:12, Andrew Collier wrote:

> On 20 July 2010 14:03, Simon Owen  wrote:
>> 
>> On 19 Jul 2010, at 22:47, Stefan Drissen wrote:
>> 
>> Now hurry along Si and integrate the label.tab in SimIce… ;-)
>> 
>> If it's just symbols you want tied in, I'm sure that can be arranged :)
>> 
>> You may want to ask David to add page information to the label.tab file
>> first though. ;-)
> 
> I don't know about Jam, but pyz80 doesn't assume there will be any
> correlation between label addresses (i.e. pc assembly addresses set
> using ORG) and the physical representation (set using DUMP). This
> means it would be quite difficult to associate a page with a symbol
> because it's difficult to be certain of the context in which they
> might later be used. (It's easy to dump symbol data from pyz80 as
> well, of course).
> 
> I don't think either of our assemblers yet generate enough information
> to map a DUMP address back to source file lines, though it would
> enable some really cool features if they could. I think I'd want to
> look at how it's done "properly" before trying to define a file format
> for it...
> 
> (Has anyone ever looked into development of Eclipse plug-ins? It isn't
> something I've ever tried, but presumably it would be plausible for
> the assembler and SimCoupe to be plug-ins to the IDE, which would save
> anybody from having to write a UI for this stuff).

Yes Jam Ass has the same addressing system as pyz80. I have had a little chat 
with Si about the possibility of having a debugger in JAM which could talk to 
simcoupe. If Simon can do simcoupe end i'll have a go. But don't know much 
about TCP/IP Sockets which I think is what is need.

> 
>> If you have any other thoughts on what should be added or changed, I'm open
>> to suggestions.  It got left a bit unfinished when I could do what I needed
>> from it to debug SimCoupe itself, but if there are more people using it then
>> it's more likely to be worked on.
> 
> I would find a history of breakpoint expressions quite useful.
> 
> Andrew



Re: Debugging - argh

2010-07-20 Thread Thomas Harte
>From the realm of the ridiculous, a RESTful interface for controlling
the debugger and reading machine state with the emulator including a
miniature HTTP server that exposes the interface (on localhost, at
least) would be the absolutely perfect thing. I was looking into
drafting a generic spec for such a thing a while ago but didn't get as
far as a document.

The benefit would be that the debugger was a separate program from the
emulator potentially by a different author without either having to
impose very far on the other's project. Realistically, it'd mean that
your fast, cross-platform emulator can remain largely in SDL and I can
write and attach an OS X specific front-end on the emulator (with
sufficient extra knowledge to step through the original source code,
hopefully), or even write one in Javascript and run it anywhere Sim
Coupe can run.

When I looked into it, there seemed to be lots of claims of the like
of "a complete HTTP server requiring only BSD sockets underneath in
less than 2000 lines of C code" around, so I'm not sure that side is
the problem. I keep meaning to investigate something similar in my
Electron emulator, but time is a problem nowadays.

On Tue, Jul 20, 2010 at 4:12 PM, Andrew Collier  wrote:
> On 20 July 2010 14:03, Simon Owen  wrote:
>>
>> On 19 Jul 2010, at 22:47, Stefan Drissen wrote:
>>
>> Now hurry along Si and integrate the label.tab in SimIce… ;-)
>>
>> If it's just symbols you want tied in, I'm sure that can be arranged :)
>>
>> You may want to ask David to add page information to the label.tab file
>> first though. ;-)
>
> I don't know about Jam, but pyz80 doesn't assume there will be any
> correlation between label addresses (i.e. pc assembly addresses set
> using ORG) and the physical representation (set using DUMP). This
> means it would be quite difficult to associate a page with a symbol
> because it's difficult to be certain of the context in which they
> might later be used. (It's easy to dump symbol data from pyz80 as
> well, of course).
>
> I don't think either of our assemblers yet generate enough information
> to map a DUMP address back to source file lines, though it would
> enable some really cool features if they could. I think I'd want to
> look at how it's done "properly" before trying to define a file format
> for it...
>
> (Has anyone ever looked into development of Eclipse plug-ins? It isn't
> something I've ever tried, but presumably it would be plausible for
> the assembler and SimCoupe to be plug-ins to the IDE, which would save
> anybody from having to write a UI for this stuff).
>
>> If you have any other thoughts on what should be added or changed, I'm open
>> to suggestions.  It got left a bit unfinished when I could do what I needed
>> from it to debug SimCoupe itself, but if there are more people using it then
>> it's more likely to be worked on.
>
> I would find a history of breakpoint expressions quite useful.
>
> Andrew
>


Re: Debugging - argh

2010-07-20 Thread Andrew Collier
On 20 July 2010 14:03, Simon Owen  wrote:
>
> On 19 Jul 2010, at 22:47, Stefan Drissen wrote:
>
> Now hurry along Si and integrate the label.tab in SimIce… ;-)
>
> If it's just symbols you want tied in, I'm sure that can be arranged :)
>
> You may want to ask David to add page information to the label.tab file
> first though. ;-)

I don't know about Jam, but pyz80 doesn't assume there will be any
correlation between label addresses (i.e. pc assembly addresses set
using ORG) and the physical representation (set using DUMP). This
means it would be quite difficult to associate a page with a symbol
because it's difficult to be certain of the context in which they
might later be used. (It's easy to dump symbol data from pyz80 as
well, of course).

I don't think either of our assemblers yet generate enough information
to map a DUMP address back to source file lines, though it would
enable some really cool features if they could. I think I'd want to
look at how it's done "properly" before trying to define a file format
for it...

(Has anyone ever looked into development of Eclipse plug-ins? It isn't
something I've ever tried, but presumably it would be plausible for
the assembler and SimCoupe to be plug-ins to the IDE, which would save
anybody from having to write a UI for this stuff).

> If you have any other thoughts on what should be added or changed, I'm open
> to suggestions.  It got left a bit unfinished when I could do what I needed
> from it to debug SimCoupe itself, but if there are more people using it then
> it's more likely to be worked on.

I would find a history of breakpoint expressions quite useful.

Andrew


Re: Debugging - argh

2010-07-20 Thread Simon Owen

On 19 Jul 2010, at 22:47, Stefan Drissen wrote:

> Now hurry along Si and integrate the label.tab in SimIce… ;-)

If it's just symbols you want tied in, I'm sure that can be arranged :)


> You may want to ask David to add page information to the label.tab file first 
> though. ;-)

Speaking of paging... it may be a good time to ask about how best to deal with 
addresses in the debugger.  The data import/export has always suffered from the 
complications of the current 64K paged setup, BASIC addresses and raw 
page+offset for both internal and external RAM.

For the debugger I started down the path of allowing a mix of plain addresses 
(0-65535, for 64K paged) and absolute (p:o for page+offset).  Disassembling 
generally only makes sense for the current 64K, but data views could let you to 
browse through the whole of RAM.  Whichever mode you started in would determine 
the extent and wrapping of the viewed block.  Worth finishing, or is that 
overcomplicating it?

I originally wanted to have a command-line interface, much like the Soft-ICE 
debugger.  It ended up being a bit more like TurboMON, which was influenced by 
the Multiface single-key commands.  The current method is fairly quick to get 
around, but requires learning more key combinations.  A command-line would be 
ultimately more flexible, but require a little extra typing.  Anyone got a 
preference?

If you have any other thoughts on what should be added or changed, I'm open to 
suggestions.  It got left a bit unfinished when I could do what I needed from 
it to debug SimCoupe itself, but if there are more people using it then it's 
more likely to be worked on.

I've not been around much recently for any home development stuff, but scene 
activity is always good to help draw me back in!

Si



RE: Debugging - argh

2010-07-19 Thread Stefan Drissen
Excellent! That helps! Thank you! 

 

Now hurry along Si and integrate the label.tab in SimIce… ;-) You may want
to ask David to add page information to the label.tab file first though. ;-)

 

Best regards,

 

Stefan

 

From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On
Behalf Of david brant
Sent: maandag 19 juli 2010 23:42
To: sam-users@nvg.ntnu.no
Subject: Re: Debugging - argh

 

 

On 19 Jul 2010, at 22:31, Stefan Drissen wrote:





And soon it dawned on him why he moved on from Z80 programming… 

 

Does a debugger for Sim Coupé exist that uses the information from the
source file for labels etc? The SimIce debugger is very nice, but the ‘where
am I’ guessing game is getting a bit tedious.

 

Best regards,

 

Stefan

 

Not as far as I know. But with JAM Assembler, it does produce a label.tab
file if that helps. Also label.tab file is updated after each build.

 

All the best and good luck

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.830 / Virus Database: 271.1.1/3015 - Release Date: 07/19/10
08:36:00



Re: Debugging - argh

2010-07-19 Thread david brant

On 19 Jul 2010, at 22:31, Stefan Drissen wrote:

> And soon it dawned on him why he moved on from Z80 programming… 
>  
> Does a debugger for Sim Coupé exist that uses the information from the source 
> file for labels etc? The SimIce debugger is very nice, but the ‘where am I’ 
> guessing game is getting a bit tedious.
>  
> Best regards,
>  
> Stefan

Not as far as I know. But with JAM Assembler, it does produce a label.tab file 
if that helps. Also label.tab file is updated after each build.

All the best and good luck