IBM BSC CRC?

Mon Jan 27 02:13:36 CST 2020

Hello Peter!

Thanks for the effort to help!

I maybe should elaborate a bit on what I am doing and what equipment is
involved. The sending equipment is a Alfaskop CPR4101 communication
processor. Basically IBM 3274 model C BSC compatible. There is some
description on how it communicates using BSC from page 89 and onwards in
this pdf:
http://storage.datormuseum.se/u/96935524/Datormusuem/Alfaskop/Alfaskop_System_41_Reference_Manual_IBM3270_Emulation.pdf

Essentially what is written there is very similar to what IBM has written
in
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/3274/GA23-0061-1_3274_Control_Unit_Description_and_Programmers_Guide_Jan84.pdf
on
page 159 and onwards.

The receiving end was an Intel 8274 chip programmed in BSC mode from a
small STM32 micro controller. https://i.imgur.com/aPNMMkr.jpg?1 I just
added a 1488 and 1489 and a cable to connect to the communication
controller. I pulled together some kludgy software that just acquired SYNC
and the listened to what was received on the line when sending a POLL
message to the communication controller.

So here I did capture the messages involved:
https://i.imgur.com/rHfN3t4.jpg
https://i.imgur.com/t1NgEz2.jpg

The trailing FF is because there is no state machine in the receiver that
is properly detecting the end of message and then putting  the receiver in
SYNC HUNT mode again. Not having a state machine also makes it difficult to
use the CRC hardware inside the 8274 chip. But the chip only support CRC-16
and the CCITT CRC-16. The actual communication processor uses the Motorola
6852 chip which doesn't seem to have built in CRC handling om chip so I
guess it takes place in the software.

Have checked just the IPL ROM of the software involved. And it contain a
CRC routine for checking the integrity of the ROM itself. Since many of the
routines in the ROM are used by the operating system and high level
software of the comm processor it might be the one checking BSC
communication or it might be a completely different algorithm. Don't know
for sure. 6800 assembler code generated by some kind of compiler.

; subroutine
FC03: CE F8 02 ldx #$F802 ; The address of the ID string of the software
FC06: FF 01 A9 stx $01A9
FC09: CE 00 00 ldx #$0000
FC0C: FF 01 AB stx $01AB
FC0F: CE F8 00 ldx #$F800 ; Base of IPL PROM
FC12: FF 01 A7 stx $01A7 ; Store it
FC15: BD FC 23 jsr $FC23 ; jump to CRC routine
FC18: B6 01 B7 lda $01B7
FC1B: 27 05 beq $FC22 ; If ok jump to the rts.
FC1D: 86 50 lda #$50 ; Put a "P" in A.
FC1F: 7E FB A9 jmp $FBA9 ; Error routine
FC22: 39 rts
; CRC subroutine - at least the tech spec says it does a CRC on the IPL ROM
and this sure looks like it.
FC23: 7F 01 B8 clr $01B8
FC26: 7F 01 B9 clr $01B9
FC29: FE 01 A9 ldx $01A9
FC2C: 86 F8 lda #$F8
FC2E: B7 01 BA sta $01BA
FC31: A6 00 lda (x+$00)
FC33: 08 inx
FC34: B7 01 BB sta $01BB
FC37: 74 01 B9 lsr $01B9
FC3A: 76 01 B8 ror $01B8
FC3D: C6 00 ldb #$00
FC3F: 59 rolb
FC40: F8 01 BB eorb $01BB
FC43: C4 01 andb #$01
FC45: 27 0E beq $FC55
FC47: F8 01 B8 eorb $01B8
FC4A: F7 01 B8 stb $01B8
FC4D: F6 01 B9 ldb $01B9
FC50: C8 A0 eorb #$A0
FC52: F7 01 B9 stb $01B9
FC55: 7C 01 BA inc $01BA
FC58: 27 03 beq $FC5D
FC5A: 44 lsra
FC5B: 20 D7 bra $FC34
FC5D: BC 01 AB cmpx $01AB
FC60: 26 CA bne $FC2C
FC62: FE 01 A7 ldx $01A7
FC65: EE 00 ldx (x+$00)
FC67: BC 01 B8 cmpx $01B8
FC6A: 27 03 beq $FC6F
FC6C: 7C 01 B7 inc $01B7
FC6F: 39 rts

I tried to communicate with the comm processor  without using the Intel
8274 chip, directly using the STM32 micro controller by using the SPI port.
It successfully receives the message and is able to sync but since I cannot
check incoming CRC neither can I generate a proper outbound CRC it will not
be able to communicate very well.
WIP: https://github.com/MattisLind/alfaskop_emu/tree/master/Utils/BSCGateway

More comments inline below:

Den mån 27 jan. 2020 kl 00:52 skrev Peter Coghlan via cctalk <
cctalk at classiccmp.org>:

> Mattis Lind wrote:
>
> >
> > Hello IBM BSC Experts!
> >
> > I am trying to figure out the CRC algorithm used by IBM BSC. I have
> tried a
> > lot of different settings in crcreveng but not getting a match.
> >
>
> I'm definately not an IBM BSC Expert and I don't even play one on TV.  I
> have
> tweaked some BSC emulation code written by someone else so I have some
> vague
> idea about this stuff, however, the emulation did not include CRCs so I'm
> not sure how much help I can be.
>

I guess any idea here can push me forward to find a solution!

>
> >
> > I am pretty convinced that the CRC-16 used by IBM was
> >   16          15       2
> > x      +   x     +   x     +  1
> >
>
> In the file bcb_crc.c supplied with the funetnje and HUJI-NJE packages, it
> says the following (which may or may not relate to CRCs in the BSC world):
>
>
Thanks! Interesting. Checked this CRC generator and it creates exactly the
same CRC bytes compared to the other CRC implementations I have found
around on the net. But not matching the bytes received.

>  | The generating polynomial is X^16+X^15+X^2+1 (CRC-16). When computing
> the
>  | CRC, DLE's are not computed (except from a second DLE in a sequence of
>  | 2 DLE's). Furthermore, the first DLE+ETB which starts a text block is
>  | not computed also.
>
> There is also some code for checking CRCs, however, it is not clear to me
> if this code is for use with BSC lines or with DECnet lines.
>

Cannot really understand what bcb is and what has to do with it. Is the
protocol some kind of BSC derivative with extra features. Don't really
understand it when glancing quickly through the code.

>
> >
> > This would give the polynomial 8005.
> > Anyone against this statement?
> >
> > But what was the initial value?
> >
> > I have two actual messages from equipment employing IBM BSC:
> > 32016CD90240404070032688
> > and
> > 32016CD90240C84050030D28
> >
>
> These appear to be something like:
>
> SYN SOH '%' 'R' STX SP SP SP ACK0 ETX followed by CRC-16
>
> and
>
> SYN SOH '%' 'R' STX SP 'H' SP '&' ETX followed by CRC-16

Absolutely right!

> > From this document (
> >
> http://bitsavers.trailing-edge.com/pdf/ibm/datacomm/GA27-3004-2_General_Information_Binary_Synchronous_Communications_Oct70.pdf
> > )
> > I get that the CRC calculation is reset on SOH (01h) or STX (02h) and
> > accumulates until and including the ETX (03h). (excluding any SYN (32h)
> > characters).
> >
>
> On page 17, it seems to suggest that the CRC calculation is not reset by
> STX
> when the STX follows SOH, which it does in the above cases.
>
>
You are right. My comment was a bit ambiguous. If it has hit a SOH or a STX
it will accumulate until it find a ETX or ETB.

> >
> > I have tried crcreveng back and forth and I am not getting the CRC bytes
> > right.
> > I think I have tried most things, different bit order, different initial
> > values. But nothing.
> >
> > I also tried the mode in crcreveng where it searches for matches but it
> > always says "no models found". Maybe I am doing something wrong when
> using
> > crcreveng?
> >
> > Any clues? Surely there are someone out there that has been around for
> some
> > time and knows this, right?
> >
>
> On page 8, it says: "SOH% is presently used to identify request-for-test or
> station-dependent control messages." - could this be significant?
>

This is a status message sent by the communication controller is response
to a POLL. It tells status and sense information for the terminal. Pages
172 and 175 in the IBM document mentioned above.

>
> What produced the the two sequences you quoted above and do you know what
> those messages mean?  Is it possible that the CRC included with them is
> deliberately wrong?
>

Don't think they are wrong. This is a ex-production equipment and the
software is a late version and has certainly been in production for quite
many years. Although obviously totally obsolete by now.

One of my concerns is my complete inability to get the same CRC digits from
crc reveng compared with the three C crc algorithms I found on the
internet. I just have to do something wrong when fiddling with the options.
But what? I think I have tried bit order, inverting the bits etc. But still
nothing.

Are there any crc reveng experts out there??

I reckon that I once upon a time earlier failed to work with crc reveng. At
that time I had a tape with a CRC on it. I had to resort to check the
actual hardware to get the right polynomial. The hardware used a signetics
N9401 chip which has 8 hardcoded polynomials in it. As it was wired for
CRC-16 the polynomial was 8005 and I was able to get the checksum correct.
But I completely failed to find it using crc reveng. Unfortunately I have
no idea why.

> Regards,
> Peter Coghlan.
>