Right, this is getting real annoying. A lot of decisions in the reset procedure are made based on reading I/O ports where I have no idea what devices may be connected to that ports. Even with the full schematics and datasheets it would still be a lot of work, and without these it is a lot of guessing. It's also possible that by trial and error patching sooner or later we will override safety features and/or set things to fire...
Then there is still the mystery of why is it locked while the RAM was cleared? Is something wrong and is it a safety feature? We certainly don't want to work around that. Is it custom firmware? I don't think so, the keyboard processing is there in the firmware, but if they made a quick patch good luck finding it amongst 100 memory locations that are all involved in the decision to lock or not.
So a few suggestion:
- Replace the RAM. Since the ROM checksum is disabled I'm not sure the RAM check is even working, who knows it's faulty after all.
- Try to find an interface, as far as I could see they are obsolete but there must be something out there.
- Try to find other firmware, based on the model numbers in the ROM there's a few choices. Maybe the ROM is faulty, no way to tell since the checksum is not working.
62N040RU025P
62N040RU050P
64N040RU100P
64N040RU150P
62N080RU012P
62N080RU025P
64N080RU050P
64N080RU075P
Siemens stabizet D2425
Maybe this guy is willing to read the EPROM, he has like 5 boards on offer:
https://www.ebay.de/itm/274598338156I will stop chasing ghosts for the moment, revert to the original firmware and see if I can get the RS232 working, maybe the lock can be cancelled that way.