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  [ 231 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 12  Next
Author Message
 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: 15440
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: 15440
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: 15440
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: 15440
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: 3844
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: 15440
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: 3844
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 976 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: 15440
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: 15440
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: 3844
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: 15440
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: 3844
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: 15440
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: 15440
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  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: December 4th, 2017, 1:06 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
3 months later and nothing to report unfortunately.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: January 23rd, 2018, 9:55 
Offline

Joined: July 30th, 2017, 20:02
Posts: 2
Location: Florida
Wow I wanna say I am impressed with the effort to save this wonderful beast of a machine. My hat is off to all who are trying.

I have searched high and low to find a replacement for my beloved sp808 preferably portable.

Incomes the iPad but no success in finding apps that do what half the sp808 can do. So I set about building a sampler /looper using a Raspberry Pi but the hardware connecting with Python programming language has proven to be quite difficult for me any ways. So back to the iPad, I looked at Swift programming language, watched some tutorials.

So now I have decided to build an sp808 IOS app minus the 4 channel digital recorder and d-beam . So it will have the sampling and looping capabilities of the sp808 and to keep it simple for now no effects but I am sure we can add that later. Another idea was to incorporate the IOS app called Samplr into it where you can manipulate the wav file in realtime with the iPads touchscreen...how cool would that be.

I wrote the Samplr developer in hopes that he will either release the code as open source or work with me on this project ...stay tuned.


Attachments:
Future808.jpg
Future808.jpg [ 49.91 KiB | Viewed 287146 times ]
Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: November 11th, 2018, 19:27 
Offline

Joined: November 11th, 2018, 19:24
Posts: 2
Location: Denver
Hello,
I'm posting to see if anyone got the SP-808 drive up amd running. I've been trying to find a working ATAPI flash drive for ages. Any help would be greatly appreciated!
Thank you


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Joetech13 wrote:
I've been trying to find a working ATAPI flash drive for ages.

Unless HaQue can enlighten us to the contrary, you might like to try the SalvationData adapter with my suggested ATA-to-ATAPI modification.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: November 11th, 2018, 21:04 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
Ive got the adapter, but been too busy in all aspects of work/home to go further. I bought a mainboard of the unit to try and do additional testing but the shonky eBay seller gave me the wrong board (control board not a mainboard), and will not answer email or phone. I still plan to buy an 808 but just tied up.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: November 12th, 2018, 1:24 
Offline

Joined: November 11th, 2018, 19:24
Posts: 2
Location: Denver
fzabkar wrote:
Joetech13 wrote:
I've been trying to find a working ATAPI flash drive for ages.

Unless HaQue can enlighten us to the contrary, you might like to try the SalvationData adapter with my suggested ATA-to-ATAPI modification.

I'll give it a shot. Thank you!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 231 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 12  Next

All times are UTC - 5 hours [ DST ]


Who is online

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