SEARCH 

IBM Bisync Device and Control Unit Addresses

The following table lists the allowed values for IBM Bisync Control Unit and device addresses for ASCII and EBCDIC:

Control Unit or Device Number Address
ASCII EBCDIC
0 x'20 x'40
1 x'41 x'C1
2 x'42 x'C2
3 x'43 x'C3
4 x'44 x'C4
5 x'45 x'C5
6 x'46 x'C6
7 x'47 x'C7
8 x'48 x'C8
9 x'49 x'C9
10 x'5B x'4A
11 x'2E x'4B
12 x'3C x'4C
13 x'28 x'4D
14 x'2B x'4E
15 x'21 x'4F
16 x'26 x'50
17 x'4A x'D1
18 x'4B x'D2
19 x'4C x'D3
20 x'4D x'D4
21 x'4E x'D5
22 x'4F x'D6
23 x'50 x'D7
24 x'51 x'D8
25 x'52 x'D9
26 x'5D x'5A
27 x'24 x'5B
28 x'2A x'5C
29 x'29 x'5D
30 x'3B x'5E
31 x'5E x'5F

Why are the numbers so crazy?  They're not, they actually follow a very distinct pattern, if you know how to look for it.

The most obvious way to have done it would have been to just use the 32 binary values from 0-31 as the address directly.  Of course this would lead to problems as some of the values would be misinterpreted as Bisync Line Control characters (x'02 = STX, x'03 = ETX, for example.)  So the binary value was converted to its best EBDCIC equivalent, using the lower 6 bits as address and setting the upper two bits to ensure a valid EBCDIC character resulted.  (Had to be EBCDIC to remain compatible with really old IBM hardware -printers to be exact, that understood only Line Control characters and printable EBCDIC characters).  So that's why the EBCDIC column appears to be sequential, except for a couple of 'holes' where the direct conversion resulted in invalid EBCDIC requiring substitution of values that were 'proper'.  The ASCII side is simply the EBCDIC side converted to ASCII.  You can see this really works by performing the conversion in reverse:  Given an ASCII address, convert it to EBCDIC and then strip the upper two bits.  Viola! a 6 bit CU/Dev address!

The character sets and translation tables used by JBM Electronics Gateways are:

If you have any questions or need further assistance, please e-mail us at:  support@jbmelectronics.com