![](https://forum.kerbalspaceprogram.com/uploads/set_resources_17/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://forum.kerbalspaceprogram.com/uploads/set_resources_17/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
opteron123
-
Posts
4 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by opteron123
-
-
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.....
-
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...
The Linux compatibility thread!
in KSP1 Technical Support (PC, unmodded installs)
Posted
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!!!