SimplySimon

[0.90] ProgCom - CPU Emulator V0.11.1

Recommended Posts

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.

Edited by SimplySimon

Share this post


Link to post
Share on other sites

I've been working on a C-like language compiler for ProgCom while the forums were down.

If anyone would like to help alpha-test it and submit bugs/feature requests to me, please do so! However, note that it IS in a very early alpha stage, and there will be a fair amount of glitches. I've hit the point where I couldn't find any bugs by myself, though, so it should be relatively stable.

Here's the exe, the feeble documentation, and an example gibberish test program to show the features of the language.

And here's the sourcecode repo, since that's probably required to be linked.

How to use: Open up command prompt, CD to the directory ProgComC.exe is in, and run it while passing in a file to compile. For example, to compile the test.c file included (assuming it's in the same directory as ProgComC.exe is in), you would do "ProgComC.exe test.c"

Alternatively, you can just name your C file "program.c" and it will automatically use it if no filename is passed in - so you just need to run "ProgComC.exe", or simply doubleclick on the exe.

The entire compiled unit will be written back to disk with the same filename as the source, with ".txt" appended. So, in our test.c example, the output would be named test.c.txt. This is the file that you would put in the progcom directory and run the command "load run test.c.txt" inside progcom.

The program is written in .NET 3.5, the same as KSP. Windows users should be fine, Linux users will need to install Mono, and I think Mac users also need to install Mono.

Please report any bugs or feature requests that you have!

Share this post


Link to post
Share on other sites

So I'm currently working on the K-Compiler.

It has C-like syntax and has about the same power in program (pointers, etc)

The first version will include the any* feature, inline asm and functions but not namespaces.

If anyone wants to test this contact me over the forum.

I will respond asap when the compiler is working and debugged...

Share this post


Link to post
Share on other sites

Hey.

Could you explain how to use this. I tried and I just didnt understand what to do at all.

Share this post


Link to post
Share on other sites

Updated!

Fixed some of the bugs that were reported before the forums reset.

I also added a monitor. Next up is a keyboard, probably.

Someone make a video of this showing highlights ;) plase

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?

Hey.

Could you explain how to use this. I tried and I just didnt understand what to do at all.

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?

Share this post


Link to post
Share on other sites
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?

It just wasn't running any programs at all. And I would need to learn assembly so if possible could you explain those two I would love to use this

Share this post


Link to post
Share on other sites

Okay, now that we got a C compiler for it...

How long until we can expect a Linux kernel?

;-)

Share this post


Link to post
Share on other sites
It just wasn't running any programs at all. And I would need to learn assembly so if possible could you explain those two I would love to use this

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.

Edited by SimplySimon

Share this post


Link to post
Share on other sites
Okay, now that we got a C compiler for it...

How long until we can expect a Linux kernel?

;-)

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

Share this post


Link to post
Share on other sites

I like!

Been messing aroud a bit with khyperia's c compiler for this, works pretty well.

Would be nice to be able to put comments in the c code...

Another thing im realy missing is #define and maby #ifdef too.

Share this post


Link to post
Share on other sites
I like!

Been messing aroud a bit with khyperia's c compiler for this, works pretty well.

Would be nice to be able to put comments in the c code...

Another thing im realy missing is #define and maby #ifdef too.

I'm currently in the process of completely rewriting it. (I tend to do that a lot, lol)

The new version has a much more robust preprocessor engine, so it will hopefully support #define and maybe, just maybe, #if/#ifdef/all the other #if things.

The new version is also incredibly flexible and portable, meaning it can accept/parse many different languages and emit many different output types, but obviously only if I implemented it. Right now, what's currently planned for the compiler is a KspC parser, a TI-Basic/Matlab-like language parser, ProgCom assembly output, a custom assembly output for an upcoming Minecraft cpu mod, and a direct interpreter. However, everything other than the KspC/ProgCom pipeline is kind of irrevelent to ksp, though, it's just all the features for all the different communities it's for.

Share this post


Link to post
Share on other sites

So I'm about 74% though the process of writing the basic K compiler.

For the meantime:

MODEMS :D

It would be nice to be able to...

... communicate with nearby ships within 200m (bandwidth about 800 Baud (200m) up to 1600 Baud (<10m))

... communicate with any target (save cpu state when leaving?, about 80 Baud (+ 2 Mio. m) to 400 Baud (< 2 Mio. m)

(remember 1 Baud is about 1 bit per seconds, so 8 Baud is 1 byte/s

and 800 Baud are 100 byte/s

this speeds should be used to lower the real cpu usage.)

after 1 Bio. m it should drop to about 8 to 4 baud.

It would allow inter-ship coms and docking manouvers with multiple ships at once and also coordination above great distances...

Share this post


Link to post
Share on other sites
So I'm about 74% though the process of writing the basic K compiler.

For the meantime:

MODEMS :D

...

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! :)

Share this post


Link to post
Share on other sites

I think it would be nice if there was a model that was somewhat different looking than the model currently with the pack...

I'm just saying.

Share this post


Link to post
Share on other sites
I think it would be nice if there was a model that was somewhat different looking than the model currently with the pack...

I'm just saying.

if you got any ideas for a model let me know, I can make it(that is, of corse if simplysimon wants it)

Share this post


Link to post
Share on other sites

Great work!!!!

This adds a whole new dimension.

Just throwing ideas out here, would it be possible to have a CPU i/o addressable interface that is an xml socket server. This would then allow an uplink/downlink style interface with the xml structure simulating a radio packet, that way ProgCom remains a programmable device, it is up to the user on what they do with the raw data. This could allow for user designed:

Web based "mission control" style telemetry interfaces.

The more adventurous users could develop a full fledged mission package written in the language of their choice to interface with the virtual probe via the limited command xml up/down link.

Programmable scientific payloads. Where ProgCom sends raw data and the user "scientist" can do whatever they wished.

Oh man, the possibilities...

Share this post


Link to post
Share on other sites

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.

The first 4 bytes will tell the CPU what data to send back (DATA_SRC)

The next 5 bytes will tell the CPU the data type and length (DATA_TYPE, first 3 is DATA_TYPE_FORMAT, last 2 is DATA_TYPE_LEN)

The next byte tells the CPU if it should handle it with default (internal) or by

sending and interrupt to the program running. (MODE_SELECT)

The next 2 bytes will be send per interrupt to the program in r1 if the MODE_SELECT byte is not 0. If MODE_SELECT is 0 it will do nothing

The next 2 bytes will be send per interrupt to the program in r2 if the MODE_SELECT byte is not 0. If MODE_SELECT is 0 it will do nothing

The last byte is a checksum. To create it add up the first 14 bytes and multiply it with the 15th byte. Then take the modulus from 255.

This allows for 4 Billion Datas with about 4 Million Types with a length of total 16 kb.

The cpu should respond only with the raw data split up nicely to packets.

(Just idea)

Share this post


Link to post
Share on other sites

So im almost finished with the compiler.

I give you a link to the compiler plus a source file to compile.

But Problem is i didnt get the calculation system to work.

So currently you have to do that manually.

All variables are stored in memory 12 adresses after the base_adr label which is used to locate the variables.

https://dl.dropboxusercontent.com/u/33521283/KCompiler%20Debug.zip

It is still a debug version and requires Windows 7 or Vista.

Windows 8 is not supported and will never be...

Share this post


Link to post
Share on other sites
So I'm about 74% though the process of writing the basic K compiler.

For the meantime:

MODEMS :D

It would be nice to be able to...

... communicate with nearby ships within 200m (bandwidth about 800 Baud (200m) up to 1600 Baud (<10m))

... communicate with any target (save cpu state when leaving?, about 80 Baud (+ 2 Mio. m) to 400 Baud (< 2 Mio. m)

(remember 1 Baud is about 1 bit per seconds, so 8 Baud is 1 byte/s

and 800 Baud are 100 byte/s

this speeds should be used to lower the real cpu usage.)

after 1 Bio. m it should drop to about 8 to 4 baud.

It would allow inter-ship coms and docking maneuvers with multiple ships at once and also coordination above great distances...

This is getting close to a plugin that I wanted to build or inspire.

Basically a line-of-sight communications system that uses packets to send/receive instructions or science data. The radio relay and remote tech plugins come close, but stop short of the real value in the experience. Yes, it is fun to build networks that draw blue lines across space, but I want to send/receive commands, telemetry, and other data from one scene, and have it influence / observe the vessel that is on rails. Even if it was simulated, it would still be fun.

Would be cool to procedural generate RTTY or astronomical RF phenomena and "listen" and/or track it. For example, I slew a dish to Jool to listen to my probe's transponder and decode image or science data.

Share this post


Link to post
Share on other sites
I think it would be nice if there was a model that was somewhat different looking than the model currently with the pack...

I'm just saying.

if you got any ideas for a model let me know, I can make it(that is, of corse if simplysimon wants it)

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.

Great work!!!!

This adds a whole new dimension.

Just throwing ideas out here, would it be possible to have a CPU i/o addressable interface that is an xml socket server. This would then allow an uplink/downlink style interface with the xml structure simulating a radio packet, that way ProgCom remains a programmable device, it is up to the user on what they do with the raw data. This could allow for user designed:

Web based "mission control" style telemetry interfaces.

The more adventurous users could develop a full fledged mission package written in the language of their choice to interface with the virtual probe via the limited command xml up/down link.

Programmable scientific payloads. Where ProgCom sends raw data and the user "scientist" can do whatever they wished.

Oh man, the possibilities...

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.

So im almost finished with the compiler.

I give you a link to the compiler plus a source file to compile.

But Problem is i didnt get the calculation system to work.

So currently you have to do that manually.

All variables are stored in memory 12 adresses after the base_adr label which is used to locate the variables.

https://dl.dropboxusercontent.com/u/33521283/KCompiler%20Debug.zip

It is still a debug version and requires Windows 7 or Vista.

Windows 8 is not supported and will never be...

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

first:

the lang is not intended to do real recursive stuff. Just basic counting and powering numbers.

seconds:

it is a vary basic compiler that actually allocates about 512bytes memory for variables and functions.

the problem of the stack thingy is a user problem the lang is supposed to do nothing for the user.

Also the stack would make some things with variables very unconvinient.

KISS principle.

third:

a15 is used very shortly when calling with parameters.

otherwise it could only support 14 parameters.

last point:

i am about to face the GCSE (Realschul Abschluss Deutschland) so i cannot work on the compiler

i would be happy to see some mods for it.

the principle is simple:

keep the level very low so the users is almost at assembler but always remembre the c style.

Copyright and License for the KCompiler:

The license for the KCompiler is the same as for any other mod for ksp (official mods in the forum)

=> CC BY-SA-NC

Applies for code and binary

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now