View topic - Sniffing control flow between legacy devices over PATA/ATAPI

Main » Forums home » Research and development

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

Sniffing control flow between legacy devices over PATA/ATAPI

Page 7 of 8

[ 146 posts ]

Go to page Previous 1 ... 4, 5, 6, 7, 8 Next

Previous topic | Next topic

Author

Message

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 18th, 2017, 12:08

Joined: December 4th, 2012, 1:35
Posts: 3432
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 344 times

Top

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 18th, 2017, 15:27

Joined: September 8th, 2009, 18:21
Posts: 12008
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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 18th, 2017, 15:40

Joined: September 8th, 2009, 18:21
Posts: 12008
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

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 19th, 2017, 6:33

Joined: December 4th, 2012, 1:35
Posts: 3432
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

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 19th, 2017, 9:48

Joined: December 4th, 2012, 1:35
Posts: 3432
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

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 19th, 2017, 11:38

Joined: December 4th, 2012, 1:35
Posts: 3432
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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 19th, 2017, 16:19

Joined: September 8th, 2009, 18:21
Posts: 12008
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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 19th, 2017, 17:53

Joined: September 8th, 2009, 18:21
Posts: 12008
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

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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 19th, 2017, 18:17

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

deleted

_________________
A backup a day keeps DR away.

Top

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 19th, 2017, 18:44

Joined: September 8th, 2009, 18:21
Posts: 12008
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

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 19th, 2017, 23:48

Joined: December 4th, 2012, 1:35
Posts: 3432
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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 20th, 2017, 20:12

Joined: September 8th, 2009, 18:21
Posts: 12008
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

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 20th, 2017, 22:11

Joined: December 4th, 2012, 1:35
Posts: 3432
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 337 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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 21st, 2017, 16:52

Joined: September 8th, 2009, 18:21
Posts: 12008
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

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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 21st, 2017, 19:13

Joined: September 8th, 2009, 18:21
Posts: 12008
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

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 21st, 2017, 19:48

Joined: December 4th, 2012, 1:35
Posts: 3432
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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 21st, 2017, 20:18

Joined: September 8th, 2009, 18:21
Posts: 12008
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

HaQue

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 24th, 2017, 1:53

Joined: December 4th, 2012, 1:35
Posts: 3432
Location: Adelaide, Australia

received adapter from SD. as soon as I have time I will work out with the Roland owner testing.

Top

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 24th, 2017, 2:09

Joined: September 8th, 2009, 18:21
Posts: 12008
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

fzabkar

Post subject: Re: Sniffing control flow between legacy devices over PATA/A

Posted: August 24th, 2017, 3:53

Joined: September 8th, 2009, 18:21
Posts: 12008
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

Page 7 of 8

[ 146 posts ]

Go to page Previous 1 ... 4, 5, 6, 7, 8 Next

Main » Forums home » Research and development

All times are UTC - 5 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 4 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