DSKY external interface

lricca

New member
Joined
Jan 7, 2017
Messages
9
Reaction score
0
Points
1
Hi,
first of all I'm really happy for the migration to the new forum because here is easier to talk with the developer.
Is it possible in a future update to implement an interface for the dsky? It would be a fantastic upgrade build a real dsky and connect it to the simulator thanks to this interface.

Thanks
Luigi Ricca
 

Messierhunter

New member
Joined
Apr 30, 2008
Messages
488
Reaction score
2
Points
0
Bru57000 on YouTube already has done just that. I don't know if he's here on the forum, but you should have a chat with him to see how he did it:
It sounds like he re-inserted the TCP/IP functions for the virtual AGC back into NASSP's source code.
 

lricca

New member
Joined
Jan 7, 2017
Messages
9
Reaction score
0
Points
1
Yes, thanks, I know that this person is able to connect an external hardware, but hi had to change the source code. I'm not a programmer and would be easier for me and also for other people, I think, to have an interface already avaiable.

Inviato dal mio ALE-L21 utilizzando Tapatalk
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
I did that a while ago for my external DSY I once build.
I essence it was just a serial port that transmitted the output channels from the AGC and received the input channels.
I'll have to dig a bit in my old hard drives. I'll try to post my simple changes once I find the time.
...please hold the line ...
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Hi, I found the changes.

But as you are not like to do some coding it would not be of any help.
On the other hand I would like to know what kind of external interface you were thinking about?
It is generally only possible to connect two things (hardware) if they "speak" the same protocol. So even if you use my code on the PC end, you still have to connect an external DSKY hardware that "speaks" exactly "my protocol"[1].

Nevertheless I'll try to pack only the changes I've done and post it here, so maybe others might get the idea.
The "other" side is a plain arduino board that controls the DSKY keys, segments and lights.

[1] ...not that proprietary, but still not "generic"
 

Attachments

  • ProjectApollo(external DSKY changes).zip
    16.2 KB · Views: 240
  • ProjectDSKY.arduino.zip
    19.7 KB · Views: 228
Last edited:

lricca

New member
Joined
Jan 7, 2017
Messages
9
Reaction score
0
Points
1
My idea is to use an arduino board to make the dsky, It would be very useful to implement your protocol (or also another protocol) in the source code so we don't have to recompile it on every release. It would be easier to make the arduino side interface woth some documentation.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Sure. But you mentioned the work "documentation"! That's the one thing developers don't like very much :)
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Sure. But you mentioned the work "documentation"! That's the one thing developers don't like very much :)

Oh, I LOVE documentation. Absolutely. I really recommend it. I sure want to read it when it is done.










Just don't make me write it. :lol:

(Writing this while doing analyst work on a heap of legacy batch files, luckily got the "You can let somebody else write the manuals, just give your notes to your coworker" card today)
 

dseagrav

Addon Developer
Addon Developer
Joined
Nov 4, 2010
Messages
117
Reaction score
0
Points
16
"documentation"

"Documentation is like pizza; When it's good, it's very very good, and when it's bad, it's better than nothing."

"There are three main kinds of untruth: Lies, Damned Lies, and Documentation."
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Urwumpe is right of course! I didn't write that statement correct:
..."documentation"! That's the one thing developers don't like to write, but LOVE to have them being accurate and ...present.:thumbup:
 

lricca

New member
Joined
Jan 7, 2017
Messages
9
Reaction score
0
Points
1
Ok, I did not think to wake up the kraken:lol:
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Hello again,

as promised[1] a short documentation of the protocol I've used:

PC => DSKY
A message from the PC to the external DSKY consists of three bytes that represent
a) the channel number (010, 011 & 013)
b) the channel value (bit-flags, depending on the channel, for further details Table of IO Channels)
This C-structure shows this:
PHP:
#pragma pack(1)
typedef struct{
	UINT8  channel; // [010|011|013]
	UINT16 value;   // channel data
} message_t;
Note, that this message will be transmitted via the UART in "TCP/IP network byte order". This means that the data format for the 'value' is big-endian
I am not sure by now, why I choose that endianess, but I think I had in mind to connect my external DSKY directly to the virtual AGC project, which uses network sockets to communicate.

DSKY => PC
For whatever reasons I choose a different approach for the other direction (DSKY to PC).
As only the keyboard creates events/messages, one single channel would fulfill the task, but as the real Hardware handled the PRO key different than all the other keys, I "invented" another message style for the "return trip"[2]

A message from the external DSKY to the PC consists of four bytes that represent
a) Kind (either 'k' for (K)eycode, or 'b' for Input Channel (B)it.
b) Three bytes of data, depending on the type of course:
For 'k' messages, only the first byte contains the keycode value, the following two bytes will always be zero. The 'keycode' values are like the Input Channel 015 values found at Virtual AGC documentation.
For 'b' messages, the first data byte contains the channel value (only 032, ass we only message the PRO-Key state); the second data byte contains the bit-number (here 14) to be manipulated; the third data byte contains either a one (1) or a zero (0) to either set or clear that bit.
A C-structure showing this:
PHP:
#pragma pack(1)
typedef struct {
	UINT8  type;        // ['k'|'b']
	union {
		struct {
			UINT8  channel; // 032
			UINT8  bit;     // currently only 14
			UINT8  value;   // [0|1]
		} k;
		struct {
			UINT8  keycode; // AGC Keycode (Input channel 015)
			UINT16 spare;   // all zero
		} b;
	} data;
} message_t;
Note, that due to the fact that the only multi-byte data is 'spare' it does not matter what endianess is used here.


For all who are not familiar with octal number representation, do yourself a favor and get used to it if you are planning to build or work with a DSKY.



[1] ...kind of
[2] this might not be the most clever solution I think, but it worked back then when I build this thing and as it did work I felt no more pressure to change that ;)
 
Last edited:
Top