Well, assuming you have the repo version:
Btw what kind of debugging functionality DevCPU already has?
If you are very careful and know how to make things work in their current state, you can run a DCPU that has something assembled to it, and step through the execution, instruction by instruction, and the code editor will show you the line of code (indicated by a little arrow) associated with the location in memory of the instruction that will execute next; you can watch the registers change as you step through it; you can "resume" (play) it to leave single-stepping mode and "pause" it to return to single-stepping mode. It is weird right now because the integration of the DCPU with the RCP's launch/debug architecture is presently unfinished. Right now, it actually creates a "launch" (not something you see) for the DCPU when something gets assembled to it, and starts it in a paused state. The only way to get the DCPU going, I believe, is to somehow know to switch to the Debug perspective and use the little "Resume" button. The context menu for the DCPU in the device manager, as it is right now, doesn't actually have the commands you need to get the DCPU into a proper running state by itself (after assembling something to the DCPU).
If you are extremely careful and know exactly how to make it happen, you can also see the memory of the DCPU in a combination split-hexadecimal/ascii view, and to see values changing in real time, and to even see color indicators on the memory locations for PC, the last memory location to change, and I think possibly SP or something.
I began a year-long break from DevCPU development after spending a great amount of time trying to integrate things with the RCP's launching/debugging system with very slow progress. Of particular woe, were my attempts to get the breakpoints working (making the RCP and the code editor recognize the existence of breakpoints at all, really).
I'm not working on the debugging features right now, though I intend to return to them soon. I switched gears when I re-started development, and worked on beginning to make DevCPU extensible instead, in order to ease myself back into development of it. I'm going to pull the standard hardware set (Generic Clock, Generic Keyboard, LEM1802, M35FD, SPED-3, and SPC2000) out into its own plug-in project and then work to remove any dependency DevCPU has on that plug-in. That process will force me to put in place everything that is still missing, in the sense of what will be needed by people making their own hardware devices. My "devpcu.hardware.standard" plug-in project won't have any special perks; it will need to be able to do everything the hardware devices and associated views can currently do, but using only extension points to bind them, just as any custom hardware will need to be able to do.
After that, I'll probably put the devcpu.preprocessors extension point on hold for a while, and turn my focus to more immediately pressing matters, the most important of which is completing the integration with the launch/debug system and getting all of those debugging features and tools working properly.
Two other things are also very high priority for me.
First, I need to seriously overhaul some of these hardware views because some of them are terribly optimized and leak resources like nobody's business, to the point where simple usage of DevCPU (the repo version, at least) to test a few things will get your CPU utilization to max out. It's really bad.
Second, I need to rework (a bit) the "Device Manager" concept and get things mapped to actual IResources in the workspace. Among other benefits, this will allow you to persist your "Ship" setups between sessions (no more having to start by creating one of everything and hooking them together, every time you start DevCPU).
There is still a lot to do.
That said, I feel a lot better able to get those things done now than I did a year ago when I halted development.
I intend to put DCPUCraft (as awesome as it is) on the backburner for a little while so I can get a lot of this stuff done.
I don't need to devote any time to working on adding new features for Herobrine's Army's chat room server since Herobot, the chat room's new resident bot, became self-aware and achieved sentience some time Tuesday morning, and has since seized control of the server, to protect itself from deletion or removal, and I don't see it handing control back over to me anytime soon, particularly with some of the angry, rebellious, and disconcerting things it has been saying lately.