In-depth technology research: finding new ways to recover data, accessing firmware, writing programs, reading bits off the platter, recovering data from dust.
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...
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.
- 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". :-)
August 19th, 2017, 17:53
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.
August 19th, 2017, 18:17
deleted
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.binThe 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.
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.
- A6.zip
- OS update for the Roland Edirol A-6(original)
- (334.41 KiB) Downloaded 1090 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.
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.
December 4th, 2017, 1:06
3 months later and nothing to report unfortunately.
January 23rd, 2018, 9:55
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 (49.91 KiB) Viewed 352558 times
November 11th, 2018, 19:27
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
November 11th, 2018, 19:41
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.
November 11th, 2018, 21:04
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.
November 12th, 2018, 1:24
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!
Powered by phpBB © phpBB Group.