Switch to full style
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...
Post a reply

Re: Sniffing control flow between legacy devices over PATA/A

September 11th, 2020, 17:51

@fzabkar, I'm certain that Power was getting to the USB Connector, because the USB Drive I was using to test has an LED inside it. The LED was solid "on" when the SP-808 was powered up. rs

Re: Sniffing control flow between legacy devices over PATA/A

September 12th, 2020, 4:37

ryansupak wrote:Updates:

SalvationData board was a dead end. Did the ATAPI mod to that SD board, and it responds identically to the way it does in the default IDE Mode (in other words, it doesn't do anything but light the Status and Power LEDs up).

***

I found a gentleman online who manufactures and sells a board that was originally designed to emulate ATAPI Optical Drives for (I think?) defunct arcade machines, using USB Drives as a storage replacement. He was so interested in what we were doing, that after a couple of emails, he bought his own SP-808, and he is going to give adapting his existing board to our application a shot! He says he expects that his existing board will work, by way of a few small software enhancements to handle ZIP-specific commands.

He is aware of this thread, and of the concurrently-happening MidiManiac attempt to crowdfund an adapter. To me, this guy's work seems like it's by far the closest thing to a solution out there at the moment. I won't link to his page here -- but know that he is serious about pursuing this, and certainly I am sure he'll speak up if/when he wants to. :)

rs


Been bitten too many times to participate in crowd funding projects. If this thing is possible, it *should* be a relatively cheap microprocessor board. Someone just needs the skills to know how to make it.

Other option is custom firmware for the 808

Re: Sniffing control flow between legacy devices over PATA/A

September 12th, 2020, 11:20

@HaQue: I hear ya on crowdfunding. The nice thing about the other fellow (NOT the crowdfunding guy) is that he already produces a microprocessor-based working solution for sale that does a slightly different thing. He's not asking for any money (unless, of course, he releases a working product and somebody wants to buy it, haha).

Meanwhile, I've sent for a Raspberry PI. I feel like I should be able to use the GPIO pins and a little C code to sniff what's going on, and maybe eventually make the RPi into a USB Drive solution. If nothing else I'll learn something.

rs

Re: Sniffing control flow between legacy devices over PATA/A

September 13th, 2020, 10:36

I remember a few years ago when looking at a games system, there was a sniffer for I think IDE. I am blanking on details but I think it was called bus hound or something like that. It may have been hardware based or a license I couldnt afford at the time or something but I know I really wanted it, but either never did or never got it to work.

Re: Sniffing control flow between legacy devices over PATA/A

September 15th, 2020, 19:47

@HaQue

Yes -- BusHound is one I saw in my research. If I end up engineering a solution myself, I'm gonna try to use an RPi 4 in a similar way. I'd need to be able to read the GPIO pins at 1Mhz minimum to match the maximum data transfer rate of an ATAPI ZIP drive, which was about 1.4 MB/second (which I rounded up to 2 MB for good measure), and it looks like the native C library for GPIO can conservatively operate at 20-times that rate.

Meanwhile, I've been in correspondence with the guy I mentioned who already developed, and sells, a similar product. He got his SP-808 in the mail and says his card solution is pretty close to working as-is; there are only a few special commands coming from the 808 he has to iron out. I can tell he's pretty far along because he was asking me about details of hot-swapping vis a vis the 808 workflow, etc... I've offered to beta-test for him, and barring that I'll buy (3x) or (4x) from him, if his solution comes to fruition.

Here's hoping...
rs

Re: Sniffing control flow between legacy devices over PATA/A

September 21st, 2020, 12:57

Here's the guy that I ran across with an existing, but similar, solution for another application. Looks like he is pretty close. I gave him a few corner-cases to test and he did discover a few glitches, but all in all making he is excellent progress in a short time:

https://www.youtube.com/watch?v=rYdAEDZJxCM

Re: Sniffing control flow between legacy devices over PATA/A

September 24th, 2020, 11:03

Great progress, Ryan! I don't totally understand your 1MHz minimum though. If you're wanting to sample 2MB per second, that's 2M*8/sec = 16MHz? Additionally, with sampling you'd want to sample at least twice that frequency. Rule of thumb is usually much higher. 6-10 times.

Re: Sniffing control flow between legacy devices over PATA/A

October 4th, 2020, 1:37

@micmic, I've never done this before and could well be missing something. But here's how I came to ~1Mhz (correct me if I'm wrong here):

1) ATA Interface has 16 data pins (at 1 bit each), so 2 bytes per "cycle".
2) 1MHz * 2 bytes = 2MB/sec (which is ~1.4x what I actually need).

It looks like an RPi3 will do ~65MHz:
https://github.com/hzeller/rpi-gpio-dma ... op-to-gpio

So, let's conservatively assume an RPi4 will do ~70Mhz. If I'm calculating this correctly, that's over (70x) the minimum speed needed.

Am I calculating all that right?
rs

Re: Sniffing control flow between legacy devices over PATA/A

October 4th, 2020, 2:22

PS - that Youtube video is NOT me. It's a guy I contacted about all this, and he got interested in adapting his similar, existing board to the purpose. Just to be clear. :) rs
Post a reply