[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rescuing old 5.25" disks

Ben Rudiak-Gould wrote:

Michael J. Mahon wrote:


Or don't worry about the fact that the image names are not ProDOS-
compatible names.  Images are generally used by emulators, or by
transfer programs that can present any "name" they want to an
attached or emulated Apple II.
What I'm worried about is disk-imaging tools that run on actual Apple II hardware. If you send the image over the serial port there's no problem, but if you save it to a local disk then your naming options are limited. 


An overall checksum is good, but we have managed for quite a while
without them.  In fact, most computer files don't have checksums,
though they may have internal consistency checks.

If you have random bit-flip errors, it's time to work on your
hardware, since computers (and their users  ;-) are completely
intolerant of such things.
I still think checksums are important for images of commercial software, and I wish I could more clearly articulate why. It's related to my background in functional programming, where there's a strong distinction drawn between mutable and immutable data. I similarly want to distinguish between canonical images of shipped commercial software on the one hand, and ordinary disks containing files created by individual users, on the other hand. In terms of physical disks, to a large extent this is just a matter of the presence or absence of a write-enable notch. But the write-enable notch is not merely advisory -- it's enforced by a hardware/firmware interlock. What I want is a similar interlock in the file format. Since it's all done in software it can't be perfect, but it can be made safe against everything short of active malice. Zipping or gzipping the image works because then, to silently modify it, you have to re-zip it afterwards, and it's simply impossible for that to happen by accident. Adding a checksum works also. Setting the OS read-only bit isn't as good, because that often isn't preserved in transfers between machines. Setting a bit in the file is nearly useless, because there's no enforcement.
So what I want, I guess, is simply to extend the write-protect bit in formats like 2mg by including a checksum if and only if the disk is write protected. Does that sound reasonable? 

How about just including a hash, and publishing a list of good hash's?

There's no other way to prevent a changed disk image from "masquerading"
as the original.
You don't need to simulate the full Woz machine, just add half track and quarter track seeking and update the data register at four-cycle intervals. 


But even that updating needs to be done in accordance with the
Woz state machine [...]
Implicit in my statement above was that the data register should be updated *correctly* at four-cycle intervals. [...] 


The shift register is *not* updated every four cycles.  The update time
depends on the state of the state machine. [...]
I know that. Let's get down to brass tacks. What I'm saying is that most of the complexity of Woz's state machine on the read side is there to deal with read pulses that may come in at any time. If you assume that read pulses come in at regular intervals of eight 2MHz cycles, then the machine is simplified from dozens of states down to just three. Namely: 

  state A:
    if input bit is 1
      go to state B
    otherwise
      remain in state A

  state B:
    data <- 2 + input bit
    go to state C

  state C:
    data <- data * 2 + input bit
      if data >= 128
        go to state A
      otherwise
        remain in state C
This state machine runs at 0.25 MHz. Its behavior precisely matches the original Woz machine, with one exception: the original takes 1.5 us to clear the data register and shift in two bits, so the data register will contain either 0 or 1 at 6502 cycle 4n, and the full two bits at cycle 4n+1. Otherwise, data register updates happen only at cycles numbered 4n.
So accurate emulation of the state machine is much simpler than emulating the whole state machine. Unless there's software that depends on the drive not being perfect, in which case I'm sure it would be sufficient to occasionally run the simplified state machine one cycle early or late. 

If a program "times" the arrival of data at the shift register,
then it could (conceivably) be sensitive to the extra time that
"high bit true" data is held.  Certainly, the next two bits appear
quite suddenly after the read window ends.

It's not that hard to emulate the actual timing, and it needs to be
done for longer-than-32-cycle nibbles in any case.


As for "updates" to a canonical format disk image, I think that we
should only have to have *one* universal standard, so everything
reasonable that might be done to it should be considered in its
design.  Tradeoffs come later.
How about this: the disk image is an ordered list of possibly overlapping partial-track write descriptors. When you write (part of) a track, you just append a new descriptor to the file. When you read a track, you recreate its contents by starting with a blank unformatted track and applying the relevant descriptors in order. You'd have to (K)runch the disk occasionally to keep it from growing too large. (Or you could let it grow, and have a persistent record of all previous states of the disk.) This is the best compromise I can think of between a compact read-only format and a convenient writable format. 

I know of no case (anyone?) where a program *writes* a partial track
that is not a (possibly modified) RWTS write, so it might be able to
be done "on the fly" with little trouble.

Many protected games write only to save "high scores".  ;-)
You could also use whole-track descriptors instead of partial-track descriptors. The disadvantage is that you couldn't simulate the corrupting effect of a write on adjacent half- and quarter- tracks without updating those tracks too. But really, is that ever going to matter? (I know I'll regret asking that.) 

That's the $64 question.  ;-)  But other methods will be needed to
get that information in any case.

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."