SimplySimon

It's not dead yet. Yes, though it is very rudimentary. Yes, but the syntax is quite different from c. Maybe. If you have any further questions I'll be happy to answer them

I added some rudimentary documentation regarding the new features. I might improve it at some point.

I have uploaded the operating system with the latest update. It is not very sophisticated, it can basically only run one program at a time(though you can have many threads in that program) since there is no memory management stuff that ensures you don't try to load two programs into the same area of memory. You can also not give any starting parameters to a new process. Lots of other restrictions and missing features. I cut out most of the file system stuff since it wasn't working, it currently works for loading programs, but I'm not sure if it works for anything else. You'll find the OS source in the compiler folder. How to use it: 1: compile the os.pcc file into os.asm 2: copy os.asm and osasm.asm into the progCom code directory 3: assemble the osasm.asm file with "asm osasm.asm" 4: due to the new tape drive interface you need to open the "TAP" interface, enter "osasm.pct" into the lower text box and press load 5: operating system is up and running If you want to use the basic interpreter, which is the only program that takes advantage of the operating system: 6: compile the basic.pcc file into basic.asm 7: copy the file to the progcom code directory 8: assemble the file with "asm basic.asm 6000" in order to set the program to start at address 6000, the lowest address the OS will permit a program to start at 9: Press "eject" on the "TAP" interface 10: load the assembled file the same way as the OS. Filename should be "basic.pct". 11: in order for the OS to load the program the tape needs to be formatted, open the keyboard and press enter to avoid a bug, then enter "format" and press enter again. 12: when prompted whether you want to keep the executable or not, type "y" 13: Optional Step: Type "list" and enter to see the files that are now on the tape. "boot" should be the only file there. 14: when the tape is formatted type "boot" and press enter into the keyboard. 15: you should now be able to use the basic interpreter, you can test this with the following program: PRINT "Hello, World!\n\r" There is a bug with the interpreter that causes the program to crash if you type "10 IF (A/B)*B = A PRINT 11", just fyi. I have no idea what causes it. Yeah, the compiler is pretty bad. It suffers from not being thought through enough beforehand, being hastily implemented and being the first (working) high[er]-level compiler I've written. I also didn't really do a whole lot of research on how to code one, so it was mostly improvisation the whole way through. In the latest patch I added some very basic optimisations though so it should at least generate slightly more optimal code now. Your project sounds very interesting. I don't have any time to work on it right now though, but thanks for the offer. If you get around to implementing it in ksp, feel free to borrow any code from progCom if you can find anything that is of use. Changes in the new version: *Added a 4 color character mode for the monitor, as well as a 4-bit CLUT bitmap mode, 8-bit color monochrome bitmap mode, and a 16-bit color bitmap mode. You can also adjust the resolution of the monitor between 256x256, 128x256, 128x128 and 64x64 pixels now. I have only written rudimentary documentation for this yet though, will do that later. The old modes should still be usable, but since I expanded the screen ram to 4096 words instead of 2048 all older programs will need a recompile. *Added more instructions for boolean arithmetic, bit twiddling, and some other things I forget. *added the OS and BASIC interpreter I have been talking about *Added A GUI for the tape drive, programs are now loaded by entering "tapeName.pct" into the lower text field of the "TAP" interface and pressing "load". If a tape is already in the tape drive, you need to press "eject" first. If you want to save the changes made to a tape, press "save". If you want to inster an empty tape, press the button called "new" or something like that. Many of the new features are poorly documented since I wanted to release this update asap, and writing documentation is time consuming. I will do a pass on the documentation later. No previous features have been changed though (aside from how programs are loaded, see changelog above) so the current documentation should work just fine for most use cases. If anyone has any questions regarding how to use the new features, or about ProgCom in general, feel free to ask in this thread.

I got a bit busy too, and haven't worked on progcom for a while. Preemptive multitasking, as long as I've understood it correctly, is possible. There is a timer that can generate interrupts at certain intervals, so you can use that to switch tasks regularly. Of course, there is nothing keeping a task from stopping the timer, so any multitasking support is always going to be a bit odd. I was more-or-less done with the operating system. The major problem was the file system, which was tricky to get running properly. There were also some minor issues with how stack space for new threads was going to be allocated (I had no good solution) and I still needed to make sure that the floating point stack state got saved in the interrupt manager. I also did some improvements to the emulator: extended functionality for the monitor, GUI for the tape drive and some minor improvements I can't remember. I don't think I ever got around to testing them properly though. I'll probably finish up what I've done so far and release it at some point. Nice job implementing structs I hadn't thought of that way of doing it before. Although since the compiler is basically a pile of hacks a proper implementation of structs might need a fairly major rewrite. For instance, currently all parameters to a function are passed in registers, so there is a maximum limit of 16 primitive-type parameters. A struct can grow larger than 16 words, and one would reasonably expect to be able to pass a copy to a function. Thus a rewrite of the calling convention would probably be needed. Also, there is currently no robust type system and various points of the compiler assumes that all variables are 1 word long and are of one of four types (int, float, char, pointer). For instance, if you add one to a pointer to a struct you'd probably expect the compiler to add sizeof(struct) instead, so that if the pointer was pointing to an array it'd now be pointing to the next entry, but that doesn't happen at the moment.

Simple might have been the wrong word to describe the OS, rudimentary might be better. It's basically an interrupt handler with some task switching and IO functionality attached. It's not really based on anything. Page flipping could be implemented, but it would require me to double the memory attached to the monitor, which I'm hesitant to do for various reasons. It would be very simple to implement however, so I might do it anyway. Regarding the performance hit, some of that might come from the memory access times being calculated badly. Currently writing to cacheable memory (ie memory that does not share a cache line with a memory mapped hardware device) can be a lot slower for random access than writing to uncacheable memory (random access to the monitor is currently about 3x faster than an offscreen buffer). This will be fixed in the next update. I'm also considering increasing the clock rate again, but I'm less sure about that. Regarding that address range: when reading from memory, only the lowest 16 bits of the address are considered. Therefore 138265 is treated the same as 7193. So 65535 is the highest address you can read from in memory, if you try to read one address past it you will end up reading from address 0.

Neato! Glad I could help Also, I thought I'd give an update on what I've been working on for the next version: * Expanded instruction set: more comparison instructions, bit manipulation stuff and logical and/or instructions * Hardware support for text/bitmap scrolling * Some minor improvements to the text printing library * A BASIC interpreter * A simple operating system

Cool stuff! I took a look at the code, and I think I got it to work. The problem is that instead of "subi a7/a8, r0, 1" you have written "subi a7/a8, a0, 1". a0 is used by the bootloader to store the start address of the program, so it will not contain 0 when the program starts. Here's the function I used to test the changes: .text #include libText.txt #include libDraw.txt #global main main: mov fp, sp addi sp, sp, 8 movi r1, 128 movi r2, 8 initLoop: subi r2, r2, 1 wrr r1, fp, r2 bne r2, r0, initLoop mainLoop: call clearScreen ;draw a square rd r1, fp, 0 rd r2, fp, 1 rd r3, fp, 2 rd r4, fp, 3 call drawLine rd r1, fp, 2 rd r2, fp, 3 rd r3, fp, 4 rd r4, fp, 5 call drawLine rd r1, fp, 4 rd r2, fp, 5 rd r3, fp, 6 rd r4, fp, 7 call drawLine rd r1, fp, 6 rd r2, fp, 7 rd r3, fp, 0 rd r4, fp, 1 call drawLine ;draw inner square rd r1, fp, 0 rd r2, fp, 1 rd r3, fp, 2 rd r4, fp, 3 add r1, r1, r3 sri r1, r1, 1 add r2, r2, r4 sri r2, r2, 1 rd r3, fp, 2 rd r4, fp, 3 rd r5, fp, 4 rd r6, fp, 5 add r3, r3, r5 sri r3, r3, 1 add r4, r4, r6 sri r4, r4, 1 call drawLine rd r1, fp, 2 rd r2, fp, 3 rd r3, fp, 4 rd r4, fp, 5 add r1, r1, r3 sri r1, r1, 1 add r2, r2, r4 sri r2, r2, 1 rd r3, fp, 4 rd r4, fp, 5 rd r5, fp, 6 rd r6, fp, 7 add r3, r3, r5 sri r3, r3, 1 add r4, r4, r6 sri r4, r4, 1 call drawLine rd r1, fp, 4 rd r2, fp, 5 rd r3, fp, 6 rd r4, fp, 7 add r1, r1, r3 sri r1, r1, 1 add r2, r2, r4 sri r2, r2, 1 rd r3, fp, 6 rd r4, fp, 7 rd r5, fp, 0 rd r6, fp, 1 add r3, r3, r5 sri r3, r3, 1 add r4, r4, r6 sri r4, r4, 1 call drawLine rd r1, fp, 6 rd r2, fp, 7 rd r3, fp, 0 rd r4, fp, 1 add r1, r1, r3 sri r1, r1, 1 add r2, r2, r4 sri r2, r2, 1 rd r3, fp, 0 rd r4, fp, 1 rd r5, fp, 2 rd r6, fp, 3 add r3, r3, r5 sri r3, r3, 1 add r4, r4, r6 sri r4, r4, 1 call drawLine rd r1, fp, 0 addi r1, r1, 7 andi r1, r1, 255 wr r1, fp, 0 rd r1, fp, 1 addi r1, r1, 5 andi r1, r1, 255 wr r1, fp, 1 rd r1, fp, 2 addi r1, r1, 5 andi r1, r1, 255 wr r1, fp, 2 rd r1, fp, 3 subi r1, r1, 7 andi r1, r1, 255 wr r1, fp, 3 rd r1, fp, 4 subi r1, r1, 7 andi r1, r1, 255 wr r1, fp, 4 rd r1, fp, 5 subi r1, r1, 5 andi r1, r1, 255 wr r1, fp, 5 rd r1, fp, 6 subi r1, r1, 5 andi r1, r1, 255 wr r1, fp, 6 rd r1, fp, 7 addi r1, r1, 7 andi r1, r1, 255 wr r1, fp, 7 rd r5, r0, GLOBAL_NUMPAD_OUT addi r5, r5, 1 wr r5, r0, GLOBAL_NUMPAD_OUT movi r6, 15000 delayLoop: subi r6, r6, 1 bne r6, r0, delayLoop br mainLoop halt Some other minor stuff I noticed: * in the drawPixel function you have the instruction "mov r0, r3" which will try to put the value of r3 into r0, not the other way around. * You seem to have a third condition in the line drawing code, but I think that part should add offsetX/offsetY to x/y instead of constant 1. I might be wrong though. Either way it does not seem to be needed, I commented it out and the code worked anyway. * Your line drawing function does not follow the example code calling convention, although it is up to you if you want to follow that or not.

Hi, sorry for the late reply! As far as I can tell bl and ble should work with negative integers, however "movi r1, -5" will not do what you expect. movi puts a 16-bit value in the specified register, so while the instruction will gladly accept the value -5, it will in fact put the value 65531 in r1. The workaround for this currently is to use "subi r1, r0, 5", which will subtract 5 from r0, which is always 0, and thus put the right value in r1. I think I might need to document this behavior better. I'm glad you like the mod

Hello everyone! I have been busy for a while, but since I now have some time on my hands I thought I'd start updating ProgCom again This version is mostly bug fixes, though it is fixes for fairly major issues: * The &&, ^^ and || operators in the compiler should now be working * I fixed a bug that would occasionally arise when calling functions in the compiler * The assembler was generating the wrong opcode for the inti instruction, this has been fixed * The monitor was taking too much processing time, it has now been optimised * The tape drive had a few bugs with writing data to the tape, these have now been resolved. * The BUSY flag of the tape drive status register now behaves a bit more consistently * Various smaller fixes

Ok, I have uploaded the new version. Please tell me if the problem persists.

I think I've found the problem, apparently the game doesn't like it when you try to activate fly-by-wire functions in the VAB. I have disabled that and will upload an update later today.

I'm glad you like it I have fixed the folder structure in the new version I just uploaded. I also fixed a bug regarding reading from the last 8 addresses in memory as well as clarified parts of the documentation.

I have updated progcom with the compiler and a bunch of other changes . Most of the stuff is pretty behind-the-scenes, but there are quite a few visible changes too. I have not tested this as thoroughly as I probably should have so there might still be a few bugs in there, but as far as I can tell it works correctly. If anyone finds a bug or something that does not seem to work as the documentation says it should, please inform me and I'll try to fix it as soon as possible. The issues I currently know about are: The compiler: * The &&, || and ^^ operators can produce the wrong value if you assign the result of the operation to a variable that was a part of the operation. * The syntax for assigning an initial value to a global variable in inconsistent with the rest of the language (infix instead of postfix) * Some error messages are not very helpful * There is no way to specify what files need to be included in the source code yet The assembler: * If you include a file containing macros the macros might not get recognised properly, giving odd error messages. * Some error messages are very vague, bordering on useless The emulator: * Some instructions seem to have strange execution times some of the time I'm not sure if I've done a good job explaining the compiler in the documentation, so if anyone has any questions feel free to ask.

I thought I'd give an update on what I have been working on. I have created a new system for adding hardware for ProgCom, which will be the backbone for all the hardware type stuff I add to the emulator. I have made some progress on moving over most of the current functionality over to the new system, the tape drive and data relating to orientation now use it, but there is still some things left to do, such as the display and the keyboard. I have also been working on a compiler. Since I decided to go with reverse polish notation rather than infix notation the syntax is somewhat different from c/c-derived languages. Here's an example of the syntax as well as the equivalent statements in c: def main : int {//int main(void) int x y z;//int x, y, z; x 2 =;//x = 2; y 3 =;//y = 3; z x y * =;//z = x * y; x y z add2 $ =;//x = add2(y, z); y x x + z z + * =;//y = (x+x)*(z+z); int# pointer;//int* pointer; pointer z@ =;//pointer = &z; x pointer# =;//x = *pointer; pointer x <-;//*pointer = x; if x y <; {//if(x < y) { while x y <; x++;//while(x < y) x++; } float f;//float f; f z (float) =;//f = (float)z; "Hello, World!" print$;//print("Hello, World!"); return 0; } def add2 int a b : int {//int add2(int a, int return a b +;//return a + b; } def print char# string: { asm string; "push ra" "call print_asm" "pop ra" ;; return; } It still needs a bit of work though, since it is quite buggy at the moment. Other misc changes: I moved the EX register into the range of registers addressable by normal operations. This made the ax, sx, bx and rdx instructions redundant and they have been removed. The fp, sp, ra, ex, es, ea registers can no longer be accessed as r13, r14, r15, a13, a14 and a15. The only register that can be accessed by two names is r0, which can also be accessed as 'zero'. I fixed the bootloader bug where the computer would not load a program if the tape was inserted after the computer was turned on. The "serial interface" stuff that was used for the keyboard and the tape drive in the previous few versions has been removed in favor of the new hardware system. I have updated the text printing library. The new version works a bit better. Hopefully I can release the next update in a week or two, but given how large a rewrite this has turned out to be it could take longer.

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.

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.

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.

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.

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.

Sorry for the late replies. 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. 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.

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

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.

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.

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.

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.