Date : Thu, 14 May 2009 23:18:33 +0100
From : list-a_cloud9.bbc-micro@... (Theo Markettos)
Subject: Preservation of information (floppy discs, etc.)
In article <49FB672A.6040100@...> you wrote:
> My plan was to get the hardware running, document it, deal with the software
> as part of my university final-year project, then bully the Dean of School
> into signing a copyright release and release the whole thing as OSS/FS.
>
> Comments and criticism welcome at the usual address...
That sounds an interesting university project. I've supervised Cambridge
final year CS projects (25% of credit) and it's of about the right scale.
Some things to think about:
If you're intending this as an open source project, you should think
carefully about the hardware. You want to pick something that's easy for
people to use - either free (the parallel port, with a homemade cable - some
IO chips intended for laptops like the FDC37C669 have a floppy-over-parallel
mode, so it would make sense to copy that so you can use the same cable) or
cheap (some commodity microcontroller board/USB thing). Don't go using
something just because you happen to have one lying around.
Is there some way you can get this to work with PC hardware? How does
Disk2FDI do it?
What are you going to do about the 40T/80T conundrum? The heads on 40T
drives are twice the width of 80T heads. So if you read a 40T on an 80T
drive you get each track twice, while if you write you only write half the
width. A disc written in this way will have the old contents on each
half-track. Just read everything as 80T and write the same tracks twice?
(does that already happen on Beebs with 80T drives?)
As an extension, you could consider whether you want to try to cut out the
discriminator too. A normal FDD gives a binary bitstream, which is the
product of some analogue discriminator ('is this head signal a 0 or a 1?').
If you knew the discriminator was deciding it was a 0 because the signal was 49%
then you have less confidence in that bit than at 8%. Maybe that could
feature in your DSP? You'd need to tap off a signal earlier on in the drive
hardware (easier on an old drive where it's all discretes) and digitise it.
Presumably GCR would be coped with just fine - as long as the hardware can
cope with the highest bitrate then you just bang bits as appropriate. This
will need more accurate timing.
I notice something on Disk2FDI mentions something about drives returning a
'fake' index signal:
http://apple2.org.za/gswv/a2zine/Docs/Disk2FDI_InfoPostings.txt
Not sure how they would make a fake signal. Unless it's doing something
nasty like reading DOS sector numbers from the disc to save having a
photocell.
Theo