@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

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

@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

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.

@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

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

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.

@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

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

Hi, long time lurker, first time poster.

I also have three Roland SP-808s and I'm also now running out of ZIP drives. It seems COVID turned everyone into a retro geek, and drives that were selling for £5 just 2 years ago, are now selling for nearly £100. Given they're nearly always "unable to be tested" by the seller, it's a total crap shoot.

I've tried every avenue. I even bought the drive that was fitted to the Akai MPC 2000xl, but guess what, the revision I received, isn't compatible.

I've been following the work of the Russian forum too. One of the forum members has created project that I will be testing that emulates ATAPI drives. The Tatieboggle project, is too expensive at £200 and requires some faffing (a bit like SD2SCSI does).

I was really hoping that the DataSalvation board would work, but I discovered a while back that it's not just ATAPI that the SP808 wants.

I used an SD (TF) to CF adapter, in a passive CF to IDE converter and it looked promising. But no.

The SP808 is making some assumptions and whatever our solution, it has to be able to accommodate those solutions.

Unless, we get anywhere with the decompilation of the A6 firmware and splice that with the SP808 firmware. If the A6 can use a HDD it's clearly not a hardware constraint.

I've just purchased a Digilent logic analyser, so I can (as the title of this thread asks) sniff the commands. I've also just built a PC with native IDE so that I can query the Panasonic drive that Roland fitter to the SP808.

I need a HDD guru to set me straight here. Am I right in thinking I only need to "sniff" 8 data lines to read the ATA commands? In doing so, I'll also capture the ATAPI packet?

It's 2022, who's still interested?

the data transfer is likely 16bit, so 8 bits is only sufficient to capture the task file registers (and even bytes of data). It might or might not be sufficient to figure out what the unit wants from the drive...

_________________
Adatmentés - Data recovery

Yeah, my working assumption is it's a 16bit transfer, given that the main CPU is 16bit.

I've been poking about in the firmware for the SP-808EX this afternoon and I ran it through `strings` and found the following strings of interest:
CD
HD
ZIP
FAT12
FAT16

Which makes sense to me as a factory fresh ZIP 100 disk is formatted as FAT12. An early post mentioned windows7 formatting the disk incorrectly. That is a red herring.
Early IDE ZIP drives (the ATAPI2) had an additional jumper, that when set, would present the drive as a Floppy disk drive using ARMD (ATAPI Removable Drive).
In other words, you could have a huge floppy with no and no partition table or a small disk with a DOS style partition table.
Disks formatted for the Mac had 6 partitions.
Disks formatted for PC had. Partition table with one entry, the 4th spanning the whole disk.
If the A jumper is set, the drive hides the first 32 sectors.
It is also reported as being able to make the drive behave as ARMD via VSC as some bios' where able to change how the ZIP drive behaved. Notably Asus P3B-F Motherboard had this "feature"

Iomega made a number of revisions to their drives.
The ATAPI drive firmware identifies itself as:
IOMEGA ZIP 100 23.D
while an ATA drive identifies as:
IOMEGA ZIP 100 B.29

Hsiboy

I have a few SPs myself and am looking forward with great interest in your findings!

Keep us posted and can see then if there is anything I can contribute (research, testing, etc.)

Thanks

grounder314

Forgot to mention yesterday, if you (or anyone) is looking for excellent archive of information about older technologies-protocols-operating systems (SCSI, programming, OS, etc.) check out:

http://vtda.org

http://vtda.org/books/Computing/
http://vtda.org/books/Computing/Hardware/
http://vtda.org/books/Computing/Hardware/SCSI/

Just a quick update.

I designed some PCBs to breakout the 40pin IDE cable, these are currently being manufactured by JLPCB. My timing isn't great because Chinese New year is about to start, so it could be another 3 weeks before they are in my hands.

Other things to note. The IDE multicard reader that supposedly came from and Akai 2000xl that didn't work in the SP808, also wouldn't work in an older AMD pc I have built specifically for this project. Closer inspection of the readers PCB revealed a blown resistor pack on the IDE interface. I've ordered some new ones and they arrived from Germany yesterday. Hopefully I'll get time in the next few days to repair the reader.
My thinking here is that if the reader works in the SP808 I can dump the ROM from the reader and flash it to the cheap Chinese SD to IDE adapters that appear to use the same chipset.

Cheers,

Hsiboy

Hsiboy, Thank you for the update!

Another quick update.

The multi media reader that i bought (from a guy in Italy), supposedly from an Akai MPC2000Xl doesn't work in a PC either. Under a microscope i saw that some of the resistor network packages were burned, so i ordered new ones. This didn't help. So i started the slow process of looking for shorts, and sure enough there were some more. I've ordered more SMDs to replace those. I also bought another of these unobtainium readers from an eBay seller who, basically ripped me off. Unfortunately i cant do anything about it because before the item arrived (smelling like ) he'd vanished from eBay. One day my Latvian friend, one day....

I've been reading the data between the SP808 and a Zip disk during operation using a Logic Analyser to understand what specifically the SP808 is expecting from the ZIP disk. While i was doing this, i had a look at one of those cheap IDE-SD adapters that use a KTC FC1307a and Identify as "Sintechi" - It looks like those have bad firmware as they send back garbage that the Roland SP808 cant handle. Hence the lockups.

The SP808 asks the ZIP drive to lock the door, and pressing the eject button on the front of the drive generates an INTRQ which the SP808 responds to while asking the user if they want to save their work. The SP808 also sends the ZIP drive:


Those of you playing along at home may be scratching your heads

I've been working with one of the members of the Russian forum ( ) and I am working on an alternative solution with him, that i feel is very close to working.

Finally an ask. Earlier in the thread some members were working on the disassembly of the firmware. Where did this get to? Does anyone have disassembled source they would share? I don't have the ability to disassemble for that particular processor.

HSIBOY

HaQue, I see you're still active on the forum. By any chance, do you have the disassembled A6 firmware? Yeah, i know. Grave digging on an old thread, but 5 years later, there's still no solution.

If you don't have the source, can you tell me what you used for disassembly of this Hitachi core?

The A6 can use ATA hard drives, the SP808 can't. If i could diff the disassembled firmware, i may be able to determine which portion is disk i/o and patch it.

Cheers,

HSIBOY

Just in case anyone else follows in my footsteps. These maths are wrong, well, the math is right, the numbers are wrong. Using the ATAP2 specification (remember we're talking about an ATAP2 device, running in PIO 2) a cycle can be as low as 5nSec or 20Mhz - Good luck getting the GPIO on a raspberry pi to go that fast. Even without Linux (which isn't a real time OS) interrupting every few nano seconds, the GPIOlib was written for flashing LEDs on and off etc, so it will be your bottleneck.

I'm sniffing the traffic at 60Mhz using a dedicated hardware logic analyser and i run out of DDR in about 5 seconds, which is too short to capture the full boot sequence and load of samples from a zip disk.
The lowest resolution i can get away with is 10Mhz, but, at that speed, the square waves are triangular ------\____/---\/--- Not what we want, especially when you want to decode something that was on the wire for 5nSec or less.

Another update.

I now know why the SP-808 only talks to ZIP disks and card readers fail.

I've sniffed the full interaction between SP-808 and Zip drive.

Up until this point, the idea was to somehow splice the A6 firmware with the SP-808 firmware to enable HDD.
That's a bit of a task.
However, I'm thinking I could patch out, or Nop the parts of the firmware that effectively check for ZIP specific ATAPI packets.

So, I've got the firmware, thanks to the Stirling work earlier in this thread.

Early investigation shows low entropy and plenty of strings, so I don't believe the firmware is encrypted or compressed.
That said, there is some sort of Roland header and footer on the firmware, which is holding me back from finding the entry point to the code (vector table) and any disassembly so far has resulted in some interesting code, with jumps to memory locations that don't exist.

If there's anyone with Hitachi H8/2655 machine code experience, I'd love to talk to them.