[0.90] ProgCom - CPU Emulator V0.11.1

[Cilph]

Currently trying to integrate Progcom into RemoteTech 2, which means the following:

• Moving the GUI stuff over to the RemoteTech Flight Computer;
  
• Signal delay on loading scripts and on any external input;
  
• Antenna configuration and network status via the memory map/bus.
  

Unfortunately the majority of the stuff in Progcom is marked internal, so I can't even wrap the cpu . I can play around with InternalsVisibleToAttribute locally, but it's still annoying.

That aside, the current implementation for attaching to a serial bus relies on the existence of the ProgCom part. Meaning if I replace the ProgCom part others won't be able to find a serial bus to attach to.

Edited July 1, 2013 by Cilph

[kellpossible]

Hey SimplySimon, I see you added my radial part, I hope it suits ok. I'm on holidays now so I'll have to finish the texture off for that I guess!

[SimplySimon]

Sorry for the late replies, I have been somewhat busy.

Best mod ever!

I'm glad you like it!

What a great idea!

Any chance it could be combined with Damned Robotics?

Maybe some sensors would be great, too!

What do you think?

That would be interesting, but I have other things to do before I implement sensors.

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/

I looked through it. It is interesting, but it seems to be constructed in such a way that it is quite incompatible. Thank you for the offer though!

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

Oh, wow! That does seem like a security hazard. I would like to do that, but I'm not quite sure how I'd pull it off, or if it would even be possible. The function needs to return after a while and if you accidentally make an infinite loop your game would freeze, I think. I could spawn a thread for it, but I think squad has disabled all the thread stuff. Also, I don't know if Squads policy allows mods that turn KSP into a potential tool for taking over your pc

Currently trying to integrate Progcom into RemoteTech 2, which means the following:

• Moving the GUI stuff over to the RemoteTech Flight Computer;
  
• Signal delay on loading scripts and on any external input;
  
• Antenna configuration and network status via the memory map/bus.
  

Unfortunately the majority of the stuff in Progcom is marked internal, so I can't even wrap the cpu . I can play around with InternalsVisibleToAttribute locally, but it's still annoying.

That aside, the current implementation for attaching to a serial bus relies on the existence of the ProgCom part. Meaning if I replace the ProgCom part others won't be able to find a serial bus to attach to.

I could make the cpu, keyboard and monitor public as well as add a public iSerialConnector interface to connect to instead of progcom, would that solve the problem?

Hey SimplySimon, I see you added my radial part, I hope it suits ok. I'm on holidays now so I'll have to finish the texture off for that I guess!

It suits ok. I would have given you some more time to finish it before I uploaded it, but someone requested a radial part on the irc.

Edited July 6, 2013 by SimplySimon

[MaHuJa]

There's a conflict between the Extraplanetary Launchpads build window and the progcom window. On a ship that has both, it will offer to "close" the build menu if the computer window is open. On opening it, it'll be the progcom window but stretched.

I've edited my savefile to remove the progcom component, and it worked again.

[Cilph]

I could make the cpu, keyboard and monitor public as well as add a public iSerialConnector interface to connect to instead of progcom, would that solve the problem?

I've forked it on Github and will send a pull request when I get around to finishing integration. Although currently the only things I've changed is making the cpu, assembler, keyboard, monitor public. Having a SerialConnector interface will take care of the second problem. Feel free to do any of the above without me sending a pull request though.

EDIT: Just thought of this. Might it not be a good idea to add a second CPU based on the DCPU-16 that Notch's new game uses? It has a lot of tools available.

Edited July 8, 2013 by Cilph

[SimplySimon]

EDIT: Just thought of this. Might it not be a good idea to add a second CPU based on the DCPU-16 that Notch's new game uses? It has a lot of tools available.

I've been thinking bout it. It does have a large ammount of tools available, but it would require a fairly significant rewrite. The "progcom" class could be mostly the same I think, the cpu emulator would need substantial modifications and the rest of the code would probably either have to be scrapped or completely rewritten. If I had the time I would probably do it, but since I don't currently have the time for two projects I'll focus on this one. That said, if anyone else is up to implementing DCPU in KSP, feel free to use anything you want from ProgCom's code.

[khyperia]

I've been thinking bout it. It does have a large ammount of tools available, but it would require a fairly significant rewrite. The "progcom" class could be mostly the same I think, the cpu emulator would need substantial modifications and the rest of the code would probably either have to be scrapped or completely rewritten. If I had the time I would probably do it, but since I don't currently have the time for two projects I'll focus on this one. That said, if anyone else is up to implementing DCPU in KSP, feel free to use anything you want from ProgCom's code.

*squinty eyes* Considering doing that.

Possibly. Maybe. I dunno.

Depends on a bunch of stuff.

[Cepheus]

Any news on this? I've got something I want to use it on, but I need to know how much support it'll have in the later versions of KSP. (especially concerning clock speed, and the rest)

Edited July 15, 2013 by Cepheus

[rhoark]

What kind of news are you looking for? Looking at this thread its easy to tell ProgCom is being actively developed and discussed.

[betaking]

I like this plugin, I like the idea, it could be better, a great deal better.

The problem is the implimentation of the idea. A better interface would probably look like something that would be a cross between Python's IDLE, and possibly a language derrived from C or Java, probably java, as it would need to have objects.

[Cepheus]

Agreed. If the language was one derived from C, it would make this a lot more user friendly, I think.

[drtedastro]

I would like to have the ability to have my choice of low level (asm type), mid (C type) and high level (Ida) type choices. for very specific tasks, it would be very rewarding to write the module from scratch in asm. However for fully automated probe missions, you would need to have the ability to use a more object like lang.

just my thoughts.

DrTedAstro.

[khyperia]

Agreed. If the language was one derived from C, it would make this a lot more user friendly, I think.

I would like to have the ability to have my choice of low level (asm type), mid (C type) and high level (Ida) type choices. for very specific tasks, it would be very rewarding to write the module from scratch in asm. However for fully automated probe missions, you would need to have the ability to use a more object like lang.

just my thoughts.

DrTedAstro.

Two notes: One, I hacked up a very terrible C compiler for ProgCom, I don't think it really works all too good, but it's definitely a proof-of-concept (linked somewhere at the beginning of this thread). I tried going for a full rewrite of a compiler, which might not be the best idea for full-use things (although it certainly was fun for me!) If someone writes a GCC machine description or LLVM backend, it would open up a whole world of programming languages (most in the "mid" or C range, but there's a couple high-level languages, e.g. Rust, that use llvm as a backend)

My second note: I'm taking up an idea, I'm making a DCPU emulator for KSP. The DCPU already has a bunch of tools for it (it's originally from one of notch's games, and that guy has a massive following of programming minions), including llvm backends, C compilers, and a whole swath of custom language compilers. That might also interest you, I dunno.

[drtedastro]

interesting.

[Cilph]

Have begun work on some hardware documentation for khyperia's DCPU project. Looking forward to its completion~

[zengei]

I've actually independently created a DCPU-16 plugin, Ketchup, derived the Tomato C# emulator. My implementation currently has no devices which allow control of the vessel, I was hoping to get some collaborators and interested players to reach a consensus on interfaces and specifications.

Edited July 21, 2013 by zengei
Fix url

[SimplySimon]

I thought I'd give a status update

I have implemented the non-volatile memory I have talked about, which is a tape drive. I have also done some minor changes and bugfixes to the interrupts which I hope will make them more usable, as well as some other minor changes and bugfixes elsewhere.

Currently I am redoing program loading to actually have the emulator load programs from a "tape", instead of magically inserting the program into memory like it does now. When that is done I plan to do an overhaul for the cache memory, since it doesn't behave quite realistically at the moment. That should be all for this update, so hopefully I'll get everything done relatively fast.

[drtedastro]

Hello,

just wanted to see if there was any new News??????

[Payload]

I thought I'd give a status update

I have implemented the non-volatile memory I have talked about, which is a tape drive. I have also done some minor changes and bugfixes to the interrupts which I hope will make them more usable, as well as some other minor changes and bugfixes elsewhere.

Currently I am redoing program loading to actually have the emulator load programs from a "tape", instead of magically inserting the program into memory like it does now. When that is done I plan to do an overhaul for the cache memory, since it doesn't behave quite realistically at the moment. That should be all for this update, so hopefully I'll get everything done relatively fast.

What? No braided memory? How dare you sir! I am thinking we don't need so much non-volatile memory as a tape drive. Lets just say that the programs and global values are hand woven by juvenile kerbals in vast factories called "Fun Zones" that most certainly don't resemble anything like a sweatshop. You can have a peg board looking thing. The old tape drive is played out and not as cool as woven memory.

BEHOLD!

[SimplySimon]

Hello,

just wanted to see if there was any new News??????

Not really, I'm still trying to get the program to load from a tape. I think I'm making progress though.

What? No braided memory? How dare you sir! I am thinking we don't need so much non-volatile memory as a tape drive. Lets just say that the programs and global values are hand woven by juvenile kerbals in vast factories called "Fun Zones" that most certainly don't resemble anything like a sweatshop. You can have a peg board looking thing. The old tape drive is played out and not as cool as woven memory.

BEHOLD!

While rope memory certainly is interesting it is, if I remember correctly, limited to ROM only. Since what I want to do is have some way of saving data from the emulator to somewhere it won't be deleted every time it is reset rope memory would not work for this purpose.

[Scrumilation]

I could mess around with it... if i knew anything about powerpc assembly.

But i'll try to get some auto yaw and pitch correction with the poc c compiller.

[Payload]

Not really, I'm still trying to get the program to load from a tape. I think I'm making progress though.

While rope memory certainly is interesting it is, if I remember correctly, limited to ROM only. Since what I want to do is have some way of saving data from the emulator to somewhere it won't be deleted every time it is reset rope memory would not work for this purpose.

Nope there are two kinds of rope memory. ROM and RAM. What you see the ladies making in this film is non-volatile. The volatile types used a few more wires to control the magnetic field. That requires electricity to store memory.

BTW, ROM is non-volatile storage. RAM is volatile.

The programs and mathematical constants were hand woven into this storage medium. Temporary info was stored in rope RAM and most notably, actual notebooks to be re-entered in-case of a main computer power down. That only happened one time to Apollo 13. There is no need for any real writable storage on a guidance computer. It's nice but most certainly not required. In many cases it wouldn't even be desirable. A tape, as it were, would serve no purpose besides adding weight. In space, the magnetic region on the tape would be corrupted in short order.

Edited August 13, 2013 by Payload

[drtedastro]

Nope there are two kinds of rope memory. ROM and RAM. What you see the ladies making in this film is non-volatile. The volatile types used a few more wires to control the magnetic field. That requires electricity to store memory.

BTW, ROM is non-volatile storage. RAM is volatile.

The programs and mathematical constants were hand woven into this storage medium. Temporary info was stored in rope RAM and most notably, actual notebooks to be re-entered in-case of a main computer power down. That only happened one time to Apollo 13. There is no need for any real writable storage on a guidance computer. It's nice but most certainly not required. In many cases it wouldn't even be desirable. A tape, as it were, would serve no purpose besides adding weight. In space, the magnetic region on the tape would be corrupted in short order.

H'mm, if the mag tape would be 'corrupted in short order', why did the cassette player work on Apollo 13? little itsy bitsy mag tape?

[Payload]

H'mm, if the mag tape would be 'corrupted in short order', why did the cassette player work on Apollo 13? little itsy bitsy mag tape?

Because it was analog. You might get a pop or a hiss but you won't lose everything. With computer data you really can't lose anything. The longer that tape is in space, the worse the data rot will get. I'm not really sure what relevance the size of tape makes in this comparison. Tape media is a poor choice for space travel. Reprogramming your flight computer in space is also a terrible idea for numerous reasons. I wouldn't like to die a quick but violent death because Bob went mucking about with the landing routine and left out a zero somewhere.

[drtedastro]

Paper tape would be interesting for bootstrapping.... I can just see Jeb with a paper punch 'fixing' something for Bill to try.....