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  [ 146 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 8  Next
Author Message
 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: 2816
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 3rd, 2015, 10:14 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 10828
Location: Portugal
guru wrote:
Some ATA drives use the ATA Taskfile registers to return Self Scan State, LBA>PBA translation, extended error codes and etc etc etc.


Thanks for the info.

A good example of that is when you issue the command on QUANTUM DRIVES to get the Defect List lenght :

$00 $00 $FF $FF $3F $A0 $F0

And it will return on the ATA Taskfile registers the values to use to read the defect list :)

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


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: 12422
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  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 6th, 2015, 6:24 
Offline

Joined: April 30th, 2015, 15:37
Posts: 7
Location: Melbouerne, Australia
Quote:
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.


Does this still seem a viable option? I have two Seagate ST310212A drives to experiment with - would one of them do the trick?


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 17th, 2015, 21:57 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
The best chance of getting a SSD drive to work with the SP808EX and any other retrofits is this line of HDD: http://www.ebay.com.au/itm/171110782702

I figure 64GB is the lowest capacity I would go for, since if it doesn't work then it's large enough to host an operating system in a computer.

The smallest available is 16GB from: http://goo.gl/70MHAQ at around AUD$50 and would be the one to use once the larger one is proven.

These drives are ideal as they have a very wide range of compatibility with industrial machines of all types. I found this information from a great video where a guy retrofitted a Roland MV8800 with a 128GB version: https://youtu.be/gx0hs3ozcyA

Note: He discusses CopperLan and if your doing Midi it's crazy not to be using it, check out his video covering his complete set-up: https://goo.gl/fq0sWi

-----------------------------------------

As a SP808EX owner myself, I'm very interested in your progress and especially a way to format a HDD into multiple 1/2 GB partitions that can be utilized directly or by changing the active partition after each slot is full.

Cheers


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

Joined: July 30th, 2017, 20:02
Posts: 2
Location: Florida
Wow I love how techinical this post got then suddenly died out :-(

The sp808 is a great machine that deserves a low cost replacement for the Zip Drive

Come on I know you masters can figure this out. Don't let this thread die !!!!!


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: July 30th, 2017, 20:57 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
ZipSnipe wrote:

The sp808 is a great machine that deserves a low cost replacement for the Zip Drive



Unfortunately, I could not get the PATA drive I linked to above to work.

This thread was our best hope, but the gurus have abandoned us :(


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: July 31st, 2017, 22:12 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 12422
Location: Australia
Here are the Identify Device data in a format that can be more easily correlated with the ATA command documentation:

Code:
Offset(d) 00   01   02   03   04   05   06   07   08   09

00000000  80A0 0000 0000 0000 0000 0000 0000 0000 0000 0000  € ..................
00000010  3030 3330 3438 3831 4536 3936 3131 3237 2020 2020  00304881E6961127   
00000020  0000 0000 0000 3235 2E51 2020 2020 494F 4D45 4741  ......25.Q    IOMEGA
00000030  2020 5A49 5020 3235 3020 2020 2020 2020 4154 4150    ZIP 250       ATAP
00000040  4920 2020 2020 2020 2020 2020 2020 0000 0000 0F00  I             ......
00000050  4003 0200 0000 0006 0000 0000 0000 0000 0000 0000  @...................
00000060  0000 0000 0000 0003 0001 0096 0096 00B4 00B4 0000  ...........–.–.´.´..
00000070  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000080  0010 0000 4218 4010 4000 4218 0010 4000 0407 0000  ....B.@.@.B...@.....
00000090  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000100  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000110  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000120  0000 0000 0000 0000 0000 0000 0000 0001 0000 2863  ..................(c
00000130  2920 436F 7079 7269 6768 7420 494F 4D45 4741 2032  ) Copyright IOMEGA 2
00000140  3030 3220 0000 3630 312F 2F33 3230 0000 0000 0000  002 ..601//320......
00000150  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000160  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000170  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000180  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000190  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000200  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000210  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000220  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000230  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000240  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
00000250  0000 0000 0000 0000 0000 0000                      ............

ISTM that there may be a SanDisk CF card (eg SDCFXPS-032G) which might be a compatible candidate. It comes configured as an ATAPI device (like the Zip drive), but can potentially be reconfigured as a fixed HDD, if necessary.

See viewtopic.php?f=10&t=31965

_________________
A backup a day keeps DR away.


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

Joined: September 8th, 2009, 18:21
Posts: 12422
Location: Australia
Maybe an excerpt from the schematics might be helpful to the discussion ...

Attachment:
SP808_IDE.gif
SP808_IDE.gif [ 128.59 KiB | Viewed 6508 times ]

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 1st, 2017, 19:50 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
Not a tech myself, but would think the answer would be on the IDE ZIP side i.e Roland knew they were only going to accommodate the ZIP and made the interface accordingly.

It would seem that we need to emulate the IDE Zip Mode somehow.

So that would be Mode 4 with a removable setting?

Really thought that http://www.zheino.com/products-zs.asp?ID=216&ClassID=65&SubClassId=70&title=ZHEINO%202.5 would do the job, unless fixed mode was the problem.

I've asked for the IDE spec sheet to hopefully shed some light.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 1st, 2017, 20:54 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
[quote="fzabkar"]Maybe an excerpt from the schematics might be helpful to the discussion ...

Maybe this one also: SFF-8070i Specification for ATAPI Removable Rewritable Media Devices

https://doc.xdevs.com/doc/Seagate/INF-8070.PDF


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 1st, 2017, 21:04 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
I've put the call out:
------------------------------------
Dear Mr Wagner,

I'm researching a dilemma that a lot of musicians are trying to solve with legacy Roland devices that utilized ATAPI ZIP Disks.

Basically the hope is to retrofit modern storage formats like CF and SD cards...but one device in particular (SP808EX/250MB Zip) has the entire world stumped it seems.

I sniffed out the document 'SFF-8070i Specification for ATAPI Removable Rewritable Media Devices' and from that found in your CV that you are a 'Former contributing member of the original ATA interface specification and standardization committee'

If you could shed any light at all on the matter, it would be greatly appreciated by thousands of these machines languishing in closets.

Thank you for considering this matter
------------------------------------------------


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 1st, 2017, 23:43 
Offline

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
More CF (microdrive) hints, gleaned from the 'dpreview' forums (2005) maybe it's time to rip apart those old devices?
------------------

Be careful what microdrives you buy.

There are many drives out there being sold on EBay and other sites that were taken from Apple iPod Min & Rio Carbon MP3 players, etc. These drives will NOT work in many/most digital cameras as they are not ruly compatible w/the CF spec: they merely have a CF connector but are only capable of running in True IDE mode. The MP3 player mfgrs did not need full CF-compliant interfacing and bought cost-down versions with just the features they needed. Seems that MP3 players access the drive in TrueIDE mode, while (most) digicams access the microdrive or CF card in a CF-specific memory- or I/O-mapped mode.

If it's a retail-packaged drive, it will have a "CF" logo and supports CF mode. (It will also support TrueATA/TrueIDE mode).

Microdrives coming out of the OEM channel or removed from consumer audio devices like iPODMinis, Rio Carbons, etc. do not need the extra features offered by the CF interface. Some of this logic that makes the drive run in the various CF memory-mapped and I/O mapped modes (along with attribute memory), as well as the supporting internal firmware, is removed and [b]the microdrive runs only in TrueIDE/TrueATA mode. These drives will NOT have a "CF" logo on their labels[/b].

Thus these latter drives are NOT CF cards; they just uses CF packaging, form-factor and connector style.

Many/most digital cameras can only talk to a CF card (microdrive or flash mem.) in a CF mode, and not in TrueIDE mode.

I believe the new "CF+" specification in fact makes TrueIDE support optional, whereas it was one of the supported modes in orig CF spec.

This may change since microdrives can offer UDMA mode 2 (or higher) transfers while in TrueIDE mode which is faster than the 16-20MB/sec interface rate supported by the CF memory-mapped mode


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

Joined: September 8th, 2009, 18:21
Posts: 12422
Location: Australia
CF pin #9 (#OE/#ATA SEL) determines whether the card operates in PCMCIA or True-IDE host interface mode. To select True-IDE mode, the host (or CF-IDE adapter) needs to ground this pin. That's what we would want for the Roland device. Therefore those True-IDE-only cards would be OK.

The problem appears to be that some CF cards are configured as ATA devices that look and behave like a HDD, while others are configured as ATAPI devices. ATA devices use the ATA command set whereas ATAPI devices use a SCSI command set (and the ATA A0h PACKET command).

_________________
A backup a day keeps DR away.


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

Joined: September 8th, 2009, 18:21
Posts: 12422
Location: Australia
I'm not conversant with the ATA/ATAPI/CF specs, but I notice that word 0 of the ATA Identify Device command has changed greatly over the years. I'm now not so sure that the Zip drive is an ATAPI device, or that a CF card can ever be an ATAPI device.

Information technology - ATA/ATAPI Command Set - 3 (ACS-3) - T13/2161-D:
http://www.t13.org/Documents/UploadedDo ... et_-_3.pdf

Quote:
Identify Device (ECh)

If the device is an ATA device, then bit 15 [of word 0] shall be cleared to zero.

Devices supporting the CFA feature set shall place the value 848Ah in word 0. In this case, the above definitions for the bits in word 0 are not valid.

Quote:
Identify Packet Device (A1h)

Bits (15:14) of word 0 indicate the type of device. Bit 15 shall be set to one and bit 14 shall be cleared to zero to indicate the device is an ATAPI device. Bits (12:8) of word 0 indicate the command set used by the device. This value follows the peripheral device type as defined in SPC-4 (e.g., 05h indicates a CD/DVD device).

The Iomega Zip drive reports a value of 0x80A0 in word 0.

    80A0 - 1000 0000 1010 0000

This was Identify Device word 0 in the very early days of the standard (1994):

Code:
Word.Bit      Description
==========================
0.15      0 = reserved for non magnetic drives
0.14      1 = format speed tolerance gap required
0.13      1 = track offset option available
0.12      1 = data strobe offset option available
0.11      1 = rotational speed tolerance is > 0.5%
0.10      1 = disc transfer rate > 10 Mbit/sec
0.9       1 = disc transfer rate <= 10 Mbit/sec but > 5 Mbit/sec
0.8       1 = disc transfer rate <= 5 Mbit/sec
0.7       1 = removable cartridge drive
0.6       1 = fixed drive
0.5       1 = spindle motor control option implemented
0.4       1 = head switch time > 15 usec
0.3       1 = not MFM encoded
0.2       1 = soft sectored
0.1       1 = hard sectored
0.0       0 = ATA reserved (should be zero)

http://www.users.on.net/~fzabkar/IDE-id ... ND-ATA.DOC

If we use the above bit definitions, then the following apply for the Zip drive:

    removable cartridge drive
    spindle motor control option implemented

The above appears to make sense.

For the current standard ...

Code:
bit   description
-------------------------
15    0 = ATA device
14:8  Retired
7:6   Obsolete
5:3   Retired
2     Response incomplete
1     Retired
0     Reserved

I consulted SanDisk's CF spec.

SanDisk CompactFlash Memory Card, OEM Product Manual, Version 12.0:
http://pdfstream.manualsonline.com/2/23 ... 489686.pdf

Quote:
Word 0: General Configuration.

This field informs the host that this is a non-magnetic, hard sectored, removable storage device with a transfer rate greater than 10 Mb/sec and is not MFM encoded. CompactFlash products report 848AH in compliance with the CFA specification.

There is no mention of ATAPI, or the Identify Packet Device command (A1h), or the Packet command (A0h), or SCSI commands. So it seems clear that CF cards are ATA devices, not ATAPI.

Have you been able to find a technical reference manual for the Zip drive?

Do you see any Zip drives or similar cartridge drives in the following database?

http://bitsavers.trailing-edge.com/pdf/

_________________
A backup a day keeps DR away.


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

Joined: August 17th, 2015, 21:40
Posts: 39
Location: Adelaide, South Australia
P/N: 30183900 ATAPI-250

Cannot find anything, only a photo of the board: http://cdn2.goughlui.com/wp-content/upl ... _00091.jpg


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 2nd, 2017, 12:04 
Offline

Joined: April 25th, 2008, 9:49
Posts: 25
Hello
I happened upon this and just wanted to point out ide grabber from these links http://nazyura.hardw.net/Grabb8b.zip
http://nazyura.hardw.net/Grabb16b.zip

and conventional hdd discussion Samsung HD322GJ here at hddguru.com. I don't know if anything is available for purchase and I've never built one of these(so far) as I've never had to use anything but BusHound 5.04 or 6.01. If you're in a Windows OS you might look into that also. If you look around you might still be able to find freeware,trial ware or share ware BusHound.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 146 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 8  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