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_Syst… 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_… 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>: I guess any idea here can push me forward to find a solution! 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. 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. Absolutely right! 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. 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. 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.

Mattis Lind wrote: How about this code: #include <stdio.h> int crc16(unsigned char *ptr, int count) { unsigned int crc; char i; crc = 0x0000; while (--count >= 0) { crc = crc ^ (unsigned int) *ptr++; i = 8; do { if (crc & 0x0001) crc = (crc >> 1) ^ 0xA001; /* 0x8005 bit reversed */ else crc = (crc >> 1); } while(--i); } return (crc); } void main() { /* 32 01 6C D9 02 40 40 40 70 03 26 88 */ unsigned char data1[] = {0x6c, 0xd9, 0x02, 0x40, 0x40, 0x40, 0x50, 0x03}; /* 32 01 6C D9 02 40 C8 40 50 03 0D 28 */ unsigned char data2[] = {0x6c, 0xd9, 0x02, 0x40, 0xc8, 0x40, 0x50, 0x03}; printf("crc sent: 8826 computed: %4.4x\n", crc16(data1, sizeof(data1))); printf("crc sent: 280d computed: %4.4x\n", crc16(data2, sizeof(data2))); return; } Please note that I had to cheat to get this to work. It worked initially for the second case but it only worked for the first case when I tweaked 70 to 50, ie I substituted the corresponding value from the second case. Regards, Peter Coghlan.

CRC-16 sounds familiar, as does 0x8005 for a polynomial. I collected a very large lists of CRCs a while back (it's in the test suite for the crc.py module in pydecnet); in there I have the description "IBM" for the 8005 polynomial. The list came for the most part from Wikipedia: https://en.wikipedia.org/wiki/Cyclic_redundancy_check which lists BISYNC as one of the users. Initial value would be zero; that's common for several of the older CRCs (including CRC-CCITT used by DDCMP). paul

Sorry guys, that LTspice stuff was not for this group - my mailer must have screwed up! 73 de Nigel ve3id On 26/01/2020 18:12, Bob Smith via cctalk wrote: -- Nigel Johnson MSc., MIEEE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! You can reach me by voice on Skype: TILBURY2591 If time travel ever will be possible, it already is. Ask me again yesterday This e-mail is not and cannot, by its nature, be confidential. En route from me to you, it will pass across the public Internet, easily readable by any number of system administrators along the way. Nigel Johnson <nw.johnson at ieee.org> Please consider the environment when deciding if you really need to print this message

On 1/26/20 3:12 PM, Bob Smith via cctalk wrote: If you've got the message and the checksum, however computed, there are free tools to grind through the usual suspects. I've used it on alien disk formats very successfully. --Chuck

On 01/27/2020 02:20 AM, Mattis Lind via cctalk wrote: Soem years ago I needed to crack the CRC on a Fanuc serial encoder. Luckily, the CRC value was just 5 bits. I built a device to read out and store the data from the encoder on a PC. Then, I wrote a little c program that had a "universal" CRC implementation, where the polynomial was supplied as a command line parameter. It would read the stored file, apply the polynomial as given and report the residuals. With just a 32 value search space, I just entered them one at a time, and a few minutes later, I had found the polynomial that gave all zero residuals. With a larger search space, you might construct such a program and let it run all possible polynomial values and report how many all zero residuals you got for each. Given just a few short message blocks, it shouldn't take more than a few minutes to find the magic number. Jon