All times are UTC - 5 hours [ DST ]


Forum rules


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...



Post new topic Reply to topic  [ 140 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7
Author Message
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 18th, 2017, 12:08 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2895
Location: Adelaide, Australia
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.
Attachment:
A-6(stripped).zip [1 MiB]
Downloaded 34 times


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 18th, 2017, 15:27 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
I hope the following example better illustrates my interpretation of the data "octets".

Code:
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
     18

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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 18th, 2017, 15:40 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
Code:
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

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 19th, 2017, 6:33 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2895
Location: Adelaide, Australia
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

.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 19th, 2017, 9:48 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2895
Location: Adelaide, Australia
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
Code:
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.
Quote:
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
Quote:
Controls all 313 parameters editable by Sysex,



https://mididesigner.com/qa/3470
Code:
-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.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 19th, 2017, 11:38 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2895
Location: Adelaide, Australia
http://www.chromakinetics.com/handsonic/rolSysEx.htm

"Roland System Exclusive Implementation" <--great page.


http://www.chromakinetics.com/handsonic ... i.htm#tran
Quote:
Roland's Manufacturer ID is always the first data byte after the F0, and is always 41.


http://www.chromakinetics.com/handsonic/rolArch.htm
gold!
Quote:
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.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 19th, 2017, 16:19 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
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.

Code:
' 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". :-)

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 19th, 2017, 17:53 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
HaQue wrote:
event 2 sets up the Tempo and the delta time is based off this value.

Code:
00 FF 51 03 07 A1 20


where:
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 19th, 2017, 18:17 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
deleted

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 19th, 2017, 18:44 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 19th, 2017, 23:48 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2895
Location: Adelaide, Australia
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.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 20th, 2017, 20:12 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
@HaQue, I have written a tool to extract the firmware binary from the MIDI files.

http://www.users.on.net/~fzabkar/temp/Rmid2bin.bas
http://www.users.on.net/~fzabkar/temp/Rmid2bin.exe
http://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:

Code:
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 20th, 2017, 22:11 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2895
Location: Adelaide, Australia
@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.
Attachment:
File comment: OS update for the Roland Edirol A-6(original)
A6.zip [334.41 KiB]
Downloaded 30 times

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.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 21st, 2017, 16:52 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
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/

Quote:
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 21st, 2017, 19:13 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
Here is the complete Edirol A-6 update:

http://www.users.on.net/~fzabkar/temp/RmA62bin.exe
http://www.users.on.net/~fzabkar/temp/RmA62bin.bas
http://www.users.on.net/~fzabkar/temp/A6_all.bin

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 21st, 2017, 19:48 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2895
Location: Adelaide, Australia
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!


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 21st, 2017, 20:18 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 24th, 2017, 1:53 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2895
Location: Adelaide, Australia
received adapter from SD. as soon as I have time I will work out with the Roland owner testing.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 24th, 2017, 2:09 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
I have extracted the firmware for the VS-880 (another Roland device from the same period). Perhaps a comparison of the two BINs ("A" and "B") may provide some insights.

http://www.users.on.net/~fzabkar/temp/Rvs82bin.exe
http://www.users.on.net/~fzabkar/temp/Rvs82bin.bas
http://www.users.on.net/~fzabkar/temp/VS880A.bin
http://www.users.on.net/~fzabkar/temp/VS880B.bin

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 24th, 2017, 3:53 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9607
Location: Australia
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.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 140 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group