Chuck Guzis wrote: Hm. That would be with the Read Track command, right? All the PCs I've tried to use that on just returned a 'bad command' response, or garbage... Modern PCs also don't seem to like reading single-density (FM-encoded) discs... -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

Chuck Guzis wrote: Interesting way to do copy-protection... Yet another format that can't be (easily) created without a track-writer. Or an Amiga. The Amiga Copylock system is pretty unusual too -- that varies the bit-rate mid-track (by +/- 5% or so if memory serves). For that, even a trackwriter isn't enough unless it allows you to change the bit rate. (Reading FM on modern PCs) In my experience, the current generation of PCs can't handle FM at all. My 386 (with ISA floppy controller) is scarcely any better. The last time I wanted an image of a BBC Micro floppy, I ended up streaming it across the RS423 port at 9600bps. Ugh. Not fun. -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

Philip Pemberton wrote: Do you have any kind of estimate for when this will be finished (to the point of being releasable - sounds like there might be ongoing firmware patches?). I'd be interested in buying one I think (even though I try to avoid USB if I can). I've got three IBM ones from some IBM desktop or other (I got them as boards, so unfortunately have no idea which system they came from) which are extremely good - they'd read and write FM happily, and would cope with 128-byte sectors sizes too. The only downside to them is that they sometimes throw up CMOS errors and refuse to boot, which makes my plans to turn one into a headless remotely-driven system a bit problematic. My experience has been that it's "reasonably"* easy to get hold of a PC that'll read FM (at least at 256bps and above) - but difficult to get one that'll also write. * i.e. source a pile of 'em and there'll probably be a good one in there somewhere. I've done exactly that with a 20MB ST506 drive before and a modified copy of xfer - that on a drive with failing bearings. Something like 7 hours of high-pitched bearing scream later... the drive held together though, thankfully. cheers Jules

I've done a single sided board using atmega 128 and soldered it myself. It is easy if you learn how to do. http://www.tabajara-labs.com.br/eletronica/tts/1.JPG Congratulations!!! :oD Noooooo :( Keep the work with AVR! :D

Try to buy one here in Brazil :o)

Doug Jackson wrote: That pricing was for 10K piece quantities ... unless you are going to build a ~boatload~ of these boards, the small quantity price (or buying thru a distributor) will be significantly higher. Most of the LPC21xx series are US$8-US$12 each in small quantity from www.mouser.com, for example.

Ah, OzTralia. It works for you, but doesn't work for us. - We have customs' taxes. Something around 60 to 100% of the price of the product AND the freight. - It takes ages to arrive here. - You gotta have an international credit card, to buy on shops - For paypal use, you ALSO have to use an international credit card, because brazilian debt cards - although issued by VISA - are not accepted by paypal - Ah, in Ebay, usually sellers don't ship to Brazil, even if I have a confirmed paypal address - International credit cards in Brazil aren't so easy to have as in other countries. So, internet ordering isn't always an option :o)

Chuck Guzis wrote: That sounds good. I think various calculations have been pretty much done to death over the years, but do you anticipate 16MHz being enough, or are there likely to be some things that it won't handle? (I kept all prior threads on this kind of thing, but they're a bit lost amongst the noise right now!) I like the fact it's RS232. Like you say, it'd be easy to add a converter to give USB functionality, but a bit more difficult to go the other way. That's good too, I think - I'm sure the way forward is to make the custom hardware do the bare minimum, then allow the community to develop the tools to do the more complex decoding/encoding work on regular PC hardware (which I think is also Phil's approach) Well, I assume tools can be made to translate between formats, in which case it should matter little how many of these projects there are out there... cheers Jules

Jules Richardson wrote: I'd think it'd be fine up to about 500kbps. I'm using a 40MHz clock on mine because it's a multiple of most standard data rates. 1Mbps, 500kbps and 250kbps are all integer multiples of 40MHz. This helps reduce timing jitter -- the FPGA can't count fractions-of-a-clock. It also makes the math a bit easier when you start decoding the data! The biggest problem with low sample rates is that the timing values tend to "merge" together. When there's not much space between the peaks on the histogram, it gets to be a pain to decode. The problem, of course, is the limited speed of RS-232... 115200 Baud is only 11.25Kbytes/sec; the USB interface can handle The issue is that already there are different sampling modes, and different uses for the 'special 00' byte. For my hardware, it means "add 128 to the next sample byte"; for Chuck's it means "an index pulse occurred here". IIRC on a Catweasel it means "a really short pulse was detected". However, if we could all agree on a standard interchange format for raw-disc images, then this point would be more-or-less moot. Have the data analysis software read that format, then all you have to do is write a hardware-interface app that pokes and prods the hardware into reading the disc, and saves out to that format. I'm putting together a file format based on IFF (specifically, EA-IFF 85) with 64-bit extensions. The idea behind this is that -- when necessary -- you can add extra block-types (FOURCCs) to the data format, and older applications will just ignore them. However, in this case the FOURCC is actually 8 bytes -- a 4 byte Vendor ("xDIF" for standard blocks, anything else for vendor-specified blocks) and a 4-byte Type (e.g. "TRAK"=track, "THDR"=track header, "TDAT"=track data, "IXPS"=index position). Blocks can also contain sub-blocks -- a typical xDIF file might like this: / +-- xDIF:HEAD -- xDIF header block | +-- xDIF:CREA -- Creator/Application information | +-- xDIF:DESC -- Description of image contents | +-- ... | +-- xDIF:TRAK -- data track (contains other blocks) | +-- xDIF:THDR -- track header (track #, encoding type) | +-- xDIF:TDAT -- track data | +-- xDIF:INDX -- position of index pulses | +-- xDIF:TRAK -- data track (contains other blocks) | +-- xDIF:THDR -- track header (track #, encoding type) | +-- xDIF:TDAT -- track data | +-- xDIF:INDX -- position of index pulses | ... Or you could have: +-- xDIF:TRAK -- data track (contains other blocks) | +-- xDIF:THDR -- track header (track #, encoding type) | +-- xDIF:SHDR -- sector header | +-- xDIF:SDAT -- sector data | +-- xDIF:SHDR -- sector header | +-- xDIF:SDAT -- sector data | ... for decoded discs. In the case of a "1 track, 1 block" format like, the encoded track would consist of a THDR, a TDAT and an INDX. If it was decoded (i.e. no IAM/DAM), it would consist of a THDR, and a single SHDR/SDAT pair, with sector=0 if the host machine had no concept of a sector. The order of the blocks in the file determines the interleave. Ideally this would also be described in the track header... -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

Anent all of this discussion, I'm sure that everyone's seen the HxC floppy emulator products: http://torlus.com/floppy/index.php?en What's interesting is that the USB model uses an Altera MAX7000S CPLD and 32K local SRAM and a FTDI USB-to-parallel chip. The claim is for 63K-1Mbps data rates. Given the buffer size, I'd say that there is darned little oversampling going on and that the datarate set on the emulator had better match the one on your system. A 16MHz clock is used on the MAX7000S. The standalone model uses a single PIC 18F series uC and an SD card (no external SRAM)--and runs with a 10MHz clock. The decoding is on- the-fly--there's only about 3900 bytes of RAM oin a PIC18F4525, so I'm guessing that it works sector-by-sector, so formats are probably fairly rigid. It's noteworthy that both emulators use fairly old technology. There are also $50-$300 Chinese-origin emulators available on eBay and other vendors which use a USB flash drive as storage. Thus far, I have not been able to get any meaningful technical information from the sellers. --Chuck

On Tue, 8 Dec 2009, Chuck Guzis wrote: Interesting, but since I have enough floppies and floppy drives until eternity I guess I won't ever need such an emulator. Christian

On 8 Dec 2009 at 18:12, Keith M wrote: I don't even do that with the AVR-based one. I set one of the counters to free-run in "capture" mode, where the edge of a pulse causes the contents of the timer to be latched into a register. I then store the difference between that count and the previous one, modulo 256. A very short loop with no program-dependent latencies. The AVRs also feature a 'noise filter" that drops any pulses less than 4 clocks wide. I've left the filter enabled, and it seems not to interfere with normal reading. Similarly, writing involves operating the timer in PWM mode. As long as the terminal count register is kept updated, everything works flawlessly. Most DSP chips also have timer capture mode, but can run the timers substantially faster that 16 or 20 MHz. --Chuck

Keith M wrote: That's still sampling. The time quantization is the resolution of the timer. Eric

On 12/9/09 8:40 AM, Keith M wrote: There is no need to record every value if it is only a binary signal, you can store the delta time to the next transition. This is the difference on a logic analyzer between 'state' and 'timing' modes. In 'state' mode, you sample and save every signal at each event. In 'timing' mode, a high resolution clock is used to measure the durations of each signal. The argument is how much accuracy is required to accurately describe the flux transition points in time, given the positional jitter introduced by the recording and playback mechanisms, and the distortion that occurs in the magnetic medium depending upon the pulse rate of the recording. Another problem is even though it is using saturation recording, the media may have flaws, or the head may clog due to shed, causing pulses to drop out. Data recovery has to cope with the fact there may be pulse dropouts, sometimes requiring the recovery program to 'wiggle' the head across tracks to try to rub the clog off of the heads.

On 12/9/09 11:01 AM, Chuck Guzis wrote: You probably have more experience with odd formats and using the Catweasel. Is there anything you've run into that couldn't be dealt with using the sample rates on that board? Did you ever experiment with the sampling rates on double-density data?

Al Kossow wrote: With my current implementation, I take that one step further, and process the delta T's within the hardware, to see if they fall in a particular range, and then store this equivalent RAW MFM data in the memory. And then transfer contents of memory (once bit aligned with the sync word, also in hardware) via USB to the PC. I understand where having the raw delta T's inside a PC/or something with more power, makes sense. My (limited) understanding was that timing mode you used a clock source internal(ie local oscillator) to the logic analyzer to determine when to sample --- it not synchronized with the DUT. And state mode was an external clock, synchronized with the clock present within the DUT, which told the LA when to sample. At least that's how I understood it. This is how I've used both my LAs... Thanks Keith

On 9 Dec 2009 at 11:40, Keith M wrote: Many uCs have at least an "interrupt on edge" on some of their I/O pins. Absent that, you need only hook up a flip-flop to toggle every time a pulse is received ("T" FF). Then your polling loop would look something like: waitforpulse: if pin == lastvalue then waitforpulse lastvalue = pin; That way, as long as your loop executes in less time than the minimum time between pulses, you won't miss any. --Chuck

Eric Smith wrote: So I split the difference with my bit-banged uart. :) I just constantly poll the data line until I see a start bit, and then count 1.5*bit_period instructions until I get to the middle of the first bit, and then my loop takes exactly 1 bit_period from read to read. Even at 2mbps, this works pretty good. I've done some testing with it, and it worked reliably sending almost 3 gigabits of traffic through it without a single bit error. I happen to only need to receive and transmit at particular times when the uC is sitting there doing nothing. Meaning I don't need to be interrupted...... My transmitting code works good too, although I ran into an interesting situation where MOVing a binary-0 to the port takes slightly more (or less? I forget) than MOVing a binary-1 to the port. MOV on my controller is just a mnemonic --- the actual machine code is made up of "skip next instructions", setb, and clrb....... This results in a couple clocks difference based on the data that needs transmitting. UARTs are forgiving enough, so there was no real issue, but interesting nonetheless. Since I have no formal training on this stuff, it's neat to compare my first attempt at things, and see how they differ from the "correct" or "most accepted" way of doing things. Sometimes, I'm right on the money. And most times, I'm WAY off. :) Keith

Philip Pemberton wrote: Foot, meet mouth. The current USB-enabled code runs to a shade under 7KB. Tack on a multi-mode bootloader (RS232/USB) and the RS232 firmware, and I doubt it'd eat much more than 16KB. There's also an onboard USART, so RS232 will most likely not be a problem (in hardware terms). In software terms... it doubles the amount of code required :-/ -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

Chuck Guzis wrote: The data separator has to deal with a lot more than just the variation in drive speed. That variation has long-term and short-term components, and it also has to deal with the bit shifting that isn't completely avoided by write precompensation. For many disks you can read adequately using the very simple software data separator techniques that have been described previously in this thread. However, for disks that are marginal in one way or another, the simple techniques will fail. Radio Shack customers found this out the hard way with the disk controller in the Model I expansion interface, and that wasn't even doing MFM. One of the advantages of sampling the pulses from the drive and saving the samples or delta times is that you can use data separation algorithms that would be impractical in a real floppy disk system. For instance, you can use non-causal algorithms (adjusting your separator based on future data in addition to past data), and based on information derived from other tracks of the same disk. When I was experimenting with this some years back, I found both techniques to be useful on problem disks. Eric

Al Kossow wrote: I was using a DPLL. For problem disks, I used measurements from tracks that read OK to tweak the DPLL parameters for tracks with issues, and that sometimes helped. The code was on a hard drive that crashed. :-( It wasn't very fancy code, and I hadn't spent all that much time on it, so I don't think it would be all that hard to recreate it. Eric

Chuck Guzis wrote: ISV = Instantaneous speed variation. I've read the primarily cause of it is jacket friction. Any other causes you know of? CSV = What's this one? Is it CONSTANT speed variation? Comma separated values keep ruining my google searches (Yes, I've tried -delimited in the search.) Is this the same as MSV, motor speed variation? I've seen ISV and MSV all over the place, but I don't think I've seen CSV.... I've spent quite some time coming up with some neat ideas regarding exactly this type of stuff. I have some stuff implemented, but others are just ideas swirling inside my head. Exactly! And this has been my goal from the beginning. Let me play devil's advocate. 8x500kbps would be 4mhz. Which means that your samples are every 250ns. But the pulses come from the drive are usually 250-300ns wide. _You could potentially miss one._ Now the pulse WIDTH is fixed and doesn't matter, so it's not like you need multiple samples per pulse, but I would just have to wonder about pulse placement accuracy. (ie when did that pulse really occur, did it happen at t=500ns, or t=750ns) Seems like a huge difference to me. The resolution of my timer is 40ns and I've had a fair bit of success with my reader. I'm not trying to imply my 40ns is the gold standard or anything, just pointing out that 40ns samples seem fine. Thanks Keith

On 9 Dec 2009 at 1:25, Keith M wrote: Continuous Speed Variation. See, for example: http://www.tecno.cl/archivos/0314SNY003_ing.pdf On 3.5" direct-drive units, I suspect that some of the ISV is motor noise, in particular "cogging". On belt-driven systems, ISV can arise from small eccentricities, belt defects, bearings, etc. in addition to frictional forces. Well, pulse width has no particular importance when you're reading a floppy; it's largely a function of the drive electronics. You are interested in the read pulse (leading) edges and their placement, however. The only way to miss a pulse is if two crowd into the same sampling period. With a 500KHz clock, that's not possible if your window is 250 usec. So an FM bit cell using a 500 KHz clock (i.e. 8" FM) is 4 usec and contains at most two transitions, one per 2 usec "half". At 4 MHz, each 2 usec "half" would be sampled 8 times, or 16 samples for the whole bit cell. That seems to be more than adquate. With MFM and a 500 KHz clock (8" MFM), the bit cell time decreases to 2 usec, but here is at most only one transition in that 2 usec cell, but the placement lies either at the start of the 2 usec cell or in the middle of it. So we still have 8 samples per cell, "good enough" for reading, I suspect. What do you think? Am I missing something important? --Chuck

Keith M wrote: Yes. If the system that wrote the disk is doing write precomp with reasonable values, the shifting should be relatively small, under 0.5 us. However, I've seen much more than that. (At least, I think I have. It was consistent enough and pattern-sensitive enough on some disks that I can't explain it by instantaneous speed variation.) Usually having 4 get close to 6 would indicate that the writing system was doing too much precomp. Note that the peak shifting varies with the head position; it's worse on the inner tracks because they have the highest linear bit density. (Same reason that 8" drives need reduced write current on tracks beyond 43.) The precomp is generally set based on an expectation of the inner track behavior, so it can be too much on the outer tracks. I've never found any useful published information beyond the data sheets and app notes for the FDC and data separator chips. Best regards, Eric

On Tue, Dec 8, 2009 at 04:44, Philip Pemberton <classiccmp at philpem.me.uk> wrote: Hi Phil, while of course I can't be sure for your school, in Academia the problem of copyright is only an issue if you plan to profit from your work (that was done using school resources and directed/verified/etc by school staff). If you release your work in an open manner it is part of the academic disclosure and should be available to anyone who asks. Note that this doesn't mean "free", in either libre or beer. Universities can charge fees for distributing copies of theses although most don't (for electronic copies), and if you have a copy, you can't redistribute it - just like a book. Any code can be a (electronic) appendix to a thesis. Here at McGill it has the effect (and possibly the intent) that a lot of work by profs is released with the GPL or BSD licences. As long as you don't rake in the money without the Uni getting a cut, they don't care how you publish it. Joe. -- Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem