e.stiebler wrote: Any more facts available? Online? I'm asking because I guess quite some people might be interested in this. I only know of solutions for replacing specific ST506 interface harddisk (no "generic" replacement) and even those are kinda expensive. I guess it must have a quite decent microprocessor to emulate it. What real storage will be used to save the data on? CF-card, SD-card or something? I fear this because they are not that good when it comes to many reads and writes (I have systems where the swap is for example on a MFM harddisk as well...) So.. can you share more information or do you have a page online? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/

load that pc with linux, and use "dd" it'll do a raw dump of the drive to binary (iso) format Dan. _________________________________________________________________ New! Open Messenger faster on the MSN homepage http://go.microsoft.com/?linkid=9677405

Al Kossow wrote: Interesting. I'm doing basically the same thing. Just found out this morning that almost the entire disc reader logic module was unstable -- it passes testbench perfectly, but won't work in hardware. Seems to be a fairly simple issue, but I've gone back to getting the drive stepping / status readback working over USB and adding some "fast register access" functions to the microcontroller first. The RAM read/write and USB stuff works really nicely, though. So basically I have a 512Kbyte, USB-interfaced SRAM :) I did some back-of-the-envelope calculations a while ago -- An ST412 will allow a maximum of 5e6 flux transitions per second. 1/5e6 = 200 nanoseconds between two flux transitions (worst case) The Catweasel's clock oscillator is switchable between: - 7.080MHz - 14.161MHz - 28.332MHz (Mk3 and Mk4 only) Which gives a timing resolution of: - 7.080MHz -- 141.2429 nanoseconds - 14.161MHz -- 70.6165 nanoseconds - 28.332MHz -- 35.2958 nanoseconds None of these are factors of 200ns, even if we ignore the fractional part; thus any measured timing values will be subject to a fair amount of jitter (around the 1-2 clock cycles mark). This would probably be masked by the inherent inaccuracy of the drive's spindle motor, though. Taking the coding into account, standard MFM has a minimum of 1T (200ns) and a maximum of 2T (400ns) between two transitions -- there's also the possibility of a 1.5T (300ns) delay between transitions. Using the fastest clock rate (28.332MHz)... - At 1T, you'll get a count of 5.6664. The CW can't count in fractions, so you'll see a count of 5. - At 1.5T, you'll see a count of 8.4996. The fraction is dropped, leaving a count of 8. - At 2T, you'll see a count of 11.3328. Again, the fraction is dropped, thus you see a count of 11. Decoding this would be possible, but wouldn't leave much room for error. If you had a "late" transition followed by an "early" transition, the difference in counts between two transitions could be as little as one clock. Even if the gap was wider, it'd still be hard to say with 100% certainty "this is a 01 sequence" or "this is a 001 sequence". I'm using a 40MHz primary clock reference in my disc analyser for a few reasons: - It makes the math easy. 40MHz = 25ns per count. - 25ns is an integer factor of the bit-cell sizes and transition periods used on floppy discs. It also ties in nicely with the transition rates used on MFM HDDs, assuming you don't want to write back to the drive. The 25ns resolution of a 40MHz oscillator gives a 1T count of 8, a 1.5T count of 12, and a 2T count of 16. Even with a worst-case jitter of 2 cycles, you still have a 2-count gap between the two ranges. However, the FPGA has an on-board PLL -- you can multiply the reference clock by just about any factor you like. Increase it to, say, 160MHz and you get a much better margin (though your transition rate is still limited to the speed of the RAM and the master clock). If you wanted to write back to the drive, you'd need to handle precompensation, which would involve increasing the clock rate (the ST412 and ST506 precompensation value is 12ns according to the OEM Manual). Unless, that is, you were trying to build a Write-Only Memory... :) -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

On Tue, 6 Oct 2009, Philip Pemberton wrote: According to the Catweasel IV+ documentation, there is a 56Mhz clock available. Not sure if that's new for that version or not. Steve --

On Oct 6, 2009, at 10:41 AM, e.stiebler wrote: Umm. Wow! -Dave -- Dave McGuire Port Charlotte, FL

On Tue, Oct 6, 2009 at 11:51, Philip Pemberton <classiccmp at philpem.me.uk> wrote: That may be a difficult bit. All documentation - if there ever was some - is long gone. The Amiga and Sidecar have been through many moves, and was last used sometime around 1993/4 when it was replaced by the A3000. I found a page describing the jumpers for the controller by googling "Xebec" and the assembly-number (104866 or something, I don't have it in front of me) so moving the address is certainly an option. I was asking since a google returned a message on the kernel developers list (199? timeframe, 2.0 kernel) complaining about the nonfunctional xd driver and suggesting it'd be removed in future. I still have a set of original RH5.2 install CD's I'll check those once I find them :-) I was actually assuming the way to get this drive working was to find a 8086 class machine (thus it'd be the primary controller) - so dd would not be an applicable command; then somehow use DOS either from the 5Meg partition (that should still be there if the drive kept all its bits in place) or a floppy to somehow dump the raw HD bits off. Yes, dd would be nice, but that assumes a 32-bit machine with a driver for the card. That is my concern. Hmmm, maybe an old Minix system could talk to the card :-) od the raw device to the serial port, then capture the octal data and reassemble the image file... Joe. -- Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem

On Tue, 6 Oct 2009, Joachim Thiemann wrote: That's only part of the picture. Many of the Xebec MFM/SCSI adapters had their own reserved area on the drive for configuration and bad sector maps. I wouldn't bet money on the raw track/sector format lining up with anything an ISA bus MFM controller would understand. Given the above proviso, that's definitely the best bet. If you can address the drive as a raw device it should be possible to figure out offset to start of "real" data. For extra credit, it would be fun to see if a modern SCSI adapter can be made to communicate with the command syntax supported on early Xebec boards. The earlier ones were only kinda, sorta SCSI-1 compliant. I rememember seeing a Linux kernel driver for talking to the Xebec 1410 series, but it was probably more than 10 years ago. Steve --