Hi Alan,

Since IBM hasn't made twinax controllers in many years (a decade? more?) almost everyone has migrated away from twinax devices.

There are 3rd parties who still support it, as you've discovered, but I think it's primarily useful to people who have specialized devices that are hard to replace (such as twinax based POS equipment, or specialty printers, etc.)  I don't think you'll find much interest in twinax support for PCs, and from the few that do use it, I think only the tiniest fraction are using it with Linux.

That said, if you still want to pursue it, you can certainly do it with the tn5250 code base.  Most of the 5250 protocol will be the same.  There are some differences between telnet and twinax in how the 5250 protocol is transmitted, but once you extract the actual 5250 protocol from that transmission, the rest would be the same.

IBM has taken the 5494 Functions Reference Manual (which is the best source for info about 5250) off of their site -- or, at least, I couldn't find it.  But, it looks like someone made a PDF from it and stuck it online here:

http://webfiles.icebreak.org/webfiles/Manuals/IBMi%20documentation/IBM%205250%20Functions%20Reference.pdf

This book should give you a great deal of information about how the data is encapsulated over various protocols.  From there you should be able to find the twinax info.  (It does not, however, have telnet.  For 5250 over telnet info see RFC 2877.)

Hope that helps!



On 1/4/2019 7:48 AM, alan@xxxxxxxxxxx wrote:
This list seems pretty dead, but also seems the most apropos to my
question.

I recently acquired a 5362 System/36 that actually IPLs and runs with an
internal 30 and 60 MB hard disk. It came with a 3179 terminal. But I
started looking at some more practical (and lighter) communication
options - particularly for data transfer - and only found the suite of
products by twindata.com. Which seems ok for basic emulation but
overpriced for a data transfer solution.

After browsing countless eBay listings for ISA & PCI twinax emulation
cards, I visually noticed a common hardware pattern in the component
selection so I started digging a little deeper. It turns out the wire
level protocol on midrange twinax ports isn't that complex.
Electrically it's basically differential TTL. The protocol is
essentially 1 Msps Manchester encoding with a default idle wire state,
simple pre and post ambles, and simple framing. A lot of the cards I've
found use a common framer ASIC but that could easily be replicated with
a small FPGA and some line drivers / opamps. And iCE40up5k could do the
entire job including USB and frame buffers. A BoM cost (not including
twin-ax dongle) would be < $25.

It would be fairly easy to build a completely opensource USB to twinax
adapter (or Ethernet or ...) but the protocol payload seems like an
ocean I don't want to fill with a kitchen tap of time.

How feasible would it be to leverage something like the tn5250 code base
on top of a custom hardware bridge to create a modern twinax emulation
solution? Are the payload formats over twinax and the IP encapsulation
similar?

Other than a few retro enthusiasts, how much interest would there be in
such a design? The last thing I want to do it tank segment of
TwinData's market to make what is probably an already shaky business
unstable then I run out of time and can't support things. I would hate
to leave the community with less options by creating more.

Just curious on thoughts from what seems like a 5250 core user base.

In the meantime, I may build a simple sniffer to eves-drop on the line
and capture a communication dump of the S/36 and terminal to see if the
payload looks sane.

Thanks,

-Alan

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.