>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 <and...@intensity.org.uk> wrote: > On 20 July 2010 14:03, Simon Owen <simon.o...@simcoupe.org> 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 >
