Roland DIF-AT - Revision history

RSS1: /* Strings - */

2026-05-10T12:17:49Z

Strings -

RSS1: /* Ghidra - */

2026-05-10T10:20:34Z

Ghidra -

RSS1: /* Ghidra - */

2026-05-10T10:20:08Z

Ghidra -

RSS1: /* JTAG/Programming/CPLD */

2026-05-09T15:13:53Z

JTAG/Programming/CPLD

RSS1: /* Firmware Update Files - */

2026-05-06T21:46:46Z

Firmware Update Files -

RSS1: /* Strings - */

2026-04-30T17:00:37Z

Strings -

RSS1: /* Binwalk - */

2026-04-30T16:59:26Z

Binwalk -

RSS1: /* To Do - */

2026-04-30T16:57:22Z

To Do -

RSS1: /* Firmware Update Files - */

2026-04-30T16:54:56Z

Firmware Update Files -

RSS1: /* Show Version Routine - */

2026-04-30T16:51:55Z

Show Version Routine -

@@ Line 255: / Line 255: @@
 The '''**Roland xx''' looks like a boot banner and is called differently in the firmware.  I'm sure that's why it has different start and stop markers.  Ditto for the early Version string.  Interestingly, the early Version is way at the other end of the addresses in the code.  This adds to the DFU / Bank swap theory.
-When I finally load the firmware (I still haven't at this point) I spend ages looking for what calls these strings.  I find it difficult to navigate but fascinating. It is difficult to navigate any production firmware disassembly I expect.  I have no prior experience, but it seems the H8300H is kind of a different level, a bit of an oddity.  It's used a lot in Japanese electronics.  It is in a lot of Roland devices.  Apparently it interleaves code and data frequently which makes static disassembly trickier.  '''''Especially in Cutter, which won't decompile H8 instructions (it either links to Ghidra method, which does not support the H8, or JS, which can't de-compile either)'''''
+When I finally load the firmware (I still haven't at this point) I spend ages looking for what calls these strings.  I find it difficult to navigate but fascinating. It is difficult to navigate any production firmware disassembly I expect.  I have no prior experience, but it seems the H8300H is kind of a different level, a bit of an oddity.  It's used a lot in Japanese electronics.  It is in a lot of Roland devices.  Apparently it interleaves code and data frequently which makes static disassembly trickier.  ''Especially in Cutter, which won't decompile H8 instructions.''
 ===User / Diagnostic Monitor Strings -===

@@ Line 283: / Line 283: @@
 '''H8300H is not supported in Ghidra'''.  I find a plugin, https://github.com/shizmob/ghidra-h8-300 and try to compile that and load in Ghidra.  It won't compile though -                                Later I also tried https://github.com/carllom/sleigh-h8 which I also don't get running in Ghidra -
-I have since managed to compile the H8300H plugin for Ghidra from [https://github.com/carllom/sleigh-h8 carllom].  It seems working well.  I just wasn't really au fait enough with compiling using Sleigh a few months ago.  It is actuall very easy to compile the advanced model, using this repo.
+I have since managed to compile the H8300H plugin for Ghidra from [https://github.com/carllom/sleigh-h8 carllom].  It seems working well.  I just wasn't really au fait enough with compiling using Sleigh a few months ago.  It is actually very easy to compile the advanced model, using this repo.
 ===Cutter -===

← Older revision		Revision as of 10:20, 10 May 2026
Line 282:		Line 282:

	'''H8300H is not supported in Ghidra'''. I find a plugin, https://github.com/shizmob/ghidra-h8-300 and try to compile that and load in Ghidra. It won't compile though - Later I also tried https://github.com/carllom/sleigh-h8 which I also don't get running in Ghidra -		'''H8300H is not supported in Ghidra'''. I find a plugin, https://github.com/shizmob/ghidra-h8-300 and try to compile that and load in Ghidra. It won't compile though - Later I also tried https://github.com/carllom/sleigh-h8 which I also don't get running in Ghidra -
		+
		+	I have since managed to compile the H8300H plugin for Ghidra from [https://github.com/carllom/sleigh-h8 carllom]. It seems working well. I just wasn't really au fait enough with compiling using Sleigh a few months ago. It is actuall very easy to compile the advanced model, using this repo.

	===Cutter -===		===Cutter -===

@@ Line 64: / Line 64: @@
 JTAG pads are exposed on the PCB as seen in the image above.  I could connect to these to read the CPLD.  Pretty soon they were pulled off the board, and I had to solder a pin to the leg temporarily to continue reading data.  (before I discovered tiny IC clips!)
-[Only one device is visible in the JTAG chain, the Xilinx.  The CPU, [https://www.alldatasheet.com/datasheet-pdf/download/249501/RENESAS/H8SLASH300H.html H8300H] (Hitachi/Renesas) is not equipped with JTAG at all.  Low level CPU operation is done through a bootloader mode]
+[Only one device is visible in the JTAG chain, the Xilinx.  The CPU, [https://www.alldatasheet.com/datasheet-pdf/download/249501/RENESAS/H8SLASH300H.html H8300H] (Hitachi/Renesas) is not equipped with JTAG at all.  Low level CPU operation is done through a bootloader mode] Interesting and lovely late 1990s marketing publication [https://www.ele.uva.es/~jesman/BigSeti/ftp/Microcontroladores/Hitachi/H8-300H/h8_16bit.pdf here]
 I connected to the [https://www.datasheet.live/pdfviewer?url=https%3A%2F%2Fwww.datasheet.live%2Fdatasheet%2Fxilinxsemi%2FXC95144XL-7TQ100C0962.pdf Xilinx XC95144] using [https://github.com/Aodrulez/blueTag/tree/main Bluetag], [https://openocd.org/ OpenOCD] and [https://github.com/MPLew-is/xc3sprog XC3SPROG] (open source Xilinx CLI) and was eventually able to read back ID codes and find IR Len etc.  I was happy it was responding.  It was fun, confusing and difficult to set up all these tools.  I set most of them up on a Raspberry Pi as dedicated hacking server so I can connect remotely to the hot mess setup with my laptop, somewhere more comfortable : )

@@ Line 379: / Line 379: @@
 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 (see below)
 The midi files are 4x33kb.  Minus headers etc; 32kb actual payload x 4 = 128kb firmware.  A 512kb NOR flash is generous space for this (4x bigger)  Though remember its banked for DFU (when the update is written and verified it will switch active bank flag) Also it seems remapped to different addresses in runtime operation also.
 ===DFU Python Script===

@@ Line 247: / Line 247: @@
 Alright we've heard enough about them; above is the list created with
-- '''''strings -n 6 INTEL_HEX_DIF_AT_LH28F400BVE@TSOP48_byte_swapped.bin'''''
+'''''strings -n 6 INTEL_HEX_DIF_AT_LH28F400BVE@TSOP48_byte_swapped.bin'''''
 I removed all the strings returned which are over n6 though not really strings - and - There are also two blank strings which the above table has optimised away.  These blank strings seem to have a function, which is unclear at present.

@@ Line 131: / Line 131: @@
 ==Examine Firmware -==
 ===Binwalk -===
-I slowed down a bit here because I had no idea how to actually load the file I'd dumped to look at it.  First I used [https://github.com/ReFirmLabs/binwalk Binwalk], which I *think* is more suited to SOC work (at least, I think Binwalk is able to find files and systems within bin images, which this firmware does not contain) Anyway Binwalk was able to provide an informative image showing the entropy of the file - low entropy = low chance of corruption or encryption.
+I slowed down a bit here because I had no idea how to actually load the file I'd dumped to examine it.
 ===Binvis -===

@@ Line 613: / Line 613: @@
-Here are some general pinout notes on the DIF-AT RBUS and Digital Audio flow, and the connections to the Alesis Chip (which seems to do all the heavy lifting as regards audio and timing)
+Below are some general pinout notes on the DIF-AT RBUS and Digital Audio flow, and the connections to the Alesis Chip (which seems to do all the heavy lifting as regards audio and timing)
-All audio formats go directly into the Alesis chip, and it handles so much, audio formats, inputs, - BREQ bus arbitration, WE to Flash, CE with mux to Flash, that it must be an ASIC.
+All audio formats go directly into the Alesis chip, and it handles so much, audio formats, inputs, - BREQ bus arbitration, WE to Flash, CE with mux to Flash, that it must be an ASIC.  Any thoughts on this, or anything else here, are most welcome.
-The Xilinx chip is handling RBUS signals only, after they leave the Alesis chip, they go into the Xilinx CPLD, and leave the DIF AT via an inverter.  I will inspect the signals before and after the Xilinx chip to see how it is processing the data after the Alesis chip.
+The Xilinx chip is handling RBUS signals only, after they leave the Alesis chip, they go into the Xilinx CPLD, and leave the DIF AT via an inverter.  I will inspect the signals before and after the Xilinx cpld to see how it is processing the data.
 <br />

@@ Line 142: / Line 142: @@
 Appears it was already updated in the field to the last OS version (1.022) from  I'm not sure if it then wipes the other bank?  Possibly, because the other regions are written with FF.  However it was still pretty confusing to navigate around later on; BRA from active code to 0xFF region.
-Probably some of these are the as yet un-mapped SRAM, and Alesis IC addresses.  I've added peripheral mapping for the SCI.  I'm learning a lot as I go!  Also maybe the Alesis ASIC remaps certain memory addresses at run time?  (more research has shown that this is likely). These images show the mirrored banked addresses - some lead to empty regions (maybe ram?) and some have near identical code (version differences?) and some have different data (bytes table for strings)  [[File:DIF-ATBanked ROM2.png.png|thumb|DIF-AT firmware showing mirrored 'blank' bank location.   |alt=]][[File:DIFAT Bank Example.png|alt=DIF-AT firmware with mirrored bank -near identical addressing much higher in ROM region|thumb|DIF-AT firmware with mirrored bank - almost identical addressing just much higher in ROM region|none]]
+Probably some of these are the as yet un-mapped SRAM, and Alesis IC addresses.  I've added peripheral mapping for the SCI.  I'm learning a lot as I go!  Also maybe the Alesis ASIC remaps certain memory addresses at run time?  (more research has shown that this is likely). These images show the mirrored banked addresses - some lead to empty regions (maybe ram?) and some have near identical code (version differences?) and some have different data (bytes table for strings).   [[File:DIF-ATBanked ROM2.png.png|thumb|DIF-AT firmware showing mirrored 'blank' bank location.   |alt=]][[File:DIFAT Bank Example.png|alt=DIF-AT firmware with mirrored bank -near identical addressing much higher in ROM region|thumb|DIF-AT firmware with mirrored bank - almost identical addressing just much higher in ROM region|none]]
 ==Firmware Strings -==
@@ Line 369: / Line 369: @@
 ===Firmware Update Files -===
-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.
+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 Roland are correct in that a user needs an RBUS port to send the midi files, as the DIF-AT midi port is two pins on the RBUS connector.
 https://www.roland.com/us/support/by_product/dif-at/updates_drivers/ac2a8693-f923-4894-9d8d-da20af3b75ef/ (mac, sea.hqx)
@@ Line 377: / Line 377: @@
 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 (see below)
 The midi files are 4x33kb.  Minus headers etc; 32kb actual payload x 4 = 128kb firmware.  A 512kb NOR flash is generous space for this (4x bigger)  Though remember its banked for DFU (when the update is written and verified it will switch active bank flag) Also it seems remapped to different addresses in runtime operation also.
 ===DFU Python Script===

@@ Line 298: / Line 298: @@
 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.
-These operations are described below.  I found them on Roland's site, and then looked for the relevant part of the firmware which checks for these bytes.  '''''Send single byte 0x06 from host to device. That causes the device to: enter Show-Version handler run fcn.ShowVersionSequence() transmit the version bytes to host. return to idle mode'''''
+These operations are described below.  I found them on Roland's site, and then looked for the relevant part of the firmware which checks for these bytes.  Notes from examining the firmware -  '''''Send single byte 0x06 from host to device. That causes the device to: enter Show-Version handler run fcn.ShowVersionSequence() transmit the version bytes to host. return to idle mode'''''
 {| class="wikitable"
 |+