[The Linux compatibility thread!]

Could some kind person provide a link to whatever earlier post this refers to please? Hopefully with step by step details about what I should do. I want to make certain I modify in the best possible manner for 0.22.

OK, edit with more information. KSP (clean 0.22 no mods) was crashing instantly if I clicked either of the menu options Training or Scenarios. I applied the fix that I have found necessary for every version since 0.19. Namely perform the following in a terminal within the KSP folder.

echo "7cebc7: 00" | xxd -r - KSP.x86_64
xxd -s +0x7cebc7 -l 1 KSP.x86_64 (Replies "07cebc7: 00")
echo "7cebcc: 00" | xxd -r - KSP.x86_64
xxd -s +0x7cebcc -l 1 KSP.x86_64 (Replies "07cebcc: 00")

The Training and Scenario now run so my guess is that since it fixes an immediate clean install problem that doing this again with KSP version 0.22 is the correct thing to do. I would be very interested to hear if other linux 64 bit users have the same experience and/or if there are alternate or better ways to apply this fix. I ask because I found with version 0.21 (fixed the same) that the game became very unstable whenever I had enough mods installed to go above approximately 4 Gb memory footprint. I have libpng12-0 if that is relevant.

Somebody give that man a cigar!!!!

This has been driving me nuts limiting mods on a 64bit platform and that has fixed it!!!

mod a + b would work!

mod a + b + c crash!

remove mod c

mod a + b now crash!

remove mod b

mod a work!

mod a + b crash!

?????

reinstall KSP and only add mod a + b

Aaaarrrggghhh!

Now: mod a + b + c + d + e WORKS!!!

This fix beautifully!!!

[[0.90] ProgCom - CPU Emulator V0.11.1]

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.

oooh I like that.

Building on the data payload layout that eyecikjou567 suggested (now I'm just being silly I guess and its late, but trying to keep real world SocketIO restrictions in mind) what about, say, 4 virtual GPIO buses with programmable flags and external 16 byte RAM buffers (see below) with each bus being a UDP socket OR file handle. This way it could then be extended to a databus for all sorts of virtual hardware, other then communications packages.

So the virtual hardware theory behind this is any device communicating with the CPU on the databus has DMA to external RAM modules that the CPU clocks in serially. This cuts the complexity of bus mastering from the CPU and lowers overheads from real world CPU socket/file read/writes.....maybe.

So a scheme could be:

PORT A BUFFER_ADDRESS 128

PORT A BUFFER_ADDRESS_OFFSET 129

PORT B BUFFER_ADDRESS 130

PORT B BUFFER_ADDRESS_OFFSET 131

PORT C BUFFER_ADDRESS 132

PORT C BUFFER_ADDRESS_OFFSET 133

PORT D BUFFER_ADDRESS 134

PORT D BUFFER_ADDRESS_OFFSET 135

(These are real life 16 byte socket/file buffer arrays with index)

PORT A-D FLAG REGISTER 136-139

Each ports FLAG register is bit addressable.

bit 1 - Interrupt Enable (AsyncSocketRecv() OnFileChange() )?

bit 2 - IO Direction (low= Output, High=Input)

bit 3 - Latch Data (technically not a clock/latch but a nice bit to set to fire off SocketSend() WriteFile() )

bit 4 - .... (anything else that makes Real Life socket/file IO easier)

bit 5 - .... (or any other bits that simulate control of a parallel data bus)

..

bit 32

ProgCom opens the sockets/file when the plugin starts on UDP ports 6502-6506 (homage to MOS-6502) ready for connection/listen.

SocketSend()/Writefile() is initiated when the data has been clocked from the CPU to the virtual RAM buffer and the latch bit is set to 1

SocketRecv() / OnFileChange() will flag INT_PORTNUMBER so the CPU vectors to the interrupt handler whenever there is data in a socket receive buffer.

Now if only there was a way to pump other plugin data to UDP.....

[[0.90] ProgCom - CPU Emulator V0.11.1]

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