ParaJVD : Parabellum's Java Vectrex Debugger

Official Home of ParaJVD ... Or how to turn an emulator into a full debugger!

Wednesday, March 10, 2010

ParaJVD alpha version !

Just a short update to let you know that the very first alpha version of ParaJVD (embedding the ParaJVE 0.7.0.beta4 engine) has finally been packaged, and is now available for homebrewers (but it is not public yet, sorry).

I have already sent it to several active vectrex homebrew developers.

Of course, this alpha will also be made available to any established vectrex developer ; just send me a request if you're one of them and I forgot to contact you yet.

Labels: ,

Sunday, July 13, 2008

Berzerk Video

Here is a video that shows the debugger in action :  Debugging Berzerk on ParaJVD

Nothing fancy, I'm just playing around with some of ParaJVD features, so that you can get a rough idea of the current state of the project, as well as its look and feel.

Labels: ,

Friday, July 11, 2008

Summer WIP

A quick post to show the latest development progress on ParaJVD.

Here is a snapshot of what the current version looks like (each view
can be resized/docked/moved around to match the user preferences).

  • The GUI is not dependent on a particular docking framework anymore (It still makes use of VLDocking at the moment, but it may be changed very easily in the future)

  • Implemented contextual popup menus and actions on each GUI view (Program, Registers, Memory, Console, Breakpoints, Watches, Cycles)

  • Added a Cycles view.

    This view shows an histogram of the CPU cycles elapsed during the last frames. In its top-left corner, there is also a cycles counter (a kind of progress bar) for the current frame, and also a sub-counter (the figure at the right) that displays the number of cycles needed to execute the last debug step.

  • Another new view has been added : the Watches view.

    The user enters Watch Expressions that can either be resolved as values or addresses. If it's an address, then the "content" column shows the bytes at the specified address (these bytes can be edited, just like in the Memory views).
    The "content" column displays the values on a yellow background when it was modified during the last debug step.

    The Watch Expression can be as simple as a single number (for instance "$C800"), or it can be a complex expression involving arithmetic and/or bitwise operators, and register or memory accesses (for instance "X-4*B", "DP<<8|A", "PC-[S]" or "[$C800]")

    The watch view is now roughly working, but there are still a bunch of issues hanging around, so it requires yet more work to be fully completed.

  • Once this is all done I think I'll have to get the "Project Definition" side of ParaJVD done, so that it can be used by someone else than me :-)
    (At the moment, the only way to change the binaries/sources loaded at startup is to modify a couple of ParaJVD source files ... not exactly my definition of user-friendly!).

    After that, the debugger can be released as a preview for the thousands of Vectrex homebrew developers out there.

    Thursday, March 13, 2008

    And now it's even kicking...

    15 months since last post, that must be some kind of record! =)

    Well, a lot of good stuff happened in the meantime ... the not so good news is that I didn't have much time to allocate to ParaJVE/ParaJVD coding.

    Yet I finally managed to plug in the debug engine (that can execute in normal or step in/over/out modes) and to write a memory viewer, a registers editor, an ASM source viewer, and a breakpoints manager.

    • The breakpoints manager handles standard breakpoints (double-clicking a program line in the Source Viewer will automatically create an execution breakpoint for the instruction's address) as well as memory access breakpoints (you can specify if you want it to monitor read, write or read/write access to a single address or to a whole address range).

      More breakpoint types will be added eventually (for example: invalid memory access, invalid instruction, interrupt, timers timeout, cycles count, end of frame, ...)

    • The Memory Viewer component lets you see the content of any memory area : RAM, ROM, CARTRIDGE (and even some special cartridges areas like the Cartridge-RAM embedded at $2000 in "Animaction").

      The areas that are tagged as RAM can be edited by the user, and are also monitored for changes during program execution (the bytes that changed will be displayed with a yellow background). This "snapshot" feature can be cumulative (snapshot updated manually on user-action) or not (snapshot updated automatically whenever the execution resumes).

    • The Registers Window provides you with a way to watch and edit (guess what?) the registers values. It also monitors the changes whenever the engines suspends execution, and displays the modified values using a different background color.

    • The Source Viewer component is not quite advanced yet. All it does is to load the source file(s) at startup, then scroll to the current executed line as the debug session goes on.

      The main concern with this approach is that if, for some reason, the executed address cannot be found in the loaded source file(s), the component cannot display anything. This will happen for instance if the program executes some dynamic code stored in RAM. To bypass this issue, the source viewer needs a way to be coupled with a dynamic disassembler (such a disassembler already exists within ParaJVE, I just need to think about how to integrate it tightly with the source viewer).

      For now, the viewer can load two kinds of source files :
      1. Raw ASM files - provided that each line holding an instruction starts with the address (prefixed with any number of white spaces). The list output files (.LST) generated by the AS09 assembler are perfect candidates.
      2. Debug output files (.DBG) generated by AS09

      I'd like to add support for many more assemblers, so please tell me which is your preferred assembler and I'll try to go for it (or even better, I'll exhibit a public API so that you can write your own loader and add it to ParaJVD as a pluggin).
    And since pictures are worth a thousand words, here is a screen grab of a debugging session I just had yesterday, while trying to check a corrupted ROM image (Mail Plane) :

      The "ParaJVE" tab embeds the emulator display, whereas some other tabs are not functional yet and are just place-holders ("Disassembly", "VIA-6522" and "Watches"). Each window and tab can be resized/docked/moved around to match the user preferences.


    Monday, December 18, 2006

    It's alive!

    Well, it moves, at least ... :)


      Finally made some changes to plug ParaJVE within its allocated panel. The emulator runs, its menu is accessible and functional, the keyboard events are hooked correctly, and the emulator can output its text in the embedded console panel.

      Apart from that all the other panels are dummy ... The register display is not linked to the engine, and all the other components are empty. You can't even bring the game selector at the moment (MineStorm is hard-coded, sorta).

      I guess the next step should be to make ParaJVE use the debug engine, rather than the runtime engine. The debug engine is a sub-class of the runtime engine, that can handles lots of debug events (breakpoints, running/stepping mode, ...).

      I already had a debug engine implemented at some point (since the first version of ParaJVE was running within the Eclipse debug framework, as a plugin), so hopefuly it shouldn't be too hard/long to bring it to life again...

    Friday, December 01, 2006

    ParaJVD ... A rough sketch

    This is a picture of a ParaJVD test framework that I coded to evaluate several Java Docking libraries. It is not functional at all (I was merely playing with windowing / docking features), so until I state otherwise, just take it for what it is right now : Vaporware :)

    The version in this snapshot makes use of VLDocking ; I really enjoy its Look & Fell as well as its API... So it's well on its way to be my pick.