Changes

I find Ghidra and compile Dev version for some reason I can't recall. I think so I can load third party CPUs.

==Cutter -==

Yay. Cutter was much more useful for what I wanted. Lots of functions were discovered and named with the help of LLMs. (as such, we can't take them as absolutely true, though they are likely to be mostly correct). Things discovered:

Firmware checks for input (button push) in early boot. This branches into and launches diagnostic (Monitor) mode. Run Commands not yet discovered.

DFU routine and bytes compared to trigger DFU over midi. Firmware is checking for a series of bytes sent from a different machine - these are user operations not part of diagnostic branch. '''''DFU mode trigger (multi-byte pattern): AE E8 6A F7'''''

Show version routine. Again a user operation via a different machine. The User sets a byte sequence using a button combo on a Roland mixer. It sends the bytes to the DIF-AT, and it responds by printing the DIF-AT Version number over midi, on the mixer display screen.

|}

Also the firmware itself is still available from Roland, as midi update files. These files are sent to the DIF-AT over its RBUS midi port, from an RBUS capable device. (Although classic Roland it seems to be only ''one'' digital mixer that has the correct button sequence to do the update / show version) However they are correct in that a user would need an RBUS port to send the midi files, as the DIFAT midi port is two pins on the RBUS connector.

I have not yet performed a Diff of my firmware and the midi updates. I would have to reconstruct them first into a full image. I think my firmware is not corrupted though at this point. I will try and send the DFU command and the payload using a python script instead:

With more help from LLM I made a DFU Update python script which first sends the (probable) DFU command, and then sends sequentially all midi files. I compared the received payload to the sent, and it is correct. I have yet to test on the device.