On 28 Jul 2008 at 11:37, Jules Richardson wrote: Thank you. I actually don't know the state of NTI, having been out of the picture for 8 years now. Armor was acquired by BAE last year. A bunch of NTI's business (but I don't know if that includes software) was sold to Breakwater Technologies in Seattle a few years ago. They may be the ones to contact--they might not even know they own it. So one might ask them--assuming that they haven't been gobbled up by someone else. Cheers, Chuck

On 29 Jul 2008 at 11:33, Jules Richardson wrote: To be honest, I can't tell you why I did it that way. Probably for compatibility's sake, but it's been too many years. I do recall thinking that one could have TD tD Td and td as variations. If they'll release me from the NDA that they inherited, I'm perfectly content to release the source code to the public of any tools they might have acquired (I've got every iteration since 1987). But I have a very-well justified fear of lawyers, so not before then. Certainly, any interest in floppies has to be marginal by now. Cheers, Chuck

On 29 Jul 2008 at 10:52, Fred Cisin wrote: 16 no? TD *TD T*D *T*D td *td t*d *t*d... where the * indicates high bit set. But then, who's counting? Cheers, Chuck

Philip Pemberton wrote: And I wish he would have told me before I started my external usb amiga floppy drive controller a couple years ago. :) While I haven't dug into the past posts to see what exactly you are doing, I use a Parallax uC for my solution to create .ADF (amiga emulator files) from amiga formatted disks w/ a standard pc drive. My blog has considerable detail (although spread out) about how I go about syncing to the data stream -- first at the bit-level(pulses/transitions) and then at the byte level(to the sync word) I'd encourage you to check my blog --- everything is ad-free and open source --- though it needs better organization.......... http://www.techtravels.org/amiga/amigablog high-level overview http://www.techtravels.org/amiga/amiga.html Schematic http://www.techtravels.org/AFPschematic.gif Pictures http://www.techtravels.org/amiga/amigablog/?p=139 Hope this helps Keith

Keith wrote: I'm using an Altera Cyclone II FPGA to do the data read/write stuff, a Micron SDRAM for data storage, an Atmel DataFlash chip to store the FPGA microcode and a Microchip PIC18F4550 to handle the USB interface and boot the FPGA (although strictly speaking I could use a smaller PIC and let the FPGA handle the USB interface...) It's been designed from the get-go to do everything required to image and restore soft- and hard-sectored discs. Timing resolution is around the 25ns range (which is an integer multiple of the standard data rates -- 1Mbps, 500kbps, 300kbps, and 250kbps). There's an index-pulse, track-mark and sync-word detector that handles read/write synchronisation. The FPGA contains two distinct modules - a read module and a write module. The read module is basically a chunk of logic that counts the number of clock cycles between pulses on the RD_DATA line and writes the timing values to RAM. The write module is a finite state machine that has a few simple instructions: WRITE_TIMING_R(N) -- wait N cycles and strobe WRITE_DATA SET_WR_GATE(B) -- enable/disable WRITE_GATE WAIT_TMARK -- halt the FSM until a track mark is detected (hard sector discs only) WAIT_INDEX(N) -- halt the FSM until N index pulses have been detected HALT -- stop the FSM and set the DONE flag So for a soft-sector disc you'd use WAIT_INDEX(1) then SET_WR_GATE(1) followed by a bunch of WRITE_TIMING_R() instructions and finished with a SET_WR_GATE(0). For hard-sectored, you'd use WAIT_TMARK, SET_WR_GATE(1), write some data, then SET_WR_GATE(0). That would write to sector 1 -- if you wanted to write to (e.g.) sector 5, add a WAIT_INDEX(4) after WAIT_TMARK. I've seen that before, and I'm sure I've commented on it (more than likely as "philpem"). Interesting project, though I wouldn't have used a Parallax SX... It looks like you're just wanting to read and write Amiga discs -- I'm wanting to take this to the point where it's possible to read, analyse and then remaster discs -- especially copy-protected discs. I'm also planning to add some form of auto-analysis to the driver software, which will (hopefully) allow it to use some basic heuristics to figure out the data rate and disc format, spit out a .RDI file (custom open-spec Raw Disc Image -- stores decoded MFM or FM streams or timing values) then decode the data into a .IMA file (PC), .ADF (Amiga / Acorn), .SSD/.DSD (BBC Micro) etc. for use on an emulator. One other thing that might be worth playing with is density analysis -- in theory, no two drives will write at exactly the same speed (motor speeds are rarely perfect). You can - again, theoretically - exploit this to figure out if a disc has been written to after it was mastered (e.g. high score tables, etc. have changed). -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/