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 ... 3, 4, 5, 6, 7, 8, 9 ... 12  Next
Author Message
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 11th, 2017, 0:36 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
this page has example loading configs, helpful but design concept is a bit "how ya goin' " !

http://www.reocities.com/politalk/zip/index.html


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 11th, 2017, 2:15 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
Tried another ATAPIZIP250 drive and win7 can format a disk and mount as a portable device.

CD2ISO gives: ISO9960 not detected, writes an ISO but cannot be mounted

Winimage for win7 says it's installed but is not to be found in file directory or programs list

PFM will not open or mount the ZIP disk.

If @Haque is procuring a SalvationData card, he is welcome to try my SP-808EX and additional ATAPI250ZIP drive/disk to test...I'm getting nowhere unfortunately.


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

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
As soon as I have it I will let you know :)


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Can you show us sector 0 of the ISO?

HxD - Freeware Hex Editor and Disk Editor:
https://mh-nexus.de/en/hxd/

    launch HxD
    File -> Open -> select ISO file
    Edit -> Select Block
      Start offset - 0
      Length 200
      hex
      OK
    Edit -> Copy as -> Editor view

    Select "Code" BBcode button in HDD Guru forum
    Paste (Ctrl-V) the clipboard into the "code" box

[code][/code] <- paste your hex dump in here

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 11th, 2017, 3:30 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  EB 3C 90 4D 53 44 4F 53 35 2E 30 00 02 08 02 00  ë<.MSDOS5.0.....
00000010  02 00 02 00 00 F8 EF 00 3F 00 FF 00 20 00 00 00  .....øï.?.ÿ. ...
00000020  1C 78 07 00 80 00 29 98 1F A8 08 4E 4F 20 4E 41  .x..€.)˜.¨.NO NA
00000030  4D 45 20 20 20 20 46 41 54 31 36 20 20 20 33 C9  ME    FAT16   3É
00000040  8E D1 BC F0 7B 8E D9 B8 00 20 8E C0 FC BD 00 7C  ŽÑ¼ð{ŽÙ¸. ŽÀü½.|
00000050  38 4E 24 7D 24 8B C1 99 E8 3C 01 72 1C 83 EB 3A  8N$}$‹Á™è<.r.ƒë:
00000060  66 A1 1C 7C 26 66 3B 07 26 8A 57 FC 75 06 80 CA  f¡.|&f;.&ŠWüu.€Ê
00000070  02 88 56 02 80 C3 10 73 EB 33 C9 8A 46 10 98 F7  .ˆV.€Ã.së3ÉŠF.˜÷
00000080  66 16 03 46 1C 13 56 1E 03 46 0E 13 D1 8B 76 11  f..F..V..F..Ñ‹v.
00000090  60 89 46 FC 89 56 FE B8 20 00 F7 E6 8B 5E 0B 03  `‰Fü‰Vþ¸ .÷æ‹^..
000000A0  C3 48 F7 F3 01 46 FC 11 4E FE 61 BF 00 00 E8 E6  ÃH÷ó.Fü.Nþa¿..èæ
000000B0  00 72 39 26 38 2D 74 17 60 B1 0B BE A1 7D F3 A6  .r9&8-t.`±.¾¡}ó¦
000000C0  61 74 32 4E 74 09 83 C7 20 3B FB 72 E6 EB DC A0  at2Nt.ƒÇ ;ûræëÜ 
000000D0  FB 7D B4 7D 8B F0 AC 98 40 74 0C 48 74 13 B4 0E  û}´}‹ð¬˜@t.Ht.´.
000000E0  BB 07 00 CD 10 EB EF A0 FD 7D EB E6 A0 FC 7D EB  »..Í.ëï ý}ëæ ü}ë
000000F0  E1 CD 16 CD 19 26 8B 55 1A 52 B0 01 BB 00 00 E8  áÍ.Í.&‹U.R°.»..è
00000100  3B 00 72 E8 5B 8A 56 24 BE 0B 7C 8B FC C7 46 F0  ;.rè[ŠV$¾.|‹üÇFð
00000110  3D 7D C7 46 F4 29 7D 8C D9 89 4E F2 89 4E F6 C6  =}ÇFô)}ŒÙ‰Nò‰NöÆ
00000120  06 96 7D CB EA 03 00 00 20 0F B6 C8 66 8B 46 F8  .–}Ëê... .¶Èf‹Fø
00000130  66 03 46 1C 66 8B D0 66 C1 EA 10 EB 5E 0F B6 C8  f.F.f‹ÐfÁê.ë^.¶È
00000140  4A 4A 8A 46 0D 32 E4 F7 E2 03 46 FC 13 56 FE EB  JJŠF.2ä÷â.Fü.Vþë
00000150  4A 52 50 06 53 6A 01 6A 10 91 8B 46 18 96 92 33  JRP.Sj.j.‘‹F.–’3
00000160  D2 F7 F6 91 F7 F6 42 87 CA F7 76 1A 8A F2 8A E8  Ò÷ö‘÷öB‡Ê÷v.ŠòŠè
00000170  C0 CC 02 0A CC B8 01 02 80 7E 02 0E 75 04 B4 42  ÀÌ..̸..€~..u.´B
00000180  8B F4 8A 56 24 CD 13 61 61 72 0B 40 75 01 42 03  ‹ôŠV$Í.aar.@u.B.
00000190  5E 0B 49 75 06 F8 C3 41 BB 00 00 60 66 6A 00 EB  ^.Iu.øÃA»..`fj.ë
000001A0  B0 42 4F 4F 54 4D 47 52 20 20 20 20 0D 0A 52 65  °BOOTMGR    ..Re
000001B0  6D 6F 76 65 20 64 69 73 6B 73 20 6F 72 20 6F 74  move disks or ot
000001C0  68 65 72 20 6D 65 64 69 61 2E FF 0D 0A 44 69 73  her media.ÿ..Dis
000001D0  6B 20 65 72 72 6F 72 FF 0D 0A 50 72 65 73 73 20  k errorÿ..Press
000001E0  61 6E 79 20 6B 65 79 20 74 6F 20 72 65 73 74 61  any key to resta
000001F0  72 74 0D 0A 00 00 00 00 00 00 00 AC CB D8 55 AA  rt.........¬ËØUª


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
That is a typical MSDOS FAT16 boot sector.

Code:
OEM identifier         "MSDOS5.0"
Bytes per Sector        512
Sectors per Cluster     8
Reserved Sectors        2
Number of FATs          2
Root Dir Entries        512
Total Sectors           0
Media Descriptor        F8h
Sectors per FAT         239
Sectors per Track       63
Number of Heads         255
Hidden Sectors          32
Total Sectors           489500
Drive Number            80h
Reserved                00h
Ext. Boot Sign. (0x29)  29h
Serial Number           08A81F98h
Volume Name            "NO NAME    "
File System Type       "FAT16   "
Boot Signature (0xAA55) AA55h

The fact that there are 32 Hidden Sectors suggests that Win7 has partitioned the drive as a single FAT16 volume beginning at physical sector #32. This means that CD2ISO has imaged the logical volume rather than the complete physical drive, ie it missed the first 32 sectors.

Is DMDE now able to read sector 0?

In any case this does not help us to see the Roland file system, whatever it is. ISTM that you will need to use SNARF and then HDAT2 to do this. You could run both tools from a bootable Win98 flash drive.

You can use MSINFO32.EXE to collect information about your system's hardware and software components. Go to Start -> Run and type MSINFO32. You can save all the info to a text file by selecting File -> Export. I would examine the text just in case you wish to restrict the information that you upload.

I recall a comment in another thread which suggested that the SP-808 may only support relatively low capacities. A figure of 512MB was anticipated. It was also suggested that any storage device which exceeded this limit may not be properly detected. An examination of the Roland file system may provide a clue to this limit.

Failing that, I propose to determine this limit by trial-and-error. To this end we could connect an external USB HDD enclosure to the SalvationData card. Prior to installing the HDD in its enclosure, we could reduce its capacity with a HPA.

_________________
A backup a day keeps DR away.


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

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
fzabkar wrote:
That is a typical MSDOS FAT16 boot sector

Quote:
In any case this does not help us to see the Roland file system, whatever it is

Quote:
I recall a comment in another thread which suggested that the SP-808 may only support relatively low capacities. A figure of 512MB was anticipated. It was also suggested that any storage device which exceeded this limit may not be properly detected. An examination of the Roland file system may provide a clue to this limit


Ok, what we wanted was to examine a zip disk that was formatted by the SP-808EX itself...didn't realize that.

Quote:
Failing that, I propose to determine this limit by trial-and-error. To this end we could connect an external USB HDD enclosure to the SalvationData card. Prior to installing the HDD in its enclosure, we could reduce its capacity with a HPA.


Yep ok, let's wait for the SalvationData and Mr HaQue's impeccable DOS skills to work it all out :)


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

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
The following is my initial look into the A6 OS. It isn't entirely relevant per se to the original goal, but it may preserve the grooundwork for future SP-808/A-6 hackers, and helps to get things clear in my head.


The MIDI files that hold the A6 OS update are interesting in their simplicity. I love the way Roland used an existing functionality to update the hardware.. MIDI interface = free serial interface!

the MIDI standard is simple and Roland haven't deviated from SMF (Standard MIDI File).

The Hitachi Processor is apparently upward compatible with H8/300H instruction set. What I've found id there are many ways to configure the CPU. CPU has 8 sections, I assume one MIDI file per section.

I parsed the MIDI file of the first MIDI file.

- The header chunk is standard MIDI and checks out. Nothing interesting there.

- There is a single track.

- The Track chunk also checks out, and has the same format through each file, except for the last one which is slightly different at the end.

- The Track itself consists of a list of Track events. These are separated by a time Delta value (Variable length value) and one of 3 main types of Events: MIDI Event, Meta Event and System Exclusive Event. Think of it as a list like this:

in [x] ticks,
we are going to do [x].
in [x] ticks
we are going to do [y].
in [x] ticks
we are going to say "xyz".

etc...


-The A6 OS has 3 Meta events to start with. each consist of the time delta of 0x0, 0xFF that denotes it is a Meta event, The type of meta event, the size (in variable length encoding), and the data.

event 1 (Track name):

Code:
00 FF 03 20 53 50 2D 38 30 38 20 56 65 72 20 31 2E 30 31 30 20 6D 6D 6D 20 64 64 20 79 79 79 79 20 31 2F 38


where:
0x00 = 0x0 time delta value
0xFF = Denotes this is a Meta Event
0x03 = Denotes this meta event is the Sequence/Track name
0x20 = The length of Data is 32 bytes
the rest = "SP-808 Ver 1.010 mmm dd yyyy 1/8"

event 2 is (copyright notice)

Code:
00 FF 02 20 28 43 29 31 39 39 35 2D 31 39 39 38 20 52 6F 6C 61 6E 64 20 43 6F 72 70 6F 72 61 74 69 6F 6E 2E


where:
0x00 = 0x0 time delta value
0xFF = Denotes this is a Meta Event
0x02 = Denotes this meta event is the Copyright notice.
0x20 = The length of Data is 32 bytes
the rest = "(C)1995-1998 Roland Corporation."

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


After these 3 events, there are 348 System Exclusive events (SysEx).

SysEx events can be used in a couple of different ways, but here they are used like this:

[delta time value] [SysEx byte 0xF0] [length of Data in variable length encoding] [Data]

a quick note on Variable length Encoding. It allows one to specify a size in as many bytes as you need, but no more, and no more than 4 (to everything below a 32bit ceiling)
basically, you can use the low 7 bits of the byte for your value. If you dont have enough, you set the highest bit to 1, and continue with the next byte. if the highest bit is 0, you know it is the last byte of the length. Because you are expecting a length byte/bytes, AND you know if high bit is 0... you know when length value stops. Brilliant!

Each is made up of :

Code:
10 F0 <size> <DATA bytes> F7


0x10 = time delta (time from previous event. Guessing this could be a baud rate of sorts for file transfer
0xF0 = SysEv
0xF7 = stop byte or you could say end of DATA.

here is a list of the sizes of DATA bytes in each event in each MIDI file

A6-1.MID :

1 event 0x11
1 event 0x33
1 event 0x1E
344 events 0x816E
1 event 0x11

A6-2 to A6-7 have the same:

1 event 0x11
1 event 0x33
344 events 0x816E
1 event 0x11

A6-1.MID :

1 event 0x11
1 event 0x33
1 event 0x812E
336 events 0x816E
1 event 0x8126
1 event 0x0F
1 event 0x11


I have run oout of time today to add the rest of the research, but quickly.. I am thinking the first events setup processor firmware upgrade, the large chunks are the firmware, and the end is either checksup or some end routine.
I stripped the MIDI control bytes out of the first MIDI file and I am thinking the result of all data bytes as a blob is more than likely each part of the H8 CPU firmware (OS).

I tried disassembling based around H8s/300H instructions but I think there is a bit more work to do for disassembling such as finding the vector table, properly setting up the address space in the disassembler etc..
I havent looked at the blob a whole lot yet, but it does show some clear patterns. Here is the first few SysEx events (truncated a bit, with the MIDI stuff stripped away):

Code:
41 00 7C 12 01 02 00 00 00 00 00 00 00 07 00 76 F7
41 00 7C 12 01 03 00 00 00 00 00 00 53 50 2D 38 30 38 20 56 65 72 20 31 2E 30 31 30 20 6D 6D 6D 20 64 64 20 79 79 79 79 20 68 68 3A 6D 6D 3A 73 73 38 F7
41 00 7C 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 71 F7
41 00 7C 12 00 00 01 00 00 00 00 00 5A 13 14 78 54 53 32 00 35 45 53 59 53 00 5D 00 03 72 61 04 0F 00 00 20 0C 00 00 52 6F 6C 61 00 6E 64 45 43 01 10 6D 00 72..
41 00 7C 12 00 00 01 00 00 00 0C 04 5C 00 01 30 0D 06 79 08 20 7F 7F 46 3C 19 66 30 7D 01 40 16 17 76 0F 42 40 0A 60 68 08 28 16 53 46 06 0C 58 16 58 47 02 0A..
41 00 7C 12 00 00 01 00 00 01 08 08 00 08 0D 60 6E 18 00 0A 09 79 00 00 01 1A 0E 00 4B 04 10 10 40 78 6A 02 09 70 5E 14 09 6A 09 35 70 5E 01 20 6D 76 54 60 70..
41 00 7C 12 00 00 01 00 00 02 04 0C 6E 68 00 08 70 28 6E 00 68 00 08 18 08 6E 68 45 00 09 79 00 00 01 1A 00 0D 4B 04 10 10 40 78 01 6A 09 70 5E 14 09 6A 1A 09..
41 00 7C 12 00 00 01 00 00 03 01 00 33 64 14 0D 0C 58 55 2A 2A 0D 06 1D 60 46 16 04 6A 2D 00 40 33 64 0C 02 58 55 1A 0D 06 1D 60 41 46 06 79 00 7F 7F 40 06 08..
41 00 7C 12 00 00 01 00 00 03 0D 04 68 08 28 16 46 5A 19 18 55 40 10 0D 50 17 70 01 0F 61 0A 01 68 19 29 29 7F 47 08 0B 55 79 25 40 00 04 4D 6A 79 25 00 08 04..
41 00 7C 12 00 00 01 00 00 04 09 08 0D 50 17 70 0F 61 0A 2A 01 78 7F 68 18 40 76 74 0D 50 17 70 7A 01 00 08 00 00 04 0A 61 0A 01 05 68 19 29 7F 46 26 17 18 75..
41 00 7C 12 00 00 01 00 00 05 05 0C 40 0E 0D 50 17 70 7A 02 16 00 00 00 08 0A 06 01 18 08 68 68 01 20 6D 28 76 01 10 6D 73 54 70 00 6A 28 00 40 10 01 47 00 04..
41 00 7C 12 00 00 01 00 00 06 02 00 0B 56 79 26 00 10 4D 00 40 5C 00 0C 3E 0D 00 40 58 70 00 3C 5E 12 62 08 10 04 40 7A 06 00 40 50 02 0C 7A 01 00 12 64 00 1C..
41 00 7C 12 00 00 01 00 00 06 0E 04 40 08 19 00 6B 20 00 02 40 10 1E 01 20 6D 76 00 01 10 6D 73 54 70 01 00 10 6D 74 0D 05 7A 04 10 00 40 10 00 6E 48 00 00 01..
41 00 7C 12 00 00 01 00 00 07 0A 08 00 40 10 1E 78 01 5C 04 00 0B 0A 0D 00 47 42 10 79 00 20 00 6B 20 00 12 60 00 0C 78 03 5C 00 08 0B 76 0D 00 47 2E 79 00 00..
41 00 7C 12 00 00 01 00 00 08 06 0C 79 40 00 20 5C 00 09 08 4C 6B 20 00 60 00 0C 50 78 11 68 68 79 00 00 68 11 5C 00 09 3A 6B 20 45 00 60 00 0E 5C 00 0B 00 20..
41 00 7C 12 00 00 01 00 00 09 03 00 7F 00 69 70 0D 40 79 4A 60 7F 00 6F 70 00 02 24 5A 10 0A 2C 01 00 6F 00 62 00 0E 78 01 6E 68 49 00 03 19 00 6B 20 00 02 40..
41 00 7C 12 00 00 01 00 00 09 0F 04 00 02 69 30 18 08 68 0A 68 40 28 6A 30 00 60 40 00 1C 73 30 47 44 5C 02 00 07 76 01 00 6F 60 00 00 0E 7A 10 00 00 01 00 00..


when I get time later I am going to have a closer look at the CPU manual and instruction set. Kind of starting make a little headway :)


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
That's nice work! Many thanks!

ISTM that the format of each data record could be a proprietary scheme such as Motorola S-record or Intel HEX.

https://en.wikipedia.org/wiki/SREC_(file_format)
https://en.wikipedia.org/wiki/Intel_HEX

Code:
41 00 7C 12 01 02 00 00 00 00 00 00
41 00 7C 12 01 03 00 00 00 00 00 00
41 00 7C 12 01 00 00 00 00 00 00 00
41 00 7C 12 00 00 01 00 00 00 00 00
41 00 7C 12 00 00 01 00 00 00 0C 04
41 00 7C 12 00 00 01 00 00 01 08 08
41 00 7C 12 00 00 01 00 00 02 04 0C
41 00 7C 12 00 00 01 00 00 03 01 00
41 00 7C 12 00 00 01 00 00 03 0D 04
41 00 7C 12 00 00 01 00 00 04 09 08
41 00 7C 12 00 00 01 00 00 05 05 0C
41 00 7C 12 00 00 01 00 00 06 02 00
41 00 7C 12 00 00 01 00 00 06 0E 04
41 00 7C 12 00 00 01 00 00 07 0A 08
41 00 7C 12 00 00 01 00 00 08 06 0C
41 00 7C 12 00 00 01 00 00 09 03 00
41 00 7C 12 00 00 01 00 00 09 0F 04

Code:
4100 7C12 0102 0000 0000 0000
4100 7C12 0103 0000 0000 0000
4100 7C12 0100 0000 0000 0000
4100 7C12 0000 0100 0000 0000
4100 7C12 0000 0100 0000 0C04
4100 7C12 0000 0100 0001 0808
4100 7C12 0000 0100 0002 040C
4100 7C12 0000 0100 0003 0100
4100 7C12 0000 0100 0003 0D04
4100 7C12 0000 0100 0004 0908
4100 7C12 0000 0100 0005 050C
4100 7C12 0000 0100 0006 0200
4100 7C12 0000 0100 0006 0E04
4100 7C12 0000 0100 0007 0A08
4100 7C12 0000 0100 0008 060C
4100 7C12 0000 0100 0009 0300
4100 7C12 0000 0100 0009 0F04

ISTM that "0x0000 0x0100" denotes a data record. The 5th and 6th words look like a memory address. The 6th word appears to have a maximum value of 0x0FFF (ie 4KB) and is incremented by 0xC04. If the result exceeds 0xFFF, then the 5th word is incremented. This behaves something like a segment:offset combination. It looks very strange, though.

_________________
A backup a day keeps DR away.


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Code:
41 00 7C 12 00 00 01 00 00 00 0C 04
41 00 7C 12 00 00 01 00 00 01 08 08
41 00 7C 12 00 00 01 00 00 02 04 0C
41 00 7C 12 00 00 01 00 00 03 01 00
41 00 7C 12 00 00 01 00 00 03 0D 04
                            ^  ^  ^

The last 3 bytes are better (correctly?) interpreted as ...

    0 C 4 -> 0x0C4 = 1 x 196
    1 8 8 -> 0x188 = 392 = 2 x 196
    2 4 C -> 0x24C = 588 = 3 x 196
    3 1 0 -> 0x310 = 784 = 4 x 196
    3 D 4 -> 0x3D4 = 980 = 5 x 196

It seems that they have no relationship to memory addresses.

_________________
A backup a day keeps DR away.


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
On further examination it appears that there are 5 digits. They appear to represent a block count.

Code:
41 00 7C 12 00 00 01 00 00 03 0D 04
                      ^  ^  ^  ^  ^

    0 0 3 D 4 -> 0x3D4 = 980 = 5 x 196

Each block appears to have a checksum byte before the end-of-block byte (0xF7).

The SP808EXv1001.zip file at the following URL contains a firmware update for the SP-808EX.

https://www.roland.com/us/support/by_product/sp-808ex/updates_drivers/66726efc-8259-4788-ad7d-4e90a491e8e8/

The blocks appear to have a checksum which can be either 0x75 or 0xF5.

Edit: Data bytes are limited to 7 bits, so the checksum is 0x75 in each case.

_________________
A backup a day keeps DR away.


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Each block consists of a header, 0xE0 bytes of 7-bit data, a checksum byte, and an end-of-block byte.

    total data bits per block = 0xE0 x 7
    total data bytes (8-bit) = 0xE0 x 7 / 8 = 0xC4 = 200

So 0xC4 appears to be the number of 8-bit bytes per block.

_________________
A backup a day keeps DR away.


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Here is one block from SP8EX#8.mid.

Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000560                             10 F0 81 6F 41 10 00           .ð.oA..
00000570  2B 12 00 00 01 06 0D 06 0F 0C 49 73 6F 6C 61 74  +.........Isolat
00000580  6F 00 72 20 20 20 20 00 07 00 00 00 00 16 5B 7E  o.r    .......[~
00000590  46 04 69 6C 00 46 69 6C 74 00 65 72 20 20 20 20  F.il.Filt.er   
000005A0  20 00 20 00 05 00 00 00 16 00 5C 50 4C 42 73 00   . .......\PLBs.
000005B0  4C 40 6F 77 20 42 6F 6F 73 00 74 65 72 20 00 01  L@ow Boos.ter ..
000005C0  00 00 00 00 16 5C 66 54 70 0C 45 00 54 61 70 65  .....\fTp.E.Tape
000005D0  20 00 45 63 68 6F 20 20 20 00 00 0D 00 00 00 16   .Echo   .......
000005E0  5D 01 04 44 6C 79 00 45 5A 00 20 44 65 6C 61 79  ]..Dly.EZ. Delay
000005F0  20 00 20 20 20 00 0C 00 00 00 00 16 5E 0A 4E 53   .   .......^.NS
00000600  20 18 00 4E 6F 69 73 65 53 00 75 70 70 72 65 73   ..NoiseS.uppres
00000610  00 00 02 00 00 00 16 5F 72 03 43 6D 70 00 43 6F  ......._r.Cmp.Co
00000620  6D 00 70 2F 4C 69 6D 69 74 00 65 72 00 05 00 00  m.p/Limit.er....
00000630  00 00 16 60 2E 45 6E 68 00 20 45 6E 68 61 6E 63  ...`.Enh. Enhanc
00000640  65 00 72 20 20 20 20 00 04 00 00 00 00 16 60 44  e.r    .......`D
00000650  45 06 51 20 00 33 2D 42 61 00 20 F7              E.Q .3-Ba. ÷

Here is the data payload:

Code:
Offset(h) 00 01 02 03 04 05 06 07

00000000  49 73 6F 6C 61 74 6F 00  Isolato.
00000008  72 20 20 20 20 00 07 00  r    ...
00000010  00 00 00 16 5B 7E 46 04  ....[~F.
00000018  69 6C 00 46 69 6C 74 00  il.Filt.
00000020  65 72 20 20 20 20 20 00  er     .
00000028  20 00 05 00 00 00 16 00   .......
00000030  5C 50 4C 42 73 00 4C 40  \PLBs.L@
00000038  6F 77 20 42 6F 6F 73 00  ow Boos.
00000040  74 65 72 20 00 01 00 00  ter ....
00000048  00 00 16 5C 66 54 70 0C  ...\fTp.
00000050  45 00 54 61 70 65 20 00  E.Tape .
00000058  45 63 68 6F 20 20 20 00  Echo   .
00000060  00 0D 00 00 00 16 5D 01  ......].
00000068  04 44 6C 79 00 45 5A 00  .Dly.EZ.
00000070  20 44 65 6C 61 79 20 00   Delay .
00000078  20 20 20 00 0C 00 00 00     .....
00000080  00 16 5E 0A 4E 53 20 18  ..^.NS .
00000088  00 4E 6F 69 73 65 53 00  .NoiseS.
00000090  75 70 70 72 65 73 00 00  uppres..
00000098  02 00 00 00 16 5F 72 03  ....._r.
000000A0  43 6D 70 00 43 6F 6D 00  Cmp.Com.
000000A8  70 2F 4C 69 6D 69 74 00  p/Limit.
000000B0  65 72 00 05 00 00 00 00  er......
000000B8  16 60 2E 45 6E 68 00 20  .`.Enh.
000000C0  45 6E 68 61 6E 63 65 00  Enhance.
000000C8  72 20 20 20 20 00 04 00  r    ...
000000D0  00 00 00 16 60 44 45 06  ....`DE.
000000D8  51 20 00 33 2D 42 61 00  Q .3-Ba.

It appears that the data are grouped as eight 7-bit bytes. I suspect that the 8th byte is a bit mask with each bit reflecting the state of the MS bit in each of the preceding data bytes.

For example, I suspect that the following 7-bit bytes ...

    00 0D 00 00 00 16 5D 01

... decode to these 8-bit bytes:

    00 0D 00 00 00 16 DD 01

... and these bytes ...

    00 00 00 16 60 44 45 06

... would become:

    00 00 00 16 E0 C4 45 06

Or maybe the bit order is reversed?

_________________
A backup a day keeps DR away.


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
fzabkar wrote:
For example, I suspect that the following 7-bit bytes ...

    00 0D 00 00 00 16 5D 01

... decode to these 8-bit bytes:

    00 0D 00 00 00 16 DD 01

... and these bytes ...

    00 00 00 16 60 44 45 06

... would become:

    00 00 00 16 E0 C4 45 06


Correction:

    00 0D 00 00 00 16 5D 01

... decode to these 8-bit bytes:

    00 0D 00 00 00 16 DD

... and these bytes ...

    00 00 00 16 60 44 45 06

... would become:

    00 00 00 16 E0 C4 45

_________________
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, 12:08 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
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 994 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: 15440
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: 15440
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: 3844
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: 3844
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: 3844
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  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 231 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 12  Next

All times are UTC - 5 hours [ DST ]


Who is online

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