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 ... 7, 8, 9, 10, 11, 12  Next
Author Message
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: September 24th, 2020, 11:03 
Offline

Joined: July 28th, 2020, 13:03
Posts: 4
Location: Tennessee
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.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: October 4th, 2020, 1:37 
Offline

Joined: August 25th, 2020, 15:05
Posts: 16
Location: h-tine hold it dine, tx, usa
@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


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: October 4th, 2020, 2:22 
Offline

Joined: August 25th, 2020, 15:05
Posts: 16
Location: h-tine hold it dine, tx, usa
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


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: January 7th, 2022, 7:02 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
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?


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: January 7th, 2022, 10:54 
Offline

Joined: October 3rd, 2005, 0:40
Posts: 4311
Location: Hungary
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


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: January 7th, 2022, 14:00 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
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


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: January 10th, 2022, 13:50 
Offline

Joined: January 10th, 2022, 13:36
Posts: 3
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


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: January 11th, 2022, 12:19 
Offline

Joined: January 10th, 2022, 13:36
Posts: 3
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/


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: January 30th, 2022, 10:29 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
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


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: January 30th, 2022, 12:28 
Offline

Joined: January 10th, 2022, 13:36
Posts: 3
Hsiboy, Thank you for the update!


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: February 15th, 2022, 12:58 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
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 :smoker: ) 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:
Code:
D0 EF: SET FEATURES
SUB: 00 PARAMS: 02 01 80


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 ( :agree: ) 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


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: February 15th, 2022, 13:33 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
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 :rip: 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


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: February 15th, 2022, 13:45 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
ryansupak wrote:
@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


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.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: April 29th, 2023, 7:16 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
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.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 10th, 2023, 13:28 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
Just a quick update.

There is something off with the firmware that was unpacked from the midi files earlier in this thread.

Decompilation was very scrappy and needed lots of manual intervention when it should not have required it.

As a test, I ran the firmware from a Nissan ECU (it uses the same CPU) through the decompilation and boom, a screen full of sub routines and jumps to them.

I don't get that with either the SP808 firmware or the A6 firmware.

Next, I'm seeing patterns in the firmware I wouldn't expect.
I'm seeing

Code:
7F 00 00 00 00
repeated every 14 bytes. And other anomalies that repeat through the code, suggesting it's an artifact of the midi extraction.

The other thing that makes no sense, the A6 firmware is bigger than the SP808 firmware??

I'd expect the SP808 firmware to be bigger because it has all of the effects and Synthesis that the A6 doesn't.

Very odd.

Current plan is to dump firmware to disk and examine that. However, I have just ordered a chip programmer that can handle the 56 pin flash chip, and that will be my next port.

Finally, I'm going to see if the UART on CN7 yields anything useful, as there are some strings in the firmware that are never shown on screen or stored on disk.

HSIBOY


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: May 11th, 2023, 4:31 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
Small correction to the above, it's
Code:
7A 00 00 00
,
And here's the odd thing. If I diff the Sp808 firmware and the A6 firmware, these patterns occur in the same place in both files. In fact, there are so many null bytes
Code:
00
that occurs in exactly the same place in the two files, it has to be an artifact from the midi update.
Question is, has it been extracted incorrectly, or, is it a further later of transport packing, because the firmware was being streamed in over a uart.

Also, there are strings that appear on the screen of both devices, that are not present in the firmware.
So, either the firmware does not update everything, or there is further compression.

The entropy of the two files is below 1, so I don't think it is compressed, but either way, the firmware that was extracted earlier in this thread, is currently a dead end, because it can't currently be compiled.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: June 18th, 2023, 13:42 
Offline

Joined: January 7th, 2022, 6:43
Posts: 20
Location: United Kingdom
Ok, so, a couple of things.

1. The firmware isn't H8 code. There maybe some H8 code in there,but it's not straight up H8 code.
2. The MCU used in the SP808 has a 64KB ROM, that was burnt at the factory (mask ROM).

I haven't been able to put the MCU into prom mode yet and I haven't been able to dump the flash ram either.

Slow going.


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 9th, 2023, 12:53 
Offline

Joined: August 9th, 2023, 11:40
Posts: 3
Location: Barcelona
Hi,
I want to contribute to this cause. Short history… I waiting for Midimaniac to chat about it since I found him selling his sp808 with working cf reader (the bluempc model) and I wrote a comment a year ago in this video but he never answered…

https://youtu.be/3n7enH5vOyU

My comment (a year ago…):
Quote:
My brother is onto msx (and older computing) homebrew things and I wonder time to time to maybe research a bit to maybe try tomfind a solution but everytime I start to dig I can’t just avoid ending at “why not just bypass the whole memory system and attach an iPhone with koala sampler (or even a raspi which supports koala btw) and get the best of two worlds” so keeping the ADCDAC side, fx, even synth but just use the midi side and then some hardware hacking about in and outs (so output of mic/line + fx into usb soundcard in plug to koala and the out plug into sp where the signal was hijacked so it goes to the master and sp outputs again…?)
Maybe it could be possible understand the whole hot swappable Atapi drive but for 4 stereo polyphony? About the 4 track recorder maybe it could be possible add some vstudio parts… I will love to see a solution but with propietary file compression without sources it requires a bit (too much) working for so little reward (imo) and in the end these are nutty expensive due the madness about lofi (we called noise back in the day…) and all the sp series… now revamped by roland themselves with 404mk2. I dunno… maybe just try to ask at retrobrew computers club groups so maybe one of these genius gets it as a challenge and crack the weird firmware inside these or just replace the cpu by raspi and emulation of that part at the brain surgery I’m pointing. It should not be impossible but worthy? I should look again into schematic to see how hard it will be but it’s like dejavu… I feel I done it but what I found made me brainwhased just to avoid the pain over and over… #FuckURolandcorporates I hate them as time goes more and more!


So I started reading the topic but jump into last page to see latest news… also my brother came a moment (I’m soldering some floppy interfaces for msx at the moment) and I tried to explain the problem and ask his (nerd) opinion. He told me more or less what Midimaniac tried himself here:
https://www.themidimaniac.com/archives/1076

Scroll down and use “show reader” if you get annoyning scrambled ads on top like me with the iPad (or maybe switching to desktop web version…)

There’s a log of the project “recreate that mpc blue reader” and he even tried a kickstarter but not enough backers…

So I will come back after chatting with him to see what’s in his mind and search for a collab if possible or ditch it definetly but almost sharing the possible.

I will appreciate your opinion. I will try to find time to read the whole topic meanwhile…

Cheers!


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: August 9th, 2023, 17:48 
Offline

Joined: August 9th, 2023, 11:40
Posts: 3
Location: Barcelona
Update: I read the whole topic so I have better idea how is going.

Thanks everyone involved for all the contributions.

I’ll be back!


Top
 Profile  
 
 Post subject: Re: Sniffing control flow between legacy devices over PATA/A
PostPosted: September 6th, 2023, 7:33 
Offline

Joined: September 6th, 2023, 7:16
Posts: 6
Location: United Kingdom
Hi all,

I joined up because I am also interested in finding a solution to the SP-808 zip replacement.

A couple of things:

The Startech CF drive seems readily available, it has a metal housing so will fit quite nicely, but obviously it seems to be a “dumb” IDE not ATAPI device.

Maybe a possible solution would be to have an inline pass through device which has a microcontroller that sends the appropriate commands to the SP-808, which connects between the Startech drive and the 808 drive cable. I don’t know enough about this to be sure it could work, hence my joining up here.

I have seen a FPGA based emulator for zip and other drives here https://3do.dev/products/copy-of-ide-emulator-batch2 but it seems quite expensive for this application and does a lot more than needed anyway.

I tried a few generic CF/IDE adaptors, some of them looked like they were going to work and gave me the option to format, and showed up recording time, but hung on trying to record, presumably because the 808 was waiting for some ATAPI response.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 231 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11, 12  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: Google [Bot] and 14 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