Page
of 26

DevCPU

259 replies
Posts:
4,713
Stars:
+1,644
Untagged users
wrote:
Btw what kind of debugging functionality DevCPU already has?
Well, assuming you have the repo version:
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.
livechat.png
Posted Jul 18, 14 · OP
Posts:
408
Stars:
+122
Untagged users
Thanks - It was interesting to hear about your plans and stuff under the hood.

Sooner or later DCPU based games and mods will emerge. Whether any of those will gain popularity is another story, but without proper dev tools failure is guaranteed.

Your plans sound solid, and from user perspective (aka my perspective) debugging features, support for hardware extensions and export functionality (easy way to dump the compiled code to file) are on top of the list.
Posted Jul 19, 14
Posts:
1
Stars:
+1
Untagged users
Is there any way to obtain the binaries other than compiling the repository version? The download page no longer exists... :/
Posted Jul 20, 15
Posts:
4,713
Stars:
+1,644
Untagged users
wrote:
Is there any way to obtain the binaries other than compiling the repository version? The download page no longer exists... :/
Sorry, I didn't update the DNS records for DevCPU.com when the IP changed. It's fixed now (though it could take an hour or so to propagate to your ISP's DNS).

On the subject of DevCPU, I really do intend to work on it more. The stuff that's in the repository is already way better than the old binary version that's available on DevCPU.com, and whenever I get time to work on it more, it will get even better. When I start to see more progress on some of the DCPU-16-based/derived games (Megastage, Project Trillek, etc.), I'll make it a higher priority.
livechat.png
Posted Jul 21, 15 · OP
Posts:
408
Stars:
+122
Untagged users
I am fully aware of the slim changes that anybody would answer this post, but I ask anyway :-)

I just witnessed GPU running 1000+ DCPUs (emulated with CUDA) without breaking a sweat. I wonder how it compares to high-end CPU capacity - I never really tested it.
Posted Oct 7, 15
Posts:
4,713
Stars:
+1,644
Untagged users
wrote:
I am fully aware of the slim changes that anybody would answer this post, but I ask anyway :-)

I just witnessed GPU running 1000+ DCPUs (emulated with CUDA) without breaking a sweat. I wonder how it compares to high-end CPU capacity - I never really tested it.
Well, a while back, I started making a DCPU mod for Minecraft. Here's a video showing 580 different DCPUs with 580 different attached LEM1802s, all emulated on CPU, and I wasn't even trying to be efficient.I've tried to do DCPU emulation on GPU before, but the logic is so conditional and branching that it isn't an ideal problem for GPU; it doesn't benefit that much from it because it isn't highly parallelizable in the right way. GPU wants to perform the same instructions across multiple cores at the same time, just with different data. DCPU-16 emulation doesn't fit that very well.
livechat.png
Posted Oct 7, 15 · OP
Posts:
703
Stars:
+256
Untagged users
Hi, been a while, anyone out here?
Posted Oct 11, 15
Posts:
4,713
Stars:
+1,644
Untagged users
I'm here. handup.gif
livechat.png
Posted Oct 11, 15 · OP
Posts:
703
Stars:
+256
Untagged users
Just found my old MegastageCS code, been a while what with the job and a move. Figured I would come back to see if anyone was alive. Seems this place is suffering a heat death much like the world is was based in, a very slow one.
Posted Oct 12, 15
Posts:
200
Stars:
+23
Untagged users
Um... all you know that Space Enginers is open source ?? I think that an DCPU-16 emulator running inside would be pretty close to was 0x10c was supussed to be ... I think.

Also, about emulating inside of a GPU, I repply about it on reddit : https://www.reddit.com/r/dcpu16/comments/3ilzu0/dcpu16_emulator_as_glsl_fragmentshader/cv14oho
wrote:
I remember some talk time ago, about running the virtual CPU on the GPU...

GPU aren't friendly to branching code (and you would do a lot on a interpreter VM!, and I don't know if would be possible to do JIT on a GPU). So probably only could do efficiently a CPU per GPU warp (ie per CUDA code). Ie, running not too many CPUs at same time (32, 48 , more ??)

If someone would try this, should try with OpenCL or using OpenGL/DirectX compute shaders. Using fragment shaders it's actually pretty primitive and ancient way of doing this kind of tasks.

It could be interesting try it, even if the GPU are working on a bad situation, it would offload the CPU to another tasks.
Yep, I'm afraid that I have a blog: zardoz.es
Trillek computer specs
Trillek computer implementation
DCPU & LEM180X tools
Posted Oct 22, 15
Page
of 26
Login or Register
Latest Threads
0x10c.com Feed
There are no entries in this feed.
NoticeNotices