CHARACTER SYNC AND MESSAGE BOUNDARIES IN BSC
Most hobbyists are familiar with asynchronous serial communications which solve certain problems for transmission/reception in a very different way from how BSC addresses those problems. Async is a stop-start type of link where there can be variable durations of idle time between characters, using start bits to help the receiver sync up. In BSC, a clock is transmitted to show bit boundaries but specific characters are sent to help the receiver decide which bit is the first of each following characters.
Typically in serial, start bits are used to signal the boundary of a character and often a stop bit delineates the end. The receiver is operating at some baud rate consistent with the one used by the transmitter. When the start bit arrives, the receiver decides on a time to sample the state of the line which corresponds to roughly the middle of each bit.
For example, at 300 baud each bit takes 1/300 (0.003333) of a second, so from the detection of the rising edge of the start bit the middle of the following data bits start .005 seconds later and every .003333 afterwards. The receiver looks at the line at 0.005, 0.008333, 0.011666, 0.015, and so forth. If the line is logically 1, the bit is considered a one otherwise a zero. Each start bit causes the receiver to synchronize for testing the bit value of the following bits making up a data character.
The BSC link does this differently. It is emitting bits whose value is sampled at the edge of the clock signal that rides along the same cable. Thus extracting bit values doesn't require estimating the time to sample, it is defined by the hardware. However, the link has to decide whether a given bit is the first, second, third, fourth, fifth, sixth, seventh or eighth of an EBCDIC byte.
This is accomplished by transmitting an 8 bit pattern, the SYN character (x32), so that the receiver can set a counter that will represent the bit number of the byte. At least two SYN are transmitted, causing the receiver to synchronize on the byte boundary, then a long string of bits are sent whose separation into bytes is controlled only by that counter. Periodically, extra sets of SYN are sent to ensure the receiver stays in sync with the byte boundary.
As should be obvious, SYN is stripped off from the message and ignored by anything downstream, since it only existed to establish byte boundaries. Control characters are sent to delineate header information from the body of the message. There is a cyclic redundancy check (CRC 16) that is accumulated by the transmitter and receiver. That value is transmitted at the end of a block and compared to the accumulated value as a way of spotting errors in reception.
WHAT ABOUT AVR PROCESSOR USART TO IMPLEMENT THE LINK, E.G. ARDUINO
The AVR processor in the Arduino has a USART function built in, which supports both async and synchronous serial communications. It produces a clock that is sent to the other side, thus causing the receiver to sample the value of each bit at the clock transition instead of the time delay established by a start bit.
However, it doesn't understand SYN and thus it handles character boundaries the same way that it does in async mode. A start bit precedes every character. Thus, the USART is not capable of either transmitting or receiving BSC streams even if I could handle the CRC and other control characters in software.
WHAT ABOUT A RASPBERRY PI LIBRARY AND HARDWARE CONNECTION
The Raspberry Pi does not have a USART either and isn't capable of implementing the BSC stream. I suppose that at extremely low data rates one might be able to bit-bang either this or the Arduino to fake a clock and the data stream, but I consider this impractical in the extreme.
IS THERE A SYNCHRONOUS SERIAL OPEN SOURCE VHDL/VERILOG THAT CAN WORK
I went on a hunt through opencores.org and other internet sources looking for an FPGA implementation that someone had already accomplished of at least the basics of sync serial links but there wasn't even a USART implementation similar to the AVR, much less a version that would work with BSC.
ROLL MY OWN USING AN FPGA
Implementing BSC is pretty straightforward and should be easy coding on an FPGA. I have a clock that I generate and transmit over to the 3174 side as well as use if for encoding and decoding characters. A state machine will allow the receiver to synchronize to the SYN SYN characters and to evaluate every EBCDIC character that follows.
The BSC link I am implemented is non-switched and point to point. That means I have a pretty simply polling mechanism to check with the 3174 for any keystrokes and messages. In between I listen for the 3174 to request the line by an ENQ to send back responses. If I have a 3270 data stream to send, I ask for the line with ENQ and transmit the message.
There will be a bit of logic to accumulate the checksum, transmit the value or check for a match with the received block. Framing and unpacking messages is straightforward using the control characters such as STX and ETX.
The only other function I would need is a standard async serial link to pass the messages in and out of a PC where I would build 3270 datastreams and interpret responses from the controller.
Overall it is conceptually easy but still involve a bit of VHDL coding and lots of debugging to get this working properly. Too, it would expose any misunderstandings I had about BSC as used by the 3174, requiring yet more debugging.
LEVERAGE WORK BY MATTIS LIND WHO IS ATTEMPTING PARALLEL PROJECT
Mattis Lind is attempting to use an Alfaskop 4110 terminal, a Swedish terminal that is compatible with the IBM 3270 family, using either BSC or SDLC through a very similar controller to my 3174 to connect to a mainframe. He wants to link this to Hercules. Thus, his work is very parallel to what I am trying to achieve. https://github.com/MattisLind/alfaskop_emu
His solution is a board housing a microcontroller (STM32) that manages the BSC link to the controller, dealing with all the control functions, checksums, SYN characters and framing. The other side of the board he designed, which he calls a SyncDongle, speaks ordinary async serial to the PC where he is running Hercules. The 2703 communications controller code in Hercules provides him an entry point to tie this all together.
Mattis is still working out bugs particularly in the function that copies messages between the two types of serial links on the board. Still, the bones are all there and would give me a very fast route to achieve my goals. I can send the PCB files out, get the board and create my own SyncDongle. I can either wait for his code to be finished or work on this portion myself.
No comments:
Post a Comment