Disc reader project -- quick status update

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/