[0.90] ProgCom - CPU Emulator V0.11.1

[frash23]

Never.

Linux does run on intel or intel-compatible cpus.

There are other linux compatible kernels for ppc and arm but

this cpu has not enough power and the ISA is to low for a full kernel or

operating system.

No offence to simplysimon, but this cpu (or better the envoirment) is designed for batch

processing and maybe a very very small disk os (dos).

I haven't read the rest of the post, but not even uClinux?

Running a NES emulator on that would be hilarious

[rhoark]

There doesn't seem to be any facility for memory remapping or partitioning, but the timer interrupt is all you need for multitasking. There's enough to work with that someone could implement stdlib and a POSIX system, if they were inclined.

[SimplySimon]

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 mine taking a whack at some of this stuff.

1) I just kind of haven't gotten around to it yet. All the code I've used have been fairly ok with the current precision so it hasn't felt like a priority. I should probably implement it, it should be fairly easy.

The fixed point vector stuff in general was initially only meant as a solution to the problem of "I don't have floating point numbers yet", and since I have implemented floating point numbers now I should probably just change all vectors to use those instead (IIRC floating point support has been in every released version of progcom so I really don't have an excuse). I've been putting it off since it is fairly easy to convert the vectors to floating point numbers, and changing it would require me to A) do some rewriting in a bunch of places, change how all the example code works, and C) break all code everyone has written for this mod that references those vectors.

2) I think that it would be better implemented as a serial interface thing, since then you could could implement it as an external part and do stuff like measure fuel levels in specific stages or fuel tanks instead of some hardcoded behaviour.

I don't really have a set-in-stone way of determining serial vs memory-mapped. Things which are separate parts would of course require the serial interface, since that is the only way to interface to ProgCom from "the outside". Other than that, the memory mapped stuff is from things that I feel could be present "on chip" as it were, accelerometers and other small components, while the keyboard is "separate" so it is connected through the serial cable (plus, I needed something to demonstrate the serial stuff). It is not a perfect definition, but it is what I try to follow when adding features (or will follow, since the serial stuff was implemented this version).

3) I could implement that, but it would probably have to wait until the non-volatile memory stuff since I plan to do a rewrite of program loading once I get to that. I suppose if you insert a tape/disc/whatever into the computer it would still be there when you restart.

4) I accept pull requests, yes

[thewonderidiot]

1) I just kind of haven't gotten around to it yet. All the code I've used have been fairly ok with the current precision so it hasn't felt like a priority. I should probably implement it, it should be fairly easy.

The fixed point vector stuff in general was initially only meant as a solution to the problem of "I don't have floating point numbers yet", and since I have implemented floating point numbers now I should probably just change all vectors to use those instead (IIRC floating point support has been in every released version of progcom so I really don't have an excuse). I've been putting it off since it is fairly easy to convert the vectors to floating point numbers, and changing it would require me to A) do some rewriting in a bunch of places, change how all the example code works, and C) break all code everyone has written for this mod that references those vectors.

Ah, that makes sense! © kind of sucks though.

2) I think that it would be better implemented as a serial interface thing, since then you could could implement it as an external part and do stuff like measure fuel levels in specific stages or fuel tanks instead of some hardcoded behaviour.

I don't really have a set-in-stone way of determining serial vs memory-mapped. Things which are separate parts would of course require the serial interface, since that is the only way to interface to ProgCom from "the outside". Other than that, the memory mapped stuff is from things that I feel could be present "on chip" as it were, accelerometers and other small components, while the keyboard is "separate" so it is connected through the serial cable (plus, I needed something to demonstrate the serial stuff). It is not a perfect definition, but it is what I try to follow when adding features (or will follow, since the serial stuff was implemented this version).

Sounds good. I really like the idea of having one fuel sensor per tank idea, but it would probably fill up your serial interfaces really quickly -- maybe there could be a dedicated fuel sensor controller that would interface over serial to ProgCom, which collects and passes along information from all fuel sensors on the vehicle. That way you would only need to take up a single serial line (just thinking out loud here... )

3) I could implement that, but it would probably have to wait until the non-volatile memory stuff since I plan to do a rewrite of program loading once I get to that. I suppose if you insert a tape/disc/whatever into the computer it would still be there when you restart.

Yep, that would be perfect! You could just check for some type of valid boot record at the beginning of the nonvolatile memory and use it if it's there

[thewonderidiot]

Whoops, double post. Ignore.

Edited June 11, 2013 by thewonderidiot

[SimplySimon]

Ah, that makes sense! © kind of sucks though.

Yeah. I suppose I could implement a second set of variables, but that seems like a suboptimal solution. I'll probably keep it as it is unless I discover some crippling flaw with the current system.

Sounds good. I really like the idea of having one fuel sensor per tank idea, but it would probably fill up your serial interfaces really quickly -- maybe there could be a dedicated fuel sensor controller that would interface over serial to ProgCom, which collects and passes along information from all fuel sensors on the vehicle. That way you would only need to take up a single serial line (just thinking out loud here... )

Yeah, the issue of "not enough interfaces" would need to be solved somehow. That would probably be a good solution. If you knew the ammount of fuel in a stage and your fuel consumption you could also bypass fuel sensors by doing some sort of integration in software. It could be tricky to make that work properly though.

Yep, that would be perfect! You could just check for some type of valid boot record at the beginning of the nonvolatile memory and use it if it's there

I'll probably do something along those lines.

[rhoark]

For the fuel you could write to it the number of a fuel tank and it would write back the fuel in that tank.

[tallman]

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:

1. Special folder ~/communitycode/ should be introduced for this
   
2. 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.
   
3. 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.

[tallman]

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.

[SimplySimon]

I propose the structure for community code:

1. Special folder ~/communitycode/ should be introduced for this
   
2. 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.
   
3. 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.

That seems like it would work. If nobody has any objections, I can put the folder on the github repo.

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.

I guess some kind of orbit display could be interesting, show periapsis/apoapsis, the shape of the orbit and position of the ship. The map does that already, but it would be interesting to see if it could be implemented in progcom.

[tallman]

I guess some kind of orbit display could be interesting, show periapsis/apoapsis, the shape of the orbit and position of the ship. The map does that already, but it would be interesting to see if it could be implemented in progcom.

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

[SimplySimon]

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

You are probably right. I don't really know what else to use the screen for, perhaps draw some graphs?

[joppiesaus]

Wow. This is actually handy and cool. You can code your own stuff in game!

[thewonderidiot]

Yeah. I suppose I could implement a second set of variables, but that seems like a suboptimal solution. I'll probably keep it as it is unless I discover some crippling flaw with the current system.

Hmm, okay. I'm probably going to make a branch that just uses floats for all of the values, so if you ever change your mind (or have some update in the future that breaks backwards compatibility anyways), it'll be there.

Anyways, I've never used C# or built a plugin for KSP before, so I started off with something fairly simple -- I added support for hex and binary literals pretty much everywhere a user can use a number in their program (all using a generic function as a wrapper around the various Convert.ToXXX methods). I tend to think in hex a lot, so being able to load immediate hex numbers is nice. I pushed the changeset out to my fork, and, depending on how you like to do your project management workflow, can issue a pull request for it if you would like.

[SimplySimon]

Hmm, okay. I'm probably going to make a branch that just uses floats for all of the values, so if you ever change your mind (or have some update in the future that breaks backwards compatibility anyways), it'll be there.

Anyways, I've never used C# or built a plugin for KSP before, so I started off with something fairly simple -- I added support for hex and binary literals pretty much everywhere a user can use a number in their program (all using a generic function as a wrapper around the various Convert.ToXXX methods). I tend to think in hex a lot, so being able to load immediate hex numbers is nice. I pushed the changeset out to my fork, and, depending on how you like to do your project management workflow, can issue a pull request for it if you would like.

Great! I looked through the changes and it looks good. If you issue the pull request I can test if everything works and release the next update as soon as possible.

[thewonderidiot]

Great! I looked through the changes and it looks good. If you issue the pull request I can test if everything works and release the next update as soon as possible.

Done! I just realized that there's a bit of wonky brace-formatting in the Util.parseTo() -- I thought I had all of the format settings right in Visual Studio but it looks like I missed one, and it reformatted stuff on me right before I committed. Got that fixed now. And I just noticed that you added in a GLOBAL_SPEEDACCURACY -- thanks!

[SimplySimon]

Done! I just realized that there's a bit of wonky brace-formatting in the Util.parseTo() -- I thought I had all of the format settings right in Visual Studio but it looks like I missed one, and it reformatted stuff on me right before I committed. Got that fixed now. And I just noticed that you added in a GLOBAL_SPEEDACCURACY -- thanks!

It seems like everything works, I only found one minor issue which was easily fixed.

Thus, we are now on version 0.8.1!

Added a few new instructions, better strings and some more!

Next update will probably be the nonvolatile memory, which will probably try to emulate a tape drive. I might also make some changes to the cache memory, I'm not really satisfied with how that works at the moment.

Edited June 17, 2013 by SimplySimon

[SimplySimon]

Minor update:

I added a radial part and put the "communitycode" folder up on the github repository.

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

[xorg]

Best mod ever!

[bulletrhli]

I have absolutely no idea how to work with mod..

[rainerd66]

What a great idea!

Any chance it could be combined with Damned Robotics?

Maybe some sensors would be great, too!

What do you think?

[skykooler]

Best mod ever!

Wow, this is only a few steps from a Kerbal Grasshopper!

[HoneyFox]

Hmm... I've written another simple script interpreter several weeks ago...

And i wonder if i should show it here so that you can consider use something from it.

Anyway i post the url here...

https://github.com/HoneyFox/AsmInterpreter/

[khyperia]

You know what would be really great... is if ProgCom was no longer interpreted, but rather compiled in-memory.

It's really simple to do. Only problem is compatibility, but hey, most people have x86 nowadays, so say "screw you" to all the other people

Basically, http://stackoverflow.com/a/959144/901037

I'll put into English words what that code is doing.

You take a byte[] array, standard C#, normal stuff. You fill it with binary machine code opcodes doing literally whatever you want it to do. You copy it over to a section of memory with the executable bit set. You convert it to a delegate. You call it.

Essentially, executing raw machine code.

Also, that is really terrifying that it is so simple and easy to do something like that. Like, seriously terrifying.

Edit: You can also use Reflection.Emit, but that's boring