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@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. >
