First I would put it in display test and let it run. See if it gets stuck in test mode or just when displaying game graphics.

Not familiar with R & B, but if its a data east that has the DMD controller on its own cpu then the DMD is resetting likely due to voltage issues. The game and DMD run separately, so the game continues but the display resets, shows boot up sequence, then catches up to the game in progress. It will also give weird, half animations too.

I had that on my tmnt. Power connector issues and failing capacitors on the power supply were the culprits. Measure the logic voltages on the DMD and seen if they're within spec.

^^^^^ good analysis.
That three pin connector on the dot controller board was a poor engineering decision.
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact
http://webpages.charter.net/chibler/Pinball/index.htm
http://www.PinWiki.com - The new place for pinball repair info

Highly doubtful.
Even without a cover on the window, it would take about 1900 years for the ROM to be corrupted via UV light.
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://webpages.charter.net/chibler/Pinball/index.htm
http://www.PinWiki.com - The Place to go for Pinball Repair Info

That's definitely an area of concern. I'd certainly replace the ribbon as the first step. We need to rule that out.
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://webpages.charter.net/chibler/Pinball/index.htm
http://www.PinWiki.com - The Place to go for Pinball Repair Info

I see the small ribbon cable from the DMD to the DMD controller fail more often then the one from the DMD controller board to the MPU board.

Maybe. Could be a few other things too, like RAM. I've seen Gottlieb sound boards go haywire at the exact same point and the problem was a failed RAM IC. It would be nice if you had another game to swap boards with to help isolate.
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://webpages.charter.net/chibler/Pinball/index.htm
http://www.PinWiki.com - The Place to go for Pinball Repair Info

Chris Hibler is speaking about the RAM on the Display Controller Board at position U8!!!!! This RAM would be the first part, I would suspect, available at GPE, part-number 62256LP-70.

Data_East_Display_Controller_U8_(resized).jpg

While this is true in computer, its extremely unlikely in a pinball machine. Unlike a computer, the pinball machine is designed to execute a single program all the time. When you turn on your pinball machine, the program contained on the ROM is loaded into RAM, once loaded into RAM the computer will perform a checksum against the data stored in RAM to verify it's integrity. The checksum itself is an algorithmic comparison of all the data loaded in memory against a known value; at the end of this check if the value of the checksum is not an exact match with the known value, you should receive a checksum error and the program will simply not run. The likelihood of having data corruption (even a single bit) and passing this check is infinitesimally small.

If you want to see an example of this, you can install FCIV on your computer; see https://support.microsoft.com/en-us/kb/889768 for information. While FCIV is using a much more sophisticated algorithm, the principals are the same.

Using FCIV against a text file containing the text "I like pinball" results in a checksum value of ac33eda3d4b430058f21676915503f77
now if you change the text to read "I like Pinball" the resulting checksum is fe123c23adb57df53f894a95078020a6 as you can see this tiny change resulted in a vastly different result.

Sucks that they didn't spend the extra $0.50 to socket that IC

Pin_guy provided a pretty good explanation above. One point of confusion might be clarified...

The ROM image might be copied into RAM, one byte or word (2 bytes) at a time for the checksum operation but the whole image is never copied into RAM at one time. Some computing systems use "off line" storage to store the program, and at boot time, copy the program into RAM to speed execution, but pinball processing systems don't need to do this.

During normal program execution in a pinball machine, RAM is used as a "scratchpad". Every piece of information that changes over the course of program execution (i.e. variables) are stored in RAM. The amount of RAM used varies over time as the memory "stack" or "heap" expands and contracts. It is possible for a RAM with a failed memory location or two to not impact correct program execution, if those locations are never used. But if the executing program needs to store or recall a variable from RAM, and that RAM location has failed, at best the program will act on compromised data. At worst the data represents the next instruction pointer location at which time the processor can begin to execute an area of code it was not intended to at that moment. Side affects are unpredictable but sometimes repeatable.

I can't say with 100% confidence that the problem is the RAM. It's just something to suspect. What we know with certainty is that the running program is encountering a situation that it wasn't designed to deal with. Perhaps bad data or a bad execution pointer or a bad index into a table. Without the original source code and a debug platform, we'll never know.
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://webpages.charter.net/chibler/Pinball/index.htm
http://www.PinWiki.com - The Place to go for Pinball Repair Info

Chris, thanks for providing the clarification

I just thought of something. It's possible that your game and display ROMs are mismatched. There were a few revs of the R&B ROMs and I've seen this cause issues in the past.

Since you've owned the game, has it ALWAYS behaved like this?
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://webpages.charter.net/chibler/Pinball/index.htm
http://www.PinWiki.com - The Place to go for Pinball Repair Info

That's the behavior you would expect when the dot controller resets. The controller could have reset due to power inconsistency or the 68B09 might have vectored through reset because it "went off into the weeds".
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://webpages.charter.net/chibler/Pinball/index.htm
http://www.PinWiki.com - The Place to go for Pinball Repair Info

If the updates aren't indicated in the release notes (might be in the ROM zip) then it would be tough to tell.
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://webpages.charter.net/chibler/Pinball/index.htm
http://www.PinWiki.com - The Place to go for Pinball Repair Info

Had a very similar issue on my TOM, where during a particular animation the dmd would freeze sometimes. Occasionally I had to reset the game as everything went pear shaped. I changed all the obvious and nothing helped. In desperation I changed out the mpu board and the problem went away. Surveying my MPU and MPU socket I noticed a small amount of corrosion on 2 pins where some moister must of got in. Cleaned up the pins, reseated the mpu and all worked fine. Why I never had an issue anywhere else during the game is puzzling, but It only did it on one animation and it was probably the most complex animation for the mpu/cpu to process. Might be worth having a look at your MPU board, although I know the DE and Bally setup is somewhat different. Good luck

Is it the CPU or the display that performs this integrity check? If one doesn't it could allow corrupt/bit rotted data to be loaded and executed.

Sorry that question was directed at everyone.

Interested in this too as I have a similar problem with my Hook DMD resetting but seemingly it happens more randomly on multiple animations during gameplay. I will be replacing the ROMs in the near future when the fan patch ones are out so perhaps they will solve my problem as a side effect.