Suggestions for Hardware compatibility

Hi,

I'm working on a universal controller to work with X-sim, but I have two problems:
1. I'm not the one that's going to do the gaming/testing/X-Simming and I cannot find a clear and definite description of the standard data string for 8/10/12/16 bit accurate communication that X-Sim uses. (Hardware point of view)

2. I have no experience in the gaming-feedback-type universe, so I do not know how many standards there are.

I am however a higly experienced developer of electronics, embedded software and PC tools (Win / Lin), and have the plan to use a modern Atmel USB-enabled chip (ATUSB / ATmega??U) with an extensive set of peripherals to drive an old piece of hardware (pneumatic sim chair that now is controlled by an old analogue joystick), create a HUD and more for flight simulation.

In this I hope to program several sets of data-parsers that can parse a string of serial data sent to the chip over a communications port simulation (USB Virtual Serial Port). But I do not know what types of strings my hardware will have to be able to handle.

I have seen weird ~<number>~~<number>~~<glyph>~~<number>~ strings (this is the point where I openly admit to finding the excessive padding of the Tildes a bit iffy, but okay, we now live in a world where everything talks faster than we can imagine...) but have no idea if this is meant as ASCII(~) followed by the binary representation of the number (in a fixed number of bits) or the ascii characters that represent the number. i.e.:
is ~128~ sent as:
0x7E807E
(where 7E is the representation of the ascii character ~, and 80 is the represenatation of the number 128)
or as:
0x7E3132387E
(where 7E is again ~, 31 is ascii 1, 32 is ascii 2, 38 is ascii 8 )

I am hoping for the first case, but I must be certain as testing will involve having the requester come over with his set up gaming stuff, etc and this makes it much harder for me to fiddle and find out (as I pretty much have negative time to do all this, pure charity towards my friend at this point). In the first case I will of course assume 16 bit numbers to be encoded as two consecutive bytes, with no tildes in between.

And the same question goes for the glyph ~a01~: Is the number in that 2 ascii characters (0x30 followed by 0x31), or is it 1 byte (0x01)? Again hoping for the byte, as this makes adaptive hardware-extention a ten fold easier and faster. (unlimited I2C bus additions, stacked SPI plug-and-play, etc)


Further I would like to know what other kinds of strings you people think should be parsed for this hardware to become something I can actively sell at a later stage? (It will accept a fairly industry standard device configuration packet stream of course, to adjust settings and speeds and such with a custom-written tool)

Other functions I am going to try to add are same-port (single USB plug) Joystick simulation, where the board can send joystick information to the game and, most importantly, receive it's force feedback information and use this to shake and vibrate the chair, in case the game is not yet supported by X-sim or other suites. As well as a key-press or key-combination-press keyboard device that handles the complicated keyboard events when you press a single button on the custom built HUD.

Other suggestions are welcome of course, I am a bit concerned about the number of active devices that a single Atmel can pretend to be, but I can fairly easily adapt the design into a sort of co-op board system, where two identical boards share the work by a few simple command instructions over SPI or I2C. PCB production is a breeze for me, so any and all comments and suggestions (in English, German, Dutch or French - Though I prefer English as in that case the most people can read it and it saves me alot of reading the same suggestions in different languages)