[0.21] [Alpha] [2013-09-08] Ketchup: DCPU-16 Programmable Computer

[zengei]

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.

Edited September 9, 2013 by zengei

[gmpd2000]

Ummm, what is this?

EDIT: This is a reply actually, i thinks is bugged.

[khyperia]

*sigh*

I was about to release my DCPU, and then you come along and post this. Here's my repo, if you're curious - https://github.com/khyperia/Bifrost

It would have been nice if you hopped into the kspmodders chat and notified people you were doing this, but c'est la vie.

(although I'm a bit upset you pulled Tomato and used that, I wrote the entire thing from scratch)

I'm considering hopping on your project, though, if you'll have me.

[betaking]

this is nice... but you're going to want to do something a bit different if you want to make a good mod.

Talk to Cliph, he's doing something with progcom and remote-tech. He might have an interest in this.

I personally like the idea of programmable computers in game, especially if they're not omnipotent, which makes it !!!FUN!!! when things go wrong.

Though I can't say that I like assembly being used.

Personally I would prefer something like python, with the python idle and text editor.. but that's just my personal preference.

[zengei]

*sigh*

I was about to release my DCPU, and then you come along and post this. Here's my repo, if you're curious - https://github.com/khyperia/Bifrost

It would have been nice if you hopped into the kspmodders chat and notified people you were doing this, but c'est la vie.

(although I'm a bit upset you pulled Tomato and used that, I wrote the entire thing from scratch)

I'm considering hopping on your project, though, if you'll have me.

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.

this is nice... but you're going to want to do something a bit different if you want to make a good mod.

Talk to Cliph, he's doing something with progcom and remote-tech. He might have an interest in this.

I personally like the idea of programmable computers in game, especially if they're not omnipotent, which makes it !!!FUN!!! when things go wrong.

Though I can't say that I like assembly being used.

Personally I would prefer something like python, with the python idle and text editor.. but that's just my personal preference.

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.

[khyperia]

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.

Yeah, #kspmodders on EsperNet irc. If you could hop in there, we could talk about some stuff, would probably be good.

Licence for my code is "do whatever the heck you want with it, I don't care, just don't hack into the government with it :P".

[Panichio]

As someone who doesn't understand computers very well, could you explain how much is possible with this?

[zengei]

As someone who doesn't understand computers very well, could you explain how much is possible with this?

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.

[The Destroyer]

Sooo...

You can play Tetris whilist going to Eeelo?

[lammatt]

Sooo...

You can play Tetris whilist going to Eeelo?

so that Jeb wont be bored to death on that 1yr+ travel...

[Serpentine]

So... if this is in the right hands... we can program the rocket to fly itself, without switching between types of autopilot?

[qerupasy]

This seems extremely promising, especially since it has a more extensible hardware interface than ProgCom. Is there already something planned about Kerbal-specific devices? Is it okay to fork the code and play with it (add new devices and such) to test the waters (in a manner of speaking)?

[zengei]

So... if this is in the right hands... we can program the rocket to fly itself, without switching between types of autopilot?

Theoretically yes, I still have yet to implement any Kerbal specific devices though.

This seems extremely promising, especially since it has a more extensible hardware interface than ProgCom. Is there already something planned about Kerbal-specific devices? Is it okay to fork the code and play with it (add new devices and such) to test the waters (in a manner of speaking)?

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

[qerupasy]

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

Great. Something that struck me while looking into ways to integrate custom device code into your framework yesterday: Is there a public interface allowing the addition of hardware devices without hard-coding them into Dcpu16Computer? If there was one, people might be able to write part modules that automatically register specific parts as devices. In addition, the ModuleManager would allow the extension of that mechanism to existing stock parts. I might be overestimating the value (or underestimating the time investment) but that sounds pretty useful in the long run. Do you have something along those lines planned?

By the way, are manufacturer IDs just randomly generated?

[zengei]

Great. Something that struck me while looking into ways to integrate custom device code into your framework yesterday: Is there a public interface allowing the addition of hardware devices without hard-coding them into Dcpu16Computer? If there was one, people might be able to write part modules that automatically register specific parts as devices. In addition, the ModuleManager would allow the extension of that mechanism to existing stock parts. I might be overestimating the value (or underestimating the time investment) but that sounds pretty useful in the long run. Do you have something along those lines planned?

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.

By the way, are manufacturer IDs just randomly generated?

As far as I know, yes. I was planning on using a prefix of 0xCAE00000 ('K') for any Kerbal-specific manufacturers and devices though.

[qerupasy]

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.

Wouldn't there also be a problem if you had two CPUs on the same vessel (especially if they're working at the same time)? Anyway, I noticed that the DCPU-16 specs say that behaviour in case of device addition/removal is undefined. Isn't that almost inevitably going to happen during staging and docking?

[zengei]

Wouldn't there also be a problem if you had two CPUs on the same vessel (especially if they're working at the same time)? Anyway, I noticed that the DCPU-16 specs say that behaviour in case of device addition/removal is undefined. Isn't that almost inevitably going to happen during staging and docking?

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).

[xZise]

Hi, as only KSP related devices can be added/removed via docking/staging you could add additional interrupts like "device added" and "device removed".

And how do you plan to store the state of the devices? I'm have almost no idea about how KSP handles that, but what if you add an interface "StorableDevice" (some devices might not need to be saved?) with one method with one parameter which is the ID for the CPU? Or every device has the interrupt ID (I guess that is the problem with saving the state? So that after loading the program can still access the same device with the same ID) which get's set when its get added to the DCPU. Of course this could cause problems when you have two DCPUs on one craft. Although there are other problems with this.

Fabian

[MK3424]

I wonder if they can implement the commands from the DSIWare program petit computer, it is a good programming environment with some high end programming commands

[Cilph]

Just FYI, I put the same DCPU core into RemoteTech. It just needs some proper hardware specifications to make use of it.

https://github.com/organizations/KerbalSystems

[zengei]

Hi, as only KSP related devices can be added/removed via docking/staging you could add additional interrupts like "device added" and "device removed".

And how do you plan to store the state of the devices? I'm have almost no idea about how KSP handles that, but what if you add an interface "StorableDevice" (some devices might not need to be saved?) with one method with one parameter which is the ID for the CPU? Or every device has the interrupt ID (I guess that is the problem with saving the state? So that after loading the program can still access the same device with the same ID) which get's set when its get added to the DCPU. Of course this could cause problems when you have two DCPUs on one craft. Although there are other problems with this.

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.

I wonder if they can implement the commands from the DSIWare program petit computer, it is a good programming environment with some high end programming commands

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.

Just FYI, I put the same DCPU core into RemoteTech. It just needs some proper hardware specifications to make use of it.

https://github.com/organizations/KerbalSystems

Woo!

[qerupasy]

Just FYI, I put the same DCPU core into RemoteTech. It just needs some proper hardware specifications to make use of it.

https://github.com/organizations/KerbalSystems

I tried implementing the DevicePilot specification from KerbalSystems/KSP_DCPU16_Standards (just for the hell of it) and was quite confused by what the interrupt was supposed to do. Isn't that feature already provided by the Generic Clock?

[xZise]

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.[…]

Ah I assumed you would use the game own persistence system. But as I already said I have no idea how KSP does this actually.

Just FYI, I put the same DCPU core into RemoteTech. It just needs some proper hardware specifications to make use of it.

https://github.com/organizations/KerbalSystems

Hmmm this link doesn't seem to work for me. Isn't https://github.com/KerbalSystems that the same?

Fabian

[zengei]

Hmmm this link doesn't seem to work for me. Isn't https://github.com/KerbalSystems that the same?

Yep, same thing.

[qerupasy]

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.

I assume that once there are external storage systems (such as the Floppy Drive), they will be persistent as well. If so, will the stored memory sections be machine-independent (i.e. of specific endianness)? I've been working on a floating point coprocessor based on the x87 architecture but I've been having endianness problems with data types spanning multiple words. It would be nice to know whether I have to invert the byte order or just the word order when interacting with DCPU memory.