SimplySimon

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.

Sorry for the late replies, I have been somewhat busy. I'm glad you like it! That would be interesting, but I have other things to do before I implement sensors. 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! 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 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? 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.

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

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.

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.

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

That seems like it would work. If nobody has any objections, I can put the folder on the github repo. 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.

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. 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. I'll probably do something along those lines.

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

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

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

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

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.

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.

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.

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.

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?

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. It looks good! If you finish up the textures I can put it in the next version, if you want. I'll see what I can do regarding those sensors, but they will probably not be in the next version. 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.

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'll see what I can do. 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? 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. 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.

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. That might be possible, I'll see what I can do. I had hoped to have a way for people to do their own extensions to progcom using a serial interface, but since the interface doesn't seem to show up in the final dll at the moment I don't know if I can get that working. Neato! I've tried it out, and I found a few issues: first: It seems like you are allocating all variables for all functions at fixed locations in the data section instead of on the stack. This means that recursive functions might not work as intended. second: While all variables are meant to be stored in the data section you don't actually allocate any space for them there. This means that you will be writing to the next section instead, which is the stack. This means that variables can change when something is pushed to the stack, and contents on the stack can be overwritten every time a variable is accessed. third: You seem to use register a15 in some functions. This is probably a bad idea, since a14 and a15 are used in interrupts, which means that their contents can change to fairly arbitrary values at arbitrary intervals if interrupts are enabled.

While I want to add some sort of wireless communication between ships eventually, that is probably a long way off since there are a lot of things I feel I should do first. Good to hear you are making progress on your compiler though!

If you have installed the plugin and the plugindata folders correctly, you should be able to run a program by entering "load run filename.txt" into the console. The most interesting program in the example code at the moment is probably navigator.txt. So, to run it you just enter "load run navigator.txt" into the console and turn it on. Then you enter the vertical speed you want the craft to hold multiplied by 16 into the numpad and press enter, so if you want the craft to go upwards at 1m/s you enter 16. Then you press the "TTL" button to give the computer control over the throttle, and then the program should be running properly. The assembly code is a bit more complicated to explain though, especially in a single forum post. There should be some places on the internet that explain the basic concepts of assembly programming, and if you know those and have some experience with a low level language like C you I think you be able to understand the basics of progcom assembly from the documentation and the example code. If you have any specific questions, feel free to ask here or when I'm on the IRC.

Updated! Fixed some of the bugs that were reported before the forums reset. I also added a monitor. Next up is a keyboard, probably. I could make a video, but it'd probably just be a video of how the example code works. Would that be interesting to watch? I could try, but you'll have to be a little more specific. Did you have trouble installing it, could you not run any programs or was the assembly language too confusing?

This mod adds a CPU emulator to the game which you can program with the assembly language that is described in the included manual. It is able to control most aspects of the spacecraft such as throttle, actiongroups, pitch/yaw/roll, translation and staging. For example, if you want to make a program that turns the throttle up to 100% after 10 seconds, you can do this: .text #include libLabel.txt #global main main: wr r0, r0, GLOBAL_TIMER;reset timer movil r1, CPU_CLOCKRATE;ammount of cycles in a second muli r1, r1, 10 loop: rd r2, r0, GLOBAL_TIMER bl r2, r1, loop movi r3, 1024 wr r3, r0, GLOBAL_MAINTHROTTLE halt Or, if you use the compiler, you can do this: var int# TIMER = 60;//pointer to timer var int# THROTTLE = 0;//pointer to throttle var int CLOCKRATE = 384000;//ammount of cycles in a second def main : { TIMER 0 <-;//reset timer while TIMER# CLOCKRATE 10 * <; ;//loop while the value of the timer is less than the ammount of cycles in a second times 10 THROTTLE 1024 <-;//set throttle to max while 1;;//halt return; } When the code is run, it is first translated into binary and then loaded into the emulators memory, where it is interpreted one instruction at a time. More detailed information regarding the emulator is included in the documentation in the download. You can download it here Source, documentation and example code are included in the download. Feel free to ask any questions you have in the forum thread. There is also a github repository. Changelog: 0.11.1 Added some rudimentary documentation regarding the new features. 0.11 Added some additional functionality to the monitor Added a GUI for the tape drive, in the process changed how programs are loaded Added some new instructions Added an operating system and a BASIC interpreter based on the "tiny BASIC" dialect Documentation on new features is very lacking, might fix later 0.10.4 Several fairly major bugfixes, some further clarification of parts of the documentation. 0.10.3 Minor bugfixes and additional features. Version 0.10.2 Fixed a minor bug, clarified parts of documentation. Version 0.10.1 Lots of changes, see changelog for details. Version 0.9: Added a tape drive, as well as some bugfixes. For more info, see the changelog in the download. Version 0.8.2: Added kellpossibles radial part. Version 0.8.1: New instructions, improved string handling, better constants, bug fixes. For more info, see the changelog in the download. Version 0.8: Added a keyboard. Version 0.7.2: Fixed an issue that caused the emulator to not use the entire cache memory. Version 0.7.1: Fixed a bug that caused the monitor to be blurry at low texture resolutions. Version 0.7: Fixed some of the bugs that had been reported. I also added a monitor. For more info, see the changelog in the download.