Re: Rescuing old 5.25" disks

["Bryan Parkoff" <nospam@nospam.com>]

"Ben Rudiak-Gould" <br276deleteme@cam.ac.uk> wrote in message 
news:ehba5u$7gr$1@gemini.csx.cam.ac.uk...
> 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?
>
>>>>> 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.
>
>> 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.
>
> 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.)

Ben,

    There is a possibility if you develop Apple II Simulator rather than 
Apple II Emulator.  It allows to simulate sequence event out of 14,318,180 
clock cycle while each event responds to all functions including 14MHz, 
7MHz, 3.5MHz, 2MHz and 1MHz, video, 6502 MPU, Disk II, peripheral slots, and 
more.
    It is likely that slate machine of Woz will be simulated at 2MHz 
accurately.  Bit by bit image including copy-protection scheme will work.  I 
would predict that "Where in the World is Carmen?" has spiral scheme in 1/4 
track will work in Apple II Simulator.  It does the same with Bob Bishop's 
discovery of switching GRAHPICS/TEXT back and forth will work. (It is under 
my development.)
    I am aware that simulator is slower than emulator, but we have to live 
with this when we run at Pentium IV 3.8GHz or higher.  There are many ways 
to reduce un-needed x86 instructions and increase performance.  Apple II 
Simulator would run very well at fine speed (1-4 MHz).

Bryan Parkoff