In-depth technology research: finding new ways to recover data, accessing firmware, writing programs, reading bits off the platter, recovering data from dust.
Please do not post
questions about data recovery cases here (use this forum
instead). This forum is for topics on finding new ways to recover data. Accessing firmware, writing programs, reading bits off the platter, recovering data from dust...
August 18th, 2017, 12:08
Thanks Franc. Interesting idea, may be because it is 1:30am but I am not sure I follow the last post.
I tried to find some kind of format that fit like S-record as well but came up short.
haven't had time to get back to this, but I thought some of the files may be useful to anyone looking at this.
it is just all files with midi stripped and some helper files.
August 18th, 2017, 15:27
I hope the following example better illustrates my interpretation of the data "octets".
00 16 5E 0A 4E 53 20 18 -- 7 data bytes + 1 mask byte
00/00 16/16 5E/DE 0A/8A 4E/4E 53/53 20/20 -- 7-bit / 8-bit
.0000000 0010110 1011110 0001010 1001110 1010011 0100000 -- 7-bit data bytes
00000000 00010110 11011110 10001010 01001110 01010011 00100000 -- 8-bit data bytes
: _______: : : : : :
: : ______________: : : : :
: : : _____________________: : : :
: : : : ____________________________: : :
: : : : : ___________________________________: :
: : : : : : __________________________________________:
: : : : : : :
0 0 1 1 0 0 0 -- 7-bit mask byte
After further examination it appears that the checksum is calculated on all bytes after the size byte(s). It should be 0x05 (or 0x85). This tallies with the last [short] data record in SP8EX#8.mid and also with the other "10 F0 <size> <stuff> F7" non-data records.
August 18th, 2017, 15:40
10 F0 12 41 10 00 2B 12 01 02 00 00 00 00 00 00 00 07 00 76 F7 SP8EX#1.mid
10 F0 12 41 10 00 2B 12 01 02 00 00 00 00 00 00 01 07 00 75 F7 SP8EX#2.mid
10 F0 12 41 10 00 2B 12 01 02 00 00 00 00 00 00 03 07 00 73 F7 SP8EX#4.mid
10 F0 12 41 10 00 2B 12 01 02 00 00 00 00 00 00 07 07 00 6F F7 SP8EX#8.mid
^^ ^^ ^^
: : :
current MIDI file - 1 : checksum
total number of MIDI files - 1
August 19th, 2017, 6:33
Thanks for the clarification. I get the byte to bits conversion, I was meaning how it relates to the block and hitachi itself. Should we be converting (strip the checksum byte) first before trying to disassemble the code, or use it as is? should the checksum and "header of each record be stripped before attempting disassembly?
I am not home today much, I would think going through a few examples would make these questions apparent though, so I will probably answer my own questions later.
Appreciate your work on this and the analysis. Pretty good work. Just had another thought - this all goes on the H8, but what goes on the NAND?
Seller isn't answering calls or email to fix the wrong board sent so cant read the chip yet. a raw dump might be useful to see what format data is put on like and what goes to what addresses
August 19th, 2017, 9:48
I realise the following is for different devices, and also not exactly lined up with what we have been discussing previously... but some random googling while out and about pulled up some interesting results. Not saying they are useful!
I include it as it seems to add credit to Francs research, and possibly provides some more insight to the format, if the "Roland Two-Byte Model ID" talk is relevant here.https://mididesigner.com/qa/3881/how-to-send-roland-jx-305-nibbles-2-values-in-sysex-message?show=4693#c4693
From what I see in the 305 manual the sysex messages needs 1 byte for the checksum. This means that the
byte before F7 is the checksum byte. And the 2 bytes before the checksum byte will be the V.
So your syxex message you will have to enter will be something like bla bla 03 V, I think.
To me, the talk on this page seem like the peek and poke commands we used to do on the Dick Smith Wizard computer back in the 80's.
Yes, Each sound/patch/part (whatever you call it) is made up of four waveforms that roland calls "tones"
the sysex string i am sending changes the first of the four tones on part 1 of the synth.
Hope that makes sense.
The 10 in the address means the first tone 12 = 2, 14 = 3, 16 = 4.
Also interesting to note that a Roland device can also respond to SysEx .. which I guess is obvious, but may be useful to investigate.
looking at exactly what the SysEx command table is would be interesting. looks like there may be a few:https://mididesigner.com/qa/3789
Controls all 313 parameters editable by Sysex,
-In order to use it you must set unit ID number to "17"
-In order to use it you must set "receive incoming sysex msg" to "On" in global settings
-This template uses massive SYSEX messaging, you should check your midi bus in order to be sure it manages Sysex in the right way.
August 19th, 2017, 11:38
"Roland System Exclusive Implementation" <--great page.http://www.chromakinetics.com/handsonic ... i.htm#tran
Roland's Manufacturer ID is always the first data byte after the F0, and is always 41.
What do you recommend doing after one first gets a Roland module?
Read this FAQ.
Read it again. Some people have poor reading skills, and they miss or deliberately skip over important points the first time. Worse, they tend to "fall asleep at the wheel" unless they're kept awake with periodic excursions into crass, obnoxiously provocative humor -- much of which is readily available at this web site. Indeed, I blame all of my many lapses into bad taste upon people with poor reading skills. If it wasn't for having to keep them awake, I could instead concentrate upon delivering an unwavering, myopic, textbook (ie, of no practical use) drone like the typical college instructor does.
Read the manual. (Notice a trend here? And yes, I'm actually one of those guys who, when he gets a new piece of gear, excitedly unpacks the manual first and reads it cover to cover, quite willingly, before even plugging in the gear. That's why I can't buy Casio gear. By the time I'm halfway through the pigeon-english in the manual, I'm already tying the noose to the rafter).
Get your divorce papers ready for filing. Your wife will have left you by the time you get around to experimenting with Performance Edit mode... if she knows what's good for her.
August 19th, 2017, 16:19
Thanks for those great links. I had already determined the meanings of most of the sysex events, but your info helped to fill in the missing pieces. I now believe that the checksum is 0 (or 0x80), and is calculated by summing everything after "0x2B 0x12" and before the final 0xF7.
' Parse <delta_time> <event> records
' 00 FF 03 <len> <firmware model/version/date>
' 00 FF 02 <len> <copyright notice>
' 00 FF 51 <len> <tempo stuff>
' 10 F0 <len> 41 10 00 2B 12 <01 02 00> 00 00 00 00 00 <00 07 00> <cksm> F7 - start of file 1 of 8
' 10 F0 <len> 41 10 00 2B 12 <01 02 00> 00 00 00 00 00 <07 07 00> <cksm> F7 - start of file 8 of 8
' 10 F0 <len> 41 10 00 2B 12 <01 03 00> 00 00 00 00 00 <firmware model/version/date> <cksm> F7
' 10 F0 <len> 41 10 00 2B 12 <01 00 00> 00 00 00 00 00 ...
' ... <00 00 01> <00 00 00 00 00> <00 00 01> <0C 00 00 00 00> <cksm> F7
' <-- memstart --> <---memsize --->
' (nibble mode) (nibble mode)
' 10 F0 <len> 41 10 00 2B 12 <00 00 01> <5-byte mem addr (nibble mode)> <firmware payload> <cksm> F7
' 10 F0 <len> 41 10 00 2B 12 <01 01 00> 00 00 00 00 00 <4E> <cksm> F7 - only at end of file8
' 10 F0 <len> 41 10 00 2B 12 <01 02 00> 00 00 00 00 00 <00 07 7F> <cksm> F7 - end of file 1 of 8
' 10 F0 <len> 41 10 00 2B 12 <01 02 00> 00 00 00 00 00 <07 07 7F> <cksm> F7 - end of file 8 of 8
' 00 FF 2F 00 - end of track
HaQue wrote:By the time I'm halfway through the pigeon-english in the manual ...
Ironically, I think the author meant "pidgin". :-)
August 19th, 2017, 17:53
event 2 sets up the Tempo and the delta time is based off this value.
00 FF 51 03 07 A1 20
0x00 = 0x0 time delta value
0xFF = Denotes this is a Meta Event
0x51 = Denotes this meta event is setting the Tempo
0x03 0x07 0xA1 0x20 = Set tempo to 50000 Microseconds per Quarter Note
31250bps = 0x7A12 = UART/MIDI baud rate
0x07A120 = 500 000 = 16 x 31250 = UART clock rate (16 x baud rate)
The UART clock is usually set to 16 times the baud rate. This is so that the start bit can be sampled at 8 ticks after the detection of its leading edge (ie in the middle of the bit interval), and each data bit can then be sampled at subsequent 16-tick intervals.
August 19th, 2017, 18:17
August 19th, 2017, 18:44
Each Roland sysex record starts with 0x10 0xF0. I suspect that the delta_time value of 0x10 corresponds to 16 ticks of the UART clock for each transmitted bit.
August 19th, 2017, 23:48
Thanks! yes all starting to make sense.
Here is another site devoted to SysEx http://www.2writers.com/eddie/tutsysex.htm
I think most of it is covered now though.
August 20th, 2017, 20:12
@HaQue, I have written a tool to extract the firmware binary from the MIDI files.http://www.users.on.net/~fzabkar/temp/Rmid2bin.bashttp://www.users.on.net/~fzabkar/temp/Rmid2bin.exehttp://www.users.on.net/~fzabkar/temp/SP8EXall.bin
The following DOS command converts all 8 MIDI files and writes the result to a single BIN file:
for %i in (SP8EX#?.mid) do Rmid2bin.exe infil=%i outfil=SP8EXall.bin
I don't believe it will work with your Edirol A6 MIDI files (in their original state). One difference is that they don't have a "Device-ID" parameter.
Could you upload the original MIDI files? Maybe I could accommodate the differences with some minor changes to my program.
August 20th, 2017, 22:11
@fzabkar, That's great, Thanks a lot! I probably wont have time till approx. 11pm to look at this properly, but here are the A6 Midis in Original format.
Last night I had a quick look at the files and noticed if the 4th byte 0x12 was the send command, there is no request command. So There doesn't seem to be too much in the way of verification or checking stuff. Aside from Checksums.
I've programmed things like PICs, 68HC11, Arduino's etc. This one looks a little different but hoping to be able to at least identify the ATAPI code and maybe even backport A6 to 808. But to be honest I am just a hack (hence the name!) and only formal training was Uni, the 68HC11 - a very simple chip, and playing around with building logic circuits with different 74xx chips and flip-flops... long time ago.
August 21st, 2017, 16:52
The following article suggests that the MIDI Device ID can vary between 0x01 and 0x20, with 0x10 being the default:
AR-2000: Setting the MIDI Device ID:https://www.roland.com/us/support/knowledge_base/201918109/
Rotate the SELECT dial to select the Device ID (1-32)
Your Edirol A6 sysex format appears to be ...
10 F0 <len> 41 00 7C 12 01 03 00 00 00 00 00 00 <data> <cksm> F7
... which would suggest that the Device ID byte has been omitted.
To add to the confusion, the Integra-7 has a 3-byte Model ID:https://www.roland.com/us/support/knowledge_base/210294253/
10 F0 <len> 41 10 00 00 64 12 19 02 00 22 <data> <cksm> F7
F0 - Beginning of SysEx message
41 - Roland Manufacture ID
10 - Device ID
00 00 64 - Model ID (Integra-7)
12 - Command ID (DT1)
19 02 00 22 - Address
XX - Data (for Harmonic Bars this will be 0-8)
ZZ - Checksum (Error correction calculation)
F7 - End of SysEx message
ISTM that there is no consistency across Roland's models, in which case I can't see how I could incorporate all sysex formats within a single tool ... at least not reliably.
August 21st, 2017, 19:48
Thanks, That is really very helpful. Decompilation is going well now, I am able to get a pretty good listing of assembler code. A couple of things need tweaking such as memory map, setting up a RAM config, separating code and data segments and fixing a LOT of strings so they aren't interpreted as code or data(byte, word or long). Also Hitachi H8 support has quite a few variants and options, so just coming to terms with that as well.
just wondering about the size. Both .bin are 4 bytes over aligning with an exact KB size.
786,436 bytes, or 0xC0004bytes. wondering if the it should be 0xC0000 instead and we have 4 errant bytes?
Thanks again for the work to get the firmware image, really nice!
August 21st, 2017, 20:18
HaQue wrote:just wondering about the size. Both .bin are 4 bytes over aligning with an exact KB size.
786,436 bytes, or 0xC0004bytes. wondering if the it should be 0xC0000 instead and we have 4 errant bytes?
You're right. Those extra 4 bytes are an artifact of the "octets". They are just pad bytes and can be stripped. Happy disassembly.
August 24th, 2017, 1:53
received adapter from SD. as soon as I have time I will work out with the Roland owner testing.
August 24th, 2017, 3:53
The following URLs have the same VS-880 firmware update in both MIDI and Zip formats:https://www.roland.com/global/support/by_product/vs-880/updates_drivers/
VS-880 System Update Version 3.205 (PC - ZIP) (1.84MB):https://www.roland.com/global/support/by_product/vs-880/updates_drivers/a515f755-7ba8-4746-91d8-b69c096c836e/
VS-880 System Update Version 3.205 (PC - SMF) (1.28MB):https://www.roland.com/global/support/by_product/vs-880/updates_drivers/df73daf6-73f7-4277-b2eb-0917e00ad8c3/
The VS880A.bin which I extracted from the "A" MIDIs matches the $SYSPRO0.VR8 file in the Zip version. The only difference is that the Zip file has an additional 8-byte header (0x00000000 0x000FA9FC) which defines the memory range. Also, the Zip file has 0xFF pad bytes in the unprogrammed memory addresses whereas my MIDI dump defaults to 0x00. These pad bytes are not transmitted in the MIDI files. I expect that the firmware update process first erases all of memory. I also expect that the device's firmware would be validated at every start-up, presumably with one or more checksums, in which case we would need to know how the checksum/s is/are computed and whether the pad bytes are significant.
Powered by phpBB © phpBB Group.