zengei

Endianness trouble forms the backstory of the DCPU-16, but the spec states:

Yep, same thing.

You can check out the work I'm doing in the topic/device_interface branch of the repository, specifically the IDevice interface. I have two methods: byte[] GetState() and void SetState(byte[]), the idea being that when it's time to save, the add-on will get the state of every device as an arbitrary byte array and save it to a common file per vessel. When it's time to load, the add-on will do the reverse. This is nearly enough to restore state perfectly, the only rub is that if on load there are two of the same device, I still need to know which state belongs to which device (since this could be significant if they're in different stages, etc.). Still need to look into the best way to do that, looks like there's a GetInstanceID() method on game objects that could possibly serve as a unique identifier across saves and loads. One note, I consider topic branches in the repository "private", and therefore subject to arbitrary rebasing and history rewriting, just a heads up if anyone checkouts the branch. I'll never rebase or edit version branches or master, though. From googling it appears it's a BASIC language for the Nintendo DS? It's certainly possible someone could implement a compiler to DCPU-16 object code for it (heck, maybe someone already has). Not me though. Woo!

Right now the code only allows a single CPU per vessel to be active, a rather... blunt solution. I'll be looking into doing something better in the future. It wouldn't be that hard to do, the hard part would be in the UI/UX of allowing people to configure which devices were connected to which CPUs (possibly multiple!), and displaying multiple device UIs like monitor screens. In any case, I wouldn't automatically connect devices upon docking, but maybe the aforementioned UI could allow players to dynamically reconfigure the systems (after they've safely powered off the computers, of course). Dropping away devices due to staging is a problem I hadn't considered, but if you're doing that, well the only expected behavior should be unexpected behavior. (I'm not sure exactly what would happen right now if you tried to say, interrupt a device which doesn't exist, it probably just fails silently).

Yep, see this issue on GitHub. The general idea is to provide a separate assembly (Ketchup.Api) that others could include in their projects, that would provide a single interface (IDevice) that others could implement with their Parts or Modules. Then when a vessel is loaded the DCPU would scan the vessel for any parts which implement IDevice and dynamically connect them to the CPU through a wrapper class which subclasses Tomato's Device object. I've been working on loading and storing the state of the computer, which is fairly straight forward for the CPU itself, but gets complicated with external devices. I was planning on just allowing external devices to persist their own state, but this is complicated by the fact that you could have multiple of the same device attached (think dual monitors), and not only would the two instances have to store their state without colliding with each other, but when we restore state, they would have to be restored in the right order so that the right device with the right state gets the right device index. To properly support this I'll probably need a common device interface anyway, so this will likely be the next thing I work on. By the way, for anyone following this project, I plan to do weekly releases with whatever work I've done in the previous week, not when a large set of changes are ready. So releases will likely be small, but they'll be consistent and predictable. The link to the GitHub releases page is in the first post. As far as I know, yes. I was planning on using a prefix of 0xCAE00000 ('K') for any Kerbal-specific manufacturers and devices though.

Theoretically yes, I still have yet to implement any Kerbal specific devices though. Absolutely, fork away and play, and I accept pull requests. As for Kebal specific devices, Cilph has added some draft specs for hardware here: https://github.com/KerbalSystems/KSP_DCPU16_Standards/tree/master/Hardware

Well it won't run Crysis. The simulated processor runs at 100KHz and has access to 128KB of RAM. Doesn't sound like a lot, but a competent developer can do a lot with that. If I had to give a rough analogy, it's probably within an order of magnitude as powerful as a graphing calculator (one of the old school TI-83 ones, not the fancy new ones with color displays). Since the spec for the CPU has been out for a while, a number of developers have already written fairly impressive programs. A good place to see some of these is here: http://0x10co.de/. The Tetris game I was playing in the video can be found here: http://0x10co.de/ua5qu. Another thing to keep in mind is that the capability is mostly limited by what kind of external (virtual) hardware we come up with for it. We could make the Do-Everything Device, and the processor could then just talk to the Do-Everything Device and have it do... everything, but that wouldn't be in the spirit of the design.

Ha, well, great minds think a like. I saw ProgCom and realized it would be great if we could leverage all the work that's gone into DCPU-16 already (especially since 0x10c is on indefinite hold, so all that effort is just sort of... idle). Wasn't until I went to post an update did I see you had the same idea. I'd definitely welcome collaboration, the whole idea of posting this less-than-entirely-useful proof-of-concept was to garner interest and see if like minded players would like to collaborate and come up with specs for Kerbal devices to control ships. Those hardware specs and the best way to deal with time warp (see: https://github.com/dbent/Ketchup/issues/4) are the open ended problems for me. I was thinking about writing my own emulator as well, but I found Tomato and it seemed well designed and easy to reuse so I just bootstrapped from it. I'll take a look at your code as well, I could probably learn some lessons. By the way, what is its license? Also, to be fair, I didn't realize kspmodders was a thing until now. Thanks. Well a lot of work has gone into various compilers and interpreters for the DCPU-16. Unfortunately, none as high level as Python. But part of the appeal (to me at least), is seeing how much utility you can extract from few resources.

I've actually independently created a DCPU-16 plugin, Ketchup, derived the Tomato C# emulator. My implementation currently has no devices which allow control of the vessel, I was hoping to get some collaborators and interested players to reach a consensus on interfaces and specifications.

Ketchup VERSION: 0.6.0 (2013-09-08) SOURCE: GitHub DOWNLOAD: GitHub LICENSE: MIT Ketchup is a plugin which provides parts which implement a programmable CPU. The CPU is an implementation of the DCPU-16 specification, from the game 0x10c created by Notch of Minecraft fame. Similar to ProgCom this plugin only implements virtual hardware, it does nothing useful on its own. The primary advantage over ProgCom is that it uses the DCPU-16 specification, for which numerous tools, programs, and other resources have already been written. The primary disadvantage is that the current release is merely a proof of concept, no devices have been yet been implemented which allow the CPU to interact with the vessel, so it's not currently useful as a flight computer. However, programs written for the DCPU-16 can be executed in-game on the virtual processor. See this .I didn't want to create any Kerbal-specific devices as of yet, so that the specifications and interfaces for those can be developed through consensus of interested players, rather than just on my own. If you're interested give a shout here. For more information (including why it's named "Ketchup") please see the GitHub repository.