[0.90] ProgCom - CPU Emulator V0.11.1

[opteron123]

I think (just my thought) it would be the easiest to intergrate a interrupt to the cpu.

For example we call it 0xF00BA8

The connection should reside over UDP.

The cpu will recieve packets in 16 byte length.

oooh I like that.

Building on the data payload layout that eyecikjou567 suggested (now I'm just being silly I guess and its late, but trying to keep real world SocketIO restrictions in mind) what about, say, 4 virtual GPIO buses with programmable flags and external 16 byte RAM buffers (see below) with each bus being a UDP socket OR file handle. This way it could then be extended to a databus for all sorts of virtual hardware, other then communications packages.

So the virtual hardware theory behind this is any device communicating with the CPU on the databus has DMA to external RAM modules that the CPU clocks in serially. This cuts the complexity of bus mastering from the CPU and lowers overheads from real world CPU socket/file read/writes.....maybe.

So a scheme could be:

PORT A BUFFER_ADDRESS 128

PORT A BUFFER_ADDRESS_OFFSET 129

PORT B BUFFER_ADDRESS 130

PORT B BUFFER_ADDRESS_OFFSET 131

PORT C BUFFER_ADDRESS 132

PORT C BUFFER_ADDRESS_OFFSET 133

PORT D BUFFER_ADDRESS 134

PORT D BUFFER_ADDRESS_OFFSET 135

(These are real life 16 byte socket/file buffer arrays with index)

PORT A-D FLAG REGISTER 136-139

Each ports FLAG register is bit addressable.

bit 1 - Interrupt Enable (AsyncSocketRecv() OnFileChange() )?

bit 2 - IO Direction (low= Output, High=Input)

bit 3 - Latch Data (technically not a clock/latch but a nice bit to set to fire off SocketSend() WriteFile() )

bit 4 - .... (anything else that makes Real Life socket/file IO easier)

bit 5 - .... (or any other bits that simulate control of a parallel data bus)

..

bit 32

ProgCom opens the sockets/file when the plugin starts on UDP ports 6502-6506 (homage to MOS-6502) ready for connection/listen.

SocketSend()/Writefile() is initiated when the data has been clocked from the CPU to the virtual RAM buffer and the latch bit is set to 1

SocketRecv() / OnFileChange() will flag INT_PORTNUMBER so the CPU vectors to the interrupt handler whenever there is data in a socket receive buffer.

Now if only there was a way to pump other plugin data to UDP.....

[simast]

Yeah, I think I might need a custom model for the thing. The only reason it uses the asas model is that I am crap at modeling.

I have always thought the Kerbal Engineer "chip" model would fit your mod so well. Maybe you could arrange something with the cybutek (the author of Kerbal Engineer Redux)?

[tallman]

Just bought KSP and ProgCom is the first plugin I downloaded.

I have one main question now: when I typing the commend in the console, it also affects my rocket/vessel aswel. For example, [space] is interpreted both as space in the console and as the "next stage" for my rocket. Is it possible to avoid this somehow?

[tallman]

Talking about communication: for implementing communication it's neccessary at least to have ProgCom enabled and working on the spacecrafts user don't control at the moment. Now it only works and only active for the vehicle under user's control.

I'm not sure if it possible at all. Probably KSP engine can handle only one "active" ship at a time, and other can only be handled as a passive pieces of mattery. For example, if you'll send SolidFuel engine to fly independently (activate and then decouple), it will disappear quickly (after reaching distance about 2.5 km from the command pod as from my experience).

[tallman]

I just finished my ProgCom blinker (classical "blinking led", now on ProgCom) project, and here is my comments.

1. CTL button also blocks ActionGroups from executing. It does not mentioned anywhere, and I spend lot of tyme trying to debug my code to understand what's wrong.
   
2. In "main" documention file instructionset.txt one may read "CTL toggles whether the computer can control pitch/yaw/roll etc. on and off. It also controls staging and translation until I implement separate buttons for that". But I failed to find any instructions regarding staging. Is it really possible, and if yes - then how exactly it's possible?
   
3. When using "warping" (making time faster), ProgCom continues to execute at the same speed. One may expect that when time goes 5x or 10x faster, computer acts faster aswel. If it's impossible or just too boring to implement, why not just blocking time warp when ProgCom runs a program? Just like working engine blocks warping.
   
4. In the example code navigator.txt one may find comment ";this bit of code sets the timer max to 96000 cycles (1 second)". Look like this comment a bit outdated, as long as clock rate are 384kHz now. Probably worth to implement constant CPU_CLOCK_RATE directly into the compiler?
   
5. I have strong feeling that ProgCom should consume ElectricCharge and stop to work when we run out of ElectricCharge. For purists/IT maniacs, if halted (and waiting for interrupts), it may consume less electricity then when working in infinite loop.
   
6. And, finally, why not make ProgCom module the Prob Core functionality? Why do you need additional core, when you already have ProgCom, which, in fact, programmable core by nature?
   

Edited May 23, 2013 by tallman

[SimplySimon]

I have always thought the Kerbal Engineer "chip" model would fit your mod so well. Maybe you could arrange something with the cybutek (the author of Kerbal Engineer Redux)?

I'll see what I can do.

Just bought KSP and ProgCom is the first plugin I downloaded.

I have one main question now: when I typing the commend in the console, it also affects my rocket/vessel aswel. For example, [space] is interpreted both as space in the console and as the "next stage" for my rocket. Is it possible to avoid this somehow?

That is strange, that should not happen. I am unable to reproduce this problem, do you have a sequence of steps that will reproduce the bug?

Talking about communication: for implementing communication it's neccessary at least to have ProgCom enabled and working on the spacecrafts user don't control at the moment. Now it only works and only active for the vehicle under user's control.

I'm not sure if it possible at all. Probably KSP engine can handle only one "active" ship at a time, and other can only be handled as a passive pieces of mattery. For example, if you'll send SolidFuel engine to fly independently (activate and then decouple), it will disappear quickly (after reaching distance about 2.5 km from the command pod as from my experience).

As long as the ships are less than 2.5 kilometres apart, you can have two active progcom computers running I think. If you could get computers to communicate it could help with docking, for example.

I just finished my ProgCom blinker (classical "blinking led", now on ProgCom) project, and here is my comments.

1. CTL button also blocks ActionGroups from executing. It does not mentioned anywhere, and I spend lot of tyme trying to debug my code to understand what's wrong.
   
2. In "main" documention file instructionset.txt one may read "CTL toggles whether the computer can control pitch/yaw/roll etc. on and off. It also controls staging and translation until I implement separate buttons for that". But I failed to find any instructions regarding staging. Is it really possible, and if yes - then how exactly it's possible?
   
3. When using "warping" (making time faster), ProgCom continues to execute at the same speed. One may expect that when time goes 5x or 10x faster, computer acts faster aswel. If it's impossible or just too boring to implement, why not just blocking time warp when ProgCom runs a program? Just like working engine blocks warping.
   
4. In the example code navigator.txt one may find comment ";this bit of code sets the timer max to 96000 cycles (1 second)". Look like this comment a bit outdated, as long as clock rate are 384kHz now. Probably worth to implement constant CPU_CLOCK_RATE directly into the compiler?
   
5. I have strong feeling that ProgCom should consume ElectricCharge and stop to work when we run out of ElectricCharge. For purists/IT maniacs, if halted (and waiting for interrupts), it may consume less electricity then when working in infinite loop.
   

1+2: Yeah, "Staging" in the documentation actually refers to the actiongroups. I can see how that could be confusing, so I'll fix it for the next version. If possible, I'll also create some way of activating the next stage.

3: That might be possible to implement. There will have to be a maximum clock rate, otherwise your computer would grind to a halt when warping with progcom, but other than that it could probably be done.

4: Good catch! I'll fix that for the next version. I'll probably add your CPU_CLOCK_RATE suggestion too.

5: I've been thinking about making it consume electricity, I might add that. Making it consume less electricity when halted would be difficult to implement correctly, and since halt is implemented as "br -1" I don't know if it would be correct or not.

6: In order to do that properly I think I would have to make ProgCom a part module, which is not impossible but would take some reworking. I might do that some day.

Edited May 23, 2013 by SimplySimon

[tallman]

when I typing the commend in the console, it also affects my rocket/vessel aswel.

That is strange, that should not happen. I am unable to reproduce this problem, do you have a sequence of steps that will reproduce the bug?

Well, it's happens all the time, without any special steps, both in .19.1 and (just tested) in .20

I have suggestion that it's because I'm using native Linux version, and you probably using Windows or Mac one, and therefore you, probably, can't reproduce this.

I have found workaround of some kind: there are always a lag between loading the craft model and starting of phisycal engine calculation. You can move you camera, but can't use engines, staging and so on. ProgCom works in this period (well, at least console works and it's possible to load programs), so if I load needed program quickly enought, everything going ok then. Of course, it's not comfortable, but better than nothing.

[SimplySimon]

Well, it's happens all the time, without any special steps, both in .19.1 and (just tested) in .20

I have suggestion that it's because I'm using native Linux version, and you probably using Windows or Mac one, and therefore you, probably, can't reproduce this.

I have found workaround of some kind: there are always a lag between loading the craft model and starting of phisycal engine calculation. You can move you camera, but can't use engines, staging and so on. ProgCom works in this period (well, at least console works and it's possible to load programs), so if I load needed program quickly enought, everything going ok then. Of course, it's not comfortable, but better than nothing.

I have a linux distribution installed alongside windows, so I'll try to reproduce the bug there when I get the time. Hopefully I can get this fixed for the next version, which I hope to release sometime next week.

[tallman]

I have a linux distribution installed alongside windows, so I'll try to reproduce the bug there when I get the time. Hopefully I can get this fixed for the next version, which I hope to release sometime next week.

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.

[Spartan190]

Hi, I just downloaded ProgCom and wanted to test it with the helloWorld program. So I wrote: "load run helloWorld.txt" and get the following error:

[Log]: System.IO.IsolatedStorage.IsolatedStorageException: Could not find file "D:\SteamSpiele\steamapps\common\Kerbal Space Program\GameData\progCom\Plugins\PluginData\ProgCom\helloWorld.txt".

at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0

at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0

at System.IO.File.OpenRead (System.String path) [0x00000] in <filename unknown>:0

at System.IO.StreamReader..ctor (System.String path, System.Text.Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize) [0x00000] in <filename unknown>:0

at System.IO.StreamReader..ctor (System.String path) [0x00000] in <filename unknown>:0

at KSP.IO.TextReader.CreateForType[Assembler2] (System.String filename, .Vessel flight) [0x00000] in <filename unknown>:0

at Assembler2.readFile (System.String fileName) [0x00000] in <filename unknown>:0

at Assembler2.loadText (System.String fileName) [0x00000] in <filename unknown>:0

at Assembler2.assemble (System.String fileName, Int32 loadLocation) [0x00000] in <filename unknown>:0

at ProgCom.load (System.String s) [0x00000] in <filename unknown>:0

at ProgCom.loadWrapper (System.String s) [0x00000] in <filename unknown>:0

Looks like he doesn't find the file. But it is in that folder, everything is fine with the structure.

[tallman]

Looks like he doesn't find the file. But it is in that folder, everything is fine with the structure.

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\..."

[rhoark]

It's looking in the .20-style plugin data directory. The folders in the zip are probably still .19-style.

[rhoark]

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

Edited May 24, 2013 by rhoark

[kellpossible]

I checked out the k compiler(didn't try to write anything in it yet) but I would really like a proper c compiler that we we could just port existing stuff like stdlib for use on ProgCom.

I had a look at LLVM, it's a open source compiler infrastructure that can be used to make custom languages or compile existing languages to any platform that you define. I just don't have the understanding of how compilers work and don't really have the time to start learning it now.

Maybe someone could try to use it to make a proper compiler that compiles basically any language you to ProgCom assembler(it could even make ProgCom binaries if loading them would be supported).

If we do get a good c compiler I'd be happy to help porting a standard lib for it.

GCC can also be customized to compile to a system you define but from what I have seen LLVM seems better and it can actually use GCC intermediate code to compile to its destination.

Ill try to think up a nice model for ProgCom, I was thinking to make 3 stack models(in different sizes) and one side mounted one.

How about something like this for the model?

[Spartan190]

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 put the mod into the new style and he is looking in the correct folder, the path does exist and the file, too.

Edit: Found the problem. He was really looking into new path. Thought folder is just PluginData but it's Plugins/PluginData

Edited May 24, 2013 by Spartan190

[tallman]

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

[String]

How about something like this for the model?

I haven't really had the time to work on a model but that could be nice, when I get some free time ill work on something.

[rhoark]

The latest version of Kerbal Engineer uses a model that looks like some kind of retro reel-to-reel tape device. I plan to use an override cfg for my own purposes that loads Engineer, ProgCom, Fuel Balancer, Graphotron, and RemoteTech all on that one part. Probably a probe core ring version too.

Edited May 24, 2013 by rhoark

[kellpossible]

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)

Edited May 24, 2013 by kellpossible

[kellpossible]

although, come to think of it, a cpu like this would be great on remote probes, so maybe I should make a miniature version.

I haven't tried out remote tech with this mod yet because I switched to 0.20, just wondering

does it work to control the ship even when the probe is out of range in remote tech? If it does I guess this would make it possible

to write landing software for when the probe/lander is on missions which usually have a 10 minute communication latency with remote tech, thus making landings

impossible without some form of local control like this for instance . If this requires some work on remote tech I've got the remote tech source code with me, so I could

give it a crack some time.

Edited May 24, 2013 by kellpossible

[kellpossible]

Ok, so looks like remotetech only gives control to itself, and to mechjeb (when the probe is in range). So I'll make a few changes, and add support for ProgCom as a source of control, and perhaps provide a list or something to switch between the available control sources...

I was also thinking, perhaps it might be worth making some sensor modules while I'm at it. like radar altimeter, bumper sensors, laser distance sensors, etc. Then perhaps progcom could adjust the available hardware for polling based on which hardware is part of the ship in the vab.

EDIT: and what would be really cool would be support for mechjeb! if this cpu could manipulate mechjeb (if it is attached to the ship) and use that as its control system instead of its own that would be fantastic, then get all the functions for auto landing, orbit transfers, docking, the whole shebang. That's probably a bit of a dream... but hey mechjeb is open source, so it should be possible to make the changes. I'll see if I can get remotetech to work first

Edited May 25, 2013 by kellpossible

[tallman]

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.

[tallman]

if this cpu could manipulate mechjeb (if it is attached to the ship) and use that as its control system instead of its own that would be fantastic, then get all the functions for auto landing, orbit transfers, docking, the whole shebang

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.

[tallman]

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?

[kellpossible]

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.

Well, one could implement memory mapped i2c or spi registers. Then each sensor device would be representing an i2c or spi device which can communicate with the cpu via one of those protocols. spi is simpler, but i2c would not need any extra registers per sensor or device. But you are right, this would definitely raise the bar for beginners. Although, one could probably implement a library on top of a lower level serial protocol to make it simple for beginners...

I've spent a good chunk of today sifting through the complicated tangle of remotetech's gui code and learning about unity programming along the way, so hopefully when I've gotten this to work I could move on working exciting stuff like this 3d modelling and texturing is soooo much more relaxing than coding unfortunately.

I've got the feeling you are correct about the mechjeb stuff. If we can get enough sensors and input from ksp, it should be possible to port a lot of the autopilot functionality to this ProgCom as an autopilot library or something like that.