I've done some playing around with my DP712. Slurped the main firmware image off the SPI flash chip inside before and after the trial ran out. Unfortunately the license data is actually stored on an FRAM chip that I missed the first time I took it apart.
The main processor appears to be a CME-5 (
http://www.capital-micro.com/PDF/CME-M5_Family_FPGA_Simplified_Data_Sheet_EN.pdf), an FPGA and 8051-based MCU combo. There is a JTAG port available, but I haven't managed to do anything useful with that yet.
The FRAM appears to be a Fijitsu (
https://www.fujitsu.com/us/Images/MB85RC16-DS501-00001-8v0-E.pdf). It uses i2c, contains 8 x 2kbit pages.
Page 0 (Address 0x50) = Configuration settings
Page 1 (0x51) = Appears to be unused
Page 3 (0x52) = Front panel button lock settings in bytes 0x30-32 (each button is 1 bit) and Serial number at address 0x40-4d with what appears to be a checksum at 0x55-56. Changing the SN causes it to copy the serial # back from SPI flash and rewrite it, probably because of the invalid checksum.
Page 4 (0x53) contains the configured options (licenses) starting at 0x00, with what appears to be another checksum at 0x13-0x14.
Pages 5-7 (0x54-57) Appear to be unused.
I was able to hook up a raspberry pi via i2c and can read-write most of the locations while the unit is powered on, with the exception of 0x52 (SN data). This one you can read/write right after power on before it has booted, so you have to be fast. These areas are read on bootup:
1. i2c FRAM address 0x52 Starting at 0x40, reading 23 bytes (appears to be always 0x10 followed by 9 bytes of serial #, 7 0x0 and the 2 byte checksum)
2. i2c FRAM address 0x50 Starting at 0x00, reading 24 bytes (config data and checksum)
3. i2c FRAM address 0x53 Starting at 0x00, reading 21 bytes (option info and checksum)
4. i2c FRAM address 0x52 Starting at 0x30, reading 4 bytes (First 3 bytes front panel button lockouts, unknown 4th byte. These default to all 0x00)
It also re-reads #3 above (options) every 66 seconds while running. The main blocker on getting further with this is the checksum. When the license data is all 0's (which it fills when it detects a bad checksum) the checksum is 0xcc 0x71).
Hopefully someone more seasoned with reverse engineering can take this further... I haven't given up yet though.