[0.90] ProgCom - CPU Emulator V0.11.1

[SimplySimon]

There are a several of us. Probably we should share our ProgCom code somehow?

I for one am interested to see what everyone is doing with the mod. I don't really know how to best share code though, I suppose the only way we have currently is to post the code in the thread and/or distribute zip files of the source codes somehow.

Well it's taken me several hours, and I've still got to finish the texturing (got ambient occlusion set up as a base texture, just need to add some texture/colour and add some ProgCom text on there )

Also, I don't have unity, so at the moment the model is imported as DAE, which unfortunately I think means there is no context menu for it, and also it doesn't highlight when selected and go transperent when detached from the rest of the craft. These are bugs with KSP, I guess I need to report them at some stage if they haven't already been reported. I guess more permanent fix when the model is finished is to chuck it into unity and export it as a unity model.

Here's the zip with the part file, and source files in it:

IC.zip

I'm releasing it with Creative Commons by-sa license

So, SimplySimon, I hope you like it, let me know if you think it's ok, or if something will need to change... I made it a bigger part because: don't have to worry about it sinking into things and disapearing. and also because a cpu is a pretty powerful feature to have therefore I figure it should be a bigger part to make the user think twice before placing it on a tiny ship. (in the same spirit as other ksp parts like asas)

It looks good!

If you finish up the textures I can put it in the next version, if you want.

Radar altimeter is really cool feature, which I wanted to request myself. It's the only thing that prevent me from coding "rocket parachute" solution.

Laser distance sensors is even better - it may be used for autonomous rovers and for semi-automatic docking. It also abolish the need of the first one.

Bumper sensor looks cool, but somewhat limited usage. Cutting skycrane is the only usage I can imagine just now.

Talking about sensor, I requesting "Fuel Gauge" sensor, which fits to fuel tank and returns the level of remaining fuel there. Quite usable for automatic orbit launchers.

I'll see what I can do regarding those sensors, but they will probably not be in the next version.

SimplySimon, by the way, do source code providing with the ProgCom is contemporary (I mean, example code is little bit outdated, so the source code may be outdated too)?

I can see serial bus of some kind there, thought it not included in CPUem. Is it some plans for future?

The code is for the current version. The serial bus thing will go into the next version, I am currently using it for keyboard input. I will use it to implement external hardware to progcom, and if I have done things correctly it should be possible for other mods to interface to progcom by the serial bus.

[Spartan190]

I've been working on a C-like language compiler for ProgCom while the forums were down.

If anyone would like to help alpha-test it and submit bugs/feature requests to me, please do so! However, note that it IS in a very early alpha stage, and there will be a fair amount of glitches. I've hit the point where I couldn't find any bugs by myself, though, so it should be relatively stable.

Here's the exe, the feeble documentation, and an example gibberish test program to show the features of the language.

And here's the sourcecode repo, since that's probably required to be linked.

How to use: Open up command prompt, CD to the directory ProgComC.exe is in, and run it while passing in a file to compile. For example, to compile the test.c file included (assuming it's in the same directory as ProgComC.exe is in), you would do "ProgComC.exe test.c"

Alternatively, you can just name your C file "program.c" and it will automatically use it if no filename is passed in - so you just need to run "ProgComC.exe", or simply doubleclick on the exe.

The entire compiled unit will be written back to disk with the same filename as the source, with ".txt" appended. So, in our test.c example, the output would be named test.c.txt. This is the file that you would put in the progcom directory and run the command "load run test.c.txt" inside progcom.

The program is written in .NET 3.5, the same as KSP. Windows users should be fine, Linux users will need to install Mono, and I think Mac users also need to install Mono.

Please report any bugs or feature requests that you have!

Nice compiler (I prefer writing code in C instead of assembly)

But I got some problems with Strings. I used your svn trunk and compiled it. Then I took your test program (also wrote a little test program myself) compiled it with your ProgComC but have errors when running the code in KSP.

The problem is: my string is not put into the data section so the label cannot be recognized.

Also: when I try to run the code from your test.c.txt I get: label Inc in: Inc too large or unrecognized label. That's correct: there is no label Inc but Inc3068682575.

The test.c and test.c.txt can be found here.

In the rar is also my printStr.c and printStr.c.txt (wanted to write a method to write a string into the monitor window)

[kellpossible]

I for one am interested to see what everyone is doing with the mod. I don't really know how to best share code though, I suppose the only way we have currently is to post the code in the thread and/or distribute zip files of the source codes somehow.

GitHub is pretty much the standard around here as far as I can tell for sharing sourcecode. (Also, we can see what people have been up to in the changelog). I would recommend creating a github repository for this project. You can then have a folder in there for community examples for us to share our code as well. Feel free to chuck my model and textures up there too, I'll finish the the texture tonight.

I've also just did a patch to https://github.com/JDPKSP/RemoteTech to enable ProgCom to work in conjunction with remotetech. Probably need to submit this to the original author sometime to get it included. It's a little bit of a hack, but as far as I can tell, most of remotetech grew organically, so everything in there is a bit of hack But hey it works, and now can program probes that continue to function after losing radio contact

I'll see what I can do regarding those sensors, but they will probably not be in the next version.

I'd be happy to make some more models for that.

IThe code is for the current version. The serial bus thing will go into the next version, I am currently using it for keyboard input. I will use it to implement external hardware to progcom, and if I have done things correctly it should be possible for other mods to interface to progcom by the serial bus.

Well that does sound like good news! How would other plugins do this? Would they have to reference ProgCom's dll? Or would it be purely parts/config based?

[tallman]

I'll see what I can do regarding those sensors, but they will probably not be in the next version.

Well, probably you should not worry about coding all those (and other) sesors.

Probably better to implement universal way for external "hardware" to be connected to ProgCom. And probably one of the sesors as the demo.

Community then will do as many sensors as we want

[SimplySimon]

I've started doing some simple attitude control stuff, so far so good.

Here's my wishlist:

1. Window placement persisting between flights

2. Science instrument readings

3. Setting the current target from code

1 and 2 should be doable, 3 might be a little harder to implement though. Why do you want to set the current target from code?

[SimplySimon]

GitHub is pretty much the standard around here as far as I can tell for sharing sourcecode. (Also, we can see what people have been up to in the changelog). I would recommend creating a github repository for this project. You can then have a folder in there for community examples for us to share our code as well. Feel free to chuck my model and textures up there too, I'll finish the the texture tonight.

I've also just did a patch to https://github.com/JDPKSP/RemoteTech to enable ProgCom to work in conjunction with remotetech. Probably need to submit this to the original author sometime to get it included. It's a little bit of a hack, but as far as I can tell, most of remotetech grew organically, so everything in there is a bit of hack But hey it works, and now can program probes that continue to function after losing radio contact

Well that does sound like good news! How would other plugins do this? Would they have to reference ProgCom's dll? Or would it be purely parts/config based?

I'll set up a github repo once I have the time.

They would have to reference ProgCom's dll, implement the ISerial interface in the part/partmodule they are defining, find a ProgCom part on the ship and then connect to it. I have not worked out the details for it yet, but the basics are finished.

[Lalwcat]

Anyone still have the compiler around? I built it from source, but the .zip is gone and I'd like to see the documentation and test program

[Spartan190]

Documnetation and .zip are both in the svn trunk of the sources. Located at: ...\trunk\ProgComC\ProgComC

[rhoark]

1 and 2 should be doable, 3 might be a little harder to implement though. Why do you want to set the current target from code?

For some reason I was thinking target distance and relative velocity were among the memory mapped flight values, but I must have imagined it - so that'd be something to have.

[Lalwcat]

Nice compiler (I prefer writing code in C instead of assembly)

But I got some problems with Strings. I used your svn trunk and compiled it. Then I took your test program (also wrote a little test program myself) compiled it with your ProgComC but have errors when running the code in KSP.

The problem is: my string is not put into the data section so the label cannot be recognized.

Also: when I try to run the code from your test.c.txt I get: label Inc in: Inc too large or unrecognized label. That's correct: there is no label Inc but Inc3068682575.

The test.c and test.c.txt can be found here.

In the rar is also my printStr.c and printStr.c.txt (wanted to write a method to write a string into the monitor window)

I'm seeing the same problem with strings

[rhoark]

Is the progcom patch mainlined into RemoteTech yet?

[Blaylock1988]

So is this similar to Expression 2 from HL2 Garry's Mod?

[SimplySimon]

I have not used Expression 2, but judging from what I've found about it online it seems somewhat similar. This mod uses a much more low-level language though.

[SimplySimon]

People asked for it, so I've put up a github repository here

Also, I'm mostly done with the next update. I pretty much only have to write documentation and example code before I release it, so I'll hopefully be able to do that this week.

[SimplySimon]

Updated!

Added the keyboard and the serial stuff.

Next update I'll probably do a small overhaul on how the compiler treats strings, since that is fairly primitive at the moment. I'll also try to fix any bugs that turn up in this version.

After that I should probably get around to implementing non-volatile memory.

Edited June 9, 2013 by SimplySimon

[rhoark]

Great, thanks!

[tallman]

GitHub is, first of all, the place to share the code examples.

Can you propose the directory structure for this?

Mind: except of the code itself, you always need manual of some kind and, in most cases, craft file to test the code (especially when seriabus-powered devices will appear).

You will have possibility to compose more interesting "starter set" probably.

For example, computer-controlled rocket, which can reach the orbit "programmatically" is much more easier-to-understand example if compared to navigator.txt, I believe.

Edited June 9, 2013 by tallman

[tallman]

And then: looking at navigator.txt it looks like you added CPU_CLOCKRATE constant to the compiler (haha, it also looks like you was catched by movi / movil problem just like I was). Unfortunately, it is not mentioned in both instructionset.txt and changeLog.txt.

Edited June 9, 2013 by tallman

[SimplySimon]

GitHub is, first of all, the place to share the code examples.

Can you propose the directory structure for this?

Mind: except of the code itself, you always need manual of some kind and, in most cases, craft file to test the code (especially when seriabus-powered devices will appear).

You will have possibility to compose more interesting "starter set" probably.

For example, computer-controlled rocket, which can reach the orbit "programmatically" is much more easier-to-understand example if compared to navigator.txt, I believe.

I'm not really sure how to best organise it. I guess having a folder called "communitycode" or something similar, containing a list of folders named after authors, containing folders named after programs, containing all the documentation/code/vessels needed could make sense? So, for example: "communitycode/authorname/programname/" would contain folders named code, documentation, ships etc.

And then: looking at navigator.txt it looks like you added CPU_CLOCKRATE constant to the compiler (haha, it also looks like you was catched by movi / movil problem just like I was). Unfortunately, it is not mentioned in both instructionset.txt and changeLog.txt.

Good catch, I could have sworn I had added those to the documentation. I guess I've found out what the "+labels" thing on my todo-list meant. This will be fixed in the next update.

[tallman]

I'm not really sure how to best organise it. I guess having a folder called "communitycode" or something similar, containing a list of folders named after authors, containing folders named after programs, containing all the documentation/code/vessels needed could make sense? So, for example: "communitycode/authorname/programname/" would contain folders named code, documentation, ships etc.

Well, yes, until one need some shared code - libraries, data tables and so on.

[ahappydude]

Woa dude, this is begining to be like the game 0x0 but in a way more awesome way. I havnt tried it in a while so its going to be fun cheers

[SimplySimon]

Well, yes, until one need some shared code - libraries, data tables and so on.

I'm not sure how to organise stuff to make that as easy as possible. Do you have any ideas?

Woa dude, this is begining to be like the game 0x0 but in a way more awesome way. I havnt tried it in a while so its going to be fun cheers

I'm glad you like it!

[tallman]

I'm not sure how to organise stuff to make that as easy as possible. Do you have any ideas?

Unfortunately, no. It's the reason I asked you for this

Do #include directive supports pathes? Relative pathes? Absolute pathes?

[SimplySimon]

Unfortunately, no. It's the reason I asked you for this

Do #include directive supports pathes? Relative pathes? Absolute pathes?

As far as I know, no. However, the last time I tested if subfolders worked in the progcom plugindata directory was a couple of versions ago so it might be different now.

EDIT: I did some tests, and it seems like that still does not work

Edited June 10, 2013 by SimplySimon
did some experiments

[thewonderidiot]

Hey there, I just found this mod yesterday and have to say, it's amazing! Exactly what I've been hoping for in a mod.

I've got a few questions (these may have already been answered before the Great Forum Crash of 2013, so forgive me if I'm making you repeat yourself):

1) Why do the speed/velocity measurements have a separate, hardcoded scale factor? Is there any reason why we can't adjust it like we can the position/attitude factor?

2) I agree that a fuel level sensor would be very nice to have -- is this the sort of thing you think would be done with the serial interface, or would it be better memory-mapped along with the attitude/altitude/velocity information? As a followup, if you think it would be better with serial, what's the dividing line between memory-mapped values and external serial-interfaced values?

3) Can we get the ability to specify a startup program? It would be pretty great to have the computer load a default program without having to type "load run xxxx" every time.

4) And finally, are you accepting pull requests on github? I wouldn't mind taking a whack at some of this stuff.

Edited June 10, 2013 by thewonderidiot
fixd speeling