How is this checksum calculated

Does anyone see how is this checksum being calculated?

I have 10-byte data which starts with 255 and ends with checksum (effectively start byte, 8 bytes of data, and the checksum byte). Here are several examples:

255   255   255     1   0   0   255   255   255   255
255   255   255   251   0   0   255   255   255   249
255   255   255   249   0   0   255   255   255   247
255   255   255   241   0   0   255   255   255   239
255   255   255   193   0   0   255   255   255   191
255   255   255   225   0   0   255   255   255   223

(in essence, my problem is staying in sync with the data stream, since there are too many 255s to use them to latch onto the right one. And before you say "look for 3 FFs followed by three bytes and 3 FFs", the FFs other than the first one do end up having different values on more feature-loaded version of the device)

The value in column 10 is always two less than the value in column 4.

Pete

Which device is it?

Pete

It's a sport score and time display, which outputs display state as a serial stream for connecting remote (slave) displays.

I don't think you have enough data (or enough changing data) to determine the CRC for sure. As el_supremo pointed out the last value is 2 less than all the other (9) values xor'ed together. It is also seems to be 4 more than the other bytes added and result truncated into 8 bits.