Let's develop an open-source media archive standard

Hi Sellam I can understand the need for both raw bit stream and extracted data. I propose that it should always include both types of information. The raw bits are needed to actually rebuild a particular format but often the information in the data is all that one needs to extract. In the case of the H8/89, we have working machines to read and write the format. We just need the data that fills the sectors. In the case of the H8/89, I've written a bootstrap that can be entered through the monitor commands. In some cases, the machine has no monitor or bootstrapping method. In these cases, it would be necessary to create the disk on another machine. Having the raw bits of clock and data would then be valuable. I'm currently looking at using a DSP chip to extract raw data from disk. The biggest problem so far is that one needs to do one of two things. One either needs to extract clocking operations with something like a PLL or simply oversample the bit stream from the drive. To do the PLL method, one needs to understand the disk format used and have hardware to handle that particular format. The oversampling has the advantage that one can capture all that is needed and post process it to normalize the data. The disadvantage here is that it takes a lot of data space. The DSP chip I'm looking at doesn't have enough RAM space to capture an entire track. Capturing track fragments has the issue that one needs realign things later. Knowing when the two fragments are properly connected is not easy. It looks like the newer DSP chips do have enough speed to capture raw data with little or no external hardware. This means that one can get one of the manufacture's development boards ( usually in the $50-$150 range ) and wire it up to the disk drive by connector. The disadvantage here is that as newer chips come out, the older development boards are obsoleted. Still, having the raw data means that one can recreate the disk in the future, with some effort. Dwight