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 1, 2, 3, 4, 5 ... 12  Next
Author Message
 Post subject: Sniffing control flow between legacy devices over PATA/ATAPI
PostPosted: April 30th, 2015, 16:23 
Offline

Joined: April 30th, 2015, 15:37
Posts: 7
Location: Melbouerne, Australia
So the Roland SP-808 was a music sampler that came on the market in 1998 and is considered a bit of a classic by some of its users. It ran its own proprietary embedded OS in flash and storage for music samples was provided by an Iomega Zip 100 drive and the subsequently released SP-808Ex used the Iomega Zip 250 - both these disks used the ATAPI protocol... and both these disks by today's standards sound like your sitting next to a server case during a heat wave! Hence my search for a solid state replacement. Various Compact Flash and SD to IDE adapters have been tested by myself and other users around the internet but unfortunately while the SP-808 is able to detect them in some cases the subsequent results are usually pretty dismal once any attempt is made to write to disk (there are some sketchy records of various CF to IDE adapters working but those particular devices seem to have gone the way of the dodo).

I'm currently working on a device to sniff the conversation between my SP-808 and it's zip-250 using a microcontroller development board but since my coding skills are so rusty this is going to take a few days so was hoping some one may be able to suggest an off the shelf solution? - even better if somebody was able to just save me all the drama by explaining what would have been in the zip drive ATAPI implementation that the SP-808 silently balks at?

On a related subject, once the quirks are discovered is anyone familiar with any PATA devices that have the ability to be retasked/reprogrammed so I could emulate the zip drive in silence - preferably without having to develop a custom circuit board?


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

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Does the Roland work with a real ATA device (eg PATA HDD) or does it insist on seeing an ATAPI device? If the latter, then how were you able to get any Compact Flash adapters to work, even if only partially?

FWIW, I found the following:

http://en.wikipedia.org/wiki/Zip_drive

Quote:
Zip drives are available in multiple interfaces including:
IDE True ATA (very early ATA internal Zip drives mostly sold to OEMs; these drives exhibit software compatibility issues because they do not support the ATAPI command set)
ATAPI (all Zip generations)


http://en.wikipedia.org/wiki/CompactFlash

Quote:
Use in place of a hard disk drive

CF cards may perform the function of the master or slave drive on the IDE bus, but have issues sharing the bus. Moreover, late-model cards that provide DMA (using UDMA or MWDMA) may present problems when used through a passive adapter that does not support DMA.[


CompactFlash cards and DMA/UDMA support in True IDE (tm) mode:
http://www.fccps.cz/download/adv/frr/cf.html

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: April 30th, 2015, 20:05 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
I sold my Roland years ago. I remember looking for similar, but instead sold it and bought a new Casio KB and Guitar. guess you would have seen this page:
https://jimatwood.wordpress.com/2012/01/18/converting-zip-drives-to-cf-or-sd-card-drives-for-roland-gear/

where they say the Akai MPC 2000XL MCD Drive works (but isn't hot swappable):

http://www.mpcstuff.com/akai-mpc-2000xl-mcd-drive-kit-hot-swappable-used-black/


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 1st, 2015, 6:15 
Offline

Joined: April 30th, 2015, 15:37
Posts: 7
Location: Melbouerne, Australia
fzabkar: the SP-808 recognizes late model PATA HDDs (tested Seagate ST310212A and Quantum Fireball EX) and even pretends to format them however once restarted the formatted drives show up as having zero space. Also any attempt to write to them before the restart (while it still views them as freshly formatted empty disks) ends with the system hanging - presumably this is where the SP-808 would be attempting to do DMA or whatever using quirky Zip mode... This is pretty much the same result I sore when trying with the CompactFlash adapter. Oh also just for giggles tried an old ATAPI cd burner (40x12x48: BENQ 4012P manufactured Feb 2002) and while recognized as a removable media device with no media the SP-808 had serious issues with talking to it since while not actually hung the normal instant response to button pressing took holding each button around 30 seconds to register the press.

HasQue: yes I have seen that wordpress page - unfortunately the author never followed up with publishing any of the results of his experiments, as for the MPC drive mentioned in the comments $275 for a maybe is a bit rich for my taste - I'd prefer to spend the time on it to come up with something that can be used by other SP-808 owners also.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 1st, 2015, 6:48 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
Understood. I am thinking someone with the smarts needs to come up with an emulator circuit that on the roland side the roland thinks it is the device that it is comfortable with and the emu hardware talks to whatever device.. and adds the required. I wish I had time to look into it


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 1st, 2015, 14:05 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
I would dump the Zip drive's IDENTIFY PACKET DEVICE 256-word information block. That should tell us if there is anything obviously different about the Zip drive.

I would also examine its file system with a hex editor. FWIW, I have analysed the file system of an Akai MPC2000, but I don't know if it would be similar. It's a quirky FAT16 implementation.

Akai MPC2000 - analysis of file system:
http://www.hddoracle.com/viewtopic.php?f=59&t=132&p=171

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 1st, 2015, 16:10 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
FWIW, I have used HDAT2 to get a ton of info from an ATAPI optical drive (GSA-4040B). See the attachment.


Attachments:
HDAT2.rar [7.58 KiB]
Downloaded 1840 times

_________________
A backup a day keeps DR away.
Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 1st, 2015, 18:31 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
What about intercepting the data as it is being written to the zip disk.. hacking a zip disk drive itself so that it writes to something else instead.. think those strange dummy "cassette tapes" that you used to put in a car cassette player that had an AUX input to plug in a Walkman into to play any device on a car stereo back in the day?


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 2nd, 2015, 5:50 
Offline
User avatar

Joined: May 5th, 2004, 20:06
Posts: 2782
Location: England
A nice FPGA setup would be able to emulate the translation :)

_________________
All went well until I plugged the drive in.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 2nd, 2015, 6:00 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
guru wrote:
A nice FPGA setup would be able to emulate the translation :)

I could probably find out all we need to know by getting a standard IDE HDD to sniff its own ATA traffic. I have some other ideas, but I'm waiting for the OP to come back with some info.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 2nd, 2015, 9:56 
Offline

Joined: April 30th, 2015, 15:37
Posts: 7
Location: Melbouerne, Australia
Apologies for the delay in getting back, had to resurrect a legacy pc to use for interrogating the zip drive. Now in the process of installing linux [lubuntu-15.04-desktop] and the hdparm program in order to question the zip drive - will update as soon as I figure out which way is up! (diving in the deep end here)


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 2nd, 2015, 14:48 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
norlesh wrote:
Apologies for the delay in getting back, had to resurrect a legacy pc to use for interrogating the zip drive. Now in the process of installing linux [lubuntu-15.04-desktop] and the hdparm program in order to question the zip drive - will update as soon as I figure out which way is up! (diving in the deep end here)

The methods that I'm proposing depend on running MHDD ver 4.5 in a real DOS environment. I would also prefer to see HDAT2's information dumps. You can run both programs from a bootable flash drive. I have no ideas that would run under Linux. Sorry.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 2nd, 2015, 15:35 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Spildit wrote:
fzabkar wrote:
guru wrote:
A nice FPGA setup would be able to emulate the translation :)

I could probably find out all we need to know by getting a standard IDE HDD to sniff its own ATA traffic. I have some other ideas, but I'm waiting for the OP to come back with some info.


S.M.A.R.T. Error Log ?

:D :D :D

ISTM that the logical approach to the problem of why some ATAPI/ATA devices work while others don't is to start by querying their capabilities with an Identify Device or Identify Packet Device command. That's the HDAT2 information that I'm waiting for. My preliminary search of Iomega's old web site hasn't turned up much in this regard except that the Zip drive's maximum burst transfer rate is 3.3 MB/sec. That's consistent with PIO mode 0.

Zip ATAPI drive specifications:
http://web.archive.org/web/199904211707 ... ispec.html

Code:
Burst transfer rate:       up to 26.7 Mbits/sec (3.3 MB/sec)
Sustained transfer rate:   up to 11.2 Mbits/sec (1.4 MB/sec)

http://en.wikipedia.org/wiki/AT_Attachm ... sfer_modes

Code:
Mode             #   Xfer rate     Cycle time
---------------------------------------------
PIO              0   3.3MB/s       600ns
Single-word DMA  0   2.1MB/s       960ns
            DMA  1   4.2MB/s       480ns

My theory is that the SP-808 may be wired for PIO mode only, but that its firmware may be trying to use DMA mode for those devices that report this capability. An examination of the circuit diagrams in the service manual may help.

There is a Roland SP-808 user group that appears to have this manual, if the OP would like to obtain it for us ...

http://webcache.googleusercontent.com/s ... sage/13572
https://groups.yahoo.com/group/SP-808US ... sage/13572

Quote:
The service manual is located in the "Files" area of this forum.
Look in PDF folder, first one I think.. "Sevice Notes".

I would also like to see the Identify Packet Device info block for the Akai MPC2000XL MCD. If this device also reports PIO mode only, then this will lend more weight to my theory.

In the past I have hacked the firmware in a Ricoh 2x CD burner. It reported PIO mode only but I extracted its Identify Packet Device information block and turned on its DMA bits (and recalculated two checksums). The burner then reported that it supported DMA, Windows's DMA checkbox remained enabled, and the burner's transfer rate increased slightly but measurably. In the OP's case we could take an old Seagate drive and use "set stuff" or the ATA DCO commands to disable DMA reporting. If the drive then functions properly within the Roland machine, this will be our proof of concept.

As for sniffing ATA traffic, my idea is to use MHDD to create a pseudo-uncorrectable sector 0 using the ATA READ LONG, SCT READ LONG, or WRITE UNCORRECTABLE commands. I would expect that a typical startup axis would involve sending the following commands to an ATAPI/ATA device:

    IDENTIFY PACKET DEVICE
    if error, then IDENTIFY DEVICE
    SET FEATURES - set PIO/MWDMA/UDMA mode n
    READ SECTOR 0

When the drive errors out on the READ command, it will log the 5 most recent ATA commands in its internal error log. This log can be retrieved with standard ATA commands.

Just for reference ...

Product Manuals for Zip, Jaz, Clik!
http://web.archive.org/web/199904280943 ... nuals.html

Zip ATAPI Installation Guide for VAR's and Integrators:
http://web.archive.org/web/200009180400 ... 325401.pdf

Zip ATAPI User's Guide:
http://web.archive.org/web/200106122147 ... 330001.pdf

Zip ATAPI Internal Owner's Guide:
http://web.archive.org/web/200008170955 ... 358101.pdf

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 2nd, 2015, 17:23 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Spildit wrote:
Just for the fun of it, I've plugged one DVD optical drive to my HRT card.

This is what i get from an ID device :)

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

00000070                                      00 07 04 07
00000080  00 03 00 78 00 78 00 78 00 78

Your optical drive supports PIO modes 0 and 1, MWDMA modes 0 - 2, and UDMA modes 0 - 2. It is currently set at MWDMA mode 2. The transfer cycles times are 120ns.

What do you get from an Identify Device (ECh) command?

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 2nd, 2015, 20:40 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
Spildit wrote:
This one doesn't accept the EC either, just the A1 :

From the ATA standard ...

Quote:
In response to [the IDENTIFY DEVICE] command, ATAPI devices shall return command aborted and place the ATAPI device signature in the appropriate fields (see table 206 - Device Signatures for Normal Output).


After command completion, with or without errors, the registers for an ATAPI device should look like the following:

Code:
Count       01h
LBA 27:24   reserved
LBA 23:16   EBh
LBA 15:8    14h
LBA 7:0     01h

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 3rd, 2015, 3:51 
Offline

Joined: April 30th, 2015, 15:37
Posts: 7
Location: Melbouerne, Australia
Hey there guys - sorry for the slow response - here is the service manual for the SP808 :
https://www.dropbox.com/s/fx1wy1lq7o0nu ... l.pdf?dl=0
I am in the process of figuring out how to get you the hdat2 and mhdd reports. I normally just run my laptop so have had to build a test system to run (luckily there were enough dinosaur bones left up stairs in the loft from a previous tenant - the resultant Frankenstein is now running XP since the Linux kernel panicked while trying to handle a ~2001 motherboard)... just about to go for a walk to find some floppy disks (do they still sell them?) since Frankenstein can't boot from USB!
FYI Frankenstein is running XP and has CD-ROM, FDD, HDD, and a Zip-250 (of course) ... and is excruciatingly slow!!![but heck as long as it can drive the queries] don't hesitate to propose experiments... just keep in mind that I'm a nube with this low level hdd stuff so any guidance is gratefully accepted!

P.S. THANK YOU


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 3rd, 2015, 3:54 
Offline

Joined: April 30th, 2015, 15:37
Posts: 7
Location: Melbouerne, Australia
Attachment:
Hey there guys - sorry for the slow response - here is the service manual for the SP808 :
https://www.dropbox.com/s/fx1wy1lq7o0nu ... l.pdf?dl=0
I am in the process of figuring out how to get you the hdat2 and mhdd reports. I normally just run my laptop so have had to build a test system to run (luckily there were enough dinosaur bones left up stairs in the loft from a previous tenant - the resultant Frankenstein is now running XP since the Linux kernel panicked while trying to handle a ~2001 motherboard)... just about to go for a walk to find some floppy disks (do they still sell them?) since Frankenstein can't boot from USB!
FYI Frankenstein is running XP and has CD-ROM, FDD, HDD, and a Zip-250 (of course) ... and is excruciatingly slow!!![but heck as long as it can drive the queries] don't hesitate to propose experiments... just keep in mind that I'm a nube with this low level hdd stuff so any guidance is gratefully accepted!

P.S. THANK YOU


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 3rd, 2015, 7:01 
Offline
User avatar

Joined: May 5th, 2004, 20:06
Posts: 2782
Location: England
Some ATA drives use the ATA Taskfile registers to return Self Scan State, LBA>PBA translation, extended error codes and etc etc etc.

_________________
All went well until I plugged the drive in.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 5th, 2015, 13:27 
Offline

Joined: April 30th, 2015, 15:37
Posts: 7
Location: Melbouerne, Australia
Once again apologies for delays - have been busy banging my head against the wall repeatedly.

The device identity as reported by hdparm for windows is:

ATAPI Direct-access device, with removable media
Model Number: IOMEGA ZIP 250 ATAPI
Serial Number: 00304881E6961127
Firmware Revision: 25.Q
Standards:
Supported: 4
Likely used: 4
Configuration:
DRQ response: <=10ms with INTRQ
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
DMA: mdma0 mdma1 udma0 udma1 *udma2
Cycle time: min=150ns recommended=150ns
PIO: pio0 pio1 pio2 pio3
Cycle time: no flow control=180ns IORDY flow control=180ns
Commands/features:
Enabled Supported:
* Power Management feature set
* PACKET command feature set
* DEVICE_RESET command
* NOP cmd
* Removable Media Status Notification feature set
Removable Media Status Notification feature set supported

which I am guessing is the human readable format of this:

80a0 0000 0000 0000 0000 0000 0000 0000
0000 0000 3030 3330 3438 3831 4536 3936
3131 3237 2020 2020 0000 0000 0000 3235
2e51 2020 2020 494f 4d45 4741 2020 5a49
5020 3235 3020 2020 2020 2020 4154 4150
4920 2020 2020 2020 2020 2020 2020 0000
0000 0f00 4003 0200 0000 0006 0000 0000
0000 0000 0000 0000 0000 0000 0000 0003
0001 0096 0096 00b4 00b4 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0010 0000 4218 4010 4000 4218 0010 4000
0407 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0001
0000 2863 2920 436f 7079 7269 6768 7420
494f 4d45 4741 2032 3030 3220 0000 3630
312f 2f33 3230 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

(while I was able to run hdat2 and mhdd, I failed to find a workable solution to save any of there output since I have no idea how to get hold of floppy disks any more!)


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 5th, 2015, 16:25 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15440
Location: Australia
fzabkar wrote:
Your optical drive supports PIO modes 0 and 1, MWDMA modes 0 - 2, and UDMA modes 0 - 2. It is currently set at MWDMA mode 2. The transfer cycles times are 120ns.

That should have been "PIO modes 3 and 4".

Word 88 (0x001F) is also indicating support for UDMA modes 0 - 4).

_________________
A backup a day keeps DR away.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 231 posts ]  Go to page 1, 2, 3, 4, 5 ... 12  Next

All times are UTC - 5 hours [ DST ]


Who is online

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