tallman

changeLog.txt: "you should now be able to use hexadecimal and binary constants". But one can only see hexadecimal example in instructionset.txt , and no binary.

Well, it needs a lot of trigonometric calculations. Which, in turn, needs a lot of tables, interpolation and so on. Therefore, it will be more experiment with implementing of a trigonometry, rather that experimenting with monitor

Do anyone have ideas for using of the graphical display ProgCom has? I mean, one can always implement Life or whotsoever, but what about ideas of using it for something useful? I want to have some experience with this screen, and I'll be happy if someone will propose some interesting idea for testing.

Looks like I should read about this GIT to understand how to upload code to your repository. I have a simple LED blinker and a PI-throttle-controller for maintaining zero vertical speed (i.e. it is not starting-and-stopping engine, like navigator.txt do, but tunes the throttle to compensage the gravity). I propose the structure for community code: Special folder ~/communitycode/ should be introduced for this Every program and every library should be in separate directory. This directory will have all the files with code, examples, manuals, crafts for testing, copyright notices and so on and so on. Directory for library should be named following pattern lib-something (~/communitycode/lib-vectors for example) I propose to not separate this directory by authors. It's possible to mention autorship in manual or whotsoever, but united space will stimulate us to (re)use code of their neigbours.

Unfortunately, no. It's the reason I asked you for this Do #include directive supports pathes? Relative pathes? Absolute pathes?

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

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.

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.

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, 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?

Well, I'm really not sure about it. ProgCom is "mechjeb replacement" of some kind on it's own. It can do all the same things as mechjeb can do...assuming you can provide appropriate software and align coefficients accordingly. I banned myself from using mechjeb, because it looks like computer play games with himself and I mainly looking on the pretty pictures - which is fun, but not what I'm seeking for. At the same time, I'm using ProgCom with great satisfaction. And, for example, PI-controller I designed yeasterday to control zero vertical speed, which, combined with SAS, effectively gives me possibility to build hevercrafts and cruising missiles, was very inspiring. By the way, I learned a PID controller basic theory for this, which was fun, too.

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. Trouble is: now ProgCom uses memory-mapping approach for input-output. It's much harder to implement, if you have several sensors of same type, providing different data (fuel gauges on different tanks, laser distance in different directions). Any possible "real-life" approach, like dynamic memory mapping with fixed-address descriptor structure or using of the interrupts will increase the difficulty of programming above beginner level. It's possible to implement special command for hardware input-output, like "readhw resultRegister, deviceTypeId, deviceNum", but it will be experience somewhat differ from "real" coding.

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

Are you sure? Can you open notepad, select File-Open and then copy-paste filename with full path? And we'll se if file will appear. I mean not try to visually controll all the way, just copy and paste it and try to open and we'll look. For example, I little bit worried about space in "...PluginData\ProgCo m\..."

I just found another workaround: if I press [Esc], game pauses, but computer still works (at least console commands), and I can load everything I want without affecting my vessel. It's much better solution that fast typing at the loading time.