[0.90] ProgCom - CPU Emulator V0.11.1

[SimplySimon]

Another status update! I got programs to load from the tape now, so next up is the cache memory rewrite.

Currently the way the cache memory works is that a section of memory is marked as in-cache and attempts to access it will simply be faster. This generally works fine but when values change in the background, like the control registers (heading, altitude and stuff), the values in the cache should remain unchanged. To fix this I'll create copies of cached data and have separate instructions for bypassing the cache.

Also, it turns out I didn't test the serial interfaces well enough and they are pretty much non-functional at the moment. Sending stuff to ProgCom with them works though. The issues should be fixed in the next update and I will also be putting in a new way of interfacing over the serial thing which should make that more easy.

[Scrumilation]

Another status update! I got programs to load from the tape now, so next up is the cache memory rewrite.

Currently the way the cache memory works is that a section of memory is marked as in-cache and attempts to access it will simply be faster. This generally works fine but when values change in the background, like the control registers (heading, altitude and stuff), the values in the cache should remain unchanged. To fix this I'll create copies of cached data and have separate instructions for bypassing the cache.

Also, it turns out I didn't test the serial interfaces well enough and they are pretty much non-functional at the moment. Sending stuff to ProgCom with them works though. The issues should be fixed in the next update and I will also be putting in a new way of interfacing over the serial thing which should make that more easy.

Just update it to 0.21

[SimplySimon]

I updated ProgCom to version 0.9!

The new stuff is mostly the tape drive and some bugfixes. I also finally updated ProgCom to be a PartModule. More details are in the changelog.

I delayed the compatibility-breaking cache overhaul to the next version due to some ideas I got over IRC that would take rather long to implement and are related to that.

Also, since I wanted a consistent syntax in the console starting a program is now done with "insert asm <filename>" instead of "load run <filename>".

Next up are some rewrites that are mostly behind-the-scenes as well as the cache overhaul. After that I should finally get around to implementing some peripherals.

[finger563]

I updated ProgCom to version 0.9!

The new stuff is mostly the tape drive and some bugfixes. I also finally updated ProgCom to be a PartModule. More details are in the changelog.

I delayed the compatibility-breaking cache overhaul to the next version due to some ideas I got over IRC that would take rather long to implement and are related to that.

Also, since I wanted a consistent syntax in the console starting a program is now done with "insert asm <filename>" instead of "load run <filename>".

Next up are some rewrites that are mostly behind-the-scenes as well as the cache overhaul. After that I should finally get around to implementing some peripherals.

Awesome! Glad to hear it Assembly programming my rockets is exactly what I wanted!

[jrandom]

This may have been asked in the past so forgive me if this has already been answered, but will this mod work well with RemoteTech 2 once it's released? Looking at the options, this mod is the only one that even comes close to the kind of programability that I want. kOS is far too high-level, and the built-in RT2 flight computer isn't what I'm looking for either (from what I've read -- I've not playtested RT2 in any way).

[finger563]

Another status update! I got programs to load from the tape now, so next up is the cache memory rewrite.

Currently the way the cache memory works is that a section of memory is marked as in-cache and attempts to access it will simply be faster. This generally works fine but when values change in the background, like the control registers (heading, altitude and stuff), the values in the cache should remain unchanged. To fix this I'll create copies of cached data and have separate instructions for bypassing the cache.

Also, it turns out I didn't test the serial interfaces well enough and they are pretty much non-functional at the moment. Sending stuff to ProgCom with them works though. The issues should be fixed in the next update and I will also be putting in a new way of interfacing over the serial thing which should make that more easy.

Also, any idea when the serial ports might work? I'm very interested in using them to allow an external program to communicate (get telemetry data, activate thrusters, control attitude, etc.) I've got a good bit of coding experience if you're ok with letting me help flesh them out, I'd love to!

[SimplySimon]

This may have been asked in the past so forgive me if this has already been answered, but will this mod work well with RemoteTech 2 once it's released? Looking at the options, this mod is the only one that even comes close to the kind of programability that I want. kOS is far too high-level, and the built-in RT2 flight computer isn't what I'm looking for either (from what I've read -- I've not playtested RT2 in any way).

That depends on what you mean by working "well". If you mean "will this mod run with remoteTech enabled" I'm pretty sure that it will. If you mean that the remotetech delay would apply to progCom appropriately, I'm fairly sure it won't.

Also, any idea when the serial ports might work? I'm very interested in using them to allow an external program to communicate (get telemetry data, activate thrusters, control attitude, etc.) I've got a good bit of coding experience if you're ok with letting me help flesh them out, I'd love to!

The serial ports should be pretty much fully functional since the last patch. They are at least functional enough to permit the emulator to load a program from tape. If you find any errors that are still there, please let me know.

The only problem I can see with them currently is disabling the IBF/OBE flags in the control register:

rd r1, r0, GLOBAL_GSB0;read control flags
andi r2, r1, 0b10 
xor r1, r1, r2;disable bit 1
wr r1, r0, GLOBAL_GSB0;when we write back bit 2 might have changed state in the background. That new state will be overwritten here

Not quite sure what I could do to solve that particular scenario though.

Feel free to use the serial ports for whatever you want, I added them so that people could do stuff like that.

[jrandom]

If you mean that the remotetech delay would apply to progCom appropriately, I'm fairly sure it won't.

Oh heck no! The programs would need to be instantaneous as they'd be running directly on the ship -- only way to control them properly when signal delay becomes an issue. The only delay-thing I can think of that could be added (but isn't necessary, just more realistic) would to be to include that delay when uploading new programs to distant ships.

Does progcom support memory restrictions? It would be interesting to have parts that ran faster/slower with more or less RAM and have that influence part weight (some) and energy usage (a lot). Again, not strictly necessary, but KSP works better with interesting restrictions.

Edit: Just started reading the docs, which I should have done anyways. 64K words RAM. Right there at the top. I'll read through these and try the thing about before I litter this place with more stupid questions.

Edited August 30, 2013 by jrandom

[finger563]

One thing I think is crucial to incorporate into this mod is more precise control over the crafts. I know that variable throttle (i.e. controlling different engines or engine groups with different control inputs/throttle levels) is possible for the craft, since this mod http://forum.kerbalspaceprogram.com/showthread.php/38069-WIP-Plugin-Davon-TC-systems-mod does that. I'm going to try to figure out how they perform that wizardry, and see if I can incorporate it into ProgCom. If I have luck, I'll post here and see about getting a pull and merging it into the main branch.

The next fine control I'd like to see (which may not be possible, but should be based on what I've used in FAR) is individual control of control surfaces. I'd like to have the option to control my craft's heading by manipulating control surfaces myself instead of just setting the heading. Given that FAR allows you to set different control surfaces to respond to different control inputs (pitch,roll,yaw,brake), I'm fairly certain this is possible.

If anyone else is interested in this kind of addition to ProgCom let me know!

[finger563]

Hey, quick question:

Can you make the emulator recognize signed-ness? Some of the global variables (such as pitch, etc.) take negative values. They work fine when you want to send the negative value to them, but the arithmetic breaks down and they are not recognized as negative numbers. I.e. If I want to print the value, I want it to show the negative value. My sprintf function performs the arithmetic checks but cannot determine the signed-ness of the function (using less than operators) and I cannot multiply by negative 1.

[finger563]

I realize I'm the only one here for a little while, but I'll put this here now instead of creating an issue on the repo.

I think the way the emulator/parser handles the GLOBAL_* variables has a small bug. Currently you can load these values into registers (e.g. movi r1,GLOBAL_MAINTHROTTLE), but you are unable to use the values in the registers (which should act like pointers to those memory locations) in either the read or write commands, e.g. movi r1,GLOBAL_MAINTHROTTLE -> rd r2,r0,r1 produces the following error:

Could not parse: r1 in: r1. Too large or unrecognised [sic] label

If no one responds soon for this I'll take a crack at implementing this bugfix and the previous feature request (negative integer handling with the instructions). Cheers!

EDIT: I realize now that I can get around the variable read/write access by changing the operations to

movi r1,GLOBAL_MAINTHROTTLE

rd r2,r1,0

This works as far as I can tell, just fyi. However, I am going through the repo to add in the signed arithmetic instructions and display capability.

Edited September 4, 2013 by finger563

[SimplySimon]

Sorry for the late replies.

Hey, quick question:

Can you make the emulator recognize signed-ness? Some of the global variables (such as pitch, etc.) take negative values. They work fine when you want to send the negative value to them, but the arithmetic breaks down and they are not recognized as negative numbers. I.e. If I want to print the value, I want it to show the negative value. My sprintf function performs the arithmetic checks but cannot determine the signed-ness of the function (using less than operators) and I cannot multiply by negative 1.

I'm not quite sure what you mean. I did some tests, and using negative numbers in the numpad out/pitch etc. seems to work.

As far as I know the emulator mostly respects signed-ness, the comparison instructions should do that at least. The part that doesn't respect signed-ness at the moment are the immediate values in the move and arithmetic instructions.

Currently if you want to move a negative value into a register you have to do something like:

subi rN, r0, <number>;works for all numbers up to about 64000

or:

movil rN, <number>;works up to two million
sub rN, r0, rN

or use a macro:

#macro movin rA C {
movil rA, C
sub rA, r0, rA
}
...
movin rN, <number>;a little more convenient

If you need very large negative numbers the easiest way is to store them in the data section and then read them, or you could use a combination of movhi and ori to create the number. Currently you can't use negative numbers in immediate arithmetic operations

If you want I could make the muli/divi/movil instructions sign-extend the immediate value into a 32-bit integer. I'll probably not do that for movi/subi/addi though, since if you need to add/subtract something you can switch between addi/subi and it would be tricky to implement for movi. Movi is also useful for making sure addresses stick to 16 bits, which they wouldn't if I made it sign extend.

I realize I'm the only one here for a little while, but I'll put this here now instead of creating an issue on the repo.

I think the way the emulator/parser handles the GLOBAL_* variables has a small bug. Currently you can load these values into registers (e.g. movi r1,GLOBAL_MAINTHROTTLE), but you are unable to use the values in the registers (which should act like pointers to those memory locations) in either the read or write commands, e.g. movi r1,GLOBAL_MAINTHROTTLE -> rd r2,r0,r1 produces the following error:

Could not parse: r1 in: r1. Too large or unrecognised [sic] label

If no one responds soon for this I'll take a crack at implementing this bugfix and the previous feature request (negative integer handling with the instructions). Cheers!

EDIT: I realize now that I can get around the variable read/write access by changing the operations to

movi r1,GLOBAL_MAINTHROTTLE

rd r2,r1,0

This works as far as I can tell, just fyi. However, I am going through the repo to add in the signed arithmetic instructions and display capability.

It's not really a bug, the read instruction takes two registers and a constant so using three registers should give that error. There is another version of the instruction that does use three registers, but it is not added to the assembler yet so you'd have to hand-assemble it and insert it with #literal.

Edited September 4, 2013 by SimplySimon

[Krupski]

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.

Sir,

Can you tell me what instruction set your emulator uses? The only thing I can find in the docs is "PC32 instruction set".

It "sort of" looks like MIPS32 or ARM, but it's not a complete match (I assume it's neither).

I know Motorola, Intel and AVR assembler, and I'm quite good at ASM in general, but I need a reference manual for the "processor" you are using. The syntax doesn't make sense to me (specifically those 3 operand instructions!)

Is that instruction set a clone of some existing microcontroller (that I can look up a databook for), or is it "home grown"?

If you can tell me what processor you emulate, I would really appreciate it (or whatever documentation you may have above and beyond what's in the KSP mod package).

Thanks!

-- Roger

[SimplySimon]

Sir,

Can you tell me what instruction set your emulator uses? The only thing I can find in the docs is "PC32 instruction set".

It "sort of" looks like MIPS32 or ARM, but it's not a complete match (I assume it's neither).

I know Motorola, Intel and AVR assembler, and I'm quite good at ASM in general, but I need a reference manual for the "processor" you are using. The syntax doesn't make sense to me (specifically those 3 operand instructions!)

Is that instruction set a clone of some existing microcontroller (that I can look up a databook for), or is it "home grown"?

If you can tell me what processor you emulate, I would really appreciate it (or whatever documentation you may have above and beyond what's in the KSP mod package).

Thanks!

-- Roger

The instruction set is mostly "home grown" if I understand what you mean by that term correctly. It does take some inspiration from the Nios-II instruction set, though the syntax and in-memory representations of instructions are somewhat different.

I don't really know why I put PC32 in the opcodes.txt file and I don't quite remember what it means either, but I assume it stands for ProgCom-32.

I'm afraid that the only documentation of what the instructions do is in instructionset.txt. Opcodes.txt contains some information on how the instructions are represented in-memory and how long they take to execute, but that might not be very helpful if you are trying to code something. If you have any questions feel free to ask though.

[khyperia]

I've been considering rebooting the C compiler for progcom.

However, I thought I would do something a little different this time: Use the C# compiler as a sort of "front end" for it.

This would mean that you would be writing ProgCom programs in C# (or whatever other .net language you want).

However, obviously a HUGE set of the language would be missing, ranging from 99% of the BCL, anything object-oriented, and a fair chunk of the opcodes, such as Newobj (I do not want to struggle with trying to implement GC). Essentially, anything that's in the C language would be supported, while anything else would not be.

I would then only have to write a .net CIL to ProgCom translator, which I'm about 50% of the way done with.

However, it's a lot of work, and it's not coming along very quickly.

So, I'm asking here if anyone would be interested in such a thing.

If a few people are interested, then sure, I'll finish it, but if nobody is going to be using it I have a couple other projects I should be working on.

[ShadowKatStudios]

I'm at somewhat of a loss; I've written code to keep the nose of my spaceplane above the dark/light line on the navball, however it fails to compile.

Here's my code: http://pastebin.com/84ucTJQS

[SimplySimon]

I'm at somewhat of a loss; I've written code to keep the nose of my spaceplane above the dark/light line on the navball, however it fails to compile.

Here's my code: http://pastebin.com/84ucTJQS

I see the problem, you have left out the commas separating the parameters for the bl and add instructions. Also, the bl and add instructions need to be passed registers as the first and second parameters (and third, in the case of add). Try replacing add with addi, and read GLOBAL_PITCH and controlpitch into registers before using those instructions.

This code should compile:

.text
#include libText.txt
#define controlpitch 512

#global main
main:
        movi r1, string
        call printStr
        movi r2, controlpitch
start:
        rd   r1, r0, GLOBAL_PITCH
        bl   r1, r2, correct
        jmp  start
correct:
        addi r1, r1, 1
        wr   r1, r0, GLOBAL_PITCH
        jmp  start

.data
string:
#string "SKS Flight Control Alpha-1"

However, I don't think this code will do what you described. The code will increment the crafts pitch control until it is 512. The result of this should be that the craft will constantly pull upwards (or downwards, I don't quite remember). If you want to keep the craft pointed towards the horizon I think you will need to code some sort of PID controller.

Also, I have been informed that there is a bug with the program loading: A program will load, but only if you insert the program before the emulator is turned on. If you do it out of order you will need to revert the flight or load a quicksave before you can get it to work. I'll try to fix it for the next update.

[siwdys]

Is there a way to determine position using this? I've figured out velocity, altitude, and orientation, but not absolute, or even relative position. Is there currently a way to figure this out? I kind of have a feeling like GLOBAL_VESSEL_X, GLOBAL_VESSEL_Y, and GLOBAL_VESSEL_Z might have something to do with this, but I'm not very familiar with the unity engine so I didn't really grasp what these vectors are.

[SimplySimon]

Is there a way to determine position using this? I've figured out velocity, altitude, and orientation, but not absolute, or even relative position. Is there currently a way to figure this out? I kind of have a feeling like GLOBAL_VESSEL_X, GLOBAL_VESSEL_Y, and GLOBAL_VESSEL_Z might have something to do with this, but I'm not very familiar with the unity engine so I didn't really grasp what these vectors are.

It was a while since I used that part of the code, but if I remember correctly GLOBAL_SURFACE_UP is the normal vector of the planet you are currently orbiting directly below the ship. If you multiply that vector with the sea-level altitude of the craft plus the radius of the planet I think you should get a fairly usable coordinate for the ship. The up-vector rotates with the planet, so when you are above, for example, KSC it will always have the same value.

GLOBAL_VESSEL_X/Y/Z has to do with the orientation of the ship if I remember correctly, Y being the same as HEADING, X and Z being right and upwards. They are there mostly so that you can transform vectors into a ship-relative coordinate system.

Edited October 8, 2013 by SimplySimon

[siwdys]

It was a while since I used that part of the code, but if I remember correctly GLOBAL_SURFACE_UP is the normal vector of the planet you are currently orbiting directly below the ship. If you multiply that vector with the sea-level altitude of the craft plus the radius of the planet I think you should get a fairly usable coordinate for the ship. The up-vector rotates with the planet, so when you are above, for example, KSC it will always have the same value.

GLOBAL_VESSEL_X/Y/Z has to do with the orientation of the ship if I remember correctly, Y being the same as HEADING, X and Z being right and upwards. They are there mostly so that you can transform vectors into a ship-relative coordinate system.

After some further experimentation, the GLOBAL_VESSEL_X/Y/Z are definitely for orientation. Thanks for the tip with the GLOBAL_SURFACE_UP vector, I think that's exactly what I was looking for. I like the idea of using the up vector times alt + sea level to derive Cartesian coordinates. It should also allow for deriving theta and phi in spherical coordinates using some relatively simple trig, and alt + sea level will give rho.

[lacedemonian]

Can i make a program that periodically does an action from a part's action menu (i.e. extend/retract panels)?

Can it tell if there is a selected target? Or what that target is?

Can it replicate the press of a key?

Because I want to combine this with Lazors to make an automatic missile launcher combining LIDAR with Missiles.

[SimplySimon]

Can i make a program that periodically does an action from a part's action menu (i.e. extend/retract panels)?

Can it tell if there is a selected target? Or what that target is?

Can it replicate the press of a key?

Because I want to combine this with Lazors to make an automatic missile launcher combining LIDAR with Missiles.

The "repeatedly do action" bit is possible, but you need to bind the action to an actiongroup. Here's some example code:

.text
#global main:
main:
  movi  r1, activateActionGroup
  wr    r1, r0, GLOBAL_IADDRESS
  movil r1, CPU_CLOCKRATE
  muli  r1, r1, 3
  wr    r1, r0, GLOBAL_TIMER_MAX
  movi  r1, 3
  wr    r1, r0, GLOBAL_IENABLE
  halt

activateActionGroup:
  movi  r1, 1
  wr    r1, r0, GLOBAL_ACTIONGROUP
  eret

That code should activate action group 1 every 3 seconds, although I have not tested it so it is possible it does not work as intended.

I plan on adding some way of locating selected targets, and also detecting if one is selected, but that is not in yet. Hopefully I'll get to it for the next update.

It can't currently give input to ksp as if someone has pressed a key, and I'm not entirely sure if that is possible.

[DrPoo]

Will this be updated for KSP 22?

[SimplySimon]

Will this be updated for KSP 22?

Sorry for the late reply!

Yes, it is going to be updated. It might take some time, however, since I have been a bit busy lately.

[HoneyFox]

I hope RT2 author can have an eye on this also, besides kOS...